データベーススペシャリスト資格｜2022年10月挑戦ログ　8月9日｜DB基礎知識（2相コミットメント）｜SQL（確認ドリル）

この記事は「データベーススペシャリスト資格に興味はあるが、どのようなものか？どう学ぶのか？」という方向けに、具体的な内容と私自身の挑戦ログをお伝えする。学び中の方や、これから学ぼうとされる方の参考になれば幸いだ。今回は知識およびSQL（確認ドリル）について書く。（SQLはGoogle Big Queryに準拠）

知識（2相コミットメント）
問題091（SQL確認ドリル）
考察
考察のシンプル化と英訳（練習中）
参考資料

知識（2相コミットメント）

トランザクションのACID特性（おさらい）

トランザクションのACID特性について。
atomicity（原子性）はall or nothing。半端な処理は非常にタチが悪い。たとえばaさんからbさんへの送金トランザクションで、aさんからの引き去りだけで処理が終わってしまうなど。コミットメント制御（commitかrollbackで終わる）が重要になる。
consistansy（一貫性）は正当性。トランザクションが正しく完了するか。単体だけでなく複数のときも上手く動くよう、同時実行制御が重要になる。
isolation（隔離性）は隔離水準の話。単体直列起動が手堅いが遅いので、どこまで基準を緩めるか。
durability（耐久性）は障害への体制。障害の種類ごとに回復制御の手順があり、またレプリケーションなど被災の対応もある。

分散DBと2相コミットメント

上述のコミットメント制御の一つを紹介。
分散データベースとは、複数の拠点に分けてデータベースを置くもの。たとえば東京センタと大阪センタに、東日本と西日本のデータを管理するなど。
たとえば東京倉庫（東京センタ）から大阪倉庫（大阪センタ）へ100個移送する場合。まず東京センタにマイナス100個のupdateを行い、commitする。次に大阪センタにプラス100個のupdateｗ行い、commitする。
このとき、両方無事commitできれば問題ない。しかし、仮に大阪センタ側の処理がrollbackした場合、東京センタの方を元に戻す必要がある。（東京センタ側が自動で戻るわけではないから）
方法として、東京センタ側はすでにcommitして決着が付いているのでrollbackできない。よって大阪センタをrollbackするトランザクションで、東京センタ側を再commit（プラス100個）する必要がある。
しかし、もし大阪センタがrollback後にトランザクション障害を起こしてしまうと、100個が戻らず大きな問題になってしまう。
そこで、2相コミットメントという方法を取る。分散DBのそれぞれでまとめてcommitまたはrollbackする方法。
上の例であれば、東京センタ側のトランザクションはupdate後に”ok(acknowledgement（両方）の頭を取ってackとも言う)”としてセキュア状態（commitもrollbackもできる状態）にする。次に大阪センタ側も同様にする。こうして、両者ok(ack）となれば両者commitし、片方でもng(nack)となれば両者rollbackする。
2相コミットメント制御は午前問題で頻繁に出題されるので、しっかり内容を把握しておくこと。