管理の手引き


ロック

データベース・マネージャーは、並行性制御が可能になっており、 ロックを使うことによって、無秩序にアクセスがなされることがないようになっています。 ロック はデータベース・マネージャー・リソースをアプリケーションに関連付けて、 そのリソースへの他のアプリケーションからのアクセス方法を制御する手法です。 リソースが関連付けられているアプリケーションは、 ロックを保持または所有していると言われます。

データベース・マネージャーはロックをかけることで、 アプリケーションが他のアプリケーションによって作成された非コミットのデータにアクセスすることがないようにします (ただし、非コミット読み取り分離レベルが使用されている場合は除きます)。 この原則によりデータの整合性 (データの一貫性と機密保護) が保たれます。 さらにロックを使って、行の更新を禁止することができます (反復可能読み取りアプリケーションの場合など)。

データ保全性を保つため、 データベース・マネージャーはデータベース・マネージャー制御の下で暗黙のうちにロックを獲得します。 非コミット読み取り分離レベルを除いては、 非コミット・データを他のプロセスから隠すためにアプリケーションが明示的にロックを要求する必要は全くありません。

ロックの基本原則により、 ほとんどの場合ロックを制御するためのアクションを取る必要はありません。 それでも、アプリケーションは特定の一般的なパラメーターに基づいてロックを獲得します。 ローカルな状況について把握しておくなら、 それらのパラメーターを変更してシステム・リソースを効果的に使用するうえで役立ちます。 ここでは、ロックに関する以下のトピックを説明します。

ロックの属性

データベース・マネージャーのロック機能には、以下のような基本属性があります。

モード
ロックの所有者に許可されるアクセスの種類、 そしてロックの対象の並行ユーザーに許可されるアクセスの種類。 これは、しばしばロックの状態 と呼ばれます。

オブジェクト
ロックするリソース。 明示的にロックできるオブジェクトの唯一のタイプは表です。 このほかにもデータベース・マネージャーでは、行、表、表スペースなど、 他のタイプのリソースにもロックをかけます。 ロックされているオブジェクトは、ロックの細分性 を表します。

期間
ロックが保持される時間的長さ。 ロック期間は分離レベルの影響を受けます (それについては、 並行性で説明されています)。

以下の表では、モードとその効果が示されています。 ここに示す順に、リソースへの制御が大きくなります。

表 38. ロック・モードの要約
ロック・モード 適用できるオブジェクト・タイプ 説明
IN (意図なし) 表スペース、表 ロックの所有者は、非コミット・データを含め、 表内のすべてのデータを読み取ることができますが、更新はできません。 ロック所有者によって行ロックは獲得されません。 同時に実行される他のアプリケーションは、その表を読み取ったり更新したりできます。
IS (意図共用) 表スペース、表 ロック所有者は、ロックされている表のデータを読み取ることはできますが、 更新はできません。 アプリケーションが IS 表ロックを保持している場合には、 そのアプリケーションは各行の読み取りごとに S ロックまたは NS ロックを獲得します。 いずれにしても、他のアプリケーションはその表を読み取ったり更新したりできます。
NS (次キー共用) ロック所有者とすべての並行アプリケーションは、 ロックされた行を読み取ることはできますが、更新はできません。 このロックは、S ロックの代わりに、表の行に対して獲得されます。 ここで、読み取られるデータの分離レベルは、RS か CS のいずれかです。
S (共用) 行、表 ロック所有者とすべての並行アプリケーションは、 ロックされたデータを読み取ることはできますが、更新はできません。 表の個々の行は S ロックされます。 表が S ロックされている場合、行ロックは必要ではありません。
IX (意図排他) 表スペース、表 ロック所有者と同時に実行されるアプリケーションとは、 表のデータを読み取ったり更新したりできます。 ロック所有者がデータを読み取るときには、 行ごとに S、NS、X、または U ロックが獲得されます。 また、ロック所有者が更新する行ごとに X ロックも獲得されます。 同時に実行される他のアプリケーションは、 その表を読み取ったり更新したりできます。
SIX (意図排他共用) ロック所有者は、表のデータを読み取ったり更新したりできます。 ロック所有者は、更新する行ごとに X ロックを獲得しますが、 読み取る行のロックは獲得しません。 同時に実行される他のアプリケーションは、 その表を読み取ることができます。
U (更新) 行、表 ロック所有者は、 ロックされた行または表のデータを更新できます。 ロック所有者は、行を更新する前にこの行に対して X ロックを獲得します。 他の作業単位はロックされた行または表のデータを読み取ることはできますが、更新は行えません。
NX (次キー排他) ロック所有者は、ロックされた行の読み取りはできますが更新はできません。 このモードは、NS ロックと互換性があることを除けば、X ロックと類似した働きをします。
NW (次キー弱排他) このロックは、行を非カタログ表の索引に挿入するときに、 その行の次の行に対して獲得されます。 ロック所有者は、ロックされた行の読み取りはできますが更新はできません。 このモードは、W ロックおよび NS ロックと互換性があることを除けば、 X ロックおよび NX ロックと類似した働きをします。
X (排他) 行、表 ロック所有者は、ロックされた行または表のデータを読み取ったり更新したりできます。 表は、排他ロックできます。 つまり、これらの表の行について行ロックが獲得されることはありません。 ロックされた表にアクセスできるのは、非コミット読み取りアプリケーションだけです。
W (弱排他) このロックは、行を非カタログ表に挿入するときに、その行に対して獲得されます。 ロック所有者は、ロックされた行を変更することができます。 このロックは、NW ロックと互換性があることを除けば、X ロックと類似した働きをします。 ロックされた行にアクセスできるのは、非コミット読み取りアプリケーションだけです。
Z (超排他) 表スペース、表 このロックが表上で獲得されるのは、表が変更または除去されるとき、 表の索引が作成または除去されるとき、 あるいは表が再編成されるときなど、特定の状況においてです。 同時に実行される他のアプリケーションは、 その表を読み取ったり更新したりできません。
注:"意図" ロック・モードを取得するのは、 表と表スペースだけです。 つまり、行には意図ロックは取得されません。

