web-dev-qa-db-ja.com

断続的なORA-12519(TNS:適切なハンドラが見つかりません)エラーの原因

Oracle 10データベースの前でWeblogic 9に対してJunit 4テストスイートを実行し(Hudsonを継続的統合サーバーとして使用)、スクリプトの分解中にORA-12519クラッシュが発生する場合があります。ただし、エラーは非常に断続的です。

  • 通常、同じテストクラスで発生します
  • 同じテストケースで常に発生するわけではありません(合格する場合もあります)
  • 同じ数のテストケースでは発生しません(3〜9のどこでも)
  • 時にはそれがまったく起こらない、すべてが通過する

これがローカルで発生しないことを保証することはできませんが(もちろん、同じデータベースに対して実行する場合)、同じクラスのスイートを問題なく複数回実行しました。

何か案は?

41
cynicalman

これが全員の答えになるかどうかはわかりませんが、掘り下げた後、私たちが思いついたのは次のとおりです。

このエラーは明らかにリスナーが接続を受け入れていないという事実によって引き起こされますが、他のテストで問題なく接続できる場合にエラーが発生するのはなぜですか(sqlplusでも問題なく接続できます)?問題の鍵は、接続できなかったことではなく、断続的

いくつかの調査の後、クラスのセットアップ中に作成された静的データがあり、テストクラスの存続中は接続を開いたままにして、新しいデータを作成することがわかりました。現在、このクラスがスコープ外になったときに(もちろん、finally {}ブロックを介して)すべてのリソースが適切に解放されましたが、実行中にこのクラスが使用可能なすべての接続を飲み込む場合がありました(大丈夫、悪いプラクティスアラート-これはプールを使用するのではなく直接接続されたユニットテストコードであるため、本番環境では同じ問題は発生しませんでした)。

修正点は、そのクラスを静的にせずにクラスのセットアップで実行するのではなく、メソッドごとのsetUpおよびtearDownメソッドで使用することでした。

自分のアプリでこのエラーが発生した場合は、その悪い男の子にプロファイラーを叩き、接続リークがあるかどうかを確認してください。それが役に立てば幸いです。

39
cynicalman

同様のエラーを発見した別の解決策ですが、同じエラーメッセージは、見つかったサービスハンドラの数を増やすことです。 (このエラーの私のインスタンスは、Weblogic Portal接続プールの接続が多すぎることが原因でした。)

  • SQL*Plusを実行し、SYSTEMとしてログインします。 Oracle DB XEのインストール中に使用したパスワードを知っている必要があります。
  • SQL * Plusでコマンドalter system set processes=150 scope=spfile;を実行します
  • 非常に重要:データベースを再起動します。

ここから:

http://www.atpeaz.com/index.php/2010/fixing-the-ora-12519-tnsno-appropriate-service-handler-found-error/

26
edwardsmatt

私も同じ問題を抱えていました。多くの場所で答えを探しました。プロセス/サービスハンドラーの数を変更するために、同様の多くの回答を得ました。しかし、リセットするのを忘れたらどうなるでしょうか?

次に、各Thread.sleep()の後にconnection.close();メソッドを使用してみました。

方法はわかりませんが、少なくとも私にとっては機能しています。

誰かがそれを試して、それがどのように機能するかを理解したいなら、先に進んでください。私はプログラミングの世界の初心者なので、それも知りたいです。

3

接続プールを介してDBへの多くの接続を開き、各テストの終了時に接続を解放するために接続プール(実際にはManagedDataSource)を「停止」した単体テストでこの問題が発生しました。テストスイートのある時点で、常に接続が不足していました。

テストのteardown()にThread.sleep(500)を追加し、これにより問題が解決しました。起こっていたことは、接続プールのstop()が別のスレッドのアクティブな接続を解放し、メインスレッドがテストを実行し続けると、クリーンアップスレッドがはるかに遅れてOracleサーバーが接続を使い果たしたためだと思います。スリープを追加すると、バックグラウンドスレッドがプールされた接続を解放できます。

これは、DBサーバーがはるかに大きく、操作の健全な組み合わせ(無限のDB接続/切断操作だけでなく)があるため、現実の世界ではそれほど問題ではありません。

1
Andrew McGregor

同様の問題がありました。 SpringJUnit4ClassRunnerを使用してデータベース(Spring JDBC)テストのパックを実行するたびに発生したため、アプリケーションコンテキストをクリーンアップしてすべてのリソースを解放するために、各テストに@DirtiesContextアノテーションを付ける問題を解決しました各テストは、アプリケーションコンテキストの新しい初期化で実行できます。

1
Shendor