しばちょう先生の試して納得！DBAへの道 indexページ▶▶
みなさん、こんにちは。”しばちょう”こと柴田長（しばた つかさ）です。先月告知させて頂いたDBA & Developer Daysの参加申し込みが開始されましたね。。非常に有り難いことに、私が講演を予定しているセッションはすでに満員御礼状態になったとのことで、当日へ向けて張り切って準備を進めておりますのでお楽しみに。一方、申し込みが出来なかった方も多数いらっしゃったとのこと、本当に申し訳ございませんでした。個人的にはもっと多くの講演機会を作りたいと考えておりますので、少し期待して待っていて下さい！！
さて、今回は前回の後編ということで、Oracle Automatic Storage Management（ASM）のミラーリング機能である「高速ミラー再同期」を存分にご紹介したいと思います。耳にしたことはある機能名かもしれませんが、あまりその恩恵を体感された方は多くは無いだろうと思ってはいますので、本連載では是非とも使いたくなる印象を持って頂きたいと考えています。とは言え、この機能は特に事前設定することなく有効化されているのですけどね。この高速ミラー再同期のメリットを充分にご理解頂く為に、前回はASMディスク・グループの冗長性と障害グループの定義の理解を進めて頂きましたので、もし自信の無い方は、是非とも前回の34回分を体験してから取り組んでみてくださいね。では、体験スタートです！！
※ 以降の演習問題及び解答例は、第34回の演習1を実施済みである前提で記述させて頂いておりますのでご注意ください。
1. ASMディスクの疑似障害を発生させる目的で、ASMディスク・グループDGNに所属するASMディスクDGN_D4を構成するデバイス・ファイルのパーミッションを「000」へ変更して下さい。
[grid@vm11204]$ sqlplus / as sysasm
SQL>
-- ASMディスク・グループDGNのGROUP_NUMBERを確認
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
------------ ---- ----------- ---------- ------- ------- ------ -------- -------
3 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 = 3
order by 2 ;
GROUP_NU DISK_NUM HEADER_S STATE PATH NAME FAILGROUP TOTAL_MB FREE_MB
-------- -------- -------- -------- ------------ ------ --------- -------- -------
3 0 MEMBER NORMAL /dev/sdj1 DGN_D1 FG1 1019 537
3 1 MEMBER NORMAL /dev/sdk1 DGN_D2 FG1 1019 537
3 2 MEMBER NORMAL /dev/sdl1 DGN_D3 FG2 1019 536
3 3 MEMBER NORMAL /dev/sdm1 DGN_D4 FG2 1018 537
-- /dev/sdm1のパーミッションを確認(660)
[grid@vm11204]$ ls -lrt /dev/sdm1
brw-rw----. 1 grid asmadmin 8, 193 Nov 2 14:49 /dev/sdm1
-- /dev/sdm1のパーミッションが自動的に変更されないようにudevのルールファイルを編集
[root@vm11204]# vi /etc/udev/rules.d/99-oracle.rules
# KERNEL=="sd[b-m]1",ACTION=="add|change",OWNER="grid",GROUP="asmadmin",MODE="660"
KERNEL=="sd[b-l]1",ACTION=="add|change",OWNER="grid",GROUP="asmadmin",MODE="660"
-- udevに編集したルールファイルを認識させる
[root@vm11204]# udevadm control --reload-rules
-- /dev/sdm1のパーミッションを000に変更
[grid@vm11204]$ chmod 000 /dev/sdm1
-- /dev/sdm1のパーミッションを確認(000)
[grid@vm11204]$ ls -lrt /dev/sdm1
b---------. 1 grid asmadmin 8, 193 Nov 2 15:02 /dev/sdm1
改めて解説することではないと思いますが、ASMディスクを構成するデバイス・ファイルのパーミッションを「000」に変更すると言うことは、そのASMディスクへ書込みも読込みも不可能な状態となります。つまりは、ASMインスタンスやDatabaseインスタンス、及びそれらのプロセスはASMディスクに障害が発生したと錯覚することになるでしょう。あくまで障害検証の目的である為、本番環境では実行しないようにして下さいね。当たり前ですけど。。。
と言う事で、まずはASMディスクDGN_D4のデバイス・ファイル名を特定しなければならない為、V$ASM_DISKGROUPビューでASMディスク・グループDGNのGROUP_NUMBERを確認した後、V$ASM_DISKビューへ問合せしています。その結果、ASMディスクDGN_D4のデバイス・ファイル名は「/dev/sdm1」であることが確認出来たので、そのパーミッションを「000」へ変更して頂いております。参考までに、私の環境はUDEVを使用してデバイスのOwnerやパーミッションを制御していたので、単純にchmodコマンドで「000」に設定したとしても、UDEVがルールファイルに記載されている設定（660）へ自動的に修正してくれてしまう為、ルールファイルの編集も同時に行っております。
さて、読書き不可のASMディスクを含んでいるASMディスク・グループ（今回の演習では、Normal Redundancy構成）上の表領域に対するDatabase側の処理がどのような影響を受けるのか、はたまた受けないのか興味が沸いてきていますよね？
2. TAB34表の全データを読み取れること、かつ、32MB分のレコードを新規追加出来るか確認して下さい。
[oracle@vm11204]$ sqlplus / as sysdba
SQL>
-- 以降の全表スキャンでデータ・ファイル（ASMディスク・グループ上のASMファイル）から
-- データ・ブロックを読み込ませる為に、Buffer Cacheを明示的にクリア
alter system flush buffer_cache ;
-- TAB34表の全表スキャンを実行
connect TRY/TRY
select count(*) from TAB34 ;
COUNT(*)
----------
307200
-- TAB34表へ32MB分のレコード
---- 列定義により、8KBの1ブロックに3レコードしかINSERTできない。
---- 8KBのブロックが128個で1MB
---- これを32回繰り返すので、（3 * 128 * 32）レコードをINSERTする
insert into TAB34 select SEQ34.nextval, 'PRACTICE2', 'PRACTICE2' from DUAL connect by LEVEL <= 3 * 128 * 32 ;
commit ;
12288 rows created.
Commit complete.
-- TAB34表のサイズが808MBから32MB増加していることを確認
col SEGMENT_NAME for a16
select SEGMENT_NAME, BYTES/1024/1024, BLOCKS from USER_SEGMENTS ;
SEGMENT_NAME BYTES/1024/1024 BLOCKS
---------------- --------------- ----------
TAB34 840 107520
いかがでしょうか？前回の連載で障害グループの役割を理解して頂いていれば、Normal RedundancyなASMディスク・グループにおいて一本のASMディスクに障害が発生したとしても、Database側の処理がエラーになることなく全データを読み取れますし、新たなデータを書き込むことが可能であることはご納得いただけるかと思います。
もし、上記の回答例で突っ込む部分があるとしたら、INSERT処理がDatabaseインスタンスのBuffer Cacheへ書き込んでいるだけじゃないの？ASMディスク（データファイル）へ書き込んでいないからエラーにならないのでは？と言う部分だと思います。それは正しい！ですね。なので、正確には、DBWRプロセスがエラーを出力していないのか、トレースファイルを確認してみたり、Buffer CacheからASMディスクへ書き出す為に、Checkpointを実行したり、はたまた、INSERT文にAPPENDヒント句を付けて、Direct InsertでBuffer Cacheをバイパスしたデータ挿入を試行してみても良いでしょう。いずれにしても、全く問題無く新たなデータを書き込むことが出来ますのでね。興味を持ったら試して頂けると面白いと思います。
3. ASMディスク・グループDGNの状態、及び、演習3でパーミッションを変更した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
------------ ---- ----------- ---------- ------- ------- ------ -------- -------
3 DGN 512 4096 1048576 MOUNTED NORMAL 3057 1610
HOT_USED_MB COLD_USED REQUIRED_MIRROR USABLE_FILE OFFLINE COMPATIBIL DATABASE_C
----------- --------- --------------- ----------- ------- ---------- ----------
0 1447 1019 295 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, REPAIR_TIMER
from V$ASM_DISK
where GROUP_NUMBER = 3
order by 2 ;
GROUP_NUM DISK_NUM HEADER_S STATE PATH NAME FAI TOTAL FREE REPAIR_TIMER
--------- -------- -------- -------- --------- ------ --- ----- ---- ------------
3 0 MEMBER NORMAL /dev/sdj1 DGN_D1 FG1 1019 537 0
3 1 MEMBER NORMAL /dev/sdk1 DGN_D2 FG1 1019 537 0
3 2 MEMBER NORMAL /dev/sdl1 DGN_D3 FG2 1019 536 0
3 3 UNKNOWN NORMAL DGN_D4 FG2 1018 537 12960
ASMディスクに障害が発生することは稀な事ですし、そもそもDatabaseの障害時は始めてみる現象や情報が多く混乱状態となりがちです。今回の演習でASMディスクに障害が発生した際のV$ASM_DISKGROUPビューやV$ASM_DISKビューを体験しておくことで、いざ本当に障害が発生した際に落ち着いて行動できる「かも」しれないですよね。と言う事で、少し見ておきましょう。
V$ASM_DISKGROUPビューでは、障害が発生したことでTOTAL_MBやFREE_MBが減少していることが理解できます。さらには、OFFLINE_DISKSが「1」となっていることからも障害が発生していることが理解出来ますね。
V$ASM_DISKビューでは、HEADER_STATUSがUNKNOWNとなっていることから、実際に障害が発生しているASMディスクを特定することが可能です。そして、今回初登場で大注目なのが「REPAIR_TIMER」列となります。
このV$ASM_DISK.REPAIR_TIMERが何を意味しているのかは、リファレンス・マニュアルを参照してみましょう。そこには「ディスクが自動削除されるまでの残り時間(障害がない場合は0)」と説明がされています。「残り時間」と言う事なので、時間が経過すると減っていくようなものだと認識出来ると思います。そして、「障害が無い場合は0」は問題無く理解できると思います。実際に上記の回答例でも、障害が発生しているASMディスクだけが0以外の数字が入っていますからね。良く分からないのは「ディスクが自動削除されるまで」という部分ですが、これが「高速ミラー再同期」機能と絡んでくるのです。
思い出して下さい。前回の連載では、(1) ASMディスクの疑似障害を発生させる目的でASMディスクを強制削除しましたよね。そして、(2) 残りのASMディスクで再度冗長性を維持させる為にリバランスを実行させて、(3) 障害のあったASMディスクが回復したと仮定して、(4)そのASMディスクをASMディスク・グループへ追加して再リバランス と言ったステップを踏みました。
そこで質問です。とは言え、質問前に少し仮定が長くなるのですが、分かりやすく書いたつもりなので、是非読んでみてくださいね。二つのストレージ筐体に跨ったASMディスク・グループがあり、ストレージのメンテナンス作業の為に片方のストレージを停止せざるを得なくなったシナリオを考えてみてください。一時的に停止するストレージから切り出したLUNに読み書きが不可能になりますから、もちろんデバイス・ファイル=ASMディスクへ読み書き出来なくなります。ASMインスタンスやDatabaseインスタンスにとってみれば、ASMディスク障害ですよね。これが上記で復習した前回の連載のステップ(1)となるでしょう。次にステップ(2)として冗長性回復の為のリバランスが実行された後、ストレージのメンテナンスが終了してことでASMディスクへ読書き出来るようになったとします。これがステップ(3)に該当します。このままだと、メンテナンスで停止していたASMディスクはASMディスク・グループに所属していませんから、ディスク追加+再リバランスが必要になるでしょう。これがステップ(4)ですね。はい、実際には障害ではなくメンテナンスで停止していただけなので、一時的にアクセスできなくなっただけなのに、リバランスを2回も実行するなんて無駄だと思いませんか？と言うのが質問です。（本当に質問前の仮定が長過ぎ・・・）
私は完全に無駄だと思いますし、これを回避するのが「高速ミラー再同期」機能なのです！！つまりは、ASMディスクに障害が発生してからデフォルトで3.6時間経過後に、初めてそのASMディスクをASMディスク・グループから削除して冗長性回復のリバランスが開始されます。もしも、3.6時間以内にASMディスクが読み書き可能な状態になったのであれば、そのASMディスクを再度オンライン化（ASMディスク追加とは違う）するだけで良いのです。ただし、読み書き可能な状態になるまでは、障害ASMディスクには書き込まれていない、かつ、残りの正常なASMディスクには書き込まれている差分データが存在するわけで、その差分データだけをASMディスク間で同期する機能が「高速ミラー再同期」です！！
Exadata環境は複数のCell Storage ServerでASMディスク・グループが構成されており、Cell Storage Serverには修正パッチを適用することがあります。基本的には、一台ずつ順番にパッチを適用するので、いわゆるローリング・パッチ適用となるのですが、「Cell Storage Serverにパッチを適用する」=「Cell Storage Serverを止める」 =「一時的に読書きできないASMディスクが出てくる」ことになります。そんな時に、この高速ミラー再同期の機能が無かったら、一台一台のパッチ適用の度に、ASMディスクの削除+冗長性回復の為のリバランス+ASMディスクの追加+再リバランスをするとしたら何時間、何日かかるのでしょう？と言う事になります。高速ミラー再同期機能は本当に大切な大切なASMミラーリングの機能なのです。
となると、V$ASM_DISK.REPEIR_TIMERが何を表しているのか、それは上記の3.6時間（=12960秒）をカウントダウンしている情報を示していることに何とか繋がりましたよね。とは言え、V$ASM_DISK.REPEIR_TIMERを数秒毎に確認しても、全然カウントダウンしないじゃないか？と意見する方が非常に多くいらっしゃいます。だって、V$ASM_DISK.REPEIR_TIMERは約3分間に一度しか更新されないのですから、3分間隔で監視しなければならないのです。ちょっとクセがあるので注意です。この辺りは、ASMインスタンスのアラート・ログを覗いて頂ければ、次のような表示を簡単に見つけることができますので、参考までに掲載しておきますね。
[grid@vm11204]$ sqlplus / as sysasm SQL> show parameter background_dump_dest NAME TYPE VALUE ------------------------------------ -------- -------------------------------------- background_dump_dest string /u01/app/grid/diag/asm/+asm/+ASM/trace [grid@vm11204]$ tail -f /u01/app/grid/diag/asm/+asm/+ASM/trace/alert_+ASM.log Sun Nov 02 15:21:56 2014 WARNING: Disk 3 (DGN_D4) in group 3 will be dropped in: (12960) secs on ASM inst 1 Sun Nov 02 15:24:59 2014 WARNING: Disk 3 (DGN_D4) in group 3 will be dropped in: (12776) secs on ASM inst 1 Sun Nov 02 15:28:03 2014 WARNING: Disk 3 (DGN_D4) in group 3 will be dropped in: (12592) secs on ASM inst 1
4. ASMディスク・グループDGNの属性「disk_repair_time」の値を確認後、30分へ変更して下さい。
[grid@vm11204]$ sqlplus / as sysasm
SQL>
-- ASMディスク・グループDGN(GROUP_NUMBER=3)のテンプレート以外の属性確認
set linesize 100 pages 5000
col NAME for a48
col VALUE for a16
select GROUP_NUMBER, NAME, VALUE
from V$ASM_ATTRIBUTE
where NAME not like 'template%'
and GROUP_NUMBER = 3
order by 1, 2 ;
GROUP_NUMBER NAME VALUE
------------ ------------------------------------------------ ----------------
3 access_control.enabled FALSE
3 access_control.umask 066
3 au_size 1048576
3 cell.smart_scan_capable FALSE
3 compatible.asm 11.2.0.4.0
3 compatible.rdbms 11.2.0.4.0
3 content.type data
3 disk_repair_time 3.6h
3 idp.boundary auto
3 idp.type dynamic
3 sector_size 512
-- ASMディスク・グループDGNのdisk_repair_time属性を30分へ変更
alter diskgroup DGN set attribute 'disk_repair_time'='30m' ;
-- ASMディスク・グループDGN(GROUP_NUMBER=3)のdisk_repair_time属性の値を確認
set linesize 100 pages 5000
col NAME for a48
col VALUE for a16
select GROUP_NUMBER, NAME, VALUE
from V$ASM_ATTRIBUTE
where NAME = 'disk_repair_time'
and GROUP_NUMBER = 3
order by 1, 2 ;
GROUP_NUMBER NAME VALUE
------------ ------------------------------------------------ ----------------
3 disk_repair_time 30m
V$ASM_DISK.REPEIR_TIMERのデフォルト値は、各ASMディスク・グループの属性として設定されていますので、V$ASM_ATTRIBUTEビューで「disk_repair_time」属性として確認することが可能です。そして、このdisk_repair_time属性はalter diskgroup文で自由に変更することが可能で、上記回答例では30分へ変更しています。
ストレージのメンテナンスの為に、ASMディスクへ読み書き不可能となる時間に合わせて余裕を持った値を設計することが望まれますが、あまりにも大きくし過ぎてしまうことも問題です。それは、本当のASMディスク障害時に、自動的にASMディスク・グループから削除されるまでの時間 = 残ったASMディスクでの冗長性維持の為のリバランスが実行されるまでの時間が長くなることも意味しますので、可用性の観点も忘れないようにして下さいね。
5. 演習4によって、V$ASM_DISK.REPAIR_TIMERがどのように変化したのかを観察して下さい。
[grid@vm11204]$ sqlplus / as sysasm
SQL>
-- ASMディスク・グループDGNに所属する障害ディスクのREPAIR_TIMERを確認
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, REPAIR_TIMER
from V$ASM_DISK
where GROUP_NUMBER = 3
order by 2 ;
GROUP_NUM DISK_NUM HEADER_S STATE PATH NAME FAI TOTAL FREE REPAIR_TIMER
--------- -------- -------- -------- --------- ------ --- ----- ---- ------------
3 0 MEMBER NORMAL /dev/sdj1 DGN_D1 FG1 1019 537 0
3 1 MEMBER NORMAL /dev/sdk1 DGN_D2 FG1 1019 537 0
3 2 MEMBER NORMAL /dev/sdl1 DGN_D3 FG2 1019 536 0
3 3 UNKNOWN NORMAL DGN_D4 FG2 1018 537 12409
[grid@vm11204]$ tail -f /u01/app/grid/diag/asm/+asm/+ASM/trace/alert_+ASM.log
Sun Nov 02 15:21:56 2014
WARNING: Disk 3 (DGN_D4) in group 3 will be dropped in: (12960) secs on ASM inst 1
Sun Nov 02 15:24:59 2014
WARNING: Disk 3 (DGN_D4) in group 3 will be dropped in: (12776) secs on ASM inst 1
Sun Nov 02 15:28:03 2014
WARNING: Disk 3 (DGN_D4) in group 3 will be dropped in: (12592) secs on ASM inst 1
Sun Nov 02 15:30:31 2014
SQL> alter diskgroup DGN set attribute 'disk_repair_time'='30m'
SUCCESS: alter diskgroup DGN set attribute 'disk_repair_time'='30m'
Sun Nov 02 15:31:07 2014
WARNING: Disk 3 (DGN_D4) in group 3 will be dropped in: (12409) secs on ASM inst 1
Sun Nov 02 15:34:11 2014
WARNING: Disk 3 (DGN_D4) in group 3 will be dropped in: (12224) secs on ASM inst 1
この演習は非常に重要だと個人的には思っています。結果を見て頂くとご理解頂けると思いますが、V$ASM_DISK.REPAIR_TIMERがカウントダウンを開始した後に、そのASMディスク・グループのdisk_repair_time属性を変更したところで、意味が無いと言う事なのです。本当のASMディスク障害であるとDBAが検知出来れば、前回の連載でご紹介した手動で障害ASMディスクを強制削除して、残りのASMディスクでの冗長性維持の為のリバランスを早々に実行させることもお薦めします。そうなのです。リアルタイムな障害検知が如何に大切かも感じとって頂けたかもしれませんね。
6. ASMディスクの疑似障害を回復（デバイス・ファイル/dev/sdm1のパーミッションを「660」へ戻す）して下さい。
-- /dev/sdm1のパーミッションを確認(660) [grid@vm11204]$ ls -lrt /dev/sdm1 brw-rw----. 1 grid asmadmin 8, 193 Nov 2 14:49 /dev/sdm1 -- /dev/sdm1のパーミッションが自動的に変更されないようにudevのルールファイルを編集 [root@vm11204]# vi /etc/udev/rules.d/99-oracle.rules KERNEL=="sd[b-m]1",ACTION=="add|change",OWNER="grid",GROUP="asmadmin",MODE="660" # KERNEL=="sd[b-l]1",ACTION=="add|change",OWNER="grid",GROUP="asmadmin",MODE="660" -- udevに編集したルールファイルを認識させる [root@vm11204]# udevadm control --reload-rules -- /dev/sdm1のパーミッションとOwner設定を念のため上書き [root@vm11204]# chmod 660 /dev/sdm1 [root@vm11204]# chown grid:asmadmin /dev/sdm1 -- /dev/sdm1のパーミッションを確認(6600) [grid@vm11204]$ ls -lrt /dev/sdm1 brw-rw----. 1 grid asmadmin 8, 193 Nov 2 15:21 /dev/sdm1
ちょっと一休み的な演習問題ですね。こちらはお使いの環境に合わせて作業して頂ければと思いますので、説明は省略させて頂きますね。すいません。
7. ALTER DISKGROUP文で対象ASMディスクをONLINE化に要する時間を計測して下さい。
[grid@vm11204]$ sqlplus / as sysasm
SQL>
-- ASMディスク・グループDGNに所属する障害ディスクの状態確認（UNKNOWN状態のまま）
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, REPAIR_TIMER
from V$ASM_DISK
where GROUP_NUMBER = 3
order by 2 ;
GROUP_NUM DISK_NUM HEADER_S STATE PATH NAME FAI TOTAL FREE REPAIR_TIMER
--------- -------- -------- -------- --------- ------ --- ----- ---- ------------
3 0 MEMBER NORMAL /dev/sdj1 DGN_D1 FG1 1019 537 0
3 1 MEMBER NORMAL /dev/sdk1 DGN_D2 FG1 1019 537 0
3 2 MEMBER NORMAL /dev/sdl1 DGN_D3 FG2 1019 536 0
3 3 UNKNOWN NORMAL DGN_D4 FG2 1018 537 11305
-- ASMディスクDGN_D4をONLINE化
set timing on time on
alter diskgroup DGN online disk DGN_D4 wait ;
Diskgroup altered.
Elapsed: 00:00:09.76
はい、この演習が前回の連載の最後に提示させて頂いた高速ミラー再同期の恩恵を体験するものとなります。え？覚えていないですって？ということもあるので復習となりますが、「ASMディスクの強制DROP後の冗長性回復のためのリバランスに要した時間、さらには、削除されたASMディスクをASMディスク・グループへ追加した際にリバランスに要した時間。この二つの合計時間がおよそ1分程度要していることを覚えておいて下さいね。」と書いていましたね。
なので、この演習の結果を比較してみると、「高速ミラー再同期の機能が無ければ1分程度要する処理が、高速ミラー再同期によって10秒以内で済む」と言う事です。あくまで私の検証環境において検証データを使っている前提ですのでそのインパクトは小さいかもしれませんが、大容量のデータを扱う本番環境では処理時間の絶対値は大きくなるでしょう。例えば、1時間の処理が10分以内（恐らくもっと小さいですが）になるより圧倒的なメリットを感じて頂けますよね？
ちなみに、高速ミラー再同期は、差分データを同期すると演習3の長―い解説中に書かせて頂きました。この処理を実行中は、V$ASM_OPERATION.OPERATION列に「ONLIN（ONLINEじゃない）」と表示されますので、ご興味があれば確認してみてくださいね。
8. 最後に、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
------------ ---- ----------- ---------- ------- ------- ------ -------- -------
3 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 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, REPAIR_TIMER
from V$ASM_DISK
where GROUP_NUMBER = 3
order by 2 ;
GROUP_NUM DISK_NUM HEADER_S STATE PATH NAME FAI TOTAL FREE REPAIR_TIMER
--------- -------- -------- -------- --------- ------ --- ----- ---- ------------
3 0 MEMBER NORMAL /dev/sdj1 DGN_D1 FG1 1019 534 0
3 1 MEMBER NORMAL /dev/sdk1 DGN_D2 FG1 1019 538 0
3 2 MEMBER NORMAL /dev/sdl1 DGN_D3 FG2 1019 536 0
3 3 MEMBER NORMAL /dev/sdm1 DGN_D4 FG2 1018 537 0
最後は、高速ミラー再同期によって再同期された後のASMディスク・グループとASMディスクの状態を確認して頂きます。とは言え、何の特徴も無く面白くもない。普通です。そう、その普通が凄いことじゃないですかね？と、私は思うのですが、如何でしょうか？一時的に読書き不可な状態であったASMディスクが、高速ミラー再同期によって何もなかったかの如く表示されていること、本当に素敵だと思います。
さて、ASMミラーリング機能を代表する高速ミラー再同期を体験して頂きましたがいかがでしたでしょうか？
前回と同様に解説が難しくなりがち（いつの連載もそうだろ？）でしたが、前後編を通して高速ミラー再同期のメリットを共感して頂けたのであれば、もう貴方はASMミラーリングの虜であり、その効果を思う存分活用して頂けると信じています。是非とも現場でも利用してみて下さいね。ここまで全5回に渡り、Oracle Automatic Storage Managementをご紹介してきましたが、今回で一旦終了とさせて頂こうと考えています。私の持てる知識をほとんど吐き出せたと思っているので自分自身は満足しています。とは言え、繰り返しになりますが、かなり複雑な解説文章となってしまった事は大変申し訳なく、もし幾つか疑問をお持ちでしたら、現実世界で私を見かけた際にご質問頂ければ幸いです。連載自体は多分、終了しませんのでご安心下さいね（笑）
今回も最後まで体験して頂きましてありがとうございました。次回以降もどうぞよろしくお願い致します。