ロックとアプリケーションのパフォーマンス

アプリケーション・プログラマーは、 ロックの使用に関係するいくつかの関連した要因と、 それがアプリケーションのパフォーマンスに与える影響について知っておく必要があります。 そのような要因には、次のものが含まれます。

並行性と細分性

あるアプリケーションがロックを保持していると、 別のアプリケーションによるアクセスはできなくなります。 したがって、並行性を最大にするには、表ロックよりも行レベル・ロックが適しています。 しかし、ロックには記憶域が必要になり、また管理のための処理時間も必要になります。 したがって、記憶域と処理時間を最小限にするには、 多くの行ロックよりも 1 つの表ロックの方が適しています。

ALTER TABLE ステートメントの LOCKSIZE 文節を使用すると、 行または表レベルでロックのサイズ (細分性) を定義できます。 省略時では、行ロックが使用されます。 ALTER TABLE で定義した永続表ロックを使うと、S および X 表ロックのみが使用されます。 アプリケーションが多くの行ロックを獲得したり、解放したりする必要がなくなるので、 パフォーマンスは向上します。 次のような場合には、 LOCK TABLE ステートメントを使用して単一トランザクション表をロックするよりも、 ALTER TABLE を使用して永続表ロックをすることができます。

ALTER TABLE ステートメントを使用しても、通常のロック・エスカレーションに支障はありません。

さらに、ALTER TABLE を使用して表レベルでロックするというのはグローバルな方法であることに注目してください。 これは、その表をアクセスするすべてのアプリケーションおよびユーザーに影響を与えます。 個々のアプリケーションで使えるもう 1 つの方法は、 LOCK TABLE ステートメントを使用することです。 これにより、 データベース・レベルではなくアプリケーション・レベルで表ロックをかけることができます (上の 2 番目の黒丸を参照)。

ロックの互換性

表 39 に、 特定の状態で別のプロセスが同じリソースにロックを保持または要求している場合に、 ロック要求が許可されるかどうかを示します。 いいえは、 非互換ロックが他のプロセスによってすべて解除されるまで、 要求側が待機しなければならないことを示します。 ロック待機中に、タイムアウトになることがあるので注意してください。 はいは、ロックが許可されることを示します (ただし、 他のだれかがそのリソースを待っていない場合に限ります)。

表 39. ロック・タイプの互換性

