しばちょう先生の試して納得！DBAへの道 indexページ▶▶
みなさん、こんにちは。”しばちょう”こと柴田長（しばた つかさ）です。今年もDBA & Developer Daysの季節が近づいてまいりました。本当に一年間は早いものですね。今年のDDDは11月末に、なんと！初めてオラクル青山センターで開催される予定です。若干の混雑が予想されますが、手作り感満載で味のある セッションを数多くお届けさせて頂きけるよう準備を進めております。沢山の皆様のご参加をお待ちしております。イベント参加申し込みのページ は10月末にオープンする予定です。私もOracle Recovery Managerのバックアップ・チューニングのセッションで講演予定です。先日のOracle Open World 2014で発表されたZDLRA（Zero Data Loss Recovery Appliance）の登場で益々重要な機能となってきますので、是非ともこのタイミングでRMANマスターになって頂ければと考えています。
さて、今回の連載は前回に引き続きOracle Automatic Storage Management（ASM）の世界をお届させて頂きます。ASMの特徴はストライピングとミラーリングですが、第30回の連載において、既にストライピングの効果についてはご紹介させて頂いておりましたので、今回はミラーリングについて取り上げたいと思います。
そのASMのミラーリングの威力を存分に引き出すためには、ASMディスク・グループの冗長性と障害グループの定義の理解が大前提となってきますので、まずは前編として「障害グループと冗長性の回復」について体験して頂きます。この動作を知っているからこそ、次回後編でご紹介予定の「高速ミラー再同期」機能のメリットを充分にご理解頂けると思いますので、是非ともチャレンジしてみてください。本来は一度に体験して頂きたいと思ってシナリオを検討していたのですが、予想以上に体験して頂きたい演習問題が非常に多くなることが判明してしまったので、心苦しいですが2回に分けてお届けさせて頂くことになりました。
なお、今回の演習はこれまでのASM編の連載と同様に、仮想化ソフトウェアであるOracle VM VirtualBoxで作成した仮想環境で検証を進めさせて頂きます。Oracle Technology Networkで公開されているOracle Database 11g(11.2.0.4) on VirtualBox構築ガイド内の「Oracle VM VirtualBox を用いた Oracle Real Application Clusters(RAC)11g Release 2 環境の構築」を参考にして検証環境を作成してみてください。
こちらは2ノードRAC環境の構築ガイドとなっていますが、手順「6. 仮想マシンのクローンとクローン後の設定」をスキップして、続く手順「7. Oracle Grid Infrastructure インストールおよび構成」の「5. インストール・オプションの選択」画面において『スタンドアロン・サーバー用のOracle Grid Infrastructureの構成』を選択することで、Oracle Restart環境（ASMを使用したシングル・データベース環境）を作成することが可能です。もちろん、手順通り実施して2ノードRAC環境を構成して頂いても、以降の演習には影響はございません。
※ 以降の演習問題及び解答例は、第31回の演習1を実施済みである前提で記述させて頂いておりますのでご注意ください。
1. 4本のASM Diskで構成される標準冗長性のASMディスク・グループDGNを作成してください。また、ASMディスク・グループDGN上に配置される900MBの表領域TBS34を作成し、その表領域をデフォルト表領域とするTRYユーザー上に800MBの表TAB34を作成して下さい。
[grid@vm11204]$ sqlplus / as sysasm
SQL>
create diskgroup DGN normal redundancy
regular failgroup FG1 disk '/dev/sdj1' name DGN_D1
regular failgroup FG1 disk '/dev/sdk1' name DGN_D2
regular failgroup FG2 disk '/dev/sdl1' name DGN_D3
regular failgroup FG2 disk '/dev/sdm1' name DGN_D4
attribute
'COMPATIBLE.ASM'='11.2.0.4','COMPATIBLE.RDBMS'='11.2.0.4' ;
[oracle@vm11204]$ sqlplus / as sysdba
SQL>
-- 表領域TBS34の作成とTRYユーザーの作成
create tablespace TBS34 datafile '+DGN(DATAFILE)' size 900m ;
create user TRY identified by TRY default tablespace TBS34 ;
grant CONNECT, RESOURCE to TRY ;
-- 800MBの表TAB34を作成
connect TRY/TRY
create table TAB34 (COL1 number, COL2 char(1000), COL3 char(1000)) tablespace TBS34 ;
create sequence SEQ34 start with 10000001 increment by 1;
insert /*+append */ into TAB34
select SEQ34.nextval, 'a', 'b'
from (select 0 from all_catalog where rownum <= 800),
(select 0 from all_catalog where rownum <= 3*128);
commit ;
-- 表TAB34のサイズ確認
col SEGMENT_NAME for a16
select SEGMENT_NAME, BYTES/1024/1024, BLOCKS from USER_SEGMENTS ;
SEGMENT_NAME BYTES/1024/1024 BLOCKS
---------------- --------------- ----------
TAB34 808 103424
はい、こちらは毎度お馴染みの指の準備体操ですね。ASMディスク・グループの作成コマンドもそろそろ見慣れてきたかと思います。ASMのミラーリングは、標準冗長性（NORMAL）もしくは高冗長性（HIGH）のASMディスク・グループでしか機能しません。当たり前のことですが、ミラーデータを保持していなければどうしようもないですからね。
今回作成して頂いたASMディスク・グループは4本のASMディスクで構成される標準冗長性ですが、障害グループ（failgroup）の構成についても確認しておきましょう。このASMディスク・グループの障害グループの数は全部で何個あると思いますか？そうですね。答えはFG1とFG2の2つです。障害グループFG1に所属するASMディスクはDGN_D1とDGN_D2の2本、障害グループFG2に所属するASMディスクはDGN_D3とDGN_D4となります。と言っても、何故、このような構成にしたのか疑問が残ると思うので、簡単に解説しておきます。
障害グループとは、私の言葉で表現してみると「同時に障害になり得るASMディスクをグルーピングしておく」為に使用するものです。同時に障害になり得るとは、ストレージ筐体が分かれている例が分かりやすいかと思います。例えば、DGN_D1とDGN_D2のASMディスクがストレージ筐体Aから切り出したLogical Unit（LU）であり、DGN_D3とDGN_D4がストレージ筐体Bから切り出したLUだった場合を想定して下さい。メンテナンス作業が必要となりストレージ筐体Bの電源を落とさなければならない場合、一時的にDGN_D3とDGN_D4のASMディスクがデータベース・サーバーからアクセスできない状態となります。ASMディスク・グループDGNの障害グループFG2に所属する2本のASMディスク内のデータが読めない状態ですね。そのような場合でも、今回の構成であればデータベースを稼働し続けることが可能とするのが障害グループの役割なのです。残りの障害グループ（この例ではFG1）のASMディスクは電源を落としていないアクセス可能なストレージ筐体Aに配置されていますからね。
整理すると、ASMの障害グループとは、ある一つの障害グループに属する全てのASMディスクへアクセス不可能となったとしても全てのデータへのアクセスを継続可能となるよう、残りの障害グループに属するASMディスクにミラーデータを配置するように指示する定義なのです。上で挙げたストレージ筐体毎に障害グループを分ける例は、ExadataのCell Storage Serverで実際に採用されており、Cell Storage Serverへパッチを適用する際に、一台ずつローリング適用可能な仕組みを提供しています。非Exadataで単一ストレージ筐体の場合ではディスク・エンクロージャー単位で障害グループを分けるという例もありそうですね。もちろん、非Exadataで二つのストレージ筐体の場合でもディスク・エンクロージャー単位で障害グループを分ける（2つよりも多くの障害グループに分ける）ことも可能です。
ここまでの解説では、標準冗長性（2重化）が暗黙の前提でしたが、高冗長性（3重化）でもほとんど同じです。この違いはミラーの数になるだけで、標準冗長性ではある一つの障害グループの障害に耐えられますが、高冗長性では2つの障害グループの障害にまで耐えられますので、多重障害を懸念される重要システムの場合には高冗長性の採用をお薦めします。とは言え、ストレージ側のRAID構成でミラーを組んでいるのであれば、ディスク障害に関してはそこで一回分の障害には耐えられますから、ディスク容量やI/O性能の要件、サービス・レベルと照らし合わせて最適な設計をする必要があります。
演習1から解説が長くなってしまって恐縮ですが、もう一つ覚えておいて頂きたい重要なASMのポイントがあります。それはどのASMディスクもプライマリなデータとミラーのデータを持っているという点です。ミラーリングと言うと、ディスク単位でプライマリ専用ディスク、ミラー専用ディスクと考えがち（？）かもしれませんが、ASMではそうでは無いのです。これは、ストライピングの効果を最大限発揮する仕組みでもありますので、以降の演習でも触れていきたいと思います。
2. ASMディスク・グループDGNとASMディスクの状態を確認して下さい。
[grid@vm11204]$ sqlplus / as sysasm
SQL>
-- 作成したASMディスク・グループDGNの確認
set lines 110 pages 500
col NAME for a4
col STATE for a10
col TYPE for a8
col COMPATIBILITY for a15
col DATABASE_COMPATIBILITY for a15
select * from V$ASM_DISKGROUP where NAME = 'DGN' ;
GROUP_NUMBER NAME SECTOR_SIZE BLOCK_SIZE ALLOCAT STATE TYPE TOTAL_MB FREE_MB
------------ ---- ----------- ---------- ------- ------- ------ -------- -------
2 DGN 512 4096 1048576 MOUNTED NORMAL 4075 2147
HOT_USED_MB COLD_USED REQUIRED_MIRROR USABLE_FILE OFFLINE COMPATIBIL DATABASE_C
----------- --------- --------------- ----------- ------- ---------- ----------
0 1928 1019 564 0 11.2.0.4.0 11.2.0.4.0
-- ASMディスク・グループDGNのASMディスクの確認
set lines 110 pages 500
col NAME for a6
col HEADER_STATUS for a8
col STATE for a8
col PATH for a12
col FAILGROUP for a9
select GROUP_NUMBER, DISK_NUMBER, HEADER_STATUS, STATE, PATH, NAME, FAILGROUP, TOTAL_MB, FREE_MB
from V$ASM_DISK
where GROUP_NUMBER = 2
order by 2 ;
GROUP_NUM DISK_NUM HEADER_S STATE PATH NAME FAIL TOTAL_MB FREE_MB
--------- -------- -------- -------- --------- ------ ------------- -------
2 0 MEMBER NORMAL /dev/sdj1 DGN_D1 FG1 1019 537
2 1 MEMBER NORMAL /dev/sdk1 DGN_D2 FG1 1019 537
2 2 MEMBER NORMAL /dev/sdl1 DGN_D3 FG2 1019 535
2 3 MEMBER NORMAL /dev/sdm1 DGN_D4 FG2 1018 538
はい、こちらは完全な復習となりますが、一点だけ触れておきます。V$ASM_DISKGROUPビューのREQUIRED_MIRROR_FREE_MB列の値の算出についてです。
実はバージョン毎に算出ロジックが変化しているので正直説明し辛いのですが、Oracle Database 11g Release 2のリファレンス・マニュアルでは「1回以上のディスク障害後に冗長性をリストアするために、指定したディスク・グループで使用可能である必要がある領域の量。この列に示される領域の量には、ミラー化の影響が考慮される。」と記載されています。「冗長性をリストア」という表現でイキナリ戸惑うかもしれませんが、「冗長性の回復」と読み直して下さい。演習1の解説部において、私は標準冗長性（2重化）では一つの障害グループの障害に耐えられるとお伝えしましたが、これは一つの障害グループへアクセス出来なくなっても他の障害グループにミラーデータが存在しているのでデータベースは全てのデータへアクセスできるので大丈夫という意味でしたよね。裏を返せば、もう一つの障害グループに障害が発生したら駄目という事です。しかしながら、一回目の障害が発生した後から二回目の障害が発生するまでの間に、残りのアクセス可能なASMディスクで再度ミラーリング（正確にはリバランス処理が走ります）をし直して、冗長性を回復することが出来ていたら話は別なのです。繰り返し同じ言葉が出てきますが、言いかえれば、冗長性を回復すると言う事は、障害でアクセス出来なくなったASMディスク上に配置されていたデータを、残りのアクセス可能なASMディスク上に新たに配置し直すことを意味していますので、残りのアクセス可能なASMディスクの容量を消費することになるわけです。つまり、冗長性を回復させる為の空き領域をASMディスク・グループに残しておく必要がある、その容量を表しているのが、V$ASM_DISKGROUPビューのREQUIRED_MIRROR_FREE_MB列の値です。いやーややこしいですよね。でも非常に重要です。
計算式がバージョン毎に変化するとは言いつつも、この考え方は一貫しています。簡単に上記回答例の値を説明するとすれば、一本のASMディスクのサイズが1019MBなので、これが何かしらの障害でアクセス不可となった場合の冗長性の回復では、最大で1019MBのデータを残りのASMへ配置し直すことになると理解しておけば、納得できる数字になっていますよね。
また、一点と言っておいて二点目になってしまいますが、USABLE_FILE_MB列の値は、このREQUIRED_MIRROR_FREE_MB列の値をFREE_MB（空き領域のサイズ）から引いて、冗長性（上記の例では標準冗長性により2重化の「2」）で割った値（564 = (2,147 – 1,019) / 2）となっています。よって、このASMディスク・グループ上に564MB以下のASMファイル（データ・ファイル）を作成しても、万が一の場合の冗長性の回復が可能と読めます。しかし、障害グループの数などの構成に依存してこれらの値が正確ではない場合もあり得ますので、あくまで目安としてご利用頂くのが良いと思います。実は、今回のASMディスク・グループの構成がその例だったりしますので、以降の演習で少し触れたいと思います。
3. ALTER DISKGROUP文を使用してASMディスクDGN_D4をFORCEオプション付きでの強制DROPして下さい。ここでは、検証目的の為にリバランスは実行させないで下さい。
※ ASMディスクを手動でDROPする場合、デフォルト設定であるNOFORCEオプションをお薦めしています。今回は検証目的の為にFORCEオプションによる強制DROPを試して頂いています。
[grid@vm11204]$ sqlplus / as sysasm -- ASMディスク・グループDGNからASMディスクDGN_D4を強制削除（リバランス未実行） alter diskgroup DGN drop disk DGN_D4 force rebalance power 0 nowait ; -- 以下は、上記コマンド実行時のデータベース・インスタンス側のアラート・ログの出力結果を抜粋 Wed Oct 08 15:23:32 2014 NOTE: disk 3 (DGN_D4) in group 2 (DGN) is offline for reads NOTE: disk 3 (DGN_D4) in group 2 (DGN) is offline for writes SUCCESS: disk DGN_D4 (3.3915951878) renamed to _DROPPED_0003_DGN in diskgroup DGN
さて、少しずつ新しいコマンドを体験していきましょう。まずは、ASMディスク・グループからASMディスクを削除するコマンドの登場です。と言っても、何も難しくは無いでしょう。簡単に解説しておきますね。
ASMディスク・グループの変更なので、alter diskgroup文であることが推測できるので、SQL言語リファレンスでALTER DISKGROUP文の説明を参照します。ASMディスクの削除ですから「drop」というキーワードで検索すればdropの構文が簡単に見つかると思います。今回の演習問題では、FORCEオプション付きでの強制DROPとあるので、このキーワードも検索してみると良いでしょう。さらに、検証目的の為に「リバランスは実行させない」という指示もあるので、「rebalance power 0」を明示的に指定しましょう。ここで何故リバランスが出てくるのかが、もしかしたら疑問かもしれませんね。ちょっと解説は待って下さいね。
さて、何故、FORCEオプション付きでの強制DROP、かつ、リバランスを実行させなかったのでしょうか？を推測して頂けると、ただ単純に演習問題を解いているだけよりも、もっともっと楽しくなってくるはずです。多分。。。もったいぶらずに解説しましょう。
思い出して下さい。今回の連載の目的は、ASMのミラーリングの効果を体験することでしたよね。でも、ミラーリングが効果を発揮する時って、いつでしょう？それはASMディスクが何かしらの障害でアクセス不可能になったタイミングですよね。よって、この演習問題ではASMディスクに障害が発生してアクセス不可能になった状態を疑似的に再現してみました。（ちなみに、次回の後編ではもう少し違った疑似障害を起こす例を用意していますのでお楽しみに。） これに紐づけて、
まずは、リバランスしなかった理由、ASMディスクのDROP処理で何故リバランス処理が出てくるのかについてですが、これは演習2の解説部分をしっかり理解して頂いていれば問題無いと思いますが、一本のASMディスクにアクセス不可になったので、ASMディスク・グループとしては冗長性が崩れた状態になるわけですから「冗長性の回復」が必要になるわけで、その為のリバランスなのですね。本番運用ではもちろん自動的に「冗長性の回復」を実行して頂きたいのですが、今回は検証で冗長性の「未」回復な状態での様子を探る為に、リバランスを止めておいて頂きました。
次に、FORCEオプションを指定した理由についてです。何も指定しない場合はNOFORCEオプションが自動的に選択されますが、この違いは、実際に対象のASMディスクをASMディスク・グループから外すタイミングが冗長性を回復する前後のどちらかという部分になります。NOFORCEオプションは冗長性を回復するリバランスを実行してから外すことになるので、リバランス処理の中で移動するデータの参照元として削除対象のASMディスクからデータが読み込まれますし、リバランスが完了するまでの間でデータベースからのI/O要求も受け付けることが出来ます。つまり、障害時と言うよりはASMディスクが正常な状態での手動削除はこちらの方が良さそうですよね。一方、NOFORCEは冗長性を回復するリバランスを実行する前の段階で、ASMディスク・グループから外されることになります。つまり、ASMディスクが何かしらの障害でアクセス不可能になった状態に近しいですよね。
以上が、演習問題の指定の狙いだったわけです。とは言え、混乱させるつもりは無いのですが、本当にASMディスクに障害が発生した場合、直ぐにこの状態にはなりません。次回の後編でご紹介予定の「高速ミラー再同期」という機能が存在する為、ASMディスクに障害が発生後の一定の時間はOFFLINEステータスの状態で待機することになります。このメリットを理解して頂く前準備を今回の演習で体験して頂いているので、詳細については次回を楽しみにしていて下さいね。
えーと、相変わらず解説が長くて申し訳ないですが、伝えたいことを全て書き出しているので、是非お付き合い下さいね。
4. ASMディスク・グループDGNの各ASMディスクのI/O量を監視しながら、TAB34表を全表検索するクエリを実行して下さい。
[oracle@vm11204]$ sqlplus / as sysdba
SQL>
-- 以降の全表スキャンでデータ・ファイル（ASMディスク・グループ上のASMファイル）から
-- データ・ブロックを読み込ませる為に、Buffer Cacheを明示的にクリア
alter system flush buffer_cache ;
-- TAB34表の全表スキャンを実行
connect TRY/TRY
select count(*) from TAB34 ;
-- 以下は、上記のTAB34表の全表スキャン中の各ASMディスクのI/O量を監視した結果出力
[grid@vm11204]$ asmcmd iostat --io -G DGN 1
Group_Name Dsk_Name Reads Writes
DGN DGN_D1 0.00 1.00
DGN DGN_D2 0.00 0.00
DGN DGN_D3 0.00 1.00
DGN _DROPPED_0003_DGN 0.00 0.00
Group_Name Dsk_Name Reads Writes
DGN DGN_D1 26.00 0.00
DGN DGN_D2 41.00 1.00
DGN DGN_D3 18.00 1.00
DGN _DROPPED_0003_DGN 0.00 0.00
Group_Name Dsk_Name Reads Writes
DGN DGN_D1 86.00 0.00
DGN DGN_D2 79.00 0.00
DGN DGN_D3 58.00 0.00
DGN _DROPPED_0003_DGN 0.00 0.00
.... (省略) ....
Group_Name Dsk_Name Reads Writes
DGN DGN_D1 82.00 0.00
DGN DGN_D2 84.00 1.00
DGN DGN_D3 57.00 1.00
DGN _DROPPED_0003_DGN 0.00 0.00
Group_Name Dsk_Name Reads Writes
DGN DGN_D1 74.00 0.00
DGN DGN_D2 74.00 0.00
DGN DGN_D3 49.00 0.00
DGN _DROPPED_0003_DGN 0.00 0.00
Group_Name Dsk_Name Reads Writes
DGN DGN_D1 0.00 1.00
DGN DGN_D2 0.00 0.00
DGN DGN_D3 0.00 1.00
DGN _DROPPED_0003_DGN 0.00 0.00
こちらは、これまでの解説が本当なのか？と言う事を体験して頂く演習となっています。
まず一点目。ASMディスク・グループDGNを構成する一本のASMディスクがアクセス不可能な状態にも関わらず、そのASMディスク・グループ上にある表領域TBS34に格納されている表TAB34を全表スキャン出来るのか？という点ですが、もちろん可能でしたよね！！まさに、これがミラーリングの動作の基本となるわけです。
次に二点目。第33回の連載にも登場したasmcmdユーティリティのiostatコマンドを使用して、ASMディスク・グループDGNに所属するASMディスクに限定したI/O量を2秒毎に観察した結果を見てみましょう。強制DROPしたASMディスク以外の3本のASMディスクにしかReads列の数字が上昇していないことから、強制DROPしたASMディスクからはデータが読み込まれていないことが理解出来ます。ちなみに、強制DROPされると、ASMディスクの名前が_DROPPED_***に変化（削除前はDGN_D4）していることも実機で体験したからこそ知り得る動作ですよね。こういう部分が実に興味深いです。
ちなみに、演習問題3においてNOFORCEオプションでASMディスクを削除していた場合には、削除したASMディスクも含めて4本のASMディスクからデータを読み取る動作を確認することも出来ますので、お時間のある方は是非試して頂ければと思ます。
5. 改めて、ASMディスク・グループDGNとASMディスクの状態を確認して下さい。
[grid@vm11204]$ sqlplus / as sysasm
SQL>
-- ASMディスク・グループDGNの確認
set lines 110 pages 500
col NAME for a10
col STATE for a10
col TYPE for a8
col COMPATIBILITY for a15
col DATABASE_COMPATIBILITY for a15
select * from V$ASM_DISKGROUP where NAME = 'DGN' ;
GROUP_NUMBER NAME SECTOR_SIZE BLOCK_SIZE ALLOCAT STATE TYPE TOTAL_MB FREE_MB
------------ ---- ----------- ---------- ------- ------- ------ -------- -------
2 DGN 512 4096 1048576 MOUNTED NORMAL 3057 1606
HOT_USED_MB COLD_USED REQUIRED_MIRROR USABLE_FILE OFFLINE COMPATIBIL DATABASE_C
----------- --------- --------------- ----------- ------- ---------- ----------
0 1451 1019 293 1 11.2.0.4.0 11.2.0.4.0
-- ASMディスク・グループDGNのASMディスクの確認
set lines 110 pages 500
col NAME for a17
col HEADER_STATUS for a8
col STATE for a8
col PATH for a9
col FAILGROUP for a3
select GROUP_NUMBER, DISK_NUMBER, HEADER_STATUS, STATE, PATH, NAME, FAILGROUP, TOTAL_MB, FREE_MB
from V$ASM_DISK
where GROUP_NUMBER = 2
order by 2 ;
GROUP_NUM DISK_NUM HEADER_S STATE PATH NAME FAI TOTAL FREE
--------- -------- -------- -------- --------- ----------------- --- ----- ----
2 0 MEMBER NORMAL /dev/sdj1 DGN_D1 FG1 1019 538
2 1 MEMBER NORMAL /dev/sdk1 DGN_D2 FG1 1019 536
2 2 MEMBER NORMAL /dev/sdl1 DGN_D3 FG2 1019 532
2 3 UNKNOWN FORCING /dev/sdm1 _DROPPED_0003_DGN FG2 1018 541
さて、どんどん興味が沸いてくる感じを体感していらっしゃるでしょうか？ そうですよね。ASMディスク・グループやASMディスクがどのような状態に変化しているのか、見てみたくなってきます！と言う事で、どうぞ。
V$ASM_DISKGROUPビューでは幾つかの列の値が変化していることに気付くと思いますが、ASMディスクを強制DROPする前と比較して頂くと、TOTAL_MBの差は1,018MB（= 4075 – 3057）であり、強制削除したASMディスクの容量と合致していることが理解できると思います。もう一つ重要な列としては、OFFLINE_DISKS列の値が「1」と表示されていますが、これはこのASMディスク・グループ内でOFFLINE状態のASMディスクが1本存在することを表しているのであり、冗長構成が回復していない（=崩れている）ことを意味するので、必ず押さえておいて下さいね。
V$ASM_DISKビューでは、まだ4本のASMディスクが見えていることが確認出来ますね。しかしながら、強制DROPしたASMディスクに関しては、HEADER_STATUSがUNKOWN状態で、STATEがFORCINGとなっています。NAMEも演習4の解説で触れたように_DROPPED_***と変化していると言うのが特徴ですね。
さあ、いよいよリバランスを実行して、冗長性を回復してあげましょう。
6. リバランスを実行（強度2で実行時間を計測）した後、再度、ASMディスク・グループDGNとASMディスクの状態を確認して、冗長性が回復されたのかを確認して下さい。
[grid@vm11204]$ sqlplus / as sysasm
SQL>
-- ASMディスク・グループDGNをリバランスして冗長性を回復
set time on timing on
alter diskgroup DGN rebalance power 2 wait;
Elapsed: 00:00:21.85
-- 以下は、上記コマンド実行時のデータベース・インスタンス側のアラート・ログの出力結果を抜粋
Wed Oct 08 15:35:48 2014
SUCCESS: disk _DROPPED_0003_DGN (3.3915951878) dropped from diskgroup DGN
-- ASMディスク・グループDGNの確認
set lines 110 pages 500
col NAME for a10
col STATE for a10
col TYPE for a8
col COMPATIBILITY for a15
col DATABASE_COMPATIBILITY for a15
select * from V$ASM_DISKGROUP where NAME = 'DGN' ;
GROUP_NUMBER NAME SECTOR_SIZE BLOCK_SIZE ALLOCAT STATE TYPE TOTAL_MB FREE_MB
------------ ---- ----------- ---------- ------- ------- ------ -------- -------
2 DGN 512 4096 1048576 MOUNTED NORMAL 3057 1131
HOT_USED_MB COLD_USED REQUIRED_MIRROR USABLE_FILE OFFLINE COMPATIBIL DATABASE_C
----------- --------- --------------- ----------- ------- ---------- ----------
0 1926 1019 56 0 11.2.0.4.0 11.2.0.4.0
-- ASMディスク・グループDGNのASMディスクの確認
set lines 110 pages 500
col NAME for a6
col HEADER_STATUS for a8
col STATE for a8
col PATH for a12
col FAILGROUP for a9
select GROUP_NUMBER, DISK_NUMBER, HEADER_STATUS, STATE, PATH, NAME, FAILGROUP, TOTAL_MB, FREE_MB
from V$ASM_DISK
where GROUP_NUMBER = 2
order by 2 ;
GROUP_NUM DISK_NUM HEADER_S STATE PATH NAME FAIL TOTAL_MB FREE_MB
--------- -------- -------- -------- --------- ------ ---- -------- -------
2 0 MEMBER NORMAL /dev/sdj1 DGN_D1 FG1 1019 539
2 1 MEMBER NORMAL /dev/sdk1 DGN_D2 FG1 1019 535
2 2 MEMBER NORMAL /dev/sdl1 DGN_D3 FG2 1019 57
はい、冗長性を回復する為のリバランスを実行させる為には、リバランスを実行するコマンドを発行して頂くだけですね。今回はそのリバランスに要する時間を確認しておいて頂きたかったので「WAIT」オプションを付けて実行して頂いています。（この時間については、次回後編の解説での活用を予定しております。）
また、冗長性が回復した後のASMディスク・グループの状態を確認して頂きましたが、如何でしょうか？ 空き領域を示すFREE_MBが減少していることが気になりますよね。これは何故でしょう？と言っても、既に解説は済んでいるのですね。覚えている方は本当に私の長ったらしい解説文を隅から隅へ読んで頂けている方ですね。本当に、ありがとうございます。私は演習問題2の解説部分で「冗長性を回復すると言う事は、障害でアクセス出来なくなったASMディスク上に配置されていたデータを、残りのアクセス可能なASMディスク上に新たに配置し直すことを意味しています」と説明させて頂いていたのですね。なので、ここでの解説は割愛させて頂いて、体力と時間を次へ回したいと思います。スイマセン。
ASMディスクの状態も実に面白いですよね。強制DROPしたASMディスクが完全にASMディスク・グループDGNから外されたことを物語るように、ASMディスクが3本しか出力されなくなっています。そして、各ASMディスクのFREE_MBを確認して頂くと驚くべき（？）状況が発生しているではないですか？ ASMのストライピングの機能が、全ASMディスクに均等にデータを分散配置するとだけ覚えていると、各ASMディスクの空き容量が大幅に不均等になってしまっているので不具合かと錯覚してしまいますが、そんなことがございません。思い出すべきは障害グループです。
一本のASMディスクを強制DROPして頂きました。それにより、障害グループFG2側のASMディスクが2本から1本へ減少したことを意味します。そして、障害グループとは、ある一つの障害グループのASMディスクへアクセス不可能になったとしても、残りの障害グループで継続して全データへアクセス可能とするようにデータを配置する定義でしたよね。例えば、この3本のASMディスクの構成で冗長性が回復した状態から、障害グループFG1に所属するASMディスクDGN_D1とDGN_D2のどちらか一方、もしくは両方に障害が発生してアクセス出来なくなったとしましょう。つまり、障害グループFG2のASMディスクしかアクセスできない状態です。そのような状態でも、データベースから全てのデータへアクセス出来る状態にしておかなければならないと言うのが、今回の障害グループの構成です。ここまで、解説すれば見えてきたかと思います。今回のASMディスク・グループの構成では、障害グループFG1と障害グループFG2は同じデータ量を保持しておかなければならないと言う事。しかし、それぞれの障害グループに所属するASMディスクの本数が異なる（FG1は2本、FG2は1本）状態になってしまっていること。なので、1本のASMディスク辺り配置しなければならないデータ量は障害グループ毎に差が生まれてしまうのは必然な事なのです。
もっと解説すれば、ASMディスク・グループ上に存在する表領域は900MBです。ミラーデータを含めれば2倍の1800MBとなりますが、これを全障害グループの数（今回は2）で割ると900MBとなります。それぞれの障害グループではこの900MBを保持することになるわけで、障害グループFG1は2本のASMに分散配置させる為450MBずつ、障害グループFG1は1本のASMディスクに集中配置させなければならず、900MBを消費するのです。（ASMディスク・グループ上にはデータ・ファイル以外にもASM内部用のASMファイルも格納されているので、ある程度のオーバーヘッドの容量が存在します）
でもって、演習2の解説の最後に置き去りにしてきた箇所「このASMディスク・グループ上に564MB以下のASMファイル（データ・ファイル）を作成しても、万が一の場合の冗長性の回復が可能と読めます。しかし、障害グループの数などの構成に依存してこれらの値が正確ではない場合もあり得ます」ですが、今回の私が検証で使用したASMディスク・グループにおいては、冗長性を回復した後の障害グループFG2に所属するASMディスクの空き容量が57MBしかない事実から推測するに、演習2の段階で564MB以下のASMファイルを追加で作成していたとしたら、冗長性を回復することが出来なかったのでは？ とだけ触れておきますね。
7. 演習3でDROPしたASMディスクを再度、ASMディスク・グループDGNへ追加して、強度2でリバランスに要する時間を計測して下さい。
[grid@vm11204]$ sqlplus / as sysasm
SQL>
-- ASMディスク・グループDGNをリバランスして冗長性を回復
set timing on time on
alter diskgroup DGN add failgroup FG2 disk '/dev/sdm1' name DGN_D4 rebalance power 2 wait ;
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15033: disk '/dev/sdm1' belongs to diskgroup "DGN"
-- どのASMディスク・グループにも属していないASMディスクの検出
set linesize 150 pages 500
col NAME for a12
col HEADER_STATUS for a14
col PATH for a20
select GROUP_NUMBER, DISK_NUMBER, NAME, HEADER_STATUS, PATH
from V$ASM_DISK
where GROUP_NUMBER = 0
order by PATH ;
GROUP_NUMBER DISK_NUMBER NAME HEADER_STATUS PATH
------------ ----------- ------------ -------------- --------------------
0 0 MEMBER /dev/sdm1
-- ASMディスク・ヘッダーの初期化
[grid@vm11204]$ dd if=/dev/zero of=/dev/sdm1 bs=1048576 count=1 oflag=direct
1+0 records in
1+0 records out
1048576 bytes (1.0 MB) copied, 0.0100323 s, 105 MB/s
[grid@vm11204]$ sqlplus / as sysasm
SQL>
-- 改めて、どのASMディスク・グループにも属していないASMディスクの検出
set linesize 150 pages 500
col NAME for a12
col HEADER_STATUS for a14
col PATH for a20
select GROUP_NUMBER, DISK_NUMBER, NAME, HEADER_STATUS, PATH
from V$ASM_DISK
where GROUP_NUMBER = 0
order by PATH ;
GROUP_NUMBER DISK_NUMBER NAME HEADER_STATUS PATH
------------ ----------- ------------ -------------- --------------------
0 0 CANDIDATE /dev/sdm1
-- [RETRY] ASMディスク・グループDGNをリバランスして冗長性を回復
set timing on time on
alter diskgroup DGN add failgroup FG2 disk '/dev/sdm1' name DGN_D4 rebalance power 2 wait ;
Elapsed: 00:00:24.07
まずは解説ですが、強制DROPしたASMディスク（デバイス・ファイル /dev/sdm1）を再度、ASMディスク・グループDGNへ追加して頂きましたが、ほぼ必ずORA-15033で怒られるでしょう（笑） これもまた、実機で体験したDBAでしか知りえない情報ですね。
ORA-15033は追加しようとしたデバイス・ファイルは、既にどこかのASMディスク・グループに所属しているASMディスクなので、そんな無茶な命令をしないでください。というエラーです。とはいっても、コマンドで削除したはずなのに何故となるわけですが、これはFORCEオプション付きで削除した際にだけ現れる現象で、ASMディスク・ヘッダーに以前にASMディスク・グループに所属していた際の情報が残っていることが原因なのです。
なので、ASMディスク・ヘッダーを初期化して下さい。となるわけですが、ASMディスク・ヘッダーとはデバイス・ファイルの先頭に配置されていますので、ddコマンドでデバイス・ファイルの先頭をゼロ埋めして頂ければ問題ありません。ちなみに、良く知られているネタかもですが、odコマンドでこのASMディスク・ヘッダーを読み込んでみると次のように「ORCLDISK」であったり、ASMディスク・グループやディスク名（次の例では、「DATA」「DATA_0000」）が出力されることを知っておくと周囲から一目置かれるかもですね。
[grid@vm11204]$ od --read-bytes=128 --format=c /dev/sdb1
0000000 001 202 001 001 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0 200 X 035 { 223
0000020 G L 001 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0
0000040 O R C L D I S K ¥0 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0
0000060 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0
0000100 ¥0 002 ¥v ¥0 ¥0 002 003 D A T A _ 0 0 0
0000120 0 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0
0000140 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0 D A T A ¥0 ¥0 ¥0 ¥0
0000160 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0 ¥0
ちょっと脱線してしまいましたが、ASMディスク・ヘッダーを初期化して頂ければV$ASM_DISKビューのHEADER_STATUS列がCANDIDATEになりますので、これで問題無くディスクの追加が行えるようになりましたね。バンザーイ！
さて、ASMの冗長性の回復をベースとした障害グループを解説させて頂きましたが、いかがでしたでしょうか？
正直、障害グループの構成に関しては難しいと言うのが本音ですが、きちんと理解して使いこなして頂くことでASMのミラーリングの効果を思う存分活用して頂けると思います。Exadataで実装されているように、ASMは複数のストレージ筐体を跨ったASMディスク・グループを構成することをI/O性能をスケールアウト的に向上させることが出来ると同時に、高可用性機能も充実している点をご納得して頂けたのであれば嬉しい限りです。
また、今回の連載はあくまでミラーリング体験の前編です。次回の冒頭でもおさらいさせて頂く予定ですが、ASMディスクの強制DROP後の冗長性回復のためのリバランスに要した時間、さらには、削除されたASMディスクをASMディスク・グループへ追加した際にリバランスに要した時間。この二つの合計時間がおよそ1分程度要していることを覚えておいて下さいね。HDD交換が必要となるASMディスク障害であれば今回ご紹介した部分だけで充分なのですが、一時的にFCケーブルが寸断されたであるとか、冒頭でも述べさせて頂いた複数ストレージ筐体で構成されたASMディスク・グループの片側だけのストレージ筐体をメンテナンスで一時停止する等、実際には1~2時間程度でデータベース・サーバーからデバイス・ファイル（ASMディスク）へアクセスが再開できるケースが世の中にはあるわけです。そういったケースで大活躍する、ASMの高速ミラー再同期について、次回後編で体験して頂きたいと考えています。
今回も最後まで体験して頂きましてありがとうございました。次回以降もどうぞよろしくお願い致します。