ORA-12541「TNS:リスナーがありません」の原因と対処法｜sqlplusは繋がるのにアプリだけ接続不可

公開日 2026/6/2 最終更新日 2026/8/15

「アプリから DB に繋がらない」という連絡が来た。
確認しようと DB サーバに SSH して sqlplus / as sysdba を叩くとあっさり繋がる。
DB は稼働している。なのにアプリからは繋がらない…。

この「直接ログインは可能なのに TNS 接続だけ失敗する」という症状、原因はリスナーの停止かもしれません。今回は ORA-12541（TNS:no listener）の調査手順と復旧方法を実機ログとともに解説します。
あわせて、リスナー停止以外の原因も含めた ORA-12541 の原因パターンを一覧で整理します。

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
------------
OPEN

DB 自体は OPEN 状態で稼働しています。

2. 原因の仕組み

Oracle への接続方式は大きく2つあります。

接続方式	コマンド例	リスナー使用
BEQ（ローカル IPC）	`sqlplus / as sysdba`	使わない
TNS（TCP/IP）	`sqlplus user/pass@host:port/service`	使う

BEQ（Bequeath）はプロセス間通信（IPC: Inter-Process Communication）を使って直接 Oracle プロセスに接続するため、リスナーが停止していても接続できます。一方、TNS 接続はクライアントがまずリスナー（デフォルトポート 1521）に接続し、リスナーが接続先のサーバプロセスに転送する仕組みになっています。リスナーが停止していると、この転送ができないため ORA-12541 が返ります。

つまり、「直接ログインは可能なのに TNS 接続だけ失敗する」という症状のとき、最初に疑うべきはリスナーの停止です。

3. ORA-12541 の原因パターン一覧

ORA-12541 は「クライアントが接続しに行った先（ホストとポート）で、リスナーが応答しなかった」ことを示すエラーです。
サーバ側でリスナーが停止している場合だけでなく、接続しに行く先そのものがずれている場合にも発生します。

原因は次の6パターンに整理できます。
6パターンと、後述する切り分け表の各エラーは、いずれも実機（Oracle Database 19c・Oracle Linux 8.9）で再現して確認したものです。

#	原因パターン	起きやすい場面
1	リスナーが停止している	計画停止後の起動忘れ・OS 再起動後（自動起動が未設定）・プロセスの異常終了
2	リスナーが起動に失敗している	listener.ora の記述誤り
3	ポートが一致していない	1521 以外のポートで待ち受ける構成・接続文字列のポート誤記
4	接続先ホストの指定誤り	サーバ移行後に接続設定が旧サーバを向いたまま・ホスト名の書き間違い
5	リスナーが別の IP アドレスで待ち受けている	複数 NIC のサーバで、待受と接続経路のネットワークが合っていない
6	ファイアウォールが接続を拒否している	入れ替え後の新サーバで 1521 番ポートの許可が漏れている・ファイアウォールの設定変更で誤って遮断した

切り分けの入口はどのパターンでも同じで、DB サーバで lsnrctl status を実行することです。
リスナーが停止していればパターン1・2（停止したまま・起動に失敗）、稼働しているのに ORA-12541 が出るならパターン3〜6（接続しに行く先のずれ・経路の遮断）を疑います。

パターン1: リスナーが停止している

最も多いパターンです。
計画停止後の起動忘れ、OS 再起動後にリスナーの自動起動が設定されていない、リスナープロセスの異常終了などで起きます。

正常に稼働していれば、lsnrctl status の出力（関連行のみ抜粋）は次のようになります。

$ lsnrctl status
...
開始日                    03-8月 -2026 12:32:37
稼働時間                  1 日 3 時間 0 分 56 秒
...
リスニング・エンドポイントのサマリー...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=db-node)(PORT=1521)))
...
サービス"v11c19u"には、1件のインスタンスがあります。
  インスタンス"v11c19u"、状態READYには、このサービスに対する1件のハンドラがあります...
