データベース論トランザクション・分散データベース編

Transaction Management / Distributed Database Management

データベース論

トランザクション・分散データベース編

森下　真一

平成１４年度　夏学期


トランザクション管理

参考文献

Jeffrey D. Ullman: Principles of Database and Knowledge-base SystemsVolume I, Computer Science Press, 1988. ISBN 0-7167-8158-1

Chapter 9 Transaction Management


トランザクション管理の重要性

更新が必要なデータベース座席予約システムダブルブッキングの回避高速な処理時間よりもデータ更新の安全性を確保したい

読み出すことが中心のデータベース統計データベースWWW データベース並列な読み出し要求を数多く処理したい

トランザクション

データの読み出しや書き込みからなる処理の単位並列に実行される


例題普通預金口座　 A

T2: 1000 円を引き出すトランザクション

READ A;A := A - 1000;WRITE A;

T1: 1000 円を振り込むトランザクション

READ A;A := A + 1000;WRITE A;

A4000

T1: READ AT2: READ AT1: WRITE A 5000T2: WRITE A 3000

スケジュール：　時間軸に沿ってステートメントを並べた列

A4000

T1: READ AT1: WRITE A 5000T2: READ AT2: WRITE A 4000

順番に実行するスケジュール


例題普通預金口座　 A, B

T2: B から A へ５０００円送金

READ A;A := A + 5000;WRITE A;

READ B;IF B >= 5000 B := B - 5000;WRITE B;

T1: A から B へ２０００円送金

READ A;IF A >= 2000 A := A - 2000;WRITE A;

READ B;B := B + 2000;WRITE B;

A B4000 4000

T1 2000T1 6000T2 7000T2 1000

A B4000 4000

T2 9000T1 7000T1 6000T2 1000

A B4000 4000

T2 9000T1 7000T2 abort

T2 の影響を元に戻す必要あり

実行スケジュール例


トランザクションの原子性（ Atomicity ）の保証

整列スケジュールでは各トランザクションを原子のような塊として実行する。

原子性を保証するとは、各トランザクションを並列に実行するとき、最終結果が、ある整列スケジュールの結果と一致することを保証すること。

A B4000 4000

T2 9000T1 7000T2 abortT2 復帰 7000-5000

=2000T1 6000

例A B4000 4000

T1 2000T1 6000

整列スケジュール


Lock


データベースの更新単位をアイテム、アイテムの大きさを粒度（ granularity ）と呼ぶ

アイテムへのアクセスはロックにより管理排他的なロックのかかっているアイテムには他のトランザクションのアクセスを禁止

アイテムの粒度が大きい場合、ロック管理システムの負担は軽くなるが、同時に実行できるトランザクション数は減る

粒度の選択は典型的トランザクションを考えてきめる預金口座のように小さい単位でトランザクションが実行される場合は粒度は小さくする


ロックは様々な種類があるが当面は一種類とし、アイテム A に対するロックを LOCK 　 A 　と記述

•　 A がロックされている間は他のトランザクションは A にアクセスできない

トランザクション T

アイテム A

ロックマネージャー

•　トランザクション T はアイテム A に READ/WRITE する前に　 LOCK 　 A 　をロックマネージャーに要求　

LOCK A要求

•　ロックマネージャーはアイテム A にロックがかかっていない場合に T が LOCK A することを許可

許可

•　 T は A に対する処理を終了したら、ロックマネージャーに　 UNLOCK 　 A 　を要求し、ロックマネージャーはアイテム A に対するロックを解除

UNLOCK 　 A

Transaction Management / Distributed Database Management例題普通預金口座　 A

T2: 1000 円を引き出すトランザクション

LOCK A;READ A;A := A - 1000;WRITE A;UNLOCK A;

T1: 1000 円を振り込むトランザクション

LOCK A;READ A;A := A + 1000;WRITE A;UNLOCK A;

A4000

T1: LOCK AT1: READ AT2: READ A

A4000

T1: LOCK AT1: READ AT1: WRITE A 5000T1: UNLOCK A


A4000




各トランザクションは一つのアイテムに高々一回だけ LOCK をかける

TLOCK A;A := A+1;UNLOCK A;LOCK B;LOCK A;B := B+A;UNLOCK A;UNLOCK B;

TLOCK A;A := A+1;LOCK B;B := B+A;UNLOCK A;UNLOCK B;


Livelock

トランザクション Ti

LOCK A;READ A;A := A + i ;WRITE A;UNLOCK A;

T1 が最初に A をロック

T2, T3 が　 LOCK A 　を要求

T1 が　 UNLOCK 　 A

ロックマネージャーがT3にロックを許可

T4 が　 LOCK A 　を要求

T3が　 UNLOCK 　 A

ロックマネージャーがT4 にロックを許可T2 に順番が回らない　 Livelock

簡単な回避方法　 (First-come-first-served strategy)LOCK 　 A 　を要求するトランザクションに要求順にロックを許可　


Deadlock


LOCK B;LOCK A;

READ A;A := A + 5000;WRITE B;READ B;IF B >= 5000 B := B - 5000;WRITE B;

UNLOCK B;UNLOCK A;


LOCK A;LOCK B;

READ A;IF A >= 2000 A := A - 2000;WRITE A;READ B;B := B + 2000;WRITE B;

UNLOCK A;UNLOCK B;

T1: LOCK A; 　許可T2: LOCK B; 　許可

T1: LOCK B; 　不許可T2: LOCK A; 　不許可

T1 と T2 は永遠に待ちつづける


プロトコルを工夫して Deadlock を起こさない手法１

各トランザクションは同時にすべてのロック要求を出すロックマネージャーは、この全要求を許可するか、全てを不許可


LOCK B;LOCK A;READ A;A := A + 5000;WRITE B;READ B;IF B >= 5000 B := B - 5000;WRITE B;UNLOCK B;UNLOCK A;


LOCK A;LOCK B;READ A;IF A >= 2000 A := A - 2000;WRITE A;READ B;B := B + 2000;WRITE B;UNLOCK A;UNLOCK B;

T1: LOCK A 　許可T1: LOCK B 　許可

T1: UNLOCK AT1: UNLOCK B

T2: LOCK B 　許可T2: LOCK A 　許可


•　アイテムに順序を導入

•　各トランザクションは　　順序の大きい順に　　アイテムをロック


LOCK B;LOCK A;：


LOCK A;LOCK B;：

A 　＞　 B


LOCK A;LOCK B;：

T1 の実行後に T2 が処理される

プロトコルを工夫して Deadlock を起こさない手法２


アイテムに順序を入れる方法が Deadlock を起こさない理由

観察：　各トランザクション Ti は他のトランザクション Ti+1 がロックしているアイテム Ai の開放を待っている

前処理：　アイテムをロックしていないトランザクションを除いても、集合は依然として Deadlock 状態

Ti Ti+1Ai

注意Ti は Ai より順序の大きいアイテムをロック

背理法：　 Deadlock 状態のトランザクション集合があると仮定

Ti

LOCK Ai

Ti+1

LOCK Ai

LOCK Ai+1

Ti+2

LOCK Ai+1

LOCK Ai+2Ai 　＞ Ai+1 Ai+1 　＞ Ai+2


ある T1 を選択して、鎖を構成

T1 T2A1

T3A2

A1 　＞ A2 　 Tn は , いつか An-1 をUNLOCK. アイテムをロックしていない Tn が必ず存在し、矛盾

ループしない有限の下降鎖

TnAn-1

＞…… . ＞ An-1 　

Ti

LOCK Ai

Ti+1

LOCK Ai

LOCK Ai+1

Ti+2

LOCK Ai+1

