データベーススペシャリスト（トランザクション管理）
本日IPAのページで申込しました。DBスペシャリスト。
まだ不十分かなと思いつつも、追い詰めんとやらないので
申し込みしときました。残り90日です。やれるだけのことは
やっておこうと思います。
1:トランザクションとは
・論理的にそれ以上分割することができない一連の操作
・回復に関する基本単位となるSQL文実行の並び
トランザクション中のすべての操作は実行されるか実行されないかの
いずれか（all or nothing）
2:トランザクションの指定
・COMMIT文
該当のトランザクションで実行された更新を反映する。
・ROLLBACK文
トランザクション処理が失敗したときに処理結果を反映させない。
・TPモニタ配下の場合
アプリケーション→TPモニタ→DBMS
※TPモニタがDBMSにCOMMITやROLLBACKを発行
3:ACID特性
・原子性（Atomicity）：
すべて実行されるか全く実行されないか
・一貫性（Consistency）：
データベースの内容が矛盾のない状態
・隔離性または独立性（Isolation）：
同時実行でも順番に実行しても結果が一致
・耐久性（Durability）：
トランザクションが正常終了すると更新結果はDBから消えない。
4:同時実行制御
・ロック方式
ロックをかけて他トランザクションからのアクセスを待たせる。
→デッドロックの可能性がある。
・楽観的方式
データが他のトランザクションに更新されていないことを確認してから
更新する。
→デッドロックにはならないがトランザクションのロールバックが多い。
・時刻印方式
トランザクションごとにタイムスタンプを保持して比較する。
データアクセスが競合した場合は先にアクセスした方を優先。
→分散データベースで有効
5:排他制御（ロック方式）
・更新の消失（lost update）
あるトランザクションがデータを参照し更新している間に
他のトランザクションが同じデータを参照し更新すると
データが不正になる。
・ロックの粒度
小さい範囲でロックをかけるオーバーヘッドが増加する。
・ロックモード
粒度の小さい資源→下位の資源（行）
下位の資源にロックを掛ける際には粒度の大きい資源に
ロックを掛ける必要がある。
ロックモードの競合関係
ロックモードの遷移
・直列化可能性
複数のトランザクションを同時に実行した結果が
順番に実行した結果と一致する。
・2相ロッキングプロトコル
ロックをかけていくフェーズとロックを外すフェーズが
完全に分かれている。直列化可能にするためには
必須の機能
・デッドロック
回避策： 資源アクセスの順序を統一する。
検索後に更新するときは検索時から排他モードでロックする。
デッドロック検知=有向グラフ（待ちグラフ）
6:隔離性水準
現象P1：汚れのある読み出し（ダーティリード）
現象P2：繰り返し不可能読み出し
現象P3：幻（ファントム）
ロックの概念なんかややこしいですな。
片方がロックしてたらデッドロックで、うまく排他制御がかかっていないと
変なデータが発生してしまうということみたいです。
◆メモ
http://itpro.nikkeibp.co.jp/article/COLUMN/20070918/282210/?ST=system
http://d.hatena.ne.jp/language_and_engineering/20110104/p1
http://ossforum.jp/en/node/711
http://www.atmarkit.co.jp/fjava/rensai4/enterprise_jboss08/01.html
http://www.hitachi.co.jp/Prod/comp/soft1/manual/pc/d646910/W4690036.HTM
http://isol.pro-s.co.jp/news/2008/12/28/web-exclusive/
まだ不十分かなと思いつつも、追い詰めんとやらないので
申し込みしときました。残り90日です。やれるだけのことは
やっておこうと思います。
1:トランザクションとは
・論理的にそれ以上分割することができない一連の操作
・回復に関する基本単位となるSQL文実行の並び
トランザクション中のすべての操作は実行されるか実行されないかの
いずれか（all or nothing）
2:トランザクションの指定
・COMMIT文
該当のトランザクションで実行された更新を反映する。
・ROLLBACK文
トランザクション処理が失敗したときに処理結果を反映させない。
・TPモニタ配下の場合
アプリケーション→TPモニタ→DBMS
※TPモニタがDBMSにCOMMITやROLLBACKを発行
3:ACID特性
・原子性（Atomicity）：
すべて実行されるか全く実行されないか
・一貫性（Consistency）：
データベースの内容が矛盾のない状態
・隔離性または独立性（Isolation）：
同時実行でも順番に実行しても結果が一致
・耐久性（Durability）：
トランザクションが正常終了すると更新結果はDBから消えない。
4:同時実行制御
・ロック方式
ロックをかけて他トランザクションからのアクセスを待たせる。
→デッドロックの可能性がある。
・楽観的方式
データが他のトランザクションに更新されていないことを確認してから
更新する。
→デッドロックにはならないがトランザクションのロールバックが多い。
・時刻印方式
トランザクションごとにタイムスタンプを保持して比較する。
データアクセスが競合した場合は先にアクセスした方を優先。
→分散データベースで有効
5:排他制御（ロック方式）
・更新の消失（lost update）
あるトランザクションがデータを参照し更新している間に
他のトランザクションが同じデータを参照し更新すると
データが不正になる。
・ロックの粒度
小さい範囲でロックをかけるオーバーヘッドが増加する。
・ロックモード
粒度の小さい資源→下位の資源（行）
下位の資源にロックを掛ける際には粒度の大きい資源に
ロックを掛ける必要がある。
ロックモードの競合関係
ロックモードの遷移
・直列化可能性
複数のトランザクションを同時に実行した結果が
順番に実行した結果と一致する。
・2相ロッキングプロトコル
ロックをかけていくフェーズとロックを外すフェーズが
完全に分かれている。直列化可能にするためには
必須の機能
・デッドロック
回避策： 資源アクセスの順序を統一する。
検索後に更新するときは検索時から排他モードでロックする。
デッドロック検知=有向グラフ（待ちグラフ）
6:隔離性水準
現象P1：汚れのある読み出し（ダーティリード）
現象P2：繰り返し不可能読み出し
現象P3：幻（ファントム）
ロックの概念なんかややこしいですな。
片方がロックしてたらデッドロックで、うまく排他制御がかかっていないと
変なデータが発生してしまうということみたいです。
◆メモ
http://itpro.nikkeibp.co.jp/article/COLUMN/20070918/282210/?ST=system
http://d.hatena.ne.jp/language_and_engineering/20110104/p1
http://ossforum.jp/en/node/711
http://www.atmarkit.co.jp/fjava/rensai4/enterprise_jboss08/01.html
http://www.hitachi.co.jp/Prod/comp/soft1/manual/pc/d646910/W4690036.HTM
http://isol.pro-s.co.jp/news/2008/12/28/web-exclusive/
コメント