コマンドは正常に終了しました。

見るべきは3点です。
稼働時間（起動してからの経過時間）、リスニング・エンドポイント（待受の HOST と PORT）、そしてサービスの登録状態（状態 READY）が表示されていれば、リスナーは稼働しています。

停止していれば、同じコマンドが TNS-12541 のエラーを返します（停止時の出力例は次章の Step 1 に掲載しています）。
このパターンの調査から復旧までの流れは、次章「実機検証」で実機ログとともに解説します。

パターン2: リスナーが起動に失敗している

起動したつもりでも、listener.ora の記述誤りなどで起動に失敗しているケースです。
lsnrctl start の出力に TNS 系のエラーメッセージが出ていないかを確認します。
起動に失敗した理由はリスナーログ（listener.log）にも記録されます。

実機では、HOST に解決できないホスト名が残った状態（サーバのホスト名・IP アドレス変更後を想定）で起動を試みると、次のエラーで失敗しました。

$ lsnrctl start
...
リスニング・エラーです: (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=nosuchhost)(PORT=1521)))
TNS-12545: 接続に失敗しました。ターゲット・ホストまたはオブジェクトが存在しません。
 TNS-12560: TNS: プロトコル・アダプタ・エラー
  TNS-00515: 接続に失敗しました。ターゲット・ホストまたはオブジェクトが存在しません。
   Linux Error: 11: Resource temporarily unavailable

リスナーが起動に失敗しました。前述のエラー・メッセージを参照してください...

この状態でクライアントが接続すると、リスナー不在のため ORA-12541 になります。

パターン3: ポートが一致していない

リスナーは正常に稼働しているのに、クライアントが別のポートへ接続しに行っているケースです。
デフォルトの 1521 以外で運用している環境で、接続文字列側にポートの指定漏れ・誤記があると発生します。

実機では、リスナーが 1521 で正常稼働している状態のまま、存在しないポート 1526 へ接続すると再現しました。

$ sqlplus system/oracle@localhost:1526/v11c19u

ERROR:
ORA-12541: TNS: リスナーがありません

リスナー自体は正常でも、ポートがずれているだけで「リスナーがありません」になります。
lsnrctl status に表示される待受アドレスの PORT と、接続文字列（または tnsnames.ora）の PORT を突き合わせて確認します。

パターン4: 接続先ホストの指定誤り

tnsnames.ora や接続文字列の HOST が、リスナーの稼働していないサーバを向いているケースです。
向いた先のサーバが「接続拒否」を返してくる状態（稼働中で、ファイアウォールに遮断されていない）であれば、ORA-12541 になります。
一方、向いた先のサーバが停止していたり、ファイアウォールに遮断されていたりすると、ORA-12541 ではなく ORA-12543 やタイムアウトになります（後述の「似たエラーとの切り分け」の表を参照）。

サーバ移行後に接続設定が旧サーバを向いたままになっている、という形で起きがちです。
クライアント側の出力はポート不一致の場合と同じ ORA-12541 のため、エラーメッセージからはポート違いと区別できません。
tnsnames.ora の HOST が現在の DB サーバを指しているかを確認します。

パターン5: リスナーが別の IP アドレスで待ち受けている

業務 LAN と管理 LAN を分けている環境など、サーバが複数のネットワークに接続している構成で起きるパターンです。
例えば、リスナーが業務 LAN 側の IP だけで待ち受けているサーバに、管理 LAN 側の IP で接続しに行くと ORA-12541 になります。

リスナーは listener.ora の HOST に指定した名前・IP アドレスで待ち受けます。
実機（本検証環境の 19c）で確認すると、HOST の書き方で待受の範囲が変わりました。

HOST にホスト名を指定 → 全 IP アドレスで待ち受ける（OS 上の表示は *:1521）
HOST に IP アドレスを明示 → その IP だけで待ち受ける（OS 上の表示は 10.0.10.11:1521 のような限定表示）

