このエントリはJPOUG Advent Calendar 2016の2日目です。
昨日は Shinnosuke Akita さんでした。
久々のエントリは、Oracle Automatic Storage Management (以降、ASM)の領域監視についての一言
さてさて皆さんちゃんと領域監視してますか?
相変わらずマウントポイント(またはドライブ)の空き領域だけ見て、表領域の中の空き領域とか監視してない Oracle Database の環境持ってませんか?
さらにさらに ASM だと、マウントポイントの監視とか意味ないですからね。皆さんどうしているんでしょうか。
ASM の場合は、表領域を格納する器として、ディスク・グループっていうのがあるので、この領域がどのくらい使われているか、どのくらい空きがあるのかをちゃんと監視するようにしてください。
例えば以下のSQLで使用状況を確認することができます。
(osのgridユーザで実行)
$ sqlplus / as sysasm
SQL> select GROUP_NUMBER,NAME,STATE,TYPE,TOTAL_MB,FREE_MB,HOT_USED_MB,COLD_USED_MB,REQUIRED_MIRROR_FREE_MB,USABLE_FILE_MB from v$asm_diskgroup where NAME='DATA';
GROUP_NUMBER NAME STATE TYPE TOTAL_MB FREE_MB HOT_USED_MB COLD_USED_MB REQUIRED_MIRROR_FREE_MB USABLE_FILE_MB
------------ -------------------- ---------- ------------------ ---------- ---------- ----------- ------------ ----------------------- --------------
1 DATA MOUNTED NORMAL 228964 64936 0 164028 57241 3847
このFREE_MBを見るとディスク・グループ “DATA” 内の未使用のサイズが確認できますね。
ただし、このサイズは物理サイズなので、実際に利用できるサイズは可用性の設定を考慮してください。
標準冗長化を設定している場合は FREE_MB の1/2 が論理的に利用できるサイズです。
この辺の説明は”しばちょう先生”が詳しいので、こちらをご覧ください。
で、今回はASMの領域監視としてもう一個見ておいてほしい情報があるので、それについて書き残しておきます。
特に”障害グループ”を設定している環境で遭遇することになると思います。ASM ディスクごとに”障害グループ”が設定されたりしている環境では関係ないかな。
“障害グループ”は文字通り障害発生時の影響範囲を考慮してASMディスクを束ねたグループですよね。で、どんな障害グループがあるかというと、「Oracle Exadata Database Machine」とか、弊社の「Insight Qube」で採用しているストレージサーバとか、もっと小さな単位でみるなら、RAIDカードも”障害グループ”の単位と言えなくもないでしょう。
というわけで今回は「”障害グループ”を設定しているとなんなの?」っていうところを見ていきます。
以下は手元の環境です。
SQL> select GROUP_NUMBER,NAME,STATE,TYPE,TOTAL_MB,FREE_MB,REQUIRED_MIRROR_FREE_MB,USABLE_FILE_MB,ALLOCATION_UNIT_SIZE,VOTING_FILES,COMPATIBILITY,DATABASE_COMPATIBILITY from v$asm_diskgroup where NAME='DATA';
GROUP_NUMBER NAME STATE TYPE TOTAL_MB FREE_MB REQUIRED_MIRROR_FREE_MB USABLE_FILE_MB ALLOCATION_UNIT_SIZE VOT COMPATIBILITY DATABASE_COMPAT
------------ -------------------- ---------- ------------------ ---------- ---------- ----------------------- -------------- -------------------- --- --------------- ---------------
1 DATA MOUNTED NORMAL 228964 79400 57241 11079 1048576 N 11.2.0.0.0 10.1.0.0.0
SQL> select GROUP_NUMBER,DISK_NUMBER,MOUNT_STATUS,HEADER_STATUS,MODE_STATUS,STATE,NAME,FAILGROUP,LABEL,PATH,TOTAL_MB,FREE_MB,REPAIR_TIMER from v$asm_disk order by path;
GROUP_NUMBER DISK_NUMBER MOUNT_STAT HEADER_STA MODE_STATU STATE NAME FAILGROUP LABEL PATH TOTAL_MB FREE_MB REPAIR_TIMER
------------ ----------- ---------- ---------- ---------- ---------- -------------------- --------------- ----- -------------------------------------------------- ---------- ---------- ------------
1 0 CACHED MEMBER ONLINE NORMAL DATA_0000 FG001 /dev/oracleasm/iq_str1_0_1_SSD 57241 19850 0
1 2 CACHED MEMBER ONLINE NORMAL DATA_0001 FG001 /dev/oracleasm/iq_str1_0_2_SSD 57241 19850 0
1 1 CACHED MEMBER ONLINE NORMAL DATA_0002 FG002 /dev/oracleasm/iq_str1_0_3_SSD 57241 19847 0
1 4 CACHED MEMBER ONLINE NORMAL DATA_0003 FG002 /dev/oracleasm/iq_str1_0_4_SSD 57241 19853 0
0 0 CLOSED FORMER ONLINE NORMAL /dev/oracleasm/iq_str1_0_5_SSD 0 0 0
5 rows selected.
今回はこんな環境で検証していきます。
障害グループは検証目的で設定しているのでこの検証環境では物理的な構造とは関係ありません。
なので、皆さんも検証する際は特別な環境は不要です。シングルサーバでもできますよ。
各障害グループに ASM ディスクが2本
| 障害グループ | FG001 |
| ASMディスク | DATA_0001 |
| ASMディスク | DATA_0002 |
| 障害グループ | FG002 |
| ASM ディスク | DATA_0003 |
| ASM ディスク | DATA_0004 |
で、DATAディスク・グループに作成した表領域上のテーブルにデータをインサートしながらディスク壊してみます。
といっても本当に壊すと怒られるので、今回使用しているストレージサーバ上でターゲットになるディスクをコマンドでDisableして障害をシミュレートしました。
そのタイミングでDBノードからは見えなくなります。
まずは、データを登録しながらFREE_MBが減少する様子を眺めます。
SQL> select GROUP_NUMBER,NAME,STATE,TYPE,TOTAL_MB,FREE_MB,REQUIRED_MIRROR_FREE_MB,USABLE_FILE_MB,ALLOCATION_UNIT_SIZE,VOTING_FILES,COMPATIBILITY,DATABASE_COMPATIBILITY from v$asm_diskgroup;
GROUP_NUMBER NAME STATE TYPE TOTAL_MB FREE_MB REQUIRED_MIRROR_FREE_MB USABLE_FILE_MB ALLOCATION_UNIT_SIZE VOT COMPATIBILITY DATABASE_COMPAT
------------ -------------------- ---------- ------------------ ---------- ---------- ----------------------- -------------- -------------------- --- --------------- ---------------
1 DATA MOUNTED NORMAL 228964 69334 57241 6046 1048576 N 11.2.0.0.0 10.1.0.0.0
2 OCR MOUNTED EXTERN 1000 647 0 647 1048576 Y 11.2.0.0.0 10.1.0.0.0
SQL> select GROUP_NUMBER,DISK_NUMBER,MOUNT_STATUS,HEADER_STATUS,MODE_STATUS,STATE,NAME,FAILGROUP,LABEL,PATH,TOTAL_MB,FREE_MB,REPAIR_TIMER from v$asm_disk order by path;
GROUP_NUMBER DISK_NUMBER MOUNT_STAT HEADER_STA MODE_STATU STATE NAME FAILGROUP LABEL PATH TOTAL_MB FREE_MB REPAIR_TIMER
------------ ----------- ---------- ---------- ---------- ---------- -------------------- --------------- ----- -------------------------------------------------- ---------- ---------- ------------
1 0 CACHED MEMBER ONLINE NORMAL DATA_0000 FG001 /dev/oracleasm/iq_str1_0_1_SSD 57241 17333 0
1 2 CACHED MEMBER ONLINE NORMAL DATA_0001 FG001 /dev/oracleasm/iq_str1_0_2_SSD 57241 17334 0
1 1 CACHED MEMBER ONLINE NORMAL DATA_0002 FG002 /dev/oracleasm/iq_str1_0_3_SSD 57241 17329 0
1 4 CACHED MEMBER ONLINE NORMAL DATA_0003 FG002 /dev/oracleasm/iq_str1_0_4_SSD 57241 17338 0
0 0 CLOSED FORMER ONLINE NORMAL /dev/oracleasm/iq_str1_0_5_SSD 0 0 0
5 rows selected.
で、しばらくしてからASMディスクのメンバーになっているSSDをバッサリDisableしてしまうと、こんな感じになります。
今回は “DATA_0003” をDisableしてやりました。
※ ちなみに、各ASMディスクのFREE_MBが直前より増えているように見えるのは、アーカイブログを削除しながらテストしていたためなので気にしないでくださいな。
SQL> select GROUP_NUMBER,DISK_NUMBER,MOUNT_STATUS,HEADER_STATUS,MODE_STATUS,STATE,NAME,FAILGROUP,LABEL,PATH,TOTAL_MB,FREE_MB,REPAIR_TIMER from v$asm_disk order by path;
GROUP_NUMBER DISK_NUMBER MOUNT_STAT HEADER_STA MODE_STATU STATE NAME FAILGROUP LABEL PATH TOTAL_MB FREE_MB REPAIR_TIMER
------------ ----------- ---------- ---------- ---------- ---------- -------------------- --------------- ----- -------------------------------------------------- ---------- ---------- ------------
1 0 CACHED MEMBER ONLINE NORMAL DATA_0000 FG001 /dev/oracleasm/iq_str1_0_1_SSD 57241 20913 0
1 2 CACHED MEMBER ONLINE NORMAL DATA_0001 FG001 /dev/oracleasm/iq_str1_0_2_SSD 57241 20923 0
1 1 CACHED MEMBER ONLINE NORMAL DATA_0002 FG002 /dev/oracleasm/iq_str1_0_3_SSD 57241 20916 0
0 1 CLOSED UNKNOWN ONLINE NORMAL /dev/oracleasm/iq_str1_0_4_SSD 0 0 0
0 0 CLOSED FORMER ONLINE NORMAL /dev/oracleasm/iq_str1_0_5_SSD 0 0 0
1 4 MISSING UNKNOWN OFFLINE NORMAL DATA_0003 FG002 57241 20920 0
6 rows selected.
で、一瞬間をおいてリバランスが動き出しました。
SQL> select * from v$asm_operation;
GROUP_NUMBER OPERATION STATE POWER ACTUAL SOFAR EST_WORK EST_RATE EST_MINUTES ERROR_CODE
------------ --------------- ------------ ---------- ---------- ---------- ---------- ---------- ----------- -----------
1 REBAL RUN 1 1 8311 54849 8131 5
この時どんな感じにリバランスされるかっていうと、、、、
各ASM ディスクのFREE_MB見ててくださいね。
SQL> select GROUP_NUMBER,DISK_NUMBER,MOUNT_STATUS,HEADER_STATUS,MODE_STATUS,STATE,NAME,FAILGROUP,LABEL,PATH,TOTAL_MB,FREE_MB,REPAIR_TIMER from v$asm_disk order by path
GROUP_NUMBER DISK_NUMBER MOUNT_STAT HEADER_STA MODE_STATU STATE NAME FAILGROUP LABEL PATH TOTAL_MB FREE_MB REPAIR_TIMER
------------ ----------- ---------- ---------- ---------- ---------- -------------------- --------------- ----- -------------------------------------------------- ---------- ---------- ------------
1 0 CACHED MEMBER ONLINE NORMAL DATA_0000 FG001 /dev/oracleasm/iq_str1_0_1_SSD 57241 20913 0
1 2 CACHED MEMBER ONLINE NORMAL DATA_0001 FG001 /dev/oracleasm/iq_str1_0_2_SSD 57241 20923 0
1 1 CACHED MEMBER ONLINE NORMAL DATA_0002 FG002 /dev/oracleasm/iq_str1_0_3_SSD 57241 20651 0
0 1 CLOSED UNKNOWN ONLINE NORMAL /dev/oracleasm/iq_str1_0_4_SSD 0 0 0
0 0 CLOSED FORMER ONLINE NORMAL /dev/oracleasm/iq_str1_0_5_SSD 0 0 0
1 4 MISSING UNKNOWN OFFLINE FORCING _DROPPED_0004_DATA FG002 57241 21185 0
6 rows selected.
ほれ
SQL> /
GROUP_NUMBER DISK_NUMBER MOUNT_STAT HEADER_STA MODE_STATU STATE NAME FAILGROUP LABEL PATH TOTAL_MB FREE_MB REPAIR_TIMER
------------ ----------- ---------- ---------- ---------- ---------- -------------------- --------------- ----- -------------------------------------------------- ---------- ---------- ------------
1 0 CACHED MEMBER ONLINE NORMAL DATA_0000 FG001 /dev/oracleasm/iq_str1_0_1_SSD 57241 20309 0
1 2 CACHED MEMBER ONLINE NORMAL DATA_0001 FG001 /dev/oracleasm/iq_str1_0_2_SSD 57241 20310 0
1 1 CACHED MEMBER ONLINE NORMAL DATA_0002 FG002 /dev/oracleasm/iq_str1_0_3_SSD 57241 13431 0
0 1 CLOSED UNKNOWN ONLINE NORMAL /dev/oracleasm/iq_str1_0_4_SSD 0 0 0
0 0 CLOSED FORMER ONLINE NORMAL /dev/oracleasm/iq_str1_0_5_SSD 0 0 0
1 4 MISSING UNKNOWN OFFLINE FORCING _DROPPED_0004_DATA FG002 57241 27188 0
6 rows selected.
ほれほれ
SQL> /
GROUP_NUMBER DISK_NUMBER MOUNT_STAT HEADER_STA MODE_STATU STATE NAME FAILGROUP LABEL PATH TOTAL_MB FREE_MB REPAIR_TIMER
------------ ----------- ---------- ---------- ---------- ---------- -------------------- --------------- ----- -------------------------------------------------- ---------- ---------- ------------
1 0 CACHED MEMBER ONLINE NORMAL DATA_0000 FG001 /dev/oracleasm/iq_str1_0_1_SSD 57241 19359 0
1 2 CACHED MEMBER ONLINE NORMAL DATA_0001 FG001 /dev/oracleasm/iq_str1_0_2_SSD 57241 19360 0
1 1 CACHED MEMBER ONLINE NORMAL DATA_0002 FG002 /dev/oracleasm/iq_str1_0_3_SSD 57241 6843 0
0 1 CLOSED UNKNOWN ONLINE NORMAL /dev/oracleasm/iq_str1_0_4_SSD 0 0 0
0 0 CLOSED FORMER ONLINE NORMAL /dev/oracleasm/iq_str1_0_5_SSD 0 0 0
1 4 MISSING UNKNOWN OFFLINE FORCING _DROPPED_0004_DATA FG002 57241 31876 0
6 rows selected.
ほれほれほれ
SQL> /
GROUP_NUMBER DISK_NUMBER MOUNT_STAT HEADER_STA MODE_STATU STATE NAME FAILGROUP LABEL PATH TOTAL_MB FREE_MB REPAIR_TIMER
------------ ----------- ---------- ---------- ---------- ---------- -------------------- --------------- ----- -------------------------------------------------- ---------- ---------- ------------
1 0 CACHED MEMBER ONLINE NORMAL DATA_0000 FG001 /dev/oracleasm/iq_str1_0_1_SSD 57241 18595 0
1 2 CACHED MEMBER ONLINE NORMAL DATA_0001 FG001 /dev/oracleasm/iq_str1_0_2_SSD 57241 18607 0
1 1 CACHED MEMBER ONLINE NORMAL DATA_0002 FG002 /dev/oracleasm/iq_str1_0_3_SSD 57241 1509 0
0 1 CLOSED UNKNOWN ONLINE NORMAL /dev/oracleasm/iq_str1_0_4_SSD 0 0 0
0 0 CLOSED FORMER ONLINE NORMAL /dev/oracleasm/iq_str1_0_5_SSD 0 0 0
1 4 MISSING UNKNOWN OFFLINE FORCING _DROPPED_0004_DATA FG002 57241 35693 0
6 rows selected.
あ~れ~
SQL> /
GROUP_NUMBER DISK_NUMBER MOUNT_STAT HEADER_STA MODE_STATU STATE NAME FAILGROUP LABEL PATH TOTAL_MB FREE_MB REPAIR_TIMER
------------ ----------- ---------- ---------- ---------- ---------- -------------------- --------------- ----- -------------------------------------------------- ---------- ---------- ------------
1 0 CACHED MEMBER ONLINE NORMAL DATA_0000 FG001 /dev/oracleasm/iq_str1_0_1_SSD 57241 18599 0
1 2 CACHED MEMBER ONLINE NORMAL DATA_0001 FG001 /dev/oracleasm/iq_str1_0_2_SSD 57241 18603 0
1 1 CACHED MEMBER ONLINE NORMAL DATA_0002 FG002 /dev/oracleasm/iq_str1_0_3_SSD 57241 0 0
0 1 CLOSED UNKNOWN ONLINE NORMAL /dev/oracleasm/iq_str1_0_4_SSD 0 0 0
0 0 CLOSED FORMER ONLINE NORMAL /dev/oracleasm/iq_str1_0_5_SSD 0 0 0
1 4 MISSING UNKNOWN OFFLINE FORCING _DROPPED_0004_DATA FG002 57241 37202 0
6 rows selected.
SQL> select GROUP_NUMBER,NAME,STATE,TYPE,TOTAL_MB,FREE_MB,REQUIRED_MIRROR_FREE_MB,USABLE_FILE_MB,ALLOCATION_UNIT_SIZE,VOTING_FILES,COMPATIBILITY,DATABASE_COMPATIBILITY from v$asm_diskgroup;
GROUP_NUMBER NAME STATE TYPE TOTAL_MB FREE_MB REQUIRED_MIRROR_FREE_MB USABLE_FILE_MB ALLOCATION_UNIT_SIZE VOT COMPATIBILITY DATABASE_COMPAT
------------ -------------------- ---------- ------------------ ---------- ---------- ----------------------- -------------- -------------------- --- --------------- ---------------
1 DATA MOUNTED NORMAL 171723 37202 57241 -10019 1048576 N 11.2.0.0.0 10.1.0.0.0
と、いうわけで”障害グループ” FG002 だけディスクの空き容量がなくなってしまいました。(FREE_MB=0)
この時のリバランス処理のステータスはというと、、、、
SQL> select * from v$asm_operation;
GROUP_NUMBER OPERATION STATE POWER ACTUAL SOFAR EST_WORK EST_RATE EST_MINUTES ERROR_CODE
------------ --------------- ------------ ---------- ---------- ---------- ---------- ---------- ----------- ---------------
1 REBAL ERRS 1 ORA-15041
ハハ….ORA-15041で止まってる。
この結果から、外れたASM ディスクに乗っかってたデータは同じ”障害グループ”内の別のディスクに再配置(複製される)ようだということがわかりましたよね。
そーなんですよ。これを見るまではなんとなくほかの”障害グループ”のディスクにも移動されて、ASM ディスク全般にわたって(データ量的に)均等にリバランスされるのかと勝手に思ってました。
“障害グループ”内でデータが再配置(複製)されるということは、つまり、ディスクの本数減ってるのにデータ量をもとにもどすんだから、当然この”障害グループ”の空き容量だけ他の”障害グループより”減りますよね。
で、究極は上記の通り一部の”障害グループ”だけ空きがなくなったりします。
この状態って、ASMディスクグループの空き領域として見ていると、空いてるように見えるんですねぇ …… (キャー!!!)
「えっ! 空いてるんじゃないの?」って思ったあなた。すぐにASM ディスクか”障害グループ”ごとの空き状況を監視しましょう!!
この状態でデータ投入していた処理で何が起こっているかというと、、、、
こんな感じ。
1 declare 2 CURSOR C1 IS 3 with a as ( 4 select t1.c1 c1 5 , t2.c1 c2 6 , mod(t1.c1,t2.c1) c3 7 , to_char(t1.c1) c4 8 , to_char(t2.c1) c5 9 , to_char(mod(t1.c1,t2.c1)) c6 10 , lpad(to_char(t1.c1),200) c7 11 , lpad(to_char(t2.c1),200) c8 12 , lpad(to_char(mod(t1.c1,t2.c1)),200) c9 13 , sysdate+t1.c1 c10 14 , sysdate+t2.c1 c11 15 , sysdate+mod(t1.c1,t2.c1) c12 16 from (select rownum c1 from dual connect by level <=10000) t1 17 , (select rownum c1 from dual connect by level / declare * 行1でエラーが発生しました。: ORA-01653: 表TTT.T1を拡張できません(8192分、表領域TTT)
(えっ!? ディスクグループのFREE_MBまだ空いてるのに)
で、アラートログはっていうと、、、、こんなのが大量に吐き出されてました。
... ************************************************************* ARC3: Error 19504 Creating archive log file to '+DATA' Unable to create archive log file '+DATA' Errors in file /u01/app/oracle/diag/rdbms/iq/iq/trace/iq_arc0_12896.trc: ORA-19816: WARNING: Files may exist in db_recovery_file_dest that are not known to database. ORA-17502: ksfdcre:4 Failed to create file +DATA ORA-15041: diskgroup "DATA" space exhausted ************************************************************* WARNING: A file of type ARCHIVED LOG may exist in db_recovery_file_dest that is not known to the database. Use the RMAN command CATALOG RECOVERY AREA to re-catalog any such files. If files cannot be cataloged, then manually delete them using OS command. This is most likely the result of a crash during file creation. ************************************************************* ...
アーカイブログの生成に失敗した的なメッセージが出ているけど、でもこの時点の高速リカバリ領域は、実はまだ余裕があるように見えたりする。
SQL> select * from v$recovery_file_dest; NAME SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES ------------ -------------- --------------- ----------------- --------------- +DATA 21474836480 12795772928 0 13
(高速リカバリ領域空いてるじゃん!?)
とか、なにを信じていいかわからなくなってしまいます。
要は、表領域の拡張やデータファイルの追加、アーカイブログの生成などはディスクグループ全体にわたってデータを分散配置するので、一部の”障害グループ”で領域が確保できないだけでも、結局”空きがない”となるんですね。
まとめ
なので、ASMの領域監視をする場合に、”障害グループ”とか、ASM ディスク単位で使用状況を監視してもらえれば、いざという時に混乱しなくて済むかなと思う今日この頃です。
ちなみに、障害グループ内のディスクが1本故障したときにリバランス処理が走ってましたが、このデータ複製を行っても何とかORA-15041が出ないようにするためには、通常運用時にある程度の使用率に抑えておく必要がありますよね。
それが、どの程度かザクッと見積もってみると、大体以下のようになります。
| 障害グループを構成するディスク本数 | 目標ディスクグループ使用率※ |
| 8 ディスク | 86.6% |
| 7 ディスク | 84.9% |
| 6 ディスク | 82.5% |
| 5 ディスク | 79.2% |
| 4 ディスク | 74.3% |
| 3 ディスク | 66.0% |
| 2 ディスク | 49.5% |
[ ※ ] : ディスクが1本壊れた場合に、対象”障害グループ”内の残りのディスクで、再配置されたデータがすべて収まるようにするためには、通常運用時にこの使用率以下に抑えておく必要あり。
今日はここまで。ちゃんちゃん♪
明日は 玉城与清哉 さんです。
茅ケ崎にて