保持されているリソースの状態
要求されている 状態 なし IN IS NS S IX SIX U NX X Z NW W
なし はい はい はい はい はい はい はい はい はい はい はい はい はい
IN はい はい はい はい はい はい はい はい はい はい いいえ はい はい
IS はい はい はい はい はい はい はい はい いいえ いいえ いいえ いいえ いいえ
NS はい はい はい はい はい いいえ いいえ はい はい いいえ いいえ はい いいえ
S はい はい はい はい はい いいえ いいえ はい いいえ いいえ いいえ いいえ いいえ
IX はい はい はい いいえ いいえ はい いいえ いいえ いいえ いいえ いいえ いいえ いいえ
SIX はい はい はい いいえ いいえ いいえ いいえ いいえ いいえ いいえ いいえ いいえ いいえ
U はい はい はい はい はい いいえ いいえ いいえ いいえ いいえ いいえ いいえ いいえ
NX はい はい いいえ はい いいえ いいえ いいえ いいえ いいえ いいえ いいえ いいえ いいえ
X はい はい いいえ いいえ いいえ いいえ いいえ いいえ いいえ いいえ いいえ いいえ いいえ
Z はい いいえ いいえ いいえ いいえ いいえ いいえ いいえ いいえ いいえ いいえ いいえ いいえ
NW はい はい いいえ はい いいえ いいえ いいえ いいえ いいえ いいえ いいえ いいえ はい
W はい はい いいえ いいえ いいえ いいえ いいえ いいえ いいえ いいえ いいえ はい いいえ
Abbreviations:
I
意図
N
なし
NS
次キー共用
S
共用
NX
次キー排他
X
排他
U
更新
Z
超排他
NW
次キー弱排他
W
弱排他

これらのロック・タイプについては、ロックの属性の説明を参照してください。

Legend:
  • はい - 要求されたロックがただちに付与される
  • いいえ - 保持しているロックを解放するまで、 またはタイムアウトになるまで待機する

アプリケーション A がある表のロックを保持していて、 その表へのアクセスをアプリケーション B も待っているとします。 データベース・マネージャーはアプリケーション B のために、 ある特定のモードのロックを要求します。 A が保持しているロックのモードが、 B の要求しているロックを許可するものである場合、2 つのロック (またはモード) は、 互換性があると言います。

アプリケーション B が要求したロック・モードとアプリケーション A が保持しているロックとの間に互換性がない場合には、 アプリケーション B はそれ以上継続できません。 アプリケーション B は、アプリケーション A がロックを解放し、 さらに既存の非互換のロックがすべて 解放されるまで待機する必要があります。

ロックの変換

ロックの変換が行われるのはあるプロセスがすでにロックを保持しているデータ・オブジェクトにアクセスする場合に、 そのアクセスのモードが、すでに保持しているロックよりさらに制約の大きいロックを必要とするものである場合です。 1 プロセスの中で同じデータ・オブジェクトに (照会によって間接的に) 何度もロックを要求できますが、 1 つのデータ・オブジェクトのロックは 1 回に 1 つしか保持できません。 すでに保持しているロックのモード変更操作は、 変換 と呼ばれます。

行の変換の場合は単純です。 たとえば、X が必要なときに S または U を保持しているといった場合に、 変換が行われます。

表および行には、いくつかのロック・モードがあります。 しかし、IX (意図排他) と S (共用) ロックは、ロック変換に関しては特殊なケースです。 S と IX はどちらも他方よりも制約が大きいとはみなされないため、 これらのロックの一方を保持しているときに他方が必要になった場合には、 結果として SIX (意図排他共用) ロックに変換されることになります。 他のすべての変換の結果は、 要求されているモードの制限がよりゆるい場合は、 要求されたロック・モードが、保持するロックのモードになります。

行を更新するための照会では、変換が二重に行われる可能性もあります。 たとえば、その行が索引アクセスによって読み取られ、 S ロックがかけられていたとします。 その行が入っている表には、 それをカバーするような意図的ロックがかけられているはずです。 それが IX ではなく IS であるとします。 後で行が変更されると、表ロックは IX に変換され、 行ロックは X に変換されることになります。

通常、ロックの適用は照会の実行時に暗黙のうちに行われます。 各種の照会および表と索引の組み合わせの下で発行されるロックの種類について知っておくことは、 アプリケーションの設計と調整に役立つでしょう。 そのことについては、ロックに影響する要因を参照してください。

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

