ロック・エスカレーション

ロック・エスカレーション発生時

ロック・エスカレーションは、 処理のページまたは行へのアクセスが比較的少ない間は ページ・ロックまたは行ロックを使用し、 次にその処理のアクセスが増えると表スペース、表、またはパーティションのロックに変更して、 並行性とパフォーマンスとのバランスを取ります。 この状態が発生すると、以下で説明するように LOCKSIZE および LOCKMAX の値に応じて表スペースごとにロック・エスカレーションが異なります。 ALTER、CREATE、DROP、GRANT、および REVOKE の SQL ステートメントの実行中は、ロック・エスカレーションは延期されます。

推奨事項

Db2統計およびパフォーマンス・トレースは、ロック・エスカレーションが発生した頻度、およびタイムアウトまたはデッドロックの原因となったかどうかを判別することができます。 大まかな見積もりとして、ロック・エスカレーションの 4 分の 1 でタイムアウトまたはデッドロックが生じるのであれば、自動調整は有効ではありません。 表を変更して LOCKMAX を増やすと、エスカレーション数を減らすことができます。

または、 ロック・エスカレーションが問題となっている場合、LOCKMAX 0 を使用してロック・エスカレーションを使用不可にすることもできます。

LOCKSIZE ANY

ロック・エスカレーションを避けるために他のステップを取る場合、 LOCKSIZE ANY は可能な選択です。 LOCKSIZE ANY を使用する場合には、LOCKMAX 値には、 通常の使用であればトランザクションによって保持されるロックをエスカレートしない くらいの大きさの値を指定するようにしてください。 また、LOCKS PER USER は、 トランザクションがその限界に達しないように十分大きくなくてはなりません。

以下に、バッチ・ジョブの種類に応じた処理について説明します。

トランザクションと並行

ページまたは行ロックを使用し、 例えば 100 の更新ごとに、頻繁にコミットしなければなりません。 LOCKS PER USER を検査して限界を超えることを避けてください。 ページまたは行ロッキングは、かなり処理時間を使います。 ISOLATION(CS) 指定でバインドすると、 読み取りが多く、更新が少ないアプリケーションに対して、表スペースの X ロックへの ロック・エスカレーションを抑えることができます。 ただし、これでは、更新を頻繁に行うアプリケーションのロック・エスカレーション は防止できない可能性があります。

トランザクションと非並行

ページ・ロックまたは行ロックを使用する必要はありません。 アプリケーションは、排他モードで表を明示的にロックすることができます。