InfoDBMS_LOCKパッケージを使用すると、ユーザーが任意の仮想的なリソースのロックをかけることができます。DMLによって発生するロックの場合は、物理的なリソース(テーブル/トランザクション/セグメントなど)を必要としますが、DBMS_LOCKパッケージを使用する場合には、このような制限がありません。Lock)ロックと呼びます。contentionイベントを待機します。DBMS_LOCK.REQUEST関数を使用すると、ULロックをExclusiveに獲得し、DBMS_LOCK.RELEASE関数を使用すると、ロックを解除します。下のテストスクリプトを見てみましょう。Wait------------------上記のように、セッションBはセッションAによって占められた”1′′というリソースのロックを獲得するために待機することになります。LOCKビューを観察してみましょう。1)に対してULロックをExclusiveに獲得するために待機CTIME:40BLOCK:0-----------------テストULロック競合セッションA(SID=156)は、ULロックを”1′′と呼ばれるリソース(ID1=1)についてExclusiveに(lmode=6)獲得した状態であり、セッションB(SID=151)は、「1」という同じリソースにについてULロックをExclusiveに獲得するために待機していることを確認することができます。contention待機現象を観察することができます。0ULロックによる競合はDBMS_LOCKパッケージを効率的に使用していない場合に発生します。DBMS_LOCKパッケージは非常にシンプルでありながら柔軟で強力なブロッキング方法を提供しますが、ややもして間違って使用すると、致命的な競合を招くこともあることを留意しなければなりません。ULロックの解除は、基本的にロックを保有しているセッションでのみ可能です。したがって、特定のセッションがULロックを長時間保持することにより、同時実行の問題を起こしている場合、セッションを強制的に終了させること以外に選択肢がありません。DBMS_LOCK.REQUEST関数使用時、可能であればrelease_on_commitオプションを使用して不必要にロックを保持しないようにするのが良い方法です。このオプションを使用すると、コミットやロールバックが発生すると、トランザクションが保有していたULロックを自動的に解除します。DBMS_LOCKパッケージに関連するもう一つの待機イベントがあります。timerイベントを待機する。timer待機イベントによるパフォーマンスの問題はありません。その待機が期待以上に高く出る場合、アプリケーションの実装ロジックに問題がないかどうか検討しなければなりません。Timeenqueue待機イベントと同一に、最大3秒まで待ちます。ULロックを獲得する場合は、獲得するまで待機します。Page本サイトに掲載されている情報は日本エクセム株式会社が提供しています。