ロック・エスカレーションは、保持されるロックの数を減らすための内部機構です。 エスカレーションは、多くの行ロック (単一の表内) から単一の表ロックまであります。

ロック・エスカレーションが起きるのは、 データベース内で現在保持しているロックが多くなりすぎたときです。

ロック・エスカレーションは、 特定のデータベース・エージェントがロック・リストのそのエージェントに割り振られた分を超過した場合にも、 起こることがあります (自動調整前のロック・リストの最大パーセント (maxlocks)を参照してください)。

このような自動調整は内部的に処理されるので、 1 つまたは複数の表への並行アクセスが少なくなるのは、外部検出結果のみです。 通常、適正に構成されたデータベースでは、 ロック・エスカレーションはほとんど行われません。

ロック・エスカレーションが起きる場合の例としては、 アプリケーション設計者が大きな表で索引を使用してパフォーマンスと並行性を向上させようとしたが、 そのアプリケーションはその表の大部分のレコードにアクセスするというような場合があげられます。 (この場合、) データベース・マネージャーは、 表の大部分がロックされることを予測できないため、 S または X の表だけをロックするのではなく、各レコードを個別にロックします。 このような場合の解決策として、データベース設計者は、 アプリケーション設計者とも相談した上で、 このトランザクションに LOCK TABLE ステートメントを使用するように推奨することができます。

しばしば、内部的に自動調整要求を受け取るプロセスは、 表に対してほとんど、またはまったくレコード・ロックをかけていません。 この自動調整が行われる理由は、1 つのプロセスが多くのロックをかけているが、 その数が、1 プロセス当たりのロック数を指定するデータベース構成パラメーターより小さく、 自動調整要求が引き起こされるほどではないためです。 そのプロセスは、トランザクション終了時を除いて、 別のロックを要求したりデータベースにアクセスしたりしないかもしれません。 そして、別のプロセスが、 自動調整要求を引き起こすロックを要求する場合があります。

ロック・エスカレーションによって並行性が受諾不能なレベルまで下がると、 以下のことができるようになります。

ロックの待機とタイムアウト

ロック・タイムアウト検出を指定していない場合、異常終了時には、 ロックが解放されるまでアプリケーションの無期限待機が必要になることがあります。 たとえば、あるトランザクションが別のユーザーによって保持されているロックを待機しており、 一方でそのユーザーが実行中のトランザクションをアプリケーションがコミットできるように対話を実行してロックを解放するということをせずに作業場から席をはずしてしまった場合に、 そうなります。 明らかに、この結果アプリケーションのパフォーマンスが低下します。 こうしたケースでプログラムが停止 しないようにするには、 locktimeout 構成パラメーターを使用して、 アプリケーションがロックを獲得するまで待機する最大待ち時間を設定することができます。 (ロック・タイムアウト (locktimeout)を参照してください。)

このパラメーターを使用すると、 特に分散作業単位 (DUOW) アプリケーションにおいては、 大域デッドロックを避けることができます。 ロックがタイムアウトになる、つまり、 ロック要求が保留にされている時間が locktimeout 値より長くなると、 アプリケーションはエラーを受け取り、トランザクションがロールバックされます。 たとえば、program1 が、 すでに program2 によって保持されているロックを獲得しようとするときにタイムアウトになると、 program1 は SQLCODE -911 と理由コード 68 を返します。

データベース・マネージャー構成パラメーター diaglevel が 4 に設定され、 ロック要求がタイムアウトになった場合、 db2diag.log にはさらに情報が追加されている可能性があります。 この情報には、オブジェクト、ロック・モード、 およびこのオブジェクトへのロックを保持しているアプリケーションが含まれます。 また、現行の動的 SQL ステートメントまたは静的パッケージも見つかる可能性があります。

デッドロック

データベース・マネージャーでは、 データベースを使用するプロセスによってロックの競合が発生すると、 デッドロックになる可能性があります。 たとえば、プロセス 1 が X (排他) モードで表 A にロックをかけ、 プロセス 2 が X モードで表 B にロックをかけるとします。 次にプロセス 1 が X モードで表 B にロックをかけようとし、 さらにプロセス 2 が X モードで表 A にロックをかけようとすると、 それらのプロセスはデッドロックに陥ります。 デッドロック状態になると、プロセスは両方とも、 それらの 2 度目のロック要求が受け入れられるまで中断状態になり、しかもどちらの要求も、 いずれかのプロセスがコミットまたはロールバックを実行するまで受け入れられることはありません。 外部エージェントがいずれかのプロセスを活動化し、 強制的にロールバックを実行させるまで、この状態が無限に続きます。

