3.4.8　残存エントリによる排他待ちの回避（行識別子の再利用抑止）

インデクスキー値無排他を適用している場合，インデクスのキー値を削除した際に，インデクス格納ページに残存エントリが発生します。この場合，複数のトランザクションでINSERT文，UPDATE文，又はDELETE文を実行したり，定義系SQL文やpdmodを繰り返し実行したりすると，異なるインデクスキー値の操作であっても排他待ちが発生することがあります。ユーザ表の排他待ち発生例を次の図に示します。

［説明］

1. インデクスページには，キーAが格納されています。キーAは，データAの行識別子を持っています。

   データページには，データAが格納されています。また，データページの管理領域には，データAに対応するスロット（行識別子）があります。

   キーAとデータAは，このスロットが示す行識別子によって関連づけられています。

2. トランザクション1によってキーA及びデータAが削除されます。このとき，トランザクション1は決着します。

3. インデクスキー値無排他を適用しているため，インデクスページのキーAは残存エントリとなります。

   データページでは，データAが削除され空き領域ができます。また，スロットの情報も削除され，空きスロットができます。

4. トランザクション2によってキーB及びデータBが追加されます。このとき，トランザクション2は未決着です。

5. 未使用領域にデータBが入らないため，データページではページコンパクションが発生します。

6. インデクスページにキーBが格納されます。

   データページにはデータBが格納されます。このとき，空きスロットが存在するため，データBの行識別子はこの空きスロットを再利用します。

   なお，トランザクション2は未決着のため，キーB（データB）はこのスロットに排他を掛けたままになっています。

7. トランザクション3によって再びキーA及びデータA’が追加されます。

8. キーAには残存エントリがあるため，その残存エントリが前回使用していたスロットを再利用できるかどうか確認します。このとき，スロットは既にキーB（データB）によって排他が掛けられているため，排他待ちが発生します。

この排他待ちは，行識別子の割り当て方法を変えることで回避できます。行識別子は，データを一意に識別するためにシステムが割り当てますが，行が削除されると，その行識別子は再利用されます。同様に，行識別子に対応していたスロットも再利用されます。そのため，残存エントリによる排他待ちが発生してしまいます。この行識別子の再利用を抑止することによって，スロットも再利用されなくなり，排他待ちを回避できます。行識別子の再利用抑止による排他待ちの回避例を次の図に示します。

［説明］

1. インデクスページには，キーAが格納されています。キーAは，データAの行識別子を持っています。

   データページには，データAが格納されています。また，データページの管理領域には，データAに対応するスロット（行識別子）があります。

   キーAとデータAは，このスロットが示す行識別子によって関連づけられています。

2. トランザクション1によってキーA及びデータAが削除されます。このとき，トランザクション1は決着します。

3. インデクスキー値無排他を適用しているため，インデクスページのキーAは残存エントリとなります。

   データページでは，データAが削除され空き領域ができます。また，スロットの情報も削除され，空きスロットができます。

4. トランザクション2によってキーB及びデータBが追加されます。このとき，トランザクション2は未決着です。

5. 未使用領域にデータBが入らないため，データページではページコンパクションが発生します。

6. インデクスページにキーBが格納されます。

   データページには，データBが格納されます。データBの行識別子には，新たなスロットが割り当てられます。このとき，トランザクション2は未決着のため，キーB（データB）はこのスロットに排他を掛けたままになっています。

7. トランザクション3によって再びキーA及びデータA’が追加されます。

8. データA’の行識別子にも新たなスロットが割り当てられるため，排他待ちは発生しません。

〈この項の構成〉

• (1)　適用基準

• (2)　指定方法

• (3)　格納効率が低下するケース