LOCK Ai+2Ai 　＞ Ai+1 Ai+1 　＞ Ai+2


スケジューラーが Deadlock を検知して abort 等で対処する方法

Waits-for Graph T2: B から A へ５０００円送金

LOCK B;LOCK A;：UNLOCK B;UNLOCK A;


LOCK A;LOCK B;：UNLOCK A;UNLOCK B;


トランザクションがノード

T1 T2A

B

T1 がロックしているアイテム Aの UNLOCK を T2 が待っているとき、「 T1 の次は T2」を表現するため T1 から T2 へ有向辺を引きA をラベルとしてつける

閉路の存在は Deadlockを意味する


整列化可能性(Serializability)


トランザクションの集合をある順序で整列化した列をT1 T2 …… Tk

i=1,2,…,k の順番で Ti のステートメントを実行するスケジュールを整列スケジュール (serial schedule) と呼ぶ

トランザクションをプログラムしたときのユーザの心境は各トランザクションの実行を他のトランザクションが邪魔しないことを仮定している

つまりトランザクション全体がある整列スケジュールとして実行されることを思ってプログラムする


しかしシステムは効率を重視してトランザクションの順番を入れ替えて実行するかもしれない

入れ替えをしても、その実行結果はある整列スケジュールの実行結果と一致してほしい

スケジュールが整列化可能とは、実行結果がある整列スケジュールの実行結果と一致することと定義する

この概念をどのように定式化するか？


T2: B の x 倍をA へ振り込む

LOCK B;READ B;UNLOCK B;LOCK A;READ A;A := A+B＊ x;WRITE A; UNLOCK A;

T1: A の x 倍をB へ振り込む

LOCK A;LOCK B;READ A;READ B;B := B+A＊ x;WRITE B; UNLOCK A;UNLOCK B;

T2: LOCK B;T2: READ B;T2: UNLOCK B;

T1: LOCK A; LOCK B;T1: READ A; READ B;T1: B := B+A ＊ x; WRITE B; T1: UNLOCK A; UNLOCK B;

T2: LOCK A;T2: READ A;T2: A := A+B ＊ x;T2: WRITE A; T2: UNLOCK A;

T1 B:=B+A*xT2 A:=A+B*x

T2 A:=A+B*xT1 B:=B+A*x


A=B=1000 x=2

T2: B=1000

T2: A=3000T1: B=3000

T1: B=3000T2: A=7000

T2: A=3000T1: B=7000

A=0B=1000 x=2

T1: B=1000T2: A=2000

T2: A=2000T1: B=5000

T2: B=1000

T2: A=2000T1: B=1000

整列化不可能

整列化可能？


スケジュール S1 が整列化可能とは、ある整列スケジュール S2 が存在して任意の初期状態に対して、S1 と S2 の実行結果が一致することと定義した場合：

初期状態の候補は無限にあり、有限ステップでチェックできるか？

帰納的関数がある場合、２つの帰納的関数の等価性は一般に決定不能

スケジュール S1 が整列化可能とは、ある整列スケジュール S2 が存在して任意の初期状態に対して、LOCK と UNLOCK以外は任意をステートメントを許す場合にS1 と S2 の実行結果が一致することと定義する






f1(A, B)g1(A, B) f2(A, B)

g2(B)

LOCK A と UNLOCK A のペアに対して新しい関数 f を割当てる

f の引数は UNLOCK A の前にトランザクション中でロックされる全てのアイテムの値

T2: LOCK B;T2: UNLOCK B; g2(B)

T1: LOCK A; T1: LOCK B;T1: UNLOCK A; f1(A,B)T1: UNLOCK B; g1(A,B)

T2: LOCK A;T2: UNLOCK A; f2(A,B)

A B

f2(f1(a,g2(b)), g1(f1(a, g2(b)), g2(b)))

g1(f1(a, g2(b)), g2(b))f1(a, g2(b))

g2(b)a b






f1(A, B)g1(A, B) f2(A, B)

g2(B)

T1: LOCK A;T1: LOCK B;T1: UNLOCK A;T1: UNLOCK B;T2: LOCK B;T2: UNLOCK B;T2: LOCK A;T2: UNLOCK A;

A Ba b

f1(a,b)g1(f1(a,b), b)

g2(g1(f1(a,b), b))

f2(f1(a,b), g2(g1(f1(a,b), b)))

整列スケジュール１






f1(A, B)g1(A, B) f2(A, B)

g2(B)

T2: LOCK B;T2: UNLOCK B;T2: LOCK A;T2: UNLOCK A;T1: LOCK A;T1: LOCK B;T1: UNLOCK A;T1: UNLOCK B;

A Ba b

g2(b)

f2(a, g2(b))

f1(f2(a,g2(b)), g2(b))g1( f1(f2(a,g2(b))), g2(b))

整列スケジュール２


３つのスケジュールの最終結果

A B

f2(f1(a,g2(b)), g1(f1(a, g2(b)), g2(b)) g1(f1(a, g2(b)), g2(b)))

整列スケジュール１ f2(f1(a,b), g2(g1(f1(a,b), b)) g2(g1(f1(a,b), b)))

整列スケジュール２ f1(f2(a,g2(b)), g2(b)) g1( f1(f2(a,g2(b))), g2(b))

記号列として異なる場合、最終結果が異なるように初期状態とステートメントをつくれる

記号列は UNLOCK の実行履歴を表現している


整列化可能性を判定するアルゴリズム


スケジュールの整列化可能性を判定するアルゴリズム

スケジュールは　 T: LOCK A または T: UNLOCK Aの形をしたステートメントの列 a1, a2, …, an とする

整列化可能性判定グラフの構成各 a i =T p: UNLOCK Am について aj = Tq: LOCK Am 　 (p≠q) となる j > i が存在する場合、最小の j を選択し有向辺を張る

整列化可能な場合に対応する整列スケジュール中で T p は T q の前にある

定理　グラフに閉路がなければ整列化可能、あれば不可能

T p T q

Am

T p を始点とし Am をラベルにもつ有向辺は高々１つ


T2: LOCK AT2: UNLOCK A


T1: LOCK BT1: UNLOCK B



T1

T2 T3

整列化可能性判定グラフ閉路がない場合

A

B

B

この関係は考慮しない

B

引かない

任意の始点から出る有向辺で同一ラベルをもつ辺は高々一つ



閉路のないグラフでは、同一アイテムをラベルにもつ有向辺は、連続した列をつくる

T3

T4

T5

T2

AT1T1: LOCK A

T1: UNLOCK A :T2: LOCK AT2: UNLOCK A

:T3: LOCK AT3: UNLOCK A :T4: LOCK AT4: UNLOCK A

:T5: LOCK AT5: UNLOCK A

与えられたスケジュール


一般には複数のアイテムに対する列が交差する


整列化可能性判定グラフ G の位相ソート

閉路がない場合にはGにはいかなる有向辺の終点でないノード v が存在する

存在しないと仮定すれば、あるノードから有向辺を逆に辿る列をつくると、ノード数が有限なので、いつかは自分に戻る閉路ができる

このステップを繰返し、除かれたノード（トランザクション）列T1 T2 …… Tk 　を位相ソート列と呼ぶ

v と v を始点とする有向辺を G から除く

位相ソート列を使って整列スケジュールを作る


位相ソート列　 T1, T2, T3


T2: LOCK AT2: UNLOCK AT2: LOCK BT2: UNLOCK B

T3: LOCK AT3: UNLOCK AT3: LOCK BT3: UNLOCK B







T1

T2 T3

A

B

B

整列化可能性判定グラフ整列スケジュール



T3

T4

T5

T2

AT1T1: LOCK A

T1: UNLOCK A :T2: LOCK AT2: UNLOCK A