ロック・システムでのデッドロックは、データベース・マネージャーにおいて、 デッドロック検出機能と呼ばれる非同期システム背景プロセスによって処理されます。 デッドロック検出機能は、 dlchktime 構成パラメーターによって指定された周期で活動状態になります (デッドロック検査の時間間隔 (dlchktime)を参照)。 デッドロック検出機能が活動状態になると、 ロック・システムがデッドロック状態になっていないかどうかを調べます。 データベースが区分データベースである場合、各区画は、 システム・カタログ視点のあるデータベース区画にロック・グラフ を送ります。 このシステム・カタログ視点では、グローバルなデッドロック検出が行われます。

デッドロックが検出されると、 デッドロック検出機能はデッドロック状態のプロセスのうちどれをロールバックするかを選択します。 選択されたプロセスは活動状態にされ、 呼び出し側アプリケーションに SQLCODE -911 (SQLSTATE 40001) 理由コード 2 で戻されます。 データベース・マネージャーは選択されたプロセスを自動的にロールバックします。 ロールバックが完了すると、選択されたプロセスに属するロックは解除され、 それによってそのデッドロックにかかわっていた他のプロセスが先に進めるようになります。

デッドロック検出機能の適切な時間間隔を選択することは、 適正なパフォーマンスを確保するうえで必要なことです。 時間間隔が短すぎると不必要なオーバーヘッドが生じ、 長すぎるとデッドロックによるプロセスの遅延が長くなってしまいます。 たとえば、起動時間間隔を 30 分に設定すると、 デッドロックがほとんど 30 分間存在し続ける可能性があります。 アプリケーション設計者は、デッドロックを解決するための遅延と、 デッドロックを検出するオーバーヘッドとの間でうまくバランスを保つ必要があります。

区分データベースの場合は、時間間隔は、 すべての区画で同じにする必要があります (dlchktime 構成パラメーターを、 すべての区画で同じ値に更新しなければなりません)。 カタログ・ノードでの値が他の区画での値よりも小さかった場合には、 実際には起きていないのにデッドロックとみなされ検出される場合があります。 カタログ・ノードでの値が他の区画での値よりも大きい場合には、 2 回分より長い時間間隔が経過してからデッドロックが検出されるようなことが起こりえます。 大量のデッドロックが区分データベースで検出される場合には、 dlchktime パラメーターの値を大きくして、 ロック待機や通信待機を解決するようにしてください。

データベースにアクセスする独立したプロセスが複数個あるアプリケーションが、 デッドロックが生じやすい構造になっている場合は、 別の問題が起きる可能性があります。 その一例は、いくつかのプロセスが同じ表にアクセスして、 読み取りを行ってから書き込みを行うようになっているアプリケーションです。 それらのプロセスが最初に読み取り専用 SQL 照会を行い、 次に同じ表に対する SQL 更新を行うと、 プロセス相互間で同じデータに対する競合が生じる可能性があるため、 デッドロックの起きる可能性が大きくなります。 たとえば、2 つのプロセスが同じ表を読み取った後でその表の更新を行うと、 プロセス A がある行に対する X ロックを入手しようとしているが、 プロセス B がその行に対する S ロックを持っている (あるいは、 その反対) という状況になります。 結果として、デッドロックになってしまう可能性があります。 こうしたデッドロックを避けるため、 修正する目的でデータにアクセスするアプリケーションは、 選択を実行するときに FOR UPDATE OF 文節を使用するようにしてください。 それによって、プロセス A がデータを読み取ろうとするとき、 U ロックがかけられるようになります。
注:デッドロックが生じるときに記録されるモニターを定義することもできます。 モニターを作成するには、 SQL 解説書 で説明されている CREATE EVENT ステートメントを使用します。

アプリケーションがニックネームにアクセスする連合システム環境では、 アプリケーションによって要求されたデータが、 データ・ソースでデッドロックが起こっているために使用できない可能性があります。 このことが起こると、 DB2 はデータ・ソースでのデッドロック処理機能により、ロックを解決します。 複数のデータ・ソースにまたがるデッドロックが生じる場合は、 DB2 はデータ・ソースのタイムアウト機構により、デッドロックを解除します。

