データベース・マネージャーは、並行性制御が可能になっており、 ロックを使うことによって、無秩序にアクセスがなされることがないようになっています。 ロック はデータベース・マネージャー・リソースをアプリケーションに関連付けて、 そのリソースへの他のアプリケーションからのアクセス方法を制御する手法です。 リソースが関連付けられているアプリケーションは、 ロックを保持または所有していると言われます。
データベース・マネージャーはロックをかけることで、 アプリケーションが他のアプリケーションによって作成された非コミットのデータにアクセスすることがないようにします (ただし、非コミット読み取り分離レベルが使用されている場合は除きます)。 この原則によりデータの整合性 (データの一貫性と機密保護) が保たれます。 さらにロックを使って、行の更新を禁止することができます (反復可能読み取りアプリケーションの場合など)。
データ保全性を保つため、 データベース・マネージャーはデータベース・マネージャー制御の下で暗黙のうちにロックを獲得します。 非コミット読み取り分離レベルを除いては、 非コミット・データを他のプロセスから隠すためにアプリケーションが明示的にロックを要求する必要は全くありません。
ロックの基本原則により、 ほとんどの場合ロックを制御するためのアクションを取る必要はありません。 それでも、アプリケーションは特定の一般的なパラメーターに基づいてロックを獲得します。 ローカルな状況について把握しておくなら、 それらのパラメーターを変更してシステム・リソースを効果的に使用するうえで役立ちます。 ここでは、ロックに関する以下のトピックを説明します。
データベース・マネージャーのロック機能には、以下のような基本属性があります。
以下の表では、モードとその効果が示されています。
ここに示す順に、リソースへの制御が大きくなります。
注: | "意図" ロック・モードを取得するのは、 表と表スペースだけです。 つまり、行には意図ロックは取得されません。 |
アプリケーション・プログラマーは、 ロックの使用に関係するいくつかの関連した要因と、 それがアプリケーションのパフォーマンスに与える影響について知っておく必要があります。 そのような要因には、次のものが含まれます。
あるアプリケーションがロックを保持していると、 別のアプリケーションによるアクセスはできなくなります。 したがって、並行性を最大にするには、表ロックよりも行レベル・ロックが適しています。 しかし、ロックには記憶域が必要になり、また管理のための処理時間も必要になります。 したがって、記憶域と処理時間を最小限にするには、 多くの行ロックよりも 1 つの表ロックの方が適しています。
ALTER TABLE ステートメントの LOCKSIZE 文節を使用すると、 行または表レベルでロックのサイズ (細分性) を定義できます。 省略時では、行ロックが使用されます。 ALTER TABLE で定義した永続表ロックを使うと、S および X 表ロックのみが使用されます。 アプリケーションが多くの行ロックを獲得したり、解放したりする必要がなくなるので、 パフォーマンスは向上します。 次のような場合には、 LOCK TABLE ステートメントを使用して単一トランザクション表をロックするよりも、 ALTER TABLE を使用して永続表ロックをすることができます。
ALTER TABLE ステートメントを使用しても、通常のロック・エスカレーションに支障はありません。
さらに、ALTER TABLE を使用して表レベルでロックするというのはグローバルな方法であることに注目してください。 これは、その表をアクセスするすべてのアプリケーションおよびユーザーに影響を与えます。 個々のアプリケーションで使えるもう 1 つの方法は、 LOCK TABLE ステートメントを使用することです。 これにより、 データベース・レベルではなくアプリケーション・レベルで表ロックをかけることができます (上の 2 番目の黒丸を参照)。
表 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 | はい | はい | いいえ | いいえ | いいえ | いいえ | いいえ | いいえ | いいえ | いいえ | いいえ | はい | いいえ | ||
| |||||||||||||||
|
アプリケーション 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 プロセス当たりのロック数を指定するデータベース構成パラメーターより小さく、 自動調整要求が引き起こされるほどではないためです。 そのプロセスは、トランザクション終了時を除いて、 別のロックを要求したりデータベースにアクセスしたりしないかもしれません。 そして、別のプロセスが、 自動調整要求を引き起こすロックを要求する場合があります。
ロック・エスカレーションによって並行性が受諾不能なレベルまで下がると、 以下のことができるようになります。
現在の動的 SQL ステートメントも記録される場合があります。 記録される場合に、 もし DIAGLEVEL データベース・マネージャー構成パラメーターが 4 であれば、 記録される情報には、どの表ロックの自動調整が行われるよりも前の現在の SQL ステートメントが含まれます。 ロック・エスカレーションが失敗する場合、 もし DIAGLEVEL が 2 以上であれば、 記録される情報には、自動調整が失敗した表と現在の SQL ステートメント (利用可能で、 以前に作成されたのではない場合) が含まれます。
この情報があれば、以下で説明されているその他の点に基づいて、 適切なアクションを実行できます。
このタイプの情報を記録し始めるには、 データベース・マネージャー構成パラメーター DIAGLEVEL を 3 (省略時値) または 4 に設定します。
ロック・タイムアウト検出を指定していない場合、異常終了時には、 ロックが解放されるまでアプリケーションの無期限待機が必要になることがあります。 たとえば、あるトランザクションが別のユーザーによって保持されているロックを待機しており、 一方でそのユーザーが実行中のトランザクションをアプリケーションがコミットできるように対話を実行してロックを解放するということをせずに作業場から席をはずしてしまった場合に、 そうなります。 明らかに、この結果アプリケーションのパフォーマンスが低下します。 こうしたケースでプログラムが停止 しないようにするには、 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 つのタイプのいずれかに分類することができます。
副選択ステートメントの結果に基づいて目的の表に挿入、 更新、または削除を行うステートメントは、2 種類の処理を行います。 副選択に返される表のロックは、読み取り専用処理の規則によって決められます。 目的の表のロックは、変更処理の結果によって決まります。
アクセス・パス とは、 特定の表参照からデータを取り出すために最適化プログラムによって選択される方式です。 (データ・アクセスの概念と最適化を参照。) 最適化プログラムによって選択されるアクセス・パスは、 ロック・モードに重大な影響を与える可能性があります。 たとえば、索引走査を使ってある特定の行を見つける場合、 最適化プログラムはおそらく表については行レベル・ロック (IS) を選択するでしょう。 このようなアクセスは、次のようなステートメントによって、 EMPLOYEE 表 (従業員番号 EMPNO に基づく索引がある) から単一の従業員についての情報を選択する場合に使用されます。
SELECT * FROM EMPLOYEE WHERE EMPNO = '000310';
同様に、索引を用いない場合には、 表全体を順次に走査して選択した行を検索しなければならないので、 単一表レベル・ロック (S) を獲得することになります。 たとえば、SEX 列の索引がない状況で、 次のようなステートメントを使用してすべての男性従業員を選択するという場合には、 このタイプのアクセスが使用されます。
SELECT * FROM EMPLOYEE WHERE SEX = 'M';
以下の表に、アクセス・プランの種類ごとにどのようなロックが獲得されるかの概説を示します。 列見出しの定義については、アプリケーションの処理を参照してください。 アクセス方式の定義については、 データ・アクセスの概念と最適化も参照してください。 カーソル制御 型の処理では、 アプリケーションが更新または削除する行を見つけるまで、 基礎となるカーソルのロック・モードを使います。 この種の処理では、カーソルのロック・モードが何であっても、 更新や削除を行うときは必ず排他ロックが獲得されます。
以下の表では、ロック・モードが 1 つだけ表示されている場合、
それは表レベルのロック・モードです。
2 つのロック・モードが表示されている場合、
最初のモードは表レベルのロック・モードで、
2 番目のモードは行レベルのロック・モードです。
分離レベル | 読み取り専用 | 変更を意図 | 変更 |
---|---|---|---|
アクセス方式: 述部なしの表走査 | |||
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 |
分離レベル | 読み取り専用 | 変更を意図 | 変更 |
---|---|---|---|
アクセス方式: 述部なしの索引走査 | |||
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 IN SHARE MODE ステートメントを発行できます。 行が取り出されたかどうかに関係なく、行は変更できません。 それら取り出した行が検索前と比べて変更されていないことが分かっているので、 必要なだけの行を取り出すことができます。
LOCK TABLE IN SHARE 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 文節が入っている) を使用してカーソルをクローズすると、 データベース・マネージャーは、そのカーソルについて保持された読み取りロックがあるなら、 それらをすべて解放しようとします。 読み取りロックには、表ロック 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() のセクションを参照してください。
ロックについて注意すべき点は次のことです。