Tweet

必ずつながる！ 接続時トラブル虎の巻

パターン3：データベースまで届かないケース

　では、データベースまで届かないケースについて説明しましょう。

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

　再び接続を行うと、今までとは異なるエラーメッセージが表示されました。

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

　このメッセージは、test_nsnで指定した接続記述子の中のSERVICE_NAMEの値testdbがリスナーに登録されていないことを示しています。

　考えられる要因としては、

• test_nsnで指定した接続記述子中のSERVICE_NAMEの値testdbがリスナーに登録されているサービス名と一致しない
• リスナーが動的構成で、データベースが起動していない
• リスナーが動的構成でデータベースは起動しているが、初期化パラメータLOCAL_LISTENERで設定してあるアドレス情報が間違っているため、リスナーにデータベースサービスを登録することができていない
  

などです。test_nsnで指定した接続記述子中のSERVICE_NAMEの値testdbと、リスナーに登録されているサービス名が一致しないかどうかは、machine1上にてlsnrctl services listener1を実行すれば確認することができます。

% lsnrctl service listener1
 :
 サービスのサマリー…
 サービス"testdb.world"には1件のインスタンスがあります。
   インスタンス"testdb"、状態READYには、このサービスに対する1件の･･･
 :

　リスナーに登録されているデータベースサービス名は、testdb.worldでした。動的構成の場合、初期化パラメータSERVICE_NAMESの値がリスナーに登録されるデータベースサービス名となります。クライアントのtnsnames.oraでSERVICE_NAMEを使用する場合、その値とリスナーに登録されているデータベースサービス名の値を一致させる必要があります。

　今回の例では、初期化パラメータSERVICE_NAMESの値はtestdb.worldとなっていたため、リスナーにはtestdb.worldという名前でデータベースサービスが登録されていました。そのため、データベースサービス名とtnsnames.oraのSERVICE_NAMEが一致せず、ORA-12514が発生しました。

　よって、クライアントのtnsnames.oraのSERVICE_NAMEの値をtestdbからtestdb.worldに修正することで、ORA-12514の対処は完了です。

　補足として、次にORA-12514が発生するそのほかのケースを紹介します。

●リスナーが動的構成、かつデータベースが起動されていない場合

　リスナーが動的構成で、データベースが起動していない場合、データベースサービスの情報はリスナーには登録されません。そのためORA-12514が発生しますが、その場合は、データベースを起動させることでORA-12514は解消されます。今まで接続ができていたのにもかかわらず、急にORA-12514が発生した場合は、データベースが停止したことが原因で発生した可能性が考えられます。

　その場合、まずは以下の点を確認してください。

• リスナーを経由しないローカルでの接続を試みることでデータベースが停止しているかどうかを確認する
• アラートログを確認する
• リスナーログを確認する

　リスナーログは10gまではデフォルトで$ORACLE_HOME/network/log下に＜リスナー名＞.logという名前で作成されます。動的構成の環境でデータベースが停止した場合、リスト15のようにORA-12537と一緒にservice_diedが出力されます。

12-4月 -2009 16:24:00 * service_died * testdb * 12537  ←DB停止
13-4月 -2009 11:06:09 * service_register * testdb * 0  ←DB起動開始
13-4月 -2009 11:06:09 * service_update * testdb * 0
13-4月	-2009 11:06:36 * service_update * testdb * 0

　この出力例では、その後service_register、service_updateが出力されています。データベースサービスが「登録（register）」「更新（update）」されたときに出力されるもので、データベースが起動されたことが分かります。

　データベースのOPENが完了したかどうかについては、V$INSTANCEビューのSTATUS列が「OPEN」であることを確認するか、アラートログに「Completed: alter database open」が出力されていることを確認してください。

●リスナーが静的構成の場合

　静的構成でORA-12514が発生した場合は、データベースの停止が原因ではありません。データベースの起動や停止によって動的にデータベースの情報が登録・削除される動的サービス登録とは異なり、listener.oraにSID_LIST_＜リスナー名＞セクションを記述することで静的にデータベースサービスの情報を登録しているので、データベースが停止してもデータベースの情報がリスナーから消えることがないためです。

　そのため、静的構成でORA-12514が発生した場合は、クライアントのtnsnames.oraのネットサービス名で指定した接続記述子中のSERVICE_NAMEの値と、リスナーに登録されているサービス名が一致していないことが原因であると考えられます。

●リスナーが動的構成、かつデータベースが起動している場合

　リスナーが動的構成で、データベースは起動しているにもかかわらず、動的にデータベースサービスが登録されずにORA-12514が発生してしまう場合は、LOCAL_LISTENERで設定してあるアドレス情報が間違っているため、リスナーにデータベースサービスを登録することができない状況であると考えられます。

