最も単純な回避策は、トランザクションを分割し、より少ない数のローをロックすることです。これには、同時実行性の向上、ロールバック・ログのサイズの減少、トランザクション中にシステムが応答を停止した場合のリカバリ時間の減少という別の利点があります。
場合によっては、トランザクションの分割が容易でないことや望ましくないことがあります。その場合は、テーブルを明示的にロックすることを検討してください。SUBSUME_ROW_LOCKS
オプションが ON (デフォルト) の場合、LOCK TABLE T INEXCLUSIVE MODE でテーブル
T が排他的にロックされていると、データベース・サーバはテーブル T の個々のロー・ロックを取得する必要がなくなります。これにより、単一のトランザクションで広範な更新が
T に対して行われる場合はパフォーマンスが大幅に向上する可能性があります
(特に、キャッシュ・サイズに比べて T が大きい場合)。
SUBSUME_ROW_LOCKS を ON に設定した場合の 1 つの欠点は、この方法でロックされたテーブルに対するキーセット・カーソルが期待どおりに機能しないということです。たとえば、これらのキーセット・カーソルは、変更されたデータベース内のローについてカーソル内のローごとに
"row changed (ローが変更されました)" という警告を返すことがあります。また、データベース・サーバは、ORDER
BY を使用した更新可能カーソルをキーセット・カーソルに変えることがあります。