こんにちは。宮崎です。
今回のブログの内容は11g R2以降に準拠した内容になります。

まず、RACというテーマを踏まえて、
ASM（Automatic Storage Management）に関しての11gのR1とR2の違いを述べます。

11g R1までは、投票ディスクとOracle Cluster Registry（以下、OCR）という２つのOracle ClusterwareファイルをASMで管理できず、rawデバイスや共有ディスク内に配置していました。

ところが、11g R2では大きな変更がありました。
それは、11g R2ではこの２つのファイルをASM内で管理できるようになり、
ディスクの領域管理が楽になったのです。

・OCR

OCRとは、一言でいうと、RACの構成情報レポジトリ用ファイルのことです。
Oracle Clusterwareで制御するデータベース、サービス、リスナーなどのコンポーネントや各クラスタ・リソースのプロファイル情報やステータス情報など、Oracle Clusterware稼働に必要な情報が含まれているファイルです。

・投票ディスク

投票ディスクとは、Oracle Clusterwareがクラスタ内のノードの生死判断するのに用いるファイルです。クラスタ内の各ノードは、ハートビートと呼ばれるクラスタ同期サービス（以下、CSS）同士で生存確認を行います。その結果として、あるノードにサーバーダウンなどの異常が発生した場合、その異常が起きたノードを切り離し、クラスタを正常に保つスプリット・ブレインという機能に使用されます。

下の図は前回のブログでも出てきた、３ノードからなるクラスタ・データベースのイメージ図です。

インスタンス君①
　「おーい生きてるかー？」
インスタンス君②
　「こっちは無事だよー」
インスタンス君③
　「俺も大丈夫！」

各インスタンスはCSS社の糸電話で、こまめにお互いの無事を確かめ合っています。

しかし、ある日のこと、急にインスタンス③君が倒れてしまいました。

インスタンス君①
　「おーい生きてるかー？」
インスタンス君②
　「インスタンス君③から返事が帰ってこないの！」
インスタンス君①
　「何度呼びかけても応答してくれないな・・・」

意識を失っているので当然、糸電話で２人のインスタンス君たちと話すことはできません。
インスタンス君③がいない以上、このままでは今あるクラスタ・データベースを維持することができません。そこで残った２人のインスタンス君はある決断を下します。

インスタンス君①
　「インスタンス君③から応答があるまで、２人だけでクラスタを作りなおそうよ」
インスタンス君②
　「僕も同じ意見だよ。賛成票２票でインスタンス君③をクラスタから切り離そう」

こうして多数決によりインスタンス君③はクラスタから切り離され、インスタンス君①と②からなる新しいクラスタ・データベースができました。

それからしばらくしてインスタンス君③は何事もないかのように２人のもとに戻ってきました。

インスタンス君③
　「みんな、ただいま！」
インスタンス君①
　「おっ、やっと帰ってきたね。」
インスタンス君②
　「２人だけで大変だったんだよ！」
インスタンス君③
　「ごめんごめん！積もる話もあると思うけど、先にクラスタ作りなおそうぜ」
インスタンス君②
　「そうだね」

異常の発生したインスタンスが再び正常に起動すると、自動的にクラスタの再構成が始まります。

OCRと投票ディスクをASMで管理する利点としては、障害時にOracle Clusterwareを継続的に稼働したまま障害に対応し、その後の復旧まで自動的に行う点が挙げられます。その際、ディスクの冗長化設定を利用してデータ保護を行うとなおさらよいです。

Oracle ClusterwareとASMは、コンポーネントとしては独立しているものの、この2つが1つの機能として統合され、Grid Infrastructureと呼ばれるRACを支える重要なアーキテクチャとして提供されています。

ASMに関してはそれ自体もさることながら、ACFSも含めて色々と記事が書ける素材のため、
また折をみてお伝えしたいと思います。