トランザクション管理機構

トランザクション管理機構
トランザクション
• A logical unit of database processing
– Includes one or more db operations
– Begin transactions, End transactionsでくくる。
– ひとつのＡＰが複数のトランザクションを含み得る
• Granularity
– これからの議論はかなりsimplifyする。
– データベースはnamed data itemsの集まりと仮定
– 実際には、フィールド、レコード、ディスクブロックであったり
する。しかし、ここでの議論はgranularityとは独立に展開す
ることが可能である。
Read & Write
• Read_item(X):Xと名付けられたデータをプ
ログラム変数に取り込む操作を指す。ここ
で簡単の為、プログラム変数もＸとする。
• Write_item(X):Xと名付けられたデータ
ベース内のアイテムＸをプログラム変数Ｘ
に読み込む操作を指す。
Read & Writeの実際
• 実際にはディスクとのやりとりは既に物理データ
ベース構造のところで議論したようにブロック。
–
–
–
–
Read_item(X)
１Ｘを含むディスクブロックのアドレスを計算
２当該ブロックをメインメモリのバッファへ読み込む
３バッファ内のアイテムＸをプログラム変数へコピー
する。
– Write_item(X)も同様
• ディスクブロックへの書き出しはＯＳとリカバリマ
ネジャ（checkpointing)によって決められる
replacement policyに従って書き戻される。
Concurrency Control の役割
• 複数のトランザクションが多数のユーザによって
発行される時、何も制御しないと問題が発生する。
• 飛行機の予約のためのアクセスプログラム
– 例：次ページ
– Ｔ１：フライトＸからフライトＹへ団体旅行者をＮ席移動
– Ｔ２：フライトＸにＭ席を予約
• 不都合な問題
– Lost Update Problem
– Dirty Read Problem
– Incorrect Summary Problem
フライト座席予約トランザクションの例
Lost Update Problem
Dirty Read Problem
Incorrect Summary Problem
Failure(障害）
• Databaseではトランザクション内の全ての
オペレーションを完了するか或いは、何も
しないかを保証することが求められており、
中途半端な実行はシステムに矛盾を発
生っさせるため避けねばならない。
• 一方、システム障害により途中で処理が止
まってしまうこと自体は有り得る
– １．System Crash: hardware, software, network障害等
がトランザクション実行中に発生
– ２．Transaction or system error: トランザクション内での
数値オーバフローなどによりトランザクションプログラ
ムに障害が発生。パラメタ不正。ユーザからの割り込
み
– ３．Local Error/Exception: トランザクションを中止しな
くてはならないような状況が発生してしまった場合を指
す。例えばトランザクションにとって必要なデータが
存在しない。銀行の引き出しトランザクションで残額が
少ない時にはトランザクションのキャンセルになるが、
これ自身はプログラム動作として正しく書かれており、
failureとは言わない。そもそもプログラムが正しく記述
されていればtransaction failureにはならない。
– ４．Concurrency Control Enforcement:シリアライザビリ
ティを維持するため、あるいはデッドロックを解消する
ためにＣＣがトランザクションをアボートし、再試行する。
– ５．Disk Failure: ディスク読み書き中に発生
– ６．Physical Catastrophes: 電源故障、空調問
題、火事、泥棒、などなど。
• １，２，３，４は比較的良く発生する。５，６
は稀。独自のリカバリルーチンが対応
トランザクションの状態遷移
• トランザクションはアトミックでなければならない
が、それを保証するにはトランザクションがどの
ような状態遷移を行っているかをトレースしておく
必要がある。リカバリマネジャは以下をトレース
する。
–
–
–
–
–
Begin_trans:
Read, Write:
End_trans:
Commit_trans:
Rollback( Abort):
トランザクションの状態遷移
ログ（ＬＯＧ）
• トランザクション実行中に発生した障害か
らの回復の為、ログが利用される。
• データアイテムの値の変更に関するすべ
てのデータベース操作を記録。
• ログはディスクに記録される。ディスク障害
以外の障害からはプロテクトされると仮定
• 更に、定期的にテープにアーカイブされカ
タストロフィーにも対処する。
ログへの記録
•
•
•
•
•
Start_trans, T :
Write_item,T,X,old_value, new_value :
Read_item,T,X :
Commit,T :
Abort,T :
• ログへの書き込みデータはプロトコルに依存。
Cascadless protocolを利用する場合には
before_imageは不要となる。しかしauditなどの為
もあり書き込むことも多い。ログ量は増える。
• ログを利用した操作
– ＵＮＤＯ：
– ＲＥＤＯ：
コミットポイント
• トランザクション内のすべてのデータベース操作が成功
し、すべての操作情報がログに記録された時を指す。
• コミットポイント以降、トランザクションによてなされた更
新は持続的にデータベースに反映されることになる。
[commit, T]書き込み
• ＵＮＤＯ
• ＲＥＤＯ
• force_write
再登場ＡＣＩＤ
• Ａ：Atomicity, all or nothing property
• C: Consistency, トランザクションの実行がコミット
された場合にはconsistentな状態に遷移する。
• Ｉ：Isolation, トランザクションはあたかも自分一人
が実行しているかのように見える他のトランザク
ションから干渉されない。
• Ｄ：Durability, いかなる障害があろうともコミットし
たトランザクションによる変更は永続的なものと
なる。（しなくてはならない）
Ｓｃｈｅｄｕｌｅ
• 複数のトランザクションが同時にインターリ
ブして実行される環境を想定する時、各ト
ランザクションからのread/write操作の実行
順序をscheduleと呼ぶ。
• ここではどのようなスケジュールは障害回
復可能かを見て行くことにする。
Ｓｃｈｅｄｕｌｅ
• Ｓ： schedule
• Ｔ：Ｔ１，Ｔ２，Ｔ３，．．．
• Ｔｉ内のoperationはそこでの順序と同じ順序でＳ
内に現われるものとする。
– ここでＴｊはインターリーブ
•
•
•
•
R(read), W(write), C(commit), A(abort)を考える
例
Sa: r1(X);r2(X);w1(X);r1(Y);w2(X);w1(Y);
Sb: r1(X);w1(X);r2(X);w2(X);r1(Y);a1;
• Conflict of two operations
– Belong to different transactions
– Access the same data item.
– At least one of the operations is write.
Ｒｅｃｏｖｅｒａｂｌｉｔｙ
• あるscheduleは障害からの回復が容易で
あり、又、別のscheduleは回復処理が複雑
になることがある。
• 従って、回復可能なscheduleを明らかにす
ることは重要。或いは、回復が容易な
scheduleを明らかにすることが重要

Download Report