RAC突然、警告、接続しようとすると、クライアントが報告されます。ORA-12520：TNS：リスナーがサーバーエラーの要求タイプに使用可能なハンドラを見つけることができませんでした。
さて、その後の出会いでこの問題を迅速に処理するために決済処理を終了します。
サーバーにログインしますが、SYSDBAとしてSQLPLUS /を使用すると、データベースへのアクセスを見つけることができます。
ORA-00020：プロセスの最大数（2000）を超え、それによってプロセスの数を決定する超である2アラート・ログをチェックし、ログにエラーメッセージを発見しました。
アラート・ログ・パスは、SQLで見つけることができます：
GV $ DIAG_INFOどこから名「％アラート％」のような選択*
3. Oracleユーザーの問題を特定し、
t1.inst_idを選択し、t1.username、T1のGV $セッションから（*）カウント
t2.addr = t1.paddrとt2.inst_id = t1.inst_idにGV $プロセスT2に参加
t1.inst_idでグループ、t1.username ORDER BY 3 DESC
原因ユーザー接続のあまりxxxxの番号で見つけることができます。
4.再構築、新しい接続からユーザーを防ぎます。
クライアントの制御の程度に応じて柔軟なアプローチを選択します。あなたは、クライアントプログラムの上に絶対的なコントロールを持っている場合は、プログラムの問題は通常の状況下では、停止することができ、問題が解決されます。
私は、ユーザーロックの道を選んだ、次のSQLを実行します。
ALTERユーザーXXXXアカウントロック。
私たちは、GVの$セッションを参照してください5.この時点では、接続がまだ確立されていることがわかりました。
ユーザ名は「XXXXを」= GVの$セッションから選択*
6.これらの接続をクリーンアップします。
この時点で、問題は、クライアントプログラムを終了していない場合は、確立されたクライアントとOracleサーバーを接続するネットワークは、我々はセッション、プロセスを強制終了しても、この時点で残っていることがわかったので、私のフォローアップのテストの後、ALTER SYSTEMキルセッションを使用していませんまだ解放されません、それはこれらのプロセスに対応するユーザセッションを見つける私達につながった、$セッションビューをGVと失われた関係の$プロセスビューをGVにつながるだろう。
直接キル・システムは、オペレーティングシステムレベルで対応するセッションを処理します。
XXXXは、システムプロセスIDに対応するセッションの次のSQLアカウントを使用して見つけることができます。
T1のGV $セッションからt1.inst_id、t1.sid、t1.serial＃、t1.username、t2.spid系统进程IDを選択
t2.addr = t1.paddrとt2.inst_id = t1.inst_idにGV $プロセスT2に参加
どこt1.username = 'XXXX'
7.降りてくるために演算処理上の仕上がりを占めていました。その後、我々はクライアントと通信するためのプログラムが復元されたアカウントをロックアウトして、問題を停止して検討します。
オペレーティングシステムコマンドに対応する特定のセッションを殺すためにすべての方法は、この方法はあまりにも暴力的で、可能な限り使用しないでください。
PS -ef | grepのLOCAL = NO | grep -v grepの| awkは '{$ 2印刷}' | xargsが殺す-9
問題が解決された後、次のように、私は図書館で少しテストを行うためのpythonを使用して、問題を再現します：
＃！/ binに/ pythonの ＃- * -コーディング：UTF-8 - * - 輸入cx_Oracleコなど でCONN = co.SessionPool（' XXXX '、' XXXXXXXXX '、' XXXX '、分= 1、最大= 5000 ） 、A = [] のための I における範囲（5000 ）： プリント（I） の試行： CCC = conn.acquire（） a.append（CCC） を除く例外Eとして： プリント（E） time.sleep（ 20）
上記。