2

Oracle プロセス P1 (例: SID=123) によってアクセスされるテーブル TAB1 があります。このプロセスでは、動的 SQL 削除とそれに続くコミットが要求されます。

SID=123 によって開始されたプロセス P1 は、この TAB1 関連の操作とは別に、多くの操作で構成されています。

シナリオ：

  • SID=123 がアクティブです。P1 が TAB1 に行排他ロックを課しました (locked_object ビューのクエリから取得)。

  • 別の Oracle プロセス P2 は、SID=124 によって開始されます (P1 とまったく同じプロセスですが、データ入力のセットが異なります)。P1 が開始された直後 (たとえば、2 ～ 3 分)。

  • SID=124 は、SID=123 によって開始されたプロセス P1 が完了するまで待機しています。P2 が TAB1 に行排他ロックを課しました (locked_object ビューのクエリから取得)。

質問：

P2 による同じ行レベルのロックは、P1 による行レベルのロックから「先に進むことができる」ことを期待していると思います。プロセス P1 によって TAB1 に課せられたロックを手動でオーバーライドし (それが可能であることを願っています)、TAB1 での操作が終了したらロックを解放することはできますか? これは、P1 全体が終了するまで、P2 が現在 TAB1 で抱えている長い待ち時間を短縮するのに役立ちますか?

どんな提案でも大歓迎です。これについてさらに情報が必要な場合はお知らせください。

4

2 に答える 2

0

私は実際に「シナリオを回避しました」。これは、尋ねられている質問に対する「この答えは解決策ではない」ことを意味します。
シナリオを回避するために私がしたこと:

  1. TAB1 にもう 1 つの列を追加して、各プロセスに一意の識別番号を付けました。
  2. この列を使用して、その特定のプロセスに対応する行のみを削除しました。 これにより、プロセス P1 と P2 が同じ行を待機することを回避できたと思います。

@Codo、@a_horse_with_no_name、@Ben、@Justin Cave、@colemar に感謝します

@Justin Cave: 私はあなたが提案したのと同じ解決策を考えていましたが、昨日これを見ていれば、今まで時間を無駄にする必要はなかったでしょう. とにかく、あなたのサポートに感謝します。

于 2012-12-14T10:37:36.517 に答える
0

ロックは、プロセス境界ではなく、トランザクション境界で解放されます。

つまり、P1 にロックをすぐに解放させたい場合、P1 は削除操作の直後に明示的なコミットまたはロールバックで現在のトランザクションを終了する必要があります。

もちろん、トランザクションを終了すると、前のコミット/ロールバックの後に同じセッションで実行された他の操作もコミット/ロールバックされます。これが問題になる場合は、ビジネス ロジックを再考する必要があります。

ちょっと待って、「動的 SQL 削除の後にコミット」と書きました...「すぐに続く」という意味であれば、行の排他ロックはすでにすぐに解放されています。

于 2012-12-12T20:15:56.900 に答える