:T3: LOCK AT3: UNLOCK A :T4: LOCK AT4: UNLOCK A

:T5: LOCK AT5: UNLOCK A


位相ソートから得られる整列スケジュール内でアイテム A に対するロックはT1, T2, T3, T4, T5の順序で起こる


定理前半　　スケジュール S の整列化可能性判定グラフ G が閉路を含まない場合、位相ソートでつくった整列スケジュール R は S と等価

ノード N の深さ d(N)

N を終点とする有向辺の始点を N の隣接点

N M1

Mk

:

d(N) = 0 　　 N に隣接点がない　　　 = max{ d(M) | M は隣接点 }+1

0 0 0

1 1

2 2 1

準備


スケジュール S と R で、同じトランザクションは同一のアイテムに関して同じ値を読むことを証明

深さに関する帰納法

深さ０のとき、各アイテムの値は初期状態だから、 OK

T 深さｋ

S, R で T がアイテム A をLOCK する直前に A を UNLOCKするトランザクションを T’とする

深さｋ未満

A

T’

帰納法の仮定で S と R は T’ で A に同一の値を読み込む

S と R は T でも A に同一の値を読み込む


T2: LOCK B;T2: UNLOCK B;

T1: LOCK A; T1: LOCK B;T1: UNLOCK A;T1: UNLOCK B;

T3: LOCK A;T3: UNLOCK A;


T2

T1

整列化可能性判定グラフ閉路がある場合

B

T3

A

A


T1

T2

Tp-1

Tp

Tk

定理後半　スケジュール S の整列化可能性判定グラフが閉路を含む場合、 S は整列化不可能

Ti (i=1,…k)の中で Tp が R に最初に現れるとする

Tp-1: UNLOCK A g(…)

Tp: LOCK A:

Tp: UNLOCK A f(…)

仮に等価な整列スケジュール R があるとする

R では f(…) に g(…) は出現しない . S では出現 .

R と S は等価でないので矛盾

S

Tp: LOCK A:

Tp: UNLOCK A f(…)

R


T1

T2

Tp-1

Tp

Tk

Tp: LOCK A

Tp-1: LOCK BTp-1: UNLOCK B g(B)

Tp: LOCK B:

Tp: UNLOCK A f(A,B)

R では f(…) に g(…) は出現しない . S では出現 .

R と S は等価でないので矛盾

S

Tp: LOCK ATp: LOCK B

:Tp: UNLOCK A f(A,B)

R

もう一つ例


整列化可能性判定グラフ

T2: LOCK B;T2: UNLOCK B;

T1: LOCK A; T1: LOCK B;T1: UNLOCK A; g(…)T1: UNLOCK B;

T3: LOCK A; T3: UNLOCK A; f(…)


T2

T1B

T3

A

A


T3: LOCK AT3: UNLOCK A f(…)

:


２相ロックプロトコル(Two-phase Locking Protocol)


２相ロックプロトコル

各トランザクションにおいて、すべての LOCK 文は、すべての UNLOCK 文の前に実行する

定理２相ロックプロトコルに従ってできたスケジュール S は、必ず整列化可能


２相ロックの正当性の証明

背理法

整列化不可能な場合、整列化可能性判定グラフには閉路あり

T1

T2

T3

T4

T1 の UNLOCK 後に T2 の LOCK

T2 の UNLOCK 後に T3 の LOCK

Tk の UNLOCK 後に T1 の LOCKT5

Tk:

T1 は UNLOCK後に LOCK しており２相ロックプロトコルに従うことに矛盾


２相ロックプロトコルの最適性条件は少しでも緩めると整列化可能性は失われる

T1 は２相ロックプロトコルに従わないとする

T1LOCK A :UNLOCK A :LOCK B :UNLOCK B :

T2LOCK ALOCK BUNLOCK AUNLOCK B

T1: LOCK A:

T1: UNLOCK A

T2: LOCK AT2: LOCK BT2: UNLOCK AT2: UNLOCK B

T1: LOCK B:

T1: UNLOCK B

T1

T2

A B


注意　２相ロックプロトコルでDeadlock を回避できるわけではない


LOCK B;LOCK A;

READ A;A := A + 5000;WRITE B;READ B;IF B >= 5000 B := B - 5000;WRITE B;

UNLOCK B;UNLOCK A;


LOCK A;LOCK B;

READ A;IF A >= 2000 A := A - 2000;WRITE A;READ B;B := B + 2000;WRITE B;

UNLOCK A;UNLOCK B;


T1: LOCK B; 　不許可T2: LOCK A; 　不許可

T1 と T2 は永遠に待ちつづける


ここまでの　まとめ

•　整列化可能性の概念を定義

•　整列化可能であることと　　整列化可能性判定グラフが閉路を含まないことは同値

•　２相ロックプロトコルは整列化可能の十分条件

課題

•　いろいろなＬＯＣＫに対して整列化可能性判定グラフの　　技法をどこまで拡張して適用できるのか？

•　２相ロックプロトコルはどこまで有効か？


Read Only Lock / Write Lock を使うモデル


Read Lock (RLOCK と記述 )

•　読み込むだけのデータにかける鍵•　他のトランザクションが Write Lock してないデータにかけられる

Write Lock (WLOCK)

•　読み書きするデータにかける鍵•　他のトランザクションが Read Lockも Write Lock もしていないデータにかけられる

Read LockがかかっているデータにRead Lockは可能だが、 Write Lock は不可能

Write LockがかかっているデータにRead Lockも Write Lock も不可能


対応する整列スケジュールスケジュール

スケジュールの整列化可能性

T1 T2RLOCK A : RLOCK AUNLOCK A :

UNLOCK A

T1 T2RLOCK A :UNLOCK A

RLOCK A :UNLOCK A

T1 T2RLOCK A :UNLOCK A

RLOCK A :UNLOCK A

RLOCK 間の関係からトランザクションに順序を定義しなくても構わない点が違うだけ。他の場合は以前と同様。


RLOCK / WLOCK の場合の整列化可能性判定グラフの構成

RLOCK A (or WLOCK A)

:UNLOCK A

Ti Tm

WLOCK A

Ti : UNLOCK A 　と Tm : WLOCK A の間で WLOCK A は出現しない

ケース１ Ti Tm


RLOCK A :

UNLOCK A

Ti

WLOCK A

Tm

RLOCK A :

UNLOCK A

Tj

WLOCK A :

UNLOCK A

Tk

Tm

Ti Tj Tk


Ti Tm

ケース２

RLOCK A

Tm

WLOCK A :UNLOCK A

Ti

Ti: UNLOCK A と各 RLOCK A の間で WLOCK A は出現しない

Tn

RLOCK A

Tn


WLOCK A を中心に考えるとわかりやすい

Tm: WLOCK A Tm

・・

複数の RLOCK A単一の WLOCK A

・・

複数の RLOCK A単一の WLOCK A


T1 T2 T3 T4

WLOCK ARLOCK B

UNLOCK ARLOCK A

UNLOCK BWLOCK B

RLOCK AUNLOCK B

WLOCK BUNLOCK A

UNLOCK AWLOCK A

UNLOCK BRLOCK B

UNLOCK AUNLOCK B

T3

T2T1

T4


T1 T2 T3 T4

WLOCK ARLOCK B

UNLOCK ARLOCK A

UNLOCK BWLOCK B

RLOCK AUNLOCK B

WLOCK BUNLOCK A

UNLOCK AWLOCK A

UNLOCK BRLOCK B

UNLOCK AUNLOCK B

T3

T2T1

T4


T1 T2 T3 T4

WLOCK ARLOCK B

UNLOCK ARLOCK A

UNLOCK BWLOCK B

