ASM を味わう ～ データを壊しちゃえ ～ その４
＜ASM を味わう ～ データを壊しちゃえ ～ その４＞
ペンネーム：ダーリン
先週 ASM で管理されているファイルの情報を確認することができました。
もう少し、情報を取得してみましょう。
先週の検証からどうやら、ASM では、ファイルの指定サイズをもとに多重度に
応じたサイズの領域を “ALLOCATE していることがわかりました。
ところで、ASM を採用するに当たり多重化によるデータ保護のほかに何かメリ
ットはないのでしょうか。そういえば単に多重化するだけではありませんでし
た。ASM では、障害グループを意識してデータを多重化してくれるはずです。
ちなみに、障害グループとは障害が発生した場合に共倒れになるグループと
表現しても良いでしょう。例えば、外付けの HARD DISK を SCSI コントロー
ラーにディジーチェーンで接続したとします。この場合、複数の SCSI DISK
を接続することが出来ます。さて、オンライン REDO ログファイルや、制御
ファイルは複数のメンバを作成し、障害に備えます。例えば、異なる物理ディ
スクに配置することを検討します。最近であれば単体の DISK で構成すること
もあまりないので、同じ例を挙げるとすれば、異なる RAID グループにそれぞ
れのメンバを配置するということになるでしょう。
しかし、もしこれらの DISK が同じコントローラ接続されていた場合はどうで
しょうか。 いずれかの DISK 故障した場合は、確かに、メンバのファイルか
ら復旧することが出来るでしょう。 でも、コントローラが故障してしまうと、
一連の DISK にはまったくアクセスできなくなります。 では、SCSI コントロ
ーラが分かれていたとします。でも、電源の系統が同一であれば同じことにな
ります。 では、電源の系統も別に用意されていたとします。でも、同じサー
バルームにあれば天災などで同時にアクセスできなくなる可能性があります。
これが障害グループです。つまり、ASM では、障害グループを設定することで
同じ障害グループにはミラーリングしません。特定の障害グループで問題が発
生しても、そのほかの障害グループのデータでカバーできるようになっていま
す。
では、今回は本当に障害が発生しても大丈夫かどうか試してみましょう。
ASM の多重度には、
1) なし EXTERNAL 2) 2 多重 NORMAL 3) 3 多重 HIGH
の 3 種類があります
今検証している環境の DISK Group では “NORMAL” になっているので 2 重化
されていることになります。また、DISK 5本で構成していることもわかります。
SQL> select
2 a.group_number
3 ,a.name
4 ,a.type redundancy
5 ,b.disk_number
6 ,b.name
7 ,b.failgroup
8 ,b.path
9 from v$asm_diskgroup a,v$asm_disk b
10 where a.group_number = b.group_number
GROUP_NUMBER NAME REDUNDANCY DISK_NUMBER NAME FAILGROUP PATH
------------ ------- ---------- ----------- ---------- ---------- -------------
1 DATA NORMAL 4 DATA_0004 DATA_0004 /dev/raw/raw5
1 DATA NORMAL 3 DATA_0003 DATA_0003 /dev/raw/raw4
1 DATA NORMAL 2 DATA_0002 DATA_0002 /dev/raw/raw3
1 DATA NORMAL 1 DATA_0001 DATA_0001 /dev/raw/raw2
1 DATA NORMAL 0 DATA_0000 DATA_0000 /dev/raw/raw1
ちなみに、障害グループ（FAILGROUP）がすべて異なっていることもわかります。
今回の DISK Group を作成するときに障害グループをとくに指定していなかっ
たのですが、どうやらすべてが異なる障害グループに設定されています。
さて、2 多重化されているということは、任意の DISK が故障しても別の障害
グループに属する DISK にミラーデータが存在しているはずです。仮に、ミラ
ーされているはずの DISK が運悪く（？）宝くじにでも当たるような確率で
“たまたま”、同じタイミングで故障してしまうと残念なことに復旧できなく
なってしまいます。 そういうときのために 3 重化するという手もあります。
ただし、宝くじに連続で当たるぐらい運の悪い（？）場合はあきらめてくだ
さい。アーカイブ運用して、リストア・リカバリで対応しましょう。オンラ
イン REDO ログが壊れたらどうしようもないですが。
（それでも 3 回連続で宝くじにあるようならあきらめも付きます。）
さて、ターゲットのテーブルを作成しましょう。表領域は前回作成した、
TEST001 表領域を使います。テーブルは簡単なものにします。
SQL> create table tbl001 (c1 number,c2 timestamp) tablespace test001; Table created. SQL> select segment_name,segment_type,tablespace_name from user_segments; SEGMENT_NAME SEGMENT_TYPE TABLESPACE_NAME ------------------------------ ------------------ ---------------- DEPT TABLE USERS PK_DEPT INDEX USERS EMP TABLE USERS PK_EMP INDEX USERS BONUS TABLE USERS SALGRADE TABLE USERS TBL001 TABLE TEST001 7 rows selected.
このテーブルにデータを投入しながら、どれか DISK を 1 つ DROP しちゃい
ましょう。
SQL> begin
2 for i in 1..100 loop
3 insert into tbl001 values (i,systimestamp);
4 commit;
5 end loop;
6 end;
7 /
PL/SQL procedure successfully completed.
SQL> select count(*) from tbl001;
COUNT(*)
----------
100
別のセッションで、、、、
SQL> alter diskgroup data drop disk data_0000; Diskgroup altered.
おっしゃ。
では、、んんー？
ディスクがカリカリと動いています。なにやら、リカバリしているような、、
あ”。 alter 文で drop しても障害とはいえないなぁ。
ま、でもついでだからどうなるか見ておこう。
カリカリいっているけどそのままの状態で、もとのセッションでデータを追加し
てみます。
SQL> begin 2 for i in 1..100 loop 3 insert into tbl001 values (i,systimestamp); 4 commit; 5 end loop; 6 end; 7 / PL/SQL procedure successfully completed. SQL> select count(*) from tbl001; COUNT(*) ---------- 200
まだ、カリカリディスクは回っているようですが、特に問題なくインサート
できてしまいました。データのボリュームによるかもしれませんが、意外と
まともです。
では、今度は、本当にデータを壊してみましょう。 次に壊してみる DISK を
確認します。 えーっと。今の ASM の状態は、、
[/sql]
SQL> select
2 a.group_number
3 ,a.name
4 ,a.type redundancy
5 ,b.disk_number
6 ,b.name
7 ,b.failgroup
8 ,b.path
9 from v$asm_diskgroup a,v$asm_disk b
10 where a.group_number = b.group_number;
GROUP_NUMBER NAME REDUNDANCY DISK_NUMBER NAME FAILGROUP PATH
———— ———- ———- ———– ———- ———- ————-
1 DATA NORMAL 4 DATA_0004 DATA_0004 /dev/raw/raw5
1 DATA NORMAL 3 DATA_0003 DATA_0003 /dev/raw/raw4
1 DATA NORMAL 2 DATA_0002 DATA_0002 /dev/raw/raw3
1 DATA NORMAL 1 DATA_0001 DATA_0001 /dev/raw/raw2
1 DATA NORMAL 0 DATA_0000 DATA_0000 /dev/raw/raw1
[/sql]
あ、あれ？ “DATA_0000” DISK がまだ残ってる。どういうことでしょうか？
DROP したはずの “DATA_0000” のステータスを確認しましょう。
SQL> select mount_status 2 ,header_status 3 ,mode_status 4 ,state 5 ,total_mb 6 ,free_mb 7 ,name 8 from v$asm_disk 9 where name = 'DATA_0000';
（ 1 回目） MOUNT_STATUS HEADER_STATUS MODE_STATUS STATE TOTAL_MB FREE_MB NAME ------------ ------------- ----------- -------- -------- ------- --------- CACHED MEMBER ONLINE DROPPING 10236 9680 DATA_0000 （ 2 回目） MOUNT_STATUS HEADER_STATUS MODE_STATUS STATE TOTAL_MB FREE_MB NAME ------------ ------------- ----------- -------- -------- ------- --------- CACHED MEMBER ONLINE DROPPING 10236 9790 DATA_0000 （ 3 回目） MOUNT_STATUS HEADER_STATUS MODE_STATUS STATE TOTAL_MB FREE_MB NAME ------------ ------------- ----------- -------- -------- ------- --------- CACHED MEMBER ONLINE DROPPING 10236 10236 DATA_0000
なるほど、”DROPPING” ということなのでまだ、完全に DROP 出来ていないよ
うです。しかも、FREE_MB ( つまり空き容量 ) が徐々に増えてきているとい
うことは、今まさしく他の DISK にデータを移動しているということなのでし
ょう。
SQL> / no rows selected
おっと、最後は消えてしまいました。
完全に DROP されたようです。
念のため、もう一度確認しておきましょう。
こんな具合です。
SQL> select group_number
2 ,disk_number
3 ,mount_status
4 ,header_status
5 ,mode_status
6 ,state
7 ,name
8 from v$asm_disk;
GROUP_NUMBER DISK_NUMBER MOUNT_STATUS HEADER_STATUS MODE_STATUS STATE NAME
------------ ----------- ------------ ------------- ----------- ------ ----------
0 0 CLOSED FORMER ONLINE NORMAL
1 4 CACHED MEMBER ONLINE NORMAL DATA_0004
1 3 CACHED MEMBER ONLINE NORMAL DATA_0003
1 2 CACHED MEMBER ONLINE NORMAL DATA_0002
1 1 CACHED MEMBER ONLINE NORMAL DATA_0001
おやおや STATE は NORMAL なんですねぇ。
マニュアルには V$ASM_DISK ビューの STATE 列がとる値について以下のよう
に書かれています。
「Oracle(R) Database リファレンス 10g リリース1（10.1）」から抜粋
NORMAL － ディスクはオンライン状態であり、正常に稼働している
…….
DROPPING － ディスクは手動でオフライン化されており、ディスクに対する
領域割当てまたはデータ・アクセスが停止している。再調整が
開始され、データがこのディスクからディスク・グループ内の
他のディスクに再配置される。再調整が完了すると、ディスク
はグループから除外される。
…….
DROPPED － ディスクはディスク・グループから完全に除外されている
なのでてっきり DROPPED だと思っていました。
マニュアルバグか、製品バグか、それとも仕様なのか。とにかく STATE 列だ
けでは判断できないようなので皆さんも気をつけてください。
来週は、本当にデータを壊してみます。
台風一過と共にせみの声が聞こえなくなりました。 一緒に飛んでったのか？
茅ヶ崎にて