データベース・マネージャー構成パラメーター diaglevel が 4 に設定され、 ロック要求がデッドロックのために失敗した場合、 db2diag.log にはさらに情報が追加されている可能性があります。 この情報には、オブジェクト、ロック・モード、 およびこのオブジェクトへのロックを保持しているアプリケーションが含まれます。 また、現行の動的 SQL ステートメントまたは静的パッケージも見つかる可能性があります。

ロックに影響する要因

データベース・マネージャーのロックのモードと細分性は、 いくつかの要因によって、つまり、アプリケーションが実行する処理の種類、 アプリケーションがデータをアクセスする方法、 および指定可能なパラメーターによって決まります。

アプリケーションの処理

ロックの属性を決めるために、処理を次の 4 つのタイプのいずれかに分類することができます。

読み取り専用
このタイプには、本質的に読み取り専用である選択ステートメント (カーソルについては SQL 解説書 を参照)、 明示的な FOR READ ONLY 文節を含む選択ステートメント、あるいは、 明示はされていないが PREP コマンドまたは BIND コマンドに指定された BLOCKING オプションの値に基づいて SQL コンパイラーが読み取り専用とみなした選択ステートメントがすべて含まれます。 この場合、必要なのは共用ロック (S または IS) だけです。

変更を意図
このタイプには、FOR UPDATE 文節を含むすべての選択ステートメント、 または不明確なステートメントの解釈の結果として変更を意図したものと SQL コンパイラーがみなした選択ステートメントが含まれます。 この場合、共用および更新ロック (行では S、U、および X、 表では IX、U、X) を使います。

変更
このタイプには UPDATE、INSERT、および DELETE が含まれますが、 UPDATE WHERE CURRENT OF または DELETE WHERE CURRENT OF は含まれません。 これには排他ロック (X または IX) が必要です。

カーソル制御
このタイプには UPDATE WHERE CURRENT OF および DELETE WHERE CURRENT OF が含まれます。 これにも排他ロック (X または IX) が必要です。

副選択ステートメントの結果に基づいて目的の表に挿入、 更新、または削除を行うステートメントは、2 種類の処理を行います。 副選択に返される表のロックは、読み取り専用処理の規則によって決められます。 目的の表のロックは、変更処理の結果によって決まります。

アクセス・パス

アクセス・パス とは、 特定の表参照からデータを取り出すために最適化プログラムによって選択される方式です。 (データ・アクセスの概念と最適化を参照。) 最適化プログラムによって選択されるアクセス・パスは、 ロック・モードに重大な影響を与える可能性があります。 たとえば、索引走査を使ってある特定の行を見つける場合、 最適化プログラムはおそらく表については行レベル・ロック (IS) を選択するでしょう。 このようなアクセスは、次のようなステートメントによって、 EMPLOYEE 表 (従業員番号 EMPNO に基づく索引がある) から単一の従業員についての情報を選択する場合に使用されます。

     SELECT *
       FROM EMPLOYEE
       WHERE EMPNO = '000310';

同様に、索引を用いない場合には、 表全体を順次に走査して選択した行を検索しなければならないので、 単一表レベル・ロック (S) を獲得することになります。 たとえば、SEX 列の索引がない状況で、 次のようなステートメントを使用してすべての男性従業員を選択するという場合には、 このタイプのアクセスが使用されます。

     SELECT *
       FROM EMPLOYEE
       WHERE SEX = 'M';

以下の表に、アクセス・プランの種類ごとにどのようなロックが獲得されるかの概説を示します。 列見出しの定義については、アプリケーションの処理を参照してください。 アクセス方式の定義については、 データ・アクセスの概念と最適化も参照してください。 カーソル制御 型の処理では、 アプリケーションが更新または削除する行を見つけるまで、 基礎となるカーソルのロック・モードを使います。 この種の処理では、カーソルのロック・モードが何であっても、 更新や削除を行うときは必ず排他ロックが獲得されます。

以下の表では、ロック・モードが 1 つだけ表示されている場合、 それは表レベルのロック・モードです。 2 つのロック・モードが表示されている場合、 最初のモードは表レベルのロック・モードで、 2 番目のモードは行レベルのロック・モードです。