RLOCK AUNLOCK B

WLOCK BUNLOCK A

UNLOCK AWLOCK A

UNLOCK BRLOCK B

UNLOCK AUNLOCK B

T3

T2T1

T4


T1 T2 T3 T4

WLOCK ARLOCK B

UNLOCK ARLOCK A

UNLOCK BWLOCK B

RLOCK AUNLOCK B

WLOCK BUNLOCK A

UNLOCK AWLOCK A

UNLOCK BRLOCK B

UNLOCK AUNLOCK B

T3

T2T1

T4 T3

T2T1

T4


T1 T2 T3 T4

WLOCK ARLOCK B

UNLOCK ARLOCK A

UNLOCK BWLOCK B

RLOCK AUNLOCK B

WLOCK BUNLOCK A

UNLOCK AWLOCK A

UNLOCK BRLOCK B

UNLOCK AUNLOCK B

T3

T2T1

T4 T3

T2T1

T4


定理

整列化可能性判定グラフが閉路をもてば、スケジュールは整列化不可能

閉路がないグラフであれば、位相ソートを使ってトランザクションを整列化し、等価な整列スケジュールを生成できる

証明は LOCK－ UNLOCK の場合の考え方と同様


２相ロックプロトコル

トランザクションは、RLOCK と WLOCK 要求を全て実行した後に UNLOCK を行う

定理２相ロックプロトコルを使う場合、整列化可能性は保証される

証明は LOCK－ UNLOCK の場合の考え方と同様


木構造をしたデータ・アイテムを

扱うプロトコル


木構造をしたデータ構造

•　 HTML, XML

•　 B-tree

•　データベース　全体→各関係→ファイル→レコード


木プロコトル (tree protocol)

各トランザクションは以下の規則に

従ってアイテムをロックをかける .

1. アイテムをロックできるのは、

親アイテムをロックしているとき。

最初にロックするアイテムはこの条件を満たさなくてよい。また最初にロックするアイテムは根ノードである必要がなく、任意のアイテムを選択できる。

2. １つのアイテムを複数回ロックしない。

A

B C

D E

F G


T1 T2 T3LOCK ALOCK BLOCK DUNLOCK B

LOCK BLOCK C

LOCK EUNLOCK D

LOCK FUNLOCK A

LOCK GUNLOCK C

UNLOCK ELOCK E

UNLOCK FUNLOCK B

UNLOCK GUNLOCK E

A

B C

D E

F G



LOCK BLOCK C

LOCK EUNLOCK D

LOCK FUNLOCK A

LOCK GUNLOCK C

UNLOCK ELOCK E

UNLOCK FUNLOCK B

UNLOCK GUNLOCK E

A

B C

D E

F G



LOCK BLOCK C

LOCK EUNLOCK D

LOCK FUNLOCK A

LOCK GUNLOCK C

UNLOCK ELOCK E

UNLOCK FUNLOCK B

UNLOCK GUNLOCK E

A

B C

D E

F G



LOCK BLOCK C

LOCK EUNLOCK D

LOCK FUNLOCK A

LOCK GUNLOCK C

UNLOCK ELOCK E

UNLOCK FUNLOCK B

UNLOCK GUNLOCK E

A

B C

D E

F G



LOCK BLOCK C

LOCK EUNLOCK D

LOCK FUNLOCK A

LOCK GUNLOCK C

UNLOCK ELOCK E

UNLOCK FUNLOCK B

UNLOCK GUNLOCK E

A

B C

D E

F G



LOCK BLOCK C

LOCK EUNLOCK D

LOCK FUNLOCK A

LOCK GUNLOCK C

UNLOCK ELOCK E

UNLOCK FUNLOCK B

UNLOCK GUNLOCK E

A

B C

D E

F G


A

B C

D E

F G

A

B C

D E

F G

A

B C

D E

F G

A

B C

D E

F G

A

B C

D E

F G

A

B C

D E

F G


木プロトコルは２相ロックプロトコルではない

T1 T2LOCK ALOCK BLOCK DUNLOCK B

LOCK BLOCK C

しかし木プロトコルに従うスケジュールは整列化可能である

Abraham Silberschatz and Zvi Kedem: “Consistency in Hierachical Database Systems.” Journal of the ACM, Vol.27, No.1, Jan. 1980, pp.72-80.


証明の概略

トランザクション T が最初にロックするアイテムを FIRST(T)

２つのトランザクション Ta 　 , Tb についてFIRST(Ta) FIRST(Tb) が先祖と子孫の関係にない場合：

Ta 　と Tb が共通のアイテムをロックすることはない

FIRST(Ta) FIRST(Tb )


補題　 Ta 　と Tb が少なくとも 1つの共通するアイテムをロック。

共通するすべてのアイテムを先に Ta 　もしくは Tb がロック。

FIRST(Ta) FIRST(Tb) が先祖と子孫の関係にある場合

共通してロックするアイテムは木構造を成す

最も根ノードに近いノードを X とする

X を Ta 　が先にロックすると仮定


X

P

背理法： Tb が Ta 　より先にロックするアイテム Y が存在すると仮定

Z

Y

Ta 　が先

Tb 　が先

矛盾

•　 Ta 　はいつか Y をロック

•　 Tb 　もいつか X をロック

•　ある Z と親ノード P で矛盾


(1) 根ノードをロックするトランザクションは整列化可能

(2) 各部分木のアイテムだけロックするトランザクションは整列化可能

(3) 補題より (1)の整列に (2) の整列を各々独立に融合することが可能

木プロトコルに従うスケジュールは整列化可能である

深さに関する帰納法根ノードだけの場合

一般の場合


トランザクションの abort

COMMITMENT

Cascading Rollback


いままではトランザクションが必ず完了するケースを扱ってきた

•　個々のトランザクションが自ら abort するユーザの割り込み、０による割り算、権限のないアクセス

•　スケジューラが deadlockを検知し ,abort で deadlock 回避

•　整列性を保証するためにトランザクションの abort を強制するプロトコルを使う場合

しかし現実には完了しないまま abort するケースが多い

• システムダウン


T1

LOCK 　 AREAD 　 AA := A-1WRITE ALOCK BUNLOCK AREAD BB := B/AWRITE BUNLOCK B

T2

LOCK AREAD AA := A+2WRITE AUNLOCK A

トランザクションの２つの計算状態

•　計算実行中 (active)•　計算完了 (completed)　　あとはアイテムに結果を書くだけ

計算実行中

計算完了

計算実行中

計算完了


計算の完了を宣言する文 COMMIT

T1

LOCK 　 AREAD 　 AA := A-1WRITE ALOCK BUNLOCK AREAD BB := B/A

COMMIT

WRITE BUNLOCK B

T2

LOCK AREAD AA := A+2

COMMIT

WRITE AUNLOCK A


T1 T2 A=1, B=1LOCK 　 AREAD 　 AA := A-1 A := 0WRITE ALOCK BUNLOCK A

LOCK AREAD AA := A＋ 2 A := 2

READ BCOMMITWRITE AUNLOCK A

B := B/A B := 1/0COMMITWRITE BUNLOCK B

この時点で T1 のabort が発生

Cascading rollback（なだれ的な巻き戻し）

T1 が abort したので、 A の値を T1 の実行以前の状態に戻す必要がある

すると、ここでの更新も戻す必要がある


T1 T2 A=1, B=1LOCK 　 AREAD 　 AA := A-1 A:=0WRITE ALOCK BUNLOCK A

LOCK AREAD AA := A＋ 2 A:=2

READ BCOMMITWRITE AUNLOCK A

B := B/A B := 1/0COMMITWRITE BUNLOCK B

Dirty Read