後者の構成で実機再現した出力です。
待受は 10.0.10.11 に限定されています。

$ ss -ltn | grep 1521
LISTEN 0      128       10.0.10.11:1521       0.0.0.0:*

この状態で、待受と別の NIC の IP（192.168.30.11）へ接続すると、リスナーは稼働しているのに ORA-12541 が返ります。

$ sqlplus system/oracle@192.168.30.11:1521/v11c19u

ERROR:
ORA-12541: TNS: リスナーがありません

待受側の IP（10.0.10.11）へ接続すれば、同じリスナーで正常に接続できます。
OS レベルの待受アドレスを ss -ltn | grep 1521 で確認し、クライアントが接続しに行く IP アドレスと突き合わせます。

パターン6: ファイアウォールが接続を拒否している

経路上のファイアウォールや OS のファイアウォール（firewalld 等）が 1521 番ポートを遮断している場合も、クライアントから見るとリスナー不在と同じ見え方になります。
実機で遮断のしかたを変えて確認したところ、エラー番号は次のように分かれました。

遮断のしかた	クライアントのエラー（実測）	返り方
拒否（「このポートは受け付けない」と応答を返す）	ORA-12541	即時
拒否（「このホストへは通さない」と応答を返す）	ORA-12543	即時
破棄（何も応答を返さない・DROP）	ORA-12170（接続タイムアウト）	長い待ちの後

2つの「拒否」の違いは、ファイアウォールが返す拒否応答の単位です。
「このポートは受け付けない」というポート単位の拒否応答だと、クライアントからは「ホストには届いたが、そのポートに誰もいない」＝リスナー停止と同じ見え方になるため、ORA-12541 になります。
「このホストへは通さない」というホスト単位の拒否応答だと、クライアントからは「ホストにそもそも到達できない」＝サーバ停止と同じ見え方になるため、ORA-12543 になります。
どちらの応答を返すかは、ファイアウォール製品や設定によって異なります。
遮断ルールがポート指定かホスト指定かで決まるわけではなく、同じ「1521 番ポートを遮断する」ルールでも、応答の種類の設定によって ORA-12541 にも ORA-12543 にもなり得ます。
そのため、エラー番号から「ポートの制限か、ホストの制限か」を逆算して決めつけることはできません。
いずれの場合もリスナー側は正常です。

どの遮断のされ方かは、OS レベルの接続テストで切り分けられます。
bash の /dev/tcp 機能を使うと、sqlplus を介さずに素の TCP 接続の結果が見えます。

コマンドの意味を分解すると、次のとおりです。

bash には、/dev/tcp/<ホスト>/<ポート> という書き先へリダイレクトすると、そのホストのポートに TCP 接続を試みる機能があります（実ファイルではなく bash の内部機能です）
echo > /dev/tcp/127.0.0.1/1521 で「127.0.0.1 の 1521 番ポートへ接続する」という意味になります
先頭の timeout 5 は、応答が返らない（破棄されている）場合に 5 秒で打ち切るための保険です

telnet や nc がインストールされていないサーバでも、bash さえあれば実行できます。

$ timeout 5 bash -c 'echo > /dev/tcp/127.0.0.1/1521'
bash: connect: 接続を拒否されました

「接続を拒否されました」ならポート単位の拒否（ORA-12541 側）、「ホストへの経路がありません」ならホスト単位の拒否（ORA-12543 側）、何も表示されずタイムアウトすれば破棄（ORA-12170 側）です。

サーバ入れ替えやファイアウォールの設定変更の直後から発生し始めた場合に疑います。
OS のファイアウォール設定（firewalld なら firewall-cmd --list-all）と、経路上のファイアウォールの設定を確認します。

似たエラーとの切り分け

ORA-12541 の前後でよく登場する TNS 系エラーとの見分け方です。
どのエラーが返るかで、接続処理のどの段階で失敗したかを絞り込めます。
いずれも実機で再現して確認したものです。

