locklist - ロック・リスト用最大ストレージ構成パラメーター

このパラメーターは、ロック・リストに割り振られているメモリー量を示します。 データベースごとに 1 つのロック・リストが存在し、ロック・リストには、 データベースに同時に接続しているすべてのアプリケーションが保持しているロックが含まれています。

構成タイプ
データベース
パラメーター・タイプ
  • オンラインで構成可能
  • Db2® pureScale® 環境のメンバーにより構成可能
デフォルト [範囲]
自動 [4 - 134217728]
注: デフォルト値は、初期データベース作成後に Db2 構成アドバイザーによって変更される場合があります。
単位
ページ (4 KB)
割り振られるタイミング
最初のアプリケーションがデータベースに接続する時
解放されるタイミング
最後のアプリケーションがデータベースから切断される時

ロッキングは、 複数のアプリケーションがデータベース内にあるデータに並行アクセスするのをコントロールするために、 データベース・マネージャーが使用するメカニズムです。 行と表の両方がロックの対象です。 データベース・マネージャーは Internal Lock を獲得する場合もあります。

このパラメーターは、AUTOMATIC に設定されると、セルフチューニングが使用可能になります。 これによってメモリー・チューナーは、このパラメーターによって制御されるメモリー領域のサイズを、ワークロード要件の変化に応じて動的に変更できるようになります。 メモリー・チューナーは異なるメモリー・コンシューマーの間でメモリー・リソースをやりとりするので、セルフチューニングをアクティブにするためには、少なくとも 2 つのメモリー・コンシューマーのセルフチューニングが使用可能になっていなければなりません。

maxlocks パラメーターと一緒に locklist の値をチューニングできますが、locklist パラメーターのセルフチューニングを使用不可にしても、maxlocks パラメーターのセルフチューニングが自動的に使用不可になるわけではありません。 locklist パラメーターのセルフチューニングを使用可能にすると、maxlocks パラメーターのセルフチューニングも自動的に使用可能になります。

この構成パラメーターの自動チューニングは、セルフチューニング・メモリーがデータベースに対して使用可能なとき (self_tuning_mem 構成パラメーターが ON に設定されているとき) にのみ行われます。

すべてのプラットフォームで各ロックはロック・リストの 128 バイトまたは 256 バイトが必要ですが、これは他のロックがオブジェクトで保持されているかどうかによります。
  • 他にロックが保留されていないオブジェクトのロックを保留するには、256 バイトが必要です。
  • 既存のロックが保持されているオブジェクトでロックを記録するには 128 バイトが必要です。
1 つのアプリケーションが使用するロック・リストのパーセンテージが maxlocks に達すると、データベース・マネージャーは、そのアプリケーションが保持するロックに対して行から表へのロック・エスカレーションを行います。 この計算は共有ロックのみを仮定した場合の概算です。 使用されているロック・リストのパーセンテージを計算するには、アプリケーションが保持するロックの数に、他のロックを持つオブジェクトが、1 つのロックを保持する際に必要な値を乗じて計算します。 エスカレーション処理そのものにはそれほど時間がかかりませんが、(個別の 行に対するロッキングに対して) 表全体のロッキングは並行性を減少させ、 影響を受けた表に対する後続のアクセスのために、データベース・ パフォーマンス全体が低下する可能性があります。 推奨されるロック・リスト・サイズのコントロール方法は、以下のとおりです。
  • ロックを解放するために頻繁に COMMIT を実行します。
  • 多くの更新を実行するときには、(SQL LOCK TABLE ステートメントを 使用して) 更新前に表全体をロックします。 これは 1 つのロックのみを使用し、他のロックが更新に干渉しないようにしますが、データの並行性は減少します。

    また、ALTER TABLE ステートメントの LOCKSIZE オプションを使用して、特定の表のロッキング方法をコントロールすることもできます。

    反復可能読み取り分離レベルを使用すると、結果として自動表ロックになってしまう場合があります。

  • 保持された共有ロック数の減少が可能な場合は、 カーソル固定分離レベルを使用します。 アプリケーション整合性要件と折り合わない場合は、ロッキングの量をさらに減らすために、カーソル固定ではなく非コミット読み取りを使用してください。
  • locklist を AUTOMATIC に設定します。 ロック・リストが同期的に大きくなっていくので、ロック・エスカレーションの発生やロック・リストが満杯になる状態を回避できます。

ロック・リストが満杯になると、 ロック・エスカレーションが行のロックよりも表のロックを多く行うので、 パフォーマンスが低下する場合があり、これにより、データベースの共有オブジェクトにおける並行性が低下します。 さらに、 アプリケーション間のデッドロックが増える可能性があり (すべてのアプリケーションが、 限られた数の表ロックを待つため)、これによりトランザクションがロールバックされることになります。 データベースに対するロック要求の最大数に達すると、 アプリケーションが SQLCODE -912 を受け取ります。

推奨 : ロック・エスカレーションによってパフォーマンスの問題が生じている場合、このパラメーターか maxlocks パラメーターの値を増やす必要があります。 データベース・システム・モニターを使用すると、ロック・エスカレーションが起きているかどうかを判別できます。 lock_escals (ロック・エスカレーション) モニター・エレメントを参照してください。

以下のステップは、ロック・リストに必要なページ数を決定するのに役立ちます。
  1. ロック・リストのサイズの下限を計算します。ユーザー環境により、以下の計算式の中から 1 つを使用して計算します。
    1.   (512 * 128 * maxappls) / 4096
    2. コンセントレーターが使用可能になっている場合。
        (512 * 128 * max_coordagents) / 4096
    3. コンセントレーターが使用可能になっているパーティション・データベースの場合。
        (512 * 128 * max_coordagents * number of database partitions) / 4096

    ただし、512 はアプリケーション当たりの平均ロック数の見積もりで あり、128 は、既存のロックがあるオブジェクトに対するそれぞれのロックに 必要なバイト数です。

  2. ロック・リスト・サイズの上限を計算します。
      (512 * 256 * maxappls) / 4096

    256 はオブジェクトに対する最初のロックに必要なバイト数です。

    注: Db2 pureScale 環境の場合、 locklist 構成パラメーターを、このステップで計算された値の上限と、現在接続されているデータベースに存在するすべてのバッファー・プールの合計ページ数の 3% に等しくなるように設定してください。
  3. データに対する並列量を見積もり、また計算した上限と下限の間になるように、予測に基づいて locklist の初期値を選択します。
  4. 以下の段落に記述されているように、データベース・システム・モニターを使用してこのパラメーターの値を調整します。

ご使用のアプリケーション・シナリオで maxappls または max_coordagents が AUTOMATIC に設定されている場合は、locklist も AUTOMATIC に設定する必要があります。

データベース・システム・モニターを使用すると、指定したトランザクションによって保持される最大ロック数を判別することができます。 locks_held_top (保留されているロックの最大数) モニター・エレメントを参照してください。

この情報は、アプリケーションあたりのロックの見積数の検査または調整に役立ちます。 この妥当性検査を実行するには、モニター情報がアプリケーション・レベルではなく、 トランザクション・レベルで提供されていることに注意して、複数のアプリケーションをサンプルとする必要があります。

また、maxappls を増やしたか、または実行中のアプリケーションが頻繁にコミットを実行していない場合は、locklist の増加が必要になる場合もあります。

このパラメーターを変更した場合は、アプリケーションの再バインド (REBIND コマンドを使用) を考慮してください。