T2: READ A は　 T1 の計算が完了する以前（ T1:COMMIT の前）に T1: WRITE A 　が書き出した値を読んでいる

T1 はその後 abort し、

T2 が読んだ A の値は無効になり cascading rollbackを生む


２つの課題

•　 Dirty Read の回避

•　 Cascading rollback の回避

COMMIT, WRITE の位置を工夫して解決


Dirty Read の回避 T1

LOCK 　 AREAD 　 AA := A-1WRITE ALOCK BUNLOCK AREAD BB := B/A

COMMIT

WRITE BUNLOCK B

COMMIT つまり計算の完了を宣言してからWRITE を実行する

T1

LOCK 　 AREAD 　 AA := A-1

LOCK B

READ BB := B/A

COMMIT

WRITE AUNLOCK AWRITE BUNLOCK B


T1LOCK 　 AREAD 　 AA := A-1LOCK BREAD BB := B/ACOMMITWRITE AUNLOCK A

LOCK AREAD AA := A+2COMMITWRITE AUNLOCK A

WRITE BUNLOCK B

T2

•　 T2:READ A はもはやDirty Read ではない（計算が完了 COMMIT したあとの WRITE A の値を読んでる）

•　しかし、 T1: WRITE Bで abort すれば、Cascading Rollback が発生


T1 T2LOCK 　 AREAD 　 AA := A-1LOCK BREAD BB := B/ACOMMITWRITE AWRITE BUNLOCK AUNLOCK B

LOCK AREAD AA := A+2COMMITWRITE AUNLOCK A

Cascading Rollback の回避

すべての WRITE が完了するまで UNLOCK を実行しない

あるアイテムの値を読むとき、その値を書き出したトランザクションが abort することはない


強２相ロックプロトコル(strict two-phase locking protocol)

•　 WRITE の実行は COMMIT の後

•　すべての WRITE が完了するまで UNLOCK を実行しない


障害発生時のデータベース修復


記憶媒体の信頼性

主記憶揮発性記憶装置

電源障害時にデータが消えるsystem failure

二次ディスク　永続的記憶装置テープ

ヘッドクラッシュなど深刻な障害(media failure)　の時以外はデータが残る


System failure 発生時のデータベース修復

修復に備えデータベース更新履歴をとるログ (log)　ジャーナル (journal)

• トランザクション　 T の起動(T, begin)

• T がアイテム A の値が w のとき、値 v を書き込む(T, A, w, v)

• T がコミットしたとき(T, commit)

• T がアボートしたとき(T, abort)


再実行プロトコル (Redo Protocol)　

ログを生成する強２相ロックプロトコル

トランザクション T が COMMIT 文に達したとき、以下の処理を実行

•　トランザクション T が、値が w のアイテム A に値 v を書き出すとき、 T 内の順番に従って

(T, A, w, v)をログに書き込む。　ただし、 COMMIT 以前に A に対して w は計算された値であること。

•　 (T, commit) をログに書き込む

ログは新たな書き込みが起こるたびに二次記憶装置に書き込む

w

A

T

v


トランザクション T ログの内容A=10, B=20 　のとき

LOCK A (T, begin)LOCK B

A := A+1 (T, A, 10, 11) B := B+1 (T, B, 20, 21)

COMMIT (T, commit)

WRITE AWRITE B

UNLOCK AUNLOCK B

ログにまず書きこむ

続いてデータベースに書きこむ


ログを使ったデータベース修復の手順

•　障害発生時に各トランザクションが握るロックは開放させる

•　各トランザクションに対して最新の (T, commit) を見つける(T, begin)(T, A1, w1, v1)

: この順番で書き込みを再実行(T, An, wn, vn)(T, commit)

•　トランザクション T について、 (T, commit) がない場合、強２相ロックプロトコルなので、 T の WRITE 文は実行されない

•　 (T, abort) がある場合、 T の更新履歴はすべて破棄する


トランザクション T ログの内容A=10, B=20 　


A := A+1 (T, A, 10, 11) B := B+1 (T, B, 20, 21)

COMMIT (T, commit)

WRITE AWRITE B

UNLOCK AUNLOCK B

System Failure の際に値を戻す手順

計算も未完了でアイテムの値をWRITEしていないのでなにもしない

COMMIT直後以降は計算が完了しているので、A に 11 、 B に 21 を書き出す

既に正しい値である場合でも書く


トランザクション T ログの内容A=10, B=20 　


A := A+1 (T, A, 10, 11) B := B+1 (T, B, 20, 21)

COMMIT (T, commit)

WRITE AWRITE BUNLOCK AUNLOCK B

Abort の場合、トランザクション実行前の状態に戻す

A=11 B=21

A=10 B=20


チェックポイント処理 (checkpointing)

主記憶にあるデータ更新の履歴を二次記憶装置へ書き込む操作

abort や system failure が発生してもチェックポイント実行前の状態に戻さない

そこで各トランザクションの COMMIT 以降の状態を保存する

•　すべてのトランザクションの実行要求を禁止する•　実行中のトランザクションが abort するか、もしくは終了するまで待つ•　二次記憶への書き出しが済んでいない主記憶中のブロックを書き出す•　ログの最後に checkpoint が済んだことを書きこむ


Media failure への対処

•　 system failure への対処方法は二次記憶の信頼性に完全に依存している

•　ディスクヘッドが故障したり、子供が磁石でディスクをなでたり、天変地異がおこったりなど、 media failure に完全には対応できない

•　基本的には、定期的にバックアップをとる

•　更新の頻度は、夜間に一回から連続的まで様々


タイムスタンプ方式の並列実行制御


整列化可能性 (serializability) を LOCK により実現してきた

他に現実システムで使われている手法　：　タイムスタンプ方式

•　各トランザクションは実行を開始するときスケジューラを呼ぶ

•　スケジューラは実行開始時間をタイムスタンプとして与える

•　複数のトランザクションはタイムスタンプの順番で整列化する

•　タイムスタンプ方式は積極的プロトコルの例で、不具合が生じた時点で abort 等により不整合を修復

•　ロックを使ったスケジュールから導かれる整列化した順序とは必ずしも一致しない　


T1 T2READ B

READ AWRITE C

WRITE C

タイムスタンプ方式

2 1T1 T2

READ BREAD AWRITE C

WRITE C

T2 → T1

ロック方式

WLOCK が読み書き両方のロックの場合

T1 T2 :

:WLOCK CWRITE CUNLOCK C

WLOCK CWRITE CUNLOCK C

T1 → T2


タイムスタンプの発行

•　トランザクションの数をカウントし、次の番号をタイムスタンプとして与える

•　時計の時間を与える


タイムスタンプを使ったトランザクションの整列化

各アイテムごとに、 read time と write time を管理

•　 Read Time (RT)　　現在をふくめ現在に最も近い時刻に　　アイテムを読み出したトランザクションのタイムスタンプ

•　 Write Time (WT)　　現在をふくめ現在に最も近い時刻に　　アイテムを書き出したトランザクションのタイムスタンプ


T1 T2 A

ﾀｲﾑｽﾀﾝﾌﾟ 150 160 RT=0WT=0

READ A RT=150READ A RT=160

A:=A+1A:=A+1WRITE A WT=160

WRITE A WT=150 ??

対応する整列スケジュール T1 → T2


各アイテムに対する読み書き時間による整列化可能性チェック

•　未来に書き込まれるアイテムの値を、現在は読めない

　　 t1 < t2 をタイムスタンプとするとき、　　 t2 のトランザクションが書いたアイテム (WT=t2) を　　 t1 のトランザクションは読めない

•　未来に読み込まれるアイテムの値を、現在上書きできない

