ちょびひげこれまで、「単一サーバ」、「単一セッション」の環境で、データベース・バッファ上のオブジェクトの状態(ステータス)を詳細に見てきた。Cluster)の環境で、オブジェクトの状態(ステータス)がどのように変化していくのかを見ていく。検証を始める前に、GCS(グローバル・キャッシュ・サービス)について簡単にご説明する。GCSとは複数ノードでデータベース・バッファ上のデータを共有する為には、自分が使いたいデータ・ブロックが、「他のインスタンスに存在するか」、「更新されているか」、というような確認を行う必要がある。この確認をマスターノードに対して行う。マスターノードはハッシングによって決定される。マスターノードはGCSを提供している。このサービスを司るのがLMSプロセスであり、GCSメッセージの処理やデータベース・バッファの操作を行っている。データベース・バッファ上のデータを共有ために、マスターノードへの問い合わせが増えるほど、LMSプロセスへの負荷が高くなる。そのような環境では、マスタノードのLMSプロセス数を増やすことにより、パフォーマンスの向上が期待出来る。ユーザからの問い合わせが多いので、対応を行う窓口を増やすわけである。このようなGCSへの問い合わせ処理の流れを考えた場合、RACのパフォーマンス向上の為に重要となるのは、いかにマスターノードへの問い合わせを減らしてローカルのデータベース・バッファ内で処理を行うか、という点である。ちなみにローカルのデータベース・バッファ内での処理は共有のカレント・ブロック(SCUR)により実現されている。※SCURに関しては後述では、実際に検証を行って見て行こう。初めにRAC構成で発生する競合の種類を考えて見ると以下の4つのパターンが考えられる。今回は上記のWrite/Write競合を除いた、3つのケースを見ていく。検証環境は以下の通りである。SELECTを行った場合の流れである。データ・ブロックをカレント・ブロック(SCUR)として読込みSCUR(共有カレント・ブロック)はRACの構成で初めて出てきたステータスである。全てのノードでブロックへのアクセスが集中(SELECTの競合)したとしてもノード間でのブロックの転送は発生しない。ローカルのデータベース・バッファにカレント・ブロックを保持している為、マスターノードに問い合わせを行わずとも、データへのアクセスが可能だからである。競合その2]まず、マスターノードに対して、いずれかのノードのデータベース・バッファ上に必要なブロックが載っているかどうかの確認を行う。NODE1のデータベース・バッファ上に必要なブロックが載っている為、NODE1からNODE2にSCURブロックの転送がインターコネクト経由で行われる。ディスクI/Oはゼロ(0)である。競合その1]最初のNODE1でのSELECT(Read)は先程と同様の状態である。競合その2]次にNODE2からのUPDATE(Write)を行うと、以下のようにステータスが変化している。データ・ブロックでステータスがSCURからCRへのロックダウンが行われる。NODE2にSCURのセグメント・ヘッダとXCURのデータ・ブロックが転送される。最後にNODE2で「単一サーバ」、「単一セッション」の場合と同様にCRブロックを作成した後、UPDATEを行う。ロックダウンとは?上記の結果としてX_TO_NULL列を追加している。この列はブロックのステータスがカレントモードから別のステータスに変化した場合にカウントアップされる。上記の例では、共有のカレントモード(SCUR)から読取一貫性のモードに変化している為に、X_TO_NULL列の値がカウントアップされ1となっている。この動きをロックダウンという。自体が正しいという保証はない。