制約 (第 3 回の講義参考 ) に従ったデータ変更チェック
制約に違反する変更はさせない→トランザクションは失敗する
I :
隔離性(Isolation)
トランザクションが成功するまで、トランザクションの変更結 果は他のトランザクションには見せない
トランザクションが成功したら、その結果が他のトランザク
DBMS のトランザクション管理 (2) ：原 子性 (1)
トランザクションが失敗してもいいように
変更を元に戻すのに必要な情報を記録しておく
これをアンドゥログという
記録場所、記録方法はデータベースによってまち まち
トランザクションが失敗したら、アンドゥログを 使ってデータベースを元に戻す トランザクションの開始と終了はデータ
ベースではわからない
DBMS のトランザクション管理 (2) ：原 子性 (2)
アンドゥログを使って失敗を元に戻すDBMS のトランザクション管理 (3) ：隔 離性 (1)
他のトランザクションが実行していないようにアプリケーション に見せる
同時実行制御を使う
変更の衝突はしない
問題が少し
自分より後のトランザクションの変更結果は見えるか？
見えなくするのが理想だが
実際には見える
トランザクション実行中に他のトランザクションがコミットした データは見えるか？
見えなくすることも可能 (serializable)
見えるようにすることも可能 (read committed)
トランザクション実行中に他のトランザクションがコミットしてい ない変更は見えるか？
見えるような設定も可能 (read uncommitted: これがないデータベー
他のトランザクションによるデータ更新
(1) 理想的には
全部のトランザクションが直列に (他のトラン ザクションが全く実行されていないように ) 見 せるのがいい他のトランザクションによるデータ更新
(2)
現実は
実際にはそうはうまく行かない。トランザクションの 実行は互いに重なって行われる 古いデータを見せる(MVCC*1)トランザクションが終わるまで待 たせる
古いデータを見せる (MVCC*1) 新しいデータを見せる
ストレージ管理
どのテーブルをディスクのどの部分に格納 するかを決める
OS
のファイルをそのまま使うやり方
ディスク全体を直接管理するやり方ストレージ管理の要点
どのテーブルをどのファイル ( ディスク ) に入れるかは、物理設計で決める
テーブルをうまく配置すると性能が上がる
テーブルのサイズを考えて配置を決める
テーブルがファイルやディスクからはみ出さない ようにバッファ管理
データは一旦ディスクからメモリに読み込まないと処理でき ない
データーベース全体でこのメモリを共有する
時間がかかるファイルの読み書きの回数を減らす
バッファ管理も物理設計の対象
メモリの量
どの用途にどれだけ割り当てるか
ファイルの読み書き
内部処理 (並べ替えなど)
障害復旧
データベースが停止する
停電
ディスクの故障→データが壊れた
その他サーバのハードウェア故障
ソフトウェアのバグ
誤操作
災害障害復旧の種類→やりかたはバックアッ
プとログ
クラッシュリカバリ
ハードウェアは壊れていない 中途半端な更新データを元に戻す
コミットしていないトランザクションを強制アボートする
アーカイブリカバリ
ディスクが壊れてデータが失われた誤操作をして大事なデータを消してしまった
バックアップとログを使ってデータを元に戻す (後述
)
ディザスタリカバリ
設備が壊滅的被害： 地震、火災、その他の天災・人災 まずは設備の復旧
データを元に戻すにはやはりバックアップとログが必要
バックアップとログ
データベースを安全に使うために必須
バックアップ
データベースのコピーを作る
運転中でも作れる
ログ：Log
、もともと船の「航海日誌」のこと
データベースの変更履歴：あらゆる「変更」の履歴 が書かれている
アクティブログ クラッシュリカバリに必要