表 40. 表走査のロック・モード
分離レベル 読み取り専用 変更を意図 変更
アクセス方式: 述部なしの表走査
RR S U X
RS IS / NS IX / U IX / X
CS IS / NS IX / U IX / X
UR IN IX / U IX / X
アクセス方式: 述部ありの表走査
RR S U U
RS IS / NS IX / U IX / U
CS IS / NS IX / U IX / U
UR IN IX / U IX / U

表 41. 索引走査のロック・モード
分離レベル 読み取り専用 変更を意図 変更
アクセス方式: 述部なしの索引走査
RR S IX / U X
RS IS / NS IX / U IX / X
CS IS / NS IX / U IX / X
UR IN IX / U IX / X
アクセス方式: 単一修飾行の索引走査
RR IS / S IX / U IX / X
RS IS / NS IX / U IX / X
CS IS / NS IX / U IX / X
UR IN IX / U IX / X
アクセス方式: 開始述部と停止述部のみの索引走査
RR IS / S IX / S IX / X
RS IS / NS IX / U IX / X
CS IS / NS IX / U IX / X
UR IN IX / U IX / X
アクセス方式: 述部ありの索引走査
RR IS / S IX / S IX / U
RS IS / NS IX / U IX / U
CS IS / NS IX / U IX / U
UR IN IX / U IX / U

表 42 には、 データ・ページの読み取りの際のロック・モードが据え置かれ、 行のリストに対して以下の処理ができることが示されています。

データ・ページの据え置きアクセスでは、行に対するアクセスが 2 つのステップで行われ、 それによりロックのシナリオがさらに複雑になることを示唆しています。 分離レベルによって 2 つの主要な区分があります。 反復可能読み取り分離レベルは獲得したすべてのロックをトランザクションの終了まで保持するため、 最初のステップで獲得したロックは保持されているので、 2 番目のステップでロックをさらに獲得する必要はありません。 読み取り固定分離レベルおよびカーソル固定分離レベルでは、 2 番目のステップでロックを獲得する必要があります。 並行性を最大化するには、最初のステップでロックを獲得しないで、 修飾行だけが確実に戻されるように、すべての述部を必ず再度適用します。

表 42. 据え置きデータ・ページ・アクセスに使用される索引走査のロック・モード
分離レベル 読み取り専用 変更を意図 変更
アクセス方式: 述部なしの索引走査
RR IS / S IX / S X
RS IN IN IN
CS IN IN IN
UR IN IN IN
アクセス方式: 据え置きデータ・ページ・アクセス (述部なしの索引走査後)
RR IN IX / S X
RS IS / NS IX / U IX / X
CS IS / NS IX / U IX / X
UR IN IX / U IX / X
アクセス方式: 述部ありの索引走査
RR IS / S IX / S IX / S
RS IN IN IN
CS IN IN IN
UR IN IN IN
アクセス方式: 開始述部と停止述部のみの索引走査
RR IS / S IX / S IX / X
RS IN IN IN
CS IN IN IN
UR IN IN IN
アクセス方式: 据え置きデータ・ページ・アクセス (述部ありの索引走査後)
RR IN IX / S IX / S
RS IS / NS IX / U IX / U
CS IS / NS IX / U IX / U
UR IN IX / U IX / U

アクセス・パスはユーザーからは制御されません。最適化プログラムによって選択されます。

使用されるアクセス・パスは、ロックのモードと細分性に影響する可能性があります。 たとえば、反復可能読み取り (RR) 分離レベルを使用しているアプリケーションでは、 述部なしの表走査を使用する UPDATE 照会は表に対して X ロックを使用することになります。 索引を使って行を検索する場合、 データベース・マネージャーは表の個々の行にロックをかけることができます。

宣言済み一時表およびロッキング

宣言済み一時表は、 これらを宣言したアプリケーションのみ使用できるため、 ロックされていません。 このタイプの表は、 アプリケーションがこれを宣言してから、 これを完了または切断するまでのあいだのみ存在します。

LOCK TABLE ステートメント

アプリケーションで LOCK TABLE ステートメントを使用すると、 初期ロック・モードを獲得するための規則を指定変更できます。

このステートメントは表全体にロックをかけます。 LOCK TABLE ステートメントに指定された表だけがロックされます。 指定された表の親表と従属表はロックされません。 アクセス可能な他の表をロックすることが望ましい結果になるかどうかを、 並行性とパフォーマンスの観点から判断する必要があります。 その作業単位がコミットまたはロールバックされるまで、 ロックは解除されません。