　　 t1 < t2 をタイムスタンプとするとき、　　 RT=t2 のアイテムに t1 のトランザクションは書きこめない

どちらの場合も、 t1 のトランザクションを abort し、新しいタイムスタンプで再実行


T1 T2 A

ﾀｲﾑｽﾀﾝﾌﾟ 150 160 RT=0WT=0



WRITE A WT=150

RT=160 > 150 なので T1 は abort


READ-READ の場合

T1 T2 A

ﾀｲﾑｽﾀﾝﾌﾟ t1 t2 RT=0(t1 < t2)

READ A RT=t2READ A RT=t2

RT=t2 > t1 でも読み込んで不具合が生じないRT=t2 はそのまま　 (RT=t1 としない）


T1 T2 A

ﾀｲﾑｽﾀﾝﾌﾟ t1 t2 WT=0(t1 < t2)

WRITE A WT=t2WRITE A WT=t2

WT=t2 > t1 のとき、 A に何も書き出さない未来に書き出される値に過去の値を上書きできない

整列スケジュールでは T1 のあと T2 を実行し、T1 の WRITE 　 A の値を T2 が上書き

WT=t2 はそのまま　 (WT=t1 としない）

WRITE-WRITE の場合


T1 T2 T3 A B C

200 150 175 RT=0 RT=0 RT=0WT=0 WT=0 WT=0

READ B RT=200READ A RT=150

READ C RT=175WRITE B WT=200WRITE A WT=200

WRITE C WT=150abort

WRITE A WT=175書き出さない


タイムスタンプを使った整列化可能性チェックのまとめ

アイテム A (RT = rt, WT = wt) にタイムスタンプ t のトランザクションが操作 X (= READ or WRITE) を行うとき

•　 X=READ かつ t < wt ならば abort

•　 X=WRITE かつ t < rt ならば abort 　

•　 X=WRITE かつ t≧rt かつ t<wt ならば書き出さない

•　 X=READ かつ t≧wt ならば実行し RT:=t　　　

• X=WRITE かつ t≧rt かつ t≧wt ならば実行し WT:=t

正常な場合


タイムスタンプ方式は積極的プロトコルの例

•　同一アイテムの読み書きが競合する可能性のない場合に有効

•　不具合が生じたところでトランザクションを abort して対処


タイムスタンプの管理

•　ロックで管理する場合はロックしているアイテムだけを表に登録すればよい

•　タイムスタンプの場合、各アイテムごとに RT, WT を管理

•　アイテム数が多い場合、管理表が大きくなる


解決案　

•　実行中のトランザクションのタイムスタンプの最小値を M

　　 M は生きている最も古いトランザクションのタイムスタンプ

•　 M より小さいタイムスタンプは全て -∞ にしても　　整列化可能性のチェックは同様に実行できる

　　新しく実行されるトランザクションのタイムスタンプは　　必ず M より大きいから

•　 RT=WT= -∞ となるトランザクションは管理表から外す


タイムスタンプ方式での障害発生時の

データベース修復


Abort および障害発生時の対応

•　タイムスタンプ方式での同時実行制御は積極的プロトコル

•　 abort 時や障害発生時のデータベース修復に手間

•　 Dirty Read と Cascading Rollback に弱い

•　ログの管理による対処

•　 COMMIT の利用


T1 T2 T3 A B C

200 150 175 RT=0 RT=0 RT=0WT=0 WT=0 WT=0

READ B RT=200READ A RT=150WRITE A WT=150

READ C RT=175READ A RT=200WRITE B WT=200WRITE A WT=200

WRITE C WT=150abort

abort

Cascading Rollback の例


タイムスタンプ方式での COMMIT の利用

•　すべての計算を完了した時点で COMMIT 　を宣言

•　すべての更新したアイテムの値を書き出す

注意点

•　トランザクション T のタイムスタンプを t

•　 T が WRITE するアイテムの RT を rt

•　 t < rt ならば abort

•　 t < rt の確認を commit 以前に行えば、データベースに影響を与えずにトランザクションを abort できる

Dirty Read の回避

T A(timestamp=t)

:

COMMIT RT=rt

WRITE A


例

•　 T のタイムスタンプを 100

•　 T は最後に WRITE A と WT:=100 を実行

•　 A の RT < 100 であることを確認して T は計算を開始

•　 A の値をタイムスタンプ 110 のトランザクション　 T’ が読み、RT := 110 とする

•　 T は commit 直前に A の RT を読み、 RT=110 であることを知り abort

ロックをつかった abort 回避

RT をチェック後、 WT:=100 を実行し A をロックする

T’ が A の値を読み出すことを禁止

WRITE A を実行RT のチェックは既に行っているので不要

T (timestamp=100) :

COMMITWRITE A


ロックを使い abort を回避する方法１

•　 WRITE A をするトランザクション T (タイムスタンプ t) は、

- 計算開始時に A に対して WT=t として、 A をロック- 計算途中で abort した場合、 A のロックを開放し、　 A の WT を元に戻す

•　 commit に到達したら、ログに T の計算した値を書き出す

•　 (T, commit) をログに追加

•　データベースに T の計算した値を書き出す

•　アイテムのロックを開放

•　長時間アイテムをロックする傾向にあるが、前ページのabort は回避できる


T T’ A100 110（実行開始） RT=90　　：　　：

READ A RT=110COMMIT 100 < RT=110 abortWRITE A

T T’ A100 110（実行開始） RT=90WLOCK A WT=100　　　：　　　：COMMITWRITE AUNLOCK A

RLOCK AREAD A RT=100


ロックを使い abort を回避する方法 2楽観的方法 (Optimistic Method)

•　 T が commit する直前に、 T が読み書きするすべてのアイテムをロックし、タイムスタンプの整合性をチェックし、abort か commit を判断

- abort の場合、 A のロックを開放し、　 A の WT を元に戻す

•　 commit の場合、ログに T の計算した値を書き出す•　 (T, commit) をログに追加•　データベースに T の計算した値を書き出す•　アイテムのロックを開放

• 最初のステップでは、トランザクション実行中に RT が更新されるアイテムがないと　楽観的に考えている


T T’ A100 110（実行開始） RT=90　　：　　：

READ A RT=110WLOCK A 100 < RT=110 abortUNLOCK ACOMMITWRITE A

T T’ A100 110（実行開始） RT=90　　：　　：WLOCK A RT=90 < 100 no problemUNLOCK ACOMMITWRITE A WT=100

READ A RT=110


複数バーション法

•　トランザクション T がアイテム A に書くとき A の新バーション Ai をつくり、 WT を T のタイムスタンプとする (例外を後述 )

•　タイムスタンプ t のトランザクション T の READ A は、t 以下で t に最も近い WT のバーション Aj の値を読む

T1 T2 A0 A1 B0 B1

100 200 RT=0 RT=0WT=0 WT=0

READ A RT=100READ A RT=200WRITE B WT=200

READ B RT=100

T1: READ B はバーション B0 の値を読む


T1 T2 A B

100 200 RT=0 RT=0WT=0 WT=0

READ A RT=100READ A RT=200WRITE B WT=200

READ B RT=100abort

複数バーションをもたない場合

複数バーションをもち、すこし古い値にアクセスを許すことで、上のような abort を回避できる

しかしバーション管理は余分な記憶スペースを必要とする


新バーションを生成できずに abort する場合

•　タイムスタンプ t のトランザクション T がアイテム A に書くとき、 WT < t < RT となる A のバージョンが存在する

T1 T2 A0 A1

150 160 RT=0WT=0



WRITE Aabort

A0 は時刻 0 から少なくとも 160 までは生きているT1: WRITE A は時刻 150 で A の値を変更するので abort


•　何もしない素朴な方法問題が起こったら abort で対処

•　ロックを使って abort を回避ロックする時間が長くなる

•　 COMMIT 前に瞬間的にロックまた abort の危険性がでる

•　複数バージョン法素朴な方法に比べ abort する頻度は減るバージョン管理にスペースを食う


難しい場合：　対立するトランザクションによる abort の繰返し

T1 T2 T1 T2 A B

100 110 120 130 RT=0 RT=0WT=0 WT=0

WRITE B WT=100 WRITE A WT=110

READ A RT=100abort

WRITE B WT=120 READ B RT=110 abort

WRITE A WT=130READ A RT=120abort

再実行

再実行

abort の繰返しを回避する効果的な方法はあまりない再実行のタイミングをランダムにずらすことで対立を多少緩和


分散データベース管理

参考文献

Jeffrey D. Ullman: Principles of Database and Knowledge-base SystemsVolume I, Computer Science Press, 1988. ISBN 0-7167-8158-1

Chapter 10 Distributed Database Management


•　前回までは単一計算機に格納されたデータベースへのトランザクション処理を解説

•　複数計算機上に分散して存在するデータベースへのトランザクション処理は多少複雑化

- 　２相ロックプロトコル

- 　分散 deadlock 検知と回避

- 　分散コミットメント　２相コミットプロトコル


ノード（サイト）CPU + Disk



リンク

LAN専用電話回線

etc.

ネットワーク


ネットワークの故障・障害

•　ノードの故障、リンクの故障

分散データベースの resiliency (弾力性 )

•　複数のアクセスパスをもつネットワークの形態で補強

リング　メッシュ　ハイパーキューブ

•　データの複製により補強

アイテムの値のコピーを、必要なノードに配布


データの複製をもつ場合の注意点

•　アイテム A の値を変更するとき、 A の全コピーの値を変更

•　一つのまとまった原子的な操作に見せかける

障害発生時

•　 A のコピーをもつノード N が停止

•　 A の値を知りたいトランザクションは N 以外のノードから値を入手

•　 N が復活したとき、 A に最新の値をセット


N1コピー A

N2コピー A

N3コピー A

N4コピー B

N5コピー B

グローバルトランザクション T

口座 A から 10000 円を引き落とし口座 B へ 10000 円振込み

•　各ノードごとにコピーＡから 10000 円減額する「ローカル　サブトランザクション」を実行

•　全コピーの更新をするか否か

•　あるノードでトランザクションが abort したら全更新を無効にする


各ノードにおけるロックマネージャーの動作

トランザクション

ロックマネージャー

アイテム WLOCK ?A YB NC Y: :

アイテムに複数のコピーがある場合

複数のコピーのロックを同時に取る

WLOCK A 　要求

許可または拒否


Write-Locks-All Read-Locks-One

•　 WLOCK A (書きこみ専用ロック ) を実行するにはA のすべてのコピーを WLOCK A すればよい

•　 RLOCK A (読取り専用ロック ) を実行するにはA の一つのコピーを RLOCK A すればよい

• A のコピーをもつ各ノードでは

　 - WLOCK がかかっていなければ RLOCK を許可　　（複数の RLOCK を許可）

　 - RLOCK と WLOCK いずれも　かかってなければ　　 WLOCK を許可


アイテム A にロックをかけようとする任意のトランザクションを T1, T2

•　 T1, T2 は同時に A に WLOCK をかけられない

•　 T1 は WLOCK 、 T2 は RLOCK を同時にかけられない

•　唯一可能なのは T1 と T2 が同時に RLOCK すること

T1: WLOCK A T2:RLOCK A


Write-Locks-All のメッセージ数

N0A

N1A

NnA

WLOCK A

承認

更新データ

A のコピーは n 個

１回の WLOCK A

2n 個の制御メッセージ(WLOCK A 、承認 )

n 個の更新データ

NiA… …


Read-Locks-One のメッセージ数

•　 A のコピーを持つあるノード　 N に RLOCK A を要求

•　 N が RLOCK A を許さない場合、他のノードに要求すべきか？

•　 RLOCK A の許可が下りないのは WLOCK A が実行されている場合

•　他のサイトも RLOCK A は拒否するので、少し待って RLOCK A


過半数ロック戦略

• WLOCK A (書きこみ専用ロック ) を実行するにはA のコピーの過半数を WLOCK A すればよい

•　 RLOCK A (読取り専用ロック ) を実行するにはA のコピーの過半数を RLOCK A すればよい

• A のコピーをもつ各ノードでは

　 - WLOCK がかかっていなければ RLOCK を許可

　 - RLOCK と WLOCK いずれも　かかってなければ　　 WLOCK を許可


アイテム A にロックをかけようとする任意のトランザクションを T1, T2

•　 T1, T2 は同時に A に WLOCK をかけられない•　 T1 は RLOCK 、 T2 は WLOCK を同時にかけられない•　唯一可能なのは T1 と T2 が同時に RLOCK すること

T1 T2


過半数ロック戦略のメッセージ数

•　アイテム A のコピーが n 個ある場合

• (n+1)/2 　以上のノードに WLOCK (or RLOCK) A を要求

•　ロックと承認あわせて n+1 個以上のメッセージを送信


制御メッセージ数

WLOCK RLOCK

Write-Locks-All 2n 2

過半数ロック戦略 n+1 以上 n+1 以上

トランザクションが２つの場合Write-Locks-All deadlock する可能性大過半数ロック戦略どちらかは WLOCK を取れる

トランザクションが３つ以上の場合過半数ロック戦略でも deadlock する可能性あり


過半数ロック戦略の一般化 k-of-n 戦略 (n/2 < k ≦ n)

•　 WLOCK A (書きこみ専用ロック ) を実行するにはA の k 個のコピーを　 WLOCK A すればよい

•　 RLOCK A (読取り専用ロック ) を実行するにはA の (n-k)+1 個のコピーを RLOCK A すればよい

T1: WLOCK A T2: RLOCK A

k 個 (n-k)+1 個

Write-Locks-All n-of-n 戦略過半数ロック戦略 (n+1)/2-of-n 戦略


分散２相ロック


TT1 T2WLOCK A1 WLOCK A2UNLOCK A1 UNLOCK A2

UU1 U2WLOCK A1 WLOCK A2UNLOCK A1 UNLOCK A2

T1 U1 T2 U2

WLOCK A1UNLOCK A1 WLOCK A2

UNLOCK A2WLOCK A1UNLOCK A1 WLOCK A2

UNLOCK A2

Write-locks-all で各コピーをロック（同時にコピーを更新できない例）

アイテム A のサイト S1, S2 でのコピーを A1, A2

T1 → U1 U2 → T2

S1 S2


サブトランザクション (例えば T1, T2) の同期が必要

•　サブトランザクション全体での２相ロックプロトコルを考える必要がある

•　すべてのサブトランザクションが必要なアイテムを LOCK した後に、 UNLOCK を開始するように制御したい

•　分散合意問題 (distributed agreement problem)

•　 COMMIT を使った強２相ロックプロトコル方式による解法


T

T1 T2

WLOCK A1 WLOCK A2COMMIT COMMITUNLOCK A1 UNLOCK A2

U

U1 U2

WLOCK A1 WLOCK A2COMMIT COMMITUNLOCK A1 UNLOCK A2

COMIMIT を使った強２相ロックプロトコル方式による解法

•　すべてのサブトランザクションが COMMIT に達した時点で、トランザクション全体がコミットしたと考える

•　分散コミットメント（後に説明）により全サブトランザクションの合意を確認


強２相ロックプロトコル方式での deadlock 問題

（アイテム A, B はコピー持たないものの deadlock が起こる）

TT1 T2WLOCK A WLOCK BCOMMIT COMMITUNLOCK A UNLOCK B

UU1 U2WLOCK A WLOCK BCOMMIT COMMITUNLOCK A UNLOCK B

T1 U1 T2 U2

WLOCK A WLOCK BCOMMIT COMMIT

UNLOCK A WLOCK A WLOCK B UNLOCK BCOMMIT COMMIT UNLOCK A UNLOCK B

deadlock状態


分散データベース環境での deadlock 回避

アイテムへの全順序の導入

•　アイテムに全順序を入れる

•　トランザクションは、すべてのサブトランザクションが全順序に従ってアイテムにロックをかけるように調整


TT1 T2WLOCK A

WLOCK BCOMMIT COMMITUNLOCK A UNLOCK B

UU1 U2WLOCK A

WLOCK BCOMMIT COMMITUNLOCK A UNLOCK B

T1 U1 T2 U2

WLOCK AWLOCK B

COMMIT COMMIT UNLOCK A UNLOCK B

WLOCK AWLOCK B

COMMIT COMMITUNLOCK A UNLOCK B


時間切れ方式

•　待ち時間に上限値を設け、時間切れしたトランザクションは abort

•　待ち時間の上限値の調節

　　 - deadlock 状態にあるトランザクションが不必要にアイテムをロックし続けない程度に短くする

- deadlock 状態にないトランザクションを不必要に

abort させない程度に長くする

•　制御メッセージの通信を伴わない



T1 U1 T2 U2

WLOCK A WLOCK BCOMMIT COMMIT

UNLOCK A WLOCK A WLOCK B UNLOCK BCOMMIT COMMIT UNLOCK A UNLOCK B

Waits-for-Graphs

deadlock状態

T U T U

T U



分散コミットメント


分散データベースでのトランザクション

分散した計算機上で動作する複数の部分トランザクションにより実行される

部分トランザクションの中から調整役 (coordinator)を選ぶ

その他を参加者 (participants)　と呼ぶ


調整役

参加者 i

全参加者がコミットを表明する場合、全体としてもコミット

ある参加者がアボートを表明する場合、全体としてもアボート

参加者は

•　 vote-commit ( コミットの表明 )　

または

•　 vote-abort (アボートの表明 )

を調整役に送信

投票

調整役は

•　全参加者がvote-commit の場合は全参加者に commit を送信し、全体としてコミットすることを伝える

•　ある参加者がvote-abort の場合は全参加者に abort を送信し、全体としてアボートすることを伝える　　

決定

投票の後に決定を下す２つの相からなるので２相コミット (two-phase commit) とよぶ


初期状態

コミット終了

コミット宣言中

アボート終了

初期状態

コミット終了

コミット処理中

アボート処理中

アボート終了

vote-commit 送信

vote-abort 送信またはabort 受信

abort 受信

commit 受信

すべての参加者からvote-commit を受信

ある参加者からvote-abort を受信

commit 送信

abort 送信

参加者

調整役


初期状態

コミット終了


アボート終了

vote-commit 送信


abort 受信

commit 受信

参加者

ブロック状態

参加者 T がコミット宣言中に調整役から commit, abort いずれのメッセージも受信しない状態。　通信路の信頼性に対する不安

勝手に先に進むと問題が発生。


参加者 T がブロック状態で勝手に先に進むと微妙な問題が発生

勝手にコミット終了へ進むとき

•　 T はコミット後に、アイテム A の値を更新•　 T が更新した A の値を、ある参加者 T’ が読む•　他の参加者がアボートを宣言し、全体がアボート•　 T’ はアイテム A を Dirty Read したことになる

初期状態

コミット終了


アボート終了

vote-commit 送信


Ｔ以外はabort 受信

Ｔは勝手に進む

T が A へ書きこみT’ が Dirty Read


•　調整役が全参加者から vote_commit の受信を確認後に、T と調整役の通信が切断されたと仮定•　調整役からの commit は T 以外の参加者には送信され、これらの参加者は A のローカルコピー値を更新•　しかし T だけは commit の知らせが入らず、勝手にアボートするので、 A を更新しない•　 T とその他の参加者で A のローカルコピー値が同一でなくなる

勝手にアボート終了に進むとき

初期状態

コミット終了


アボート終了

vote-commit 送信


T は勝手に進む

Ｔ以外はcommit 受信


調整役ではなく、他の参加者に助けを求める (help-me 送信 )

•　コミット終了状態の参加者は、全体がコミットしたことを知るT に commit を送信

•　アボート終了状態の参加者は、全体がアボートしたことを知るT に abort を送信

•　初期状態にある参加者は、アボートすることで、全体を　アボートさせ、ブロック状態から抜け出る状況をつくれる

調整役には vote-abort を送信T には abort を送信

•　コミット宣言状態の参加者は、同じブロック状態にあり、　状況を変えられない

コミット宣言中の参加者 T がブロック状態から抜け出るには


初期状態


コミット終了

ブロック状態

アボート終了

救助を待つ

abort 受信

commit 受信

時間切れ

help-me 送信

commit 受信

abort 受信


vote-commit 送信

参加者


•　調整役が最終的に abort を送信する場合、commit を受信しない

　仮に commit を受信すれば、全体がコミットしたことを知る参加者から受信するので矛盾

•　調整役が最終的に commit を送信する場合、abort を受信しない

　仮に abort を受信すれば、全体のアボートを知る参加者からの受信か、初期状態の参加者 T’ が abort を決断した場合。後者の場合、調整役は初期状態ののち、 T’ から abort を受信し、最終的に abort を送信。矛盾。

•　 commit と abort を同時に受信しない

help-me を送信した参加者は矛盾した情報を受信しない


•　 help-me を使う場合、各参加者が助けを求める参加者リストを知る必要がある

•初期状態の前に参加者リストを知らせる begin-vote

メッセージを全参加者に送信

その他の修正

待ち状態

コミット終了

コミット処理中

アボート処理中

アボート終了

すべての参加者からvote-commit を受信

時間切れまたはある参加者からvote-abort を受信

commit 送信

abort 送信

初期状態

begin-vote 送信

調整役


•　２相コミット開始時に、参加者と調整役との通信が確立しない場合はアボートする

•　参加者の場合 begin-vote の受信が時間切れになるとアボートする•　調整役の場合、参加者から vote の受信が時間切れになるとアボートする

その他の修正

初期状態

考察中コミット宣言中

コミット終了

ブロック状態

アボート終了

救助を待つ

vote-commit 送信


abort 受信

commit 受信

Begin-vote 受信

時間切れ

時間切れ

help-me 送信

commit 受信abort 受信参加者


初期状態

考察中コミット宣言中

コミット終了

ブロック状態

アボート終了

救助を待つ

vote-commit 送信


abort 受信

commit 受信

Begin-vote 受信

時間切れ

時間切れ

help-me 送信

commit 受信abort 受信参加者

ここでブロック状態に陥るケース


調整役

vote-commit を送信

調整役

直後に回線が切断

commit 送信 commit を受信しない .help-me を出してもブロック状態から抜けないこの参加者は

commit の先に進み、データベースを更新してよいのか？

一部の参加者だけが commit を知る状況


•　２相コミットはデータベース製品で普及しているが、ブロック状態に陥る可能性が残っている

•　２相コミットは、全参加者が vote-commit した後は、commit するプロトコル

•　３相コミットは、全参加者が vote-commit した後に、全参加者が「全参加者が vote-commit したこと」を知ったのち commit するプロトコル

•　メッセージ通信コストが高く、現実には殆ど使われていない

３相コミット

Documents

データベース論 トランザクション・分散データベース編

データベース論トランザクション・分散データベース編