「アプリから DB に繋がらない」という連絡が来た。
確認しようと DB サーバに SSH して sqlplus / as sysdba を叩くとあっさり繋がる。
DB は生きている。なのにアプリからは繋がらない…。
この「直接ログインは可能なのに TNS 接続だけ失敗する」という症状、原因はリスナーの停止かもしれません。今回は ORA-12541（TNS:no listener）の調査手順と復旧方法を実機ログとともに解説します。
目次
1. 症状
TNS 接続（@ホスト:ポート/サービス名）を試みると ORA-12541 が返ります。
$ sqlplus system/oracle@localhost:1521/v11c19u
ERROR:
ORA-12541: TNS: リスナーがありません一方、BEQ 接続（sqlplus / as sysdba）はリスナーを使わないため、引き続き接続できます。
$ sqlplus / as sysdba
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.28.0.0.0
に接続されました。
SQL> select status from v$instance;
STATUS
------------
OPENDB 自体は OPEN 状態で稼働しています。
2. 原因の仕組み
Oracle への接続方式は大きく2つあります。
| 接続方式 | コマンド例 | リスナー使用 |
|---|---|---|
| BEQ（ローカル IPC） | sqlplus / as sysdba | 使わない |
| TNS（TCP/IP） | sqlplus user/pass@host:port/service | 使う |
BEQ はプロセス間通信（IPC）を使って直接 Oracle プロセスに接続するため、リスナーが停止していても接続できます。一方、TNS 接続はクライアントがまずリスナー（デフォルトポート 1521）に接続し、リスナーが接続先のサーバプロセスに転送する仕組みになっています。リスナーが停止していると、この転送ができないため ORA-12541 が返ります。
つまり、「直接ログインは可能なのに TNS 接続だけ失敗する」という症状はリスナー停止の典型的なサインです。
3. 調査手順
Step 1: lsnrctl status でリスナーの状態を確認する
まず、lsnrctl status でリスナーが動いているかを確認します。
$ lsnrctl status
TNS-12541: TNS: リスナーがありません。
TNS-12560: TNS: プロトコル・アダプタ・エラー
TNS-00511: リスナーがありません。
Linux Error: 111: Connection refusedTNS-12541 が返ればリスナーが停止しています。
Step 2: listener.log でいつ停止したかを確認する
listener.log にはリスナーの起動・停止・接続のタイムスタンプが記録されています。停止した時刻を確認します。
$ tail -50 ${ORACLE_BASE}/diag/tnslsnr/$(hostname)/listener/trace/listener.log
...
07:58:40 リスニングしていません: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)...))
Listener completed notification to CRS on stop
07:58:40 (COMMAND=stop) * stop * 0lsnrctl stop が実行されたタイムスタンプが確認できます。計画外の停止であれば、その時刻前後に何があったかをサーバのログや操作履歴と照合します。
Step 3: アラートログで DB の状態を確認する
リスナーが停止していても DB 自体は生きています。アラートログを確認し、DB が正常に稼働していることを確認します。
$ tail -30 ${ORACLE_BASE}/diag/rdbms/${ORACLE_SID}/${ORACLE_SID}/trace/alert_${ORACLE_SID}.logshutdown や ORA エラーのエントリがなければ DB は正常稼働中です。lsnrctl stop 自体は DB を停止させません。
Step 4: ネットワーク設定ファイルを確認する
リスナーが設定ミスで起動できていない場合も ORA-12541 が発生します。listener.ora と tnsnames.ora を確認し、ホスト名・ポート・SERVICE_NAME に誤りがないかを確認します。
$ cat ${ORACLE_HOME}/network/admin/listener.ora
$ cat ${ORACLE_HOME}/network/admin/tnsnames.oralistener.ora の確認ポイント
| 項目 | 確認内容 |
|---|---|
HOST | サーバのホスト名または IP アドレスと一致しているか |
PORT | クライアントが接続しているポート（デフォルト 1521）と一致しているか |
tnsnames.ora の確認ポイント
| 項目 | 確認内容 |
|---|---|
HOST | リスナーが稼働しているホスト名または IP と一致しているか |
PORT | listener.ora の PORT と一致しているか |
SERVICE_NAME | lsnrctl status で表示されるサービス名と一致しているか |
4. 復旧手順
リスナーを起動する
$ lsnrctl start起動直後は「リスナーはサービスをサポートしていません」と表示されます。これはリスナーは起動したが、サービスがまだ登録されていない状態です。
ORA-12514 に注意する
lsnrctl start 直後に TNS 接続を試みると ORA-12514 が返ることがあります。
ERROR:
ORA-12514: TNS:
リスナーは接続記述子でリクエストされたサービスを現在認識していませんORA-12541（リスナーが停止）とは別物です。リスナーは動いているが、PMON によるサービス登録がまだ完了していない状態を指します。PMON は約60秒間隔で自動的にサービスを登録するため、しばらく待てば接続できるようになります。
今回の実機検証では lsnrctl start から約58秒後に登録が完了し、その後の TNS 接続が成功しました。
すぐに接続したい場合は alter system register
待てない場合は以下のコマンドで PMON によるサービス登録を即時実行できます。
$ sqlplus / as sysdba
SQL> alter system register;実行後、再度 TNS 接続を試みてください。
5. Q&A
Q: sqlplus / as sysdba は繋がるのに TNS 接続だけ失敗するのはなぜですか？
A: sqlplus / as sysdba はローカル IPC（BEQ）を使って Oracle プロセスに直接接続するため、リスナーを介しません。一方、@ホスト:ポート/サービス名 形式の TNS 接続はリスナー経由のため、リスナーが停止していると失敗します。「直接ログインは可能」という症状はリスナー障害の典型的なサインです。
Q: ORA-12541 と ORA-12514 は何が違いますか？
A: 以下の通りです。
| エラー | 意味 | 主な原因 |
|---|---|---|
| ORA-12541 | リスナー自体が停止している | lsnrctl stop 後・プロセスクラッシュなど |
| ORA-12514 | リスナーは動いているがサービスが未登録 | リスナー再起動直後・サービス名の不一致 |
ORA-12514 はリスナー再起動直後の一時的な状態として発生することが多く、混同しないことが重要です。
Q: lsnrctl start 直後にすぐ TNS 接続したい場合は？
A: alter system register; を使うことで PMON によるサービス登録を即時実行できます。リスナーを起動後、sqlplus / as sysdba から実行してください。
SQL> alter system register;6. まとめ
ORA-12541 はリスナーの停止が原因で、lsnrctl start で復旧できます。「直接ログインは可能」という症状が添えられていたら、まずリスナーの状態を疑ってください。
ORA-12541 対応フロー
TNS接続で ORA-12541
│
▼
lsnrctl status でリスナー状態を確認
│
リスナー停止？
├─ YES → lsnrctl start で起動
│ │
│ ▼
│ 起動直後に ORA-12514 が出る場合
│ → しばらく待つ（約60秒）
│ または alter system register; を実行
│ │
│ ▼
│ TNS 接続成功 → 復旧完了
│
└─ NO → listener.ora / tnsnames.ora の設定を確認
サービス名・ホスト名・ポートの誤りがないかを確認