表が複数のユーザー間で共用されることが多い場合、 次のような理由から表をロックすることもできます。

LOCK TABLE IN SHARE MODE
時間の点で一貫した データにアクセスしたい、 つまり特定の時点での表の現行データにアクセスしたい場合。 表への活動が頻繁な場合、表全体を一定であるようにするための唯一の方法は、 表をロックすることです。 たとえば、アプリケーションで表のスナップショットを取りたいとします。 しかし、アプリケーションが表のいくつかの行を処理する必要があるときに、 他のアプリケーションが未処理の表を更新しています。 反復可能読み取りではこれが可能ですが、この処置は希望するものとは異なります。

別の手段として、アプリケーションは LOCK TABLE IN SHARE MODE ステートメントを発行できます。 行が取り出されたかどうかに関係なく、行は変更できません。 それら取り出した行が検索前と比べて変更されていないことが分かっているので、 必要なだけの行を取り出すことができます。

LOCK TABLE IN SHARE MODE を使用すると、 他のユーザーは表からデータを検索できますが、 表内の行を更新、削除、または挿入することはできません。

LOCK TABLE IN EXCLUSIVE MODE
表の大部分を更新したい場合。 他のすべてのユーザーがその表をアクセスできないようにすることは、 更新する各行ごとにロックをかけ、 変更をすべてコミットした後で行をロック解除するより安価で効率的です。

LOCK TABLE IN EXCLUSIVE MODE を使用すると、 他のユーザーはすべてロックアウトされます。 他のアプリケーションは、非コミット読み取りアプリケーションでない限り、 表にアクセスすることはできません。

LOCK TABLE ステートメントの詳細については、 SQL 解説書 を参照してください。

LOCK TABLE ステートメントを使用する代わりに、 LOCKSIZE パラメーターを指定した ALTER TABLE ステートメントを使用できます。 LOCKSIZE パラメーターでは、 ROW ロックまたは TABLE ロックのどちらかを選択できます。 どちらを選択しても、次に表がアクセスされるときに、 それが選択されたロックの細分性となります。 ROW ロックを選択することは、 表が作成されるときに省略時ロック・サイズを選択することと何ら変わりありません。 TABLE ロックを選択すると、 獲得する必要のあるロックの数が限定されることによって、 照会のパフォーマンスが向上します。 ただし、すべてのロックが表全体にわたって保持されるので、 並行性は低くなります。 どちらを選択しても、通常のロック・エスカレーションに支障はありません。 ALTER TABLE ステートメントの詳細については、 SQL 解説書 を参照してください。

CLOSE CURSOR WITH RELEASE

CLOSE CURSOR ステートメント (その中に WITH RELEASE 文節が入っている) を使用してカーソルをクローズすると、 データベース・マネージャーは、そのカーソルについて保持された読み取りロックがあるなら、 それらをすべて解放しようとします。 読み取りロックには、表ロック IS、S、U と行ロック S、NS、U があります。 ロック・モードについては、ロックの属性 を参照してください。

WITH RELEASE 文節は、CS または UR の分離レベルで作動しているカーソルには影響がありません。 RS または RR 分離レベルで作動するカーソルに関して WITH RELEASE 文節を指定すると、 それらの分離レベルの保証はいくつか終了してしまいます。 特に、RS カーソルでは非反復可能読み取り 現象が起こり、 RR カーソルでは非反復可能読み取り幻像読み取り 現象が起こることがあります。

もともと RR または RS であるカーソルが、 WITH RELEASE 文節を使ってクローズされた後に再度オープンされた場合は、 新たに読み取りロックが獲得されます。

CLOSE CURSOR ステートメントの他の基本文節との比較については、 DECLARE CURSOR WITH HOLD ステートメントを参照してください。

DB2 CLI 接続属性 SQL_ATTR_CLOSE_BEHAVIOR を CLI アプリケーションで使用すると、 同じ結果を得ることができます。 詳しくは、 コール・レベル・インターフェースの手引きおよび解説書SQLSetConnectAttr() のセクションを参照してください。

ロックについての考慮事項のまとめ

ロックについて注意すべき点は次のことです。


[ ページのトップ | 前ページ | 次ページ | 目次 | 索引 ]