フクの非日常

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

DB DBMSはロック、コミット、ロールバックで

DBMSで考慮が必要なものは、プロセス間の競合と、
エラー発生時のリカバリーの仕組みと見た。
トランザクションに必要なのは、ACID特性と言うからね。

インデックスや分散データーベースのような高速化、効率化はその次のステップとみた。
まずは、いかにして整合性を取るのか、その仕組みを押さえようではないか。

DBMSでよく問われるのがコミットとロールバック。
テーブルに行を追加したり、削除したりと変更を加えても、
COMMITするまでは実際のDBには反映されない。
隣の人(トランザクション)に叩いたコマンドの結果を見せたいならば、
COMMITを済みである必要がある。
逆に、COMMITせずにROLLBACKを叩くとテーブルは元の通り。
ちょっとだけ触るときに便利。

障害発生時にはロールバックとロールフォワードか。
どっちがどっちか良く忘れるのだが、ロールバックは処理の途中で障害が起きたときに使う。
端末叩いているときにエラーで落ちたら、ロールバックしてやりなおしと思えばよろし。
障害発生時に、トランザクションが終了しているのであれば、ロールフォワードを使う。
障害が起きたところまで進んでよいのでフォワードな感じかと。

ロックの種類は共有ロックと占有ロック。
共有ロック同士は共存できるが、占有ロックは他のロックと共存できない。
デッドロックの回避には、資源のロックの順序を同じにすると、まず問題なし。
この辺はソフ開というか、応用情報でもしっかり問われる範囲の話。

さきほど。
COMMITするまで隣の人(トランザクション)には見えない、と言い切ったが
実は、隔離水準レベル(ISOLATION LEVEL)に依存するものである。
このレベルを低くすると、他のトランザクションの影響を受けやすい。
コミット前のデータを読むような設定にすることもできる。
何が利点かといえば、コミットされるまで待たなくて良い、つまりロックによる待ちが少なくなる。
しかし、更新後、コミット前のデータを読んだが、やっぱりコミットされなかったとなると、
嘘のデータを読んだことになるので必要なレベルまで隔離レベルを設定する必要がある。
ダーティリード、ノンリピータブルリート、ファントムリードはDBで出てきた話かな。


コメント


管理者にだけ表示を許可する
 

 

トラックバック

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。