まず、簡単な解決策です。本番データベースでデフォルトのリンクの数が実際にあることを再確認します。 4.
select *
from v$system_parameter
where name = 'OPEN_LINKS'
あなたがそれを軽く降りるつもりはないと仮定すると：
ドキュメント 、そのセッションに関連付けられているすべてのリンクが閉じていることを意味する必要があります。それ以外は、この点について完全に無知であることを告白します。
私が考えることができる不利な点はありません。 TomKyteが提案 、かなり前ですが、開いている各データベースリンクは500kのPGAメモリを使用します。何も持っていない場合、これは明らかに問題を引き起こしますが、ほとんどの状況では問題ないはずです。
ただし、意図しない結果が発生します。この数を100に増やしたと想像してください。誰かがリンクを継続的に開き、それらすべてを介して大量のデータを描画するコードを作成しますselect * from my_massive_table または類似。これを行う4つのセッションの代わりに、100があり、数百ギガバイトを同時に転送しようとしています。あなたのネットワークは緊張の下で死にます...
おそらくもっとありますが、あなたは絵を手に入れます。
お気づきのように、最良の答えは「おそらくそうではない」ですが、これはあまり役に立ちません。セッションをどのように終了するかについては正確には言及していませんが、セッションを正常に終了するのではなく強制終了する場合は、間違いなくそうします。
データベースリンクを使用すると、リモートサーバー上に子プロセスが生成されます。サーバーはこのプロセスを絶対的に担当しなくなったため、親プロセスの終了時にサーバーが孤立したり、閉じられなかったりする可能性のあるものが無数にあります。これが常に発生するわけではありませんが、発生する可能性があります。
私は2つのことをします。
-
プロセスで例外が発生した場合は、次のクエリの結果を自分宛てに電子メールで送信してください。
select * from v$dblink少なくとも、セッションで開いているデータベースリンクを把握し、それらをトレースする方法を提供します。
-
ドキュメントのアドバイスに従ってください。具体的には次のとおりです。
"リンクを手動で閉じる場合があります。たとえば、次の場合にリンクを閉じます。
- リンクによって確立されたネットワーク接続がアプリケーションで使用されることはめったにありません。
- ユーザーセッションを終了する必要があります。」
最初のものはあなたの状況にぴったり合っているようです。あなたのプロセスが時間に敏感でない限り、そうではないようですが、あなたは何を失う必要がありますか？構文は次のとおりです。
alter session close database link <linkname>