Hitachi

ノンストップデータベース HiRDB Version 10 UAP開発ガイド


3.4.9 残存エントリによる排他待ちの回避(ユニークチェック用排他使用)

インデクスキー値無排他方式では,ユニークインデクスの一意性制約を保証するため行排他を使用して処理します。しかし,この方式では残存エントリによる排他待ちが発生し,新しいキー値を追加するとき残存エントリによる排他待ちが発生することがあります。ユニークチェック用排他による一意性制約保証は,ユニークチェック用の排他を使用して残存エントリによる排他待ちを回避します。ユニークチェック用の排他はユニークインデクスの一意性制約の確認にだけ使用しその他の処理では使用しないため,新たな排他待ちの要因にはなりません。

〈この項の構成〉

(1) 適用基準

ユニークチェック用排他による一意性制約保証を使用すると,ユニーク指定又はプライマリ指定のインデクスのキー値を削除するときに排他を取得します。そのため,排他制御に使用する共用メモリサイズが大きくなります。メモリに余裕があり,確実に残存エントリによる排他待ちを回避したい場合に指定します。増加する排他資源数については,マニュアル「HiRDB システム定義」の「付録D 排他資源数の見積もり」を参照してください。

(2) 指定方法

ユニークチェック用排他による一意性制約保証を使用するには,システム共通定義のpd_unique_check_modeオペランドに1を指定します。詳細は,マニュアル「HiRDB システム定義」の「排他制御に関するオペランド」を参照してください。

(3) ユニークチェック用排他による一意性制約保証による残存エントリの排他待ちについて

ユニークチェック用排他による一意性制約保証を使用しない場合,行排他だけを使用して一意性制約を保証します。そのため,次の図に示すように過去に削除を行い完了したキー値を追加するときに残存エントリ(一意性制約を保障するために削除中に残している削除状態のエントリ)による排他待ちが発生することがあります。

図3‒21 残存エントリによる排他待ちが発生する例

[図データ]

[説明]

(1)行の更新のため,行(R1)に排他モードがEXの排他を取得する。

(2)インデクスキー追加前に削除中のインデクスエントリの行識別子(R1)で行に排他があるかを確認する。

(3)行(R1)に排他があるため,トランザクション1の完了まで行(R1)の行排他で待つ。

ユニークチェック用排他による一意性制約保証を使用することで,次の図で示すように残存エントリによって待ちとなったり,デッドロックが発生したりすることがなくなります。

図3‒22 ユニークチェック用排他による一意性制約保証を使用することによって排他待ちを回避する例

[図データ]

[説明]

(1)行の更新のため,行(R1)に排他モードがEXの排他を取得する。

(2)インデクスキー削除時,トラザクション待ち用に排他モードがEXの排他を,キー値'101M'に対するユニークチェック用に排他モードがSRの排他を取得する。

(3)インデクスキー追加時,残存エントリの行識別子で行の排他があるかを確認する。

(4)(3)で行に排他があるため,行の排他を取得しているトランザクションがユニークチェック用の排他を取得しているかを確認する。

(5)挿入するキーと同じ値のユニークチェック用の排他を取得していないため,キー値の挿入を行ってトランザクション2の処理を続行する。