　lsnrctl statusコマンドで表示される“リスニング・エンドポイントのサマリー”部分のアドレス情報をLOCAL_LISTENERに設定すれば、データベースサービスの登録に成功し、ORA-12514は解消されます。

　よくあるケースとしては、LOCAL_LISTENERに何も値を設定せずに、リスナーのポート番号のみをデフォルトの1521からほかの番号に変えた場合が挙げられます。LOCAL_LISTENERに何も値が設定されていない場合でも、デフォルト値として“(ADDRESS=(PROTOCOL=TCP)(HOST=<ローカルホストのネットワーク名>)(PORT=1521))”が適用されています。

　そのためリスナーのポート番号を1521のままで運用している場合は、意識していなくても動的構成を使用することができてしまうのですが、ポート番号を1521から変更してしまうと、いままで使用できていた動的構成が使用できなくなってしまいます。その場合は、LOCAL_LISTENERの値をリスナーのアドレス情報に合わせて設定しなおすことで対処することができます。

●リスナーが動的構成、LOCAL_LISTENERも問題ない場合

　リスナーが動的構成で、データベースは起動しており、LOCAL_LISTENERの設定も問題ない状態でORA-12514が発生する場合は、データベースの起動より後にリスナーが起動された可能性が考えられます。

　データベースが起動している状態でリスナーを起動させると、すぐにはサービスは登録されません。PMON プロセスがサービスの登録を実行するのに1分程時間がかかるためです。そのため、リスナーが起動してから最初の1分ほどはORA-12514 が発生する場合があります。よくあるケースとして、データベースが起動している状態で、リスナーのみ再起動した場合があげられます。

　なお、リスナーが起動している状態でデータベースを起動する際は、PMONがデータベースの起動ステップに合わせて随時サービスの登録・更新を行なうので、サービスが登録されない状態は発生しないため、ORA-12514は発生しません。

パターン4：データベースまで届いたあとのケース

　最後に、リスナーに登録されたデータベースサービスまで届いたあとのケースを紹介します。

　ネットのエラーというわけではありませんが、接続時に発生するエラーとして、

　ORA-01017: ユーザー名/パスワードが無効です。ログオンは拒否されました。

というメッセージを見かける機会がよくあると思います。このメッセージは見てのとおり、ユーザー名もしくはパスワードが間違っている場合に発生します。

　このメッセージが出力される場合は、リスナーに登録されているデータベースには届いていることになり、データベースまで届いたあとの認証フェイズでエラーが発生したことになります。リスナーに登録されているデータベースサービスには届いていますので、リスナーログには、リスト16のように「establish 0」と出力されます。これは、リスナーまでは正常に接続できたことを示します。

13-4月 -2009 10:59:58 * ･･･ * establish * testdb * 0

　そのほか、認証フェイズで時間がかかってしまうと“ORA-03136: インバウンド接続がタイムアウトになりました”が発生するケースもあります。このようなエラーの場合、Netのトレースを取得して調査をするケースもあり、原因調査が難解になります。

1つ1つ原因を探れば必ず接続できる！

　いかがでしたでしょうか。データベースに接続するためには、まずはデータベースサーバまでリクエストが届き、次にそのデータベースサーバ上で起動しているリスナーまで届き、さらにリスナーが認識（登録）しているデータベースサービスまで届く必要があります。

　1つ1つ理解しながらローカル・ネーミングの構成を行えば、Netの設定はそれほど難しいものではありません。また、接続時にエラーが発生した場合でも素早く問題の切り分けを行うことができるようになります。本記事が、少しでも皆さんの運用のお役に立てれば幸いです。

　今回をもって、連載記事「Oracleトラブル対策の基礎知識」は終了となります。2008年6月から約1年間、連載で記事を掲載させていただきました。ご高覧いただきました皆様、誠にありがとうございました。システムは、構築したあと、運用が始まって初めて真価を発揮します。トラブルが発生した際に解決することは大事ですが、それを踏まえて、トラブルが発生しない様に予防保守対策を施しておくことはさらに重要です。

　さまざまなサイトで使用されているOracleデータベース、そのシステムを運用されている皆様に、本連載記事で少しでもお役に立てることができたなら、大変うれしく思います。

4/4

Index
必ずつながる！ 接続時トラブル虎の巻
	Page 1 Oracleにつながらない？！ ローカル・ネーミングの構成 パターン1：データベースサーバまで届いていないケース
	Page 2 パターン2：リスナーまで届いていないケース
	Page 3 リスナーの構成 “DBビル”で例えると
	Page 4 パターン3：データベースまで届かないケース データベースまで届いたあとのケース パターン4：データベースまで届いたあとのケース 1つ1つ原因を探れば必ず接続できる！

Oracleトラブル対策の基礎知識

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）

RSSフィード