接続処理は上から下へ4段階で進み、失敗した段階ごとにエラー番号が対応します。

① 接続先の情報を解決する（クライアント内）
      │ エントリ名を tnsnames.ora 等で引けない → ORA-12154
      │ エントリ内ホスト名の名前解決に失敗 → ORA-12545
      ▼
② 接続先ホストに到達する（ネットワーク）
      │ 到達できない → ORA-12543（即時）／ ORA-12170（応答がなくタイムアウト）
      ▼
③ リスナーに接続する（ポート 1521）
      │ 接続を拒否される → ORA-12541 ★本記事
      ▼
④ リスナーがサービスへ転送する
      │ サービス名が未登録 → ORA-12514
      ▼
   接続成功

各エラーの意味と、最初に確認する場所は次のとおりです。

エラー	失敗した段階	最初に確認する場所
ORA-12154	① 接続識別子を解決できない（未定義のエントリ名。`@ホスト名:ポート/サービス名` 直接指定でホスト名が解決できない場合も実測ではこれ）	クライアントの tnsnames.ora・TNS_ADMIN
ORA-12545	① tnsnames.ora エントリ内の HOST が解決できない	エントリの HOST・DNS / hosts ファイル
ORA-12543	② 接続先ホストに到達できない（ホスト停止・ファイアウォールの到達禁止応答）	接続先サーバの稼働状態・経路
ORA-12170	② 接続先から応答がなくタイムアウト（ファイアウォールの破棄など）	ネットワーク経路・ファイアウォール
ORA-12541（本記事）	③ ホストには届くが、接続が拒否される（リスナー不在・ポート違い）	サーバのリスナー状態・ポート指定
ORA-12514	④ リスナーは応答したが、要求されたサービス名が未登録	サービス登録の状態（`lsnrctl status`）・SERVICE_NAME

なお「名前解決の失敗」は、接続文字列の書き方でエラー番号が変わります。
実機では、@ホスト名:ポート/サービス名 の直接指定でホスト名が解決できない場合は ORA-12154、tnsnames.ora のエントリ経由でエントリ内の HOST が解決できない場合は ORA-12545 になりました。

4. 実機検証：リスナー停止を再現して調査・復旧する

原因パターンのうち最も多い「パターン1: リスナーの停止」を実機で再現し、調査から復旧までの流れを確認します。
検証環境は Oracle Database 19c（19.28 RU）・Oracle Linux 8.9 のシングル構成（Grid Infrastructure なし）です。

Step 1: lsnrctl status でリスナーの状態を確認する

まず、lsnrctl status でリスナーが動いているかを確認します。

$ lsnrctl status
TNS-12541: TNS: リスナーがありません。
 TNS-12560: TNS: プロトコル・アダプタ・エラー
  TNS-00511: リスナーがありません。
   Linux Error: 111: Connection refused

TNS-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 * 0

lsnrctl stop が実行されたタイムスタンプが確認できます。計画外の停止であれば、その時刻前後に何があったかをサーバのログや操作履歴と照合します。

Step 3: アラートログで DB の状態を確認する

リスナーが停止していても DB 自体は稼働しています。アラートログを確認し、DB が正常に稼働していることを確認します。

$ tail -30 ${ORACLE_BASE}/diag/rdbms/${ORACLE_SID}/${ORACLE_SID}/trace/alert_${ORACLE_SID}.log

shutdown や 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.ora

listener.ora の確認ポイント

項目	確認内容
`HOST`	サーバのホスト名または IP アドレスと一致しているか
`PORT`	クライアントが接続しているポート（デフォルト 1521）と一致しているか

tnsnames.ora の確認ポイント

項目	確認内容
`HOST`	リスナーが稼働しているホスト名または IP と一致しているか
`PORT`	listener.ora の PORT と一致しているか
`SERVICE_NAME`	`lsnrctl status` で表示されるサービス名と一致しているか

Step 5: リスナーを起動する

$ lsnrctl start

起動直後は「リスナーはサービスをサポートしていません」と表示されます。これはリスナーは起動したが、サービスがまだ登録されていない状態です。

起動直後の ORA-12514 に注意する

lsnrctl start 直後に TNS 接続を試みると ORA-12514 が返ることがあります。

ERROR:
ORA-12514: TNS:
リスナーは接続記述子でリクエストされたサービスを現在認識していません

ORA-12541（リスナーが停止）とは別物です。リスナーは動いているが、LREG（Listener Registration Process）によるサービス登録がまだ完了していない状態を指します。LREG は約60秒間隔で自動的にサービスを登録するため、しばらく待てば接続できるようになります。
なお、サービス登録は 11g までは PMON が担っていましたが、12c 以降は専任のバックグラウンドプロセス LREG が行います（実機でも ps -ef で ora_lreg_<SID> プロセスを確認できます）。

今回の実機検証では lsnrctl start から約58秒後に登録が完了し、その後の TNS 接続が成功しました。

すぐに接続したい場合は alter system register

待てない場合は以下のコマンドで LREG によるサービス登録を即時実行できます。

$ 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; を使うことで LREG によるサービス登録を即時実行できます。リスナーを起動後、sqlplus / as sysdba から実行してください。

SQL> alter system register;

Q: サーバ側とクライアント側、どちらから調べるべきですか？

A: DB サーバにログインできるなら、まず DB サーバで lsnrctl status を実行します。
停止していた場合は、リスナーを起動すれば復旧します。
リスナーが正常稼働しているのに ORA-12541 が出る場合は、クライアントが接続しに行った先がリスナーの待受と合っていません。
接続文字列・tnsnames.ora の HOST と PORT を、lsnrctl status の待受アドレスと突き合わせてください。

Q: Grid Infrastructure（Oracle Restart・RAC）環境でも調べ方は同じですか？

A: 入口の確認（リスナーが応答しているか）は同じです。
ただし、GI 環境ではリスナーは GI の管理リソースとして動作しているため、起動・停止と稼働状態の確認には srvctl を使います（srvctl status listener / srvctl start listener）。
srvctl で分かるのは「リソースとして起動しているか・どのノードで動いているか」までで、サービスの登録状態は GI 環境でも lsnrctl status で確認します（リスナーが動作している grid ユーザーで実行します）。
本記事の実機検証は GI なしのシングル構成で行っています。

6. まとめ

ORA-12541 は「接続しに行った先でリスナーが応答しない」エラーです。
サーバ側のリスナー停止が最も多い原因ですが、「ORA-12541 の原因パターン一覧」の章で整理したとおり、接続先ホスト・ポートの指定ずれや、待受アドレスの不一致、ファイアウォールでも発生します。
「直接ログインは可能」という症状が添えられていたら、まずリスナーの状態を確認してください。

ORA-12541 対応フロー

TNS接続で ORA-12541
        │
        ▼
DBサーバで lsnrctl status を実行
        │
        ├─ リスナー停止 → lsnrctl start で起動
        │        │
        │        ├─ 起動直後に ORA-12514 が出る場合
        │        │    → しばらく待つ（約60秒）
        │        │      または alter system register; を実行
        │        │    │
        │        │    ▼
        │        │  TNS 接続成功 → 復旧完了
        │        │
        │        └─ 起動に失敗する場合
        │             → lsnrctl start のエラー内容と
        │               listener.ora の記述を確認
        │
        └─ リスナー稼働中 → 接続しに行く先のずれを疑う
                 ├─ 接続文字列 / tnsnames.ora の HOST・PORT
                 ├─ lsnrctl status の待受アドレス（HOST・PORT）
                 └─ 経路上・OS のファイアウォール

タグ

ORA-12541

Oracle Database

TNS

トラブルシューティング

リスナー