しばちょう先生の試して納得！DBAへの道 indexページ▶▶
みなさん、こんにちは。”しばちょう”こと柴田長（しばた つかさ）です。
さあ、今年もOracle DBA & Developer Day 2016（10/27@ウェスティンホテル東京）がやってきます！私も午前中のKeynoteと午後に二コマぶち抜きセッションを担当させて頂きますので、是非ともご参加をお願い致します。
とは言え、この記事が公開されるのはその前日位なので、今書いている文章の効果を発揮できるのは一日程度ですけどね・・・
さて今回は、Oracle Database 12c Release 1から、ASMディスク・グループ内のディスクの置換（Replace Diskコマンド）が実装されています。この機能が実装されるまではASMディスクに障害が発生した際には、基本的に冗長性回復の為に残ったASMディスクでリバランスを実行してディスクを交換した後に、そのASMディスクを追加して再度リバランスを実行します。となると、リバランスが2回で無駄な感じがしてしまいますよね。そこで登場するのが本機能！一回のリバランスで、障害のあったASMディスク上に配置されていたデータだけを新たに追加したディスク上にミラーデータを使用して復元できるのです。普段はあまり使用し無いかもしれませんが、知っておくとイザという時に役に立つコマンドを幾つか学んでおきましょう！
以下の演習をOracle Database 12c Release 12.1.0.2 のデータベースで試してみてください。なお、Oracle Database 12c Release 1 (12.1.0.2) の単一インスタンス・データベースのインストレーション・ガイド 及び、Oracle VM VirtualBoxを用いたOracle Database 12c Release 1 環境の構築ガイドが、Oracle Technology Networkのこちらのページに公開されておりますので、参考にしてみてください。
- 【今回ご紹介するネタ一覧（逆引き）】
- ✓ ユーティリティでのASMディスクの状態確認方法（演習2）
- ✓ ASMインスタンス上でのASMファイル番号の確認方法（演習3）
- ✓ ASMインスタンス上でのASMファイルのFull Path取得方法（演習3）
- ✓ ASMディスクの置換コマンド（演習9）
1. High Redundancyもしくは、Normal RedundancyなASMディスク・グループ上に、以下のスクリプトを参考として検証用の表を作成して下さい。
[oracle@vm12c1 ~]$ sqlplus / as sysdba
SQL>
create tablespace TBS49 datafile '+DATA(DATAFILE)' size 100m ;
create user TRY identified by TRY12345 default tablespace TBS49 ;
grant CONNECT, RESOURCE, DBA to TRY ;
connect TRY/TRY12345
create table TAB49 (COL1 number, COL2 char(1000)) ;
insert /*+append */ into TAB49
select LEVEL, 'sibacho' from DUAL connect by LEVEL <=7*128*32 ;
commit ;
set linesize 150 pages 5000
col SEGMENT_NAME for a16
select SEGMENT_NAME, BYTES/1024/1024 from USER_SEGMENTS ;
SEGMENT_NAME BYTES/1024/1024
---------------- ---------------
TAB49 33
set linesize 150 pages 5000
col FILE_NAME for a60
select FILE_NAME, TABLESPACE_NAME, BYTES/1024/1024 from DBA_DATA_FILES ;
FILE_NAME TABLESPACE_NAME BYTES/1024/1024
------------------------------------------ --------------- ---------------
+DATA/ORCL/DATAFILE/system.261.841575323 SYSTEM 800
+DATA/ORCL/DATAFILE/sysaux.262.841575331 SYSAUX 400
+DATA/ORCL/DATAFILE/tbs49.263.925534375 TBS49 100
+DATA/ORCL/DATAFILE/users.269.920275325 USERS 100
+DATA/ORCL/DATAFILE/undotbs.267.896676927 UNDOTBS 200
はい、こちらは毎度の指の準備体操ですから、説明は割愛させて頂きます。なお、ASMディスク・グループの作成方法は「第30回 ASMディスク・グループの作成と使用量の確認」を参考にしてみて下さい。
これ以降の演習では、模擬的ではありますがASMディスクの障害を発生させることになりますので、必ず、High RedundancyもしくはNormal RedundancyのASMディスク・グループで実行をして下さい。あくまで学習の為に記載させて頂いておりますので、本番環境では絶対に実行しないようにお願い致します。自己責任でお願い致します！
2. ASMディスク・グループのASMディスク状態について、asmcmdユーティリティを使用して確認して下さい。
[grid@vm12c1 ~]$
$ export ORACLE_SID=+ASM
$ asmcmd
ASMCMD> lsdsk -pk -G DATA
Total_MB Free_MB OS_MB Name Failgroup Failgroup_Type Library Label UDID Product Redund Group_Num Disk_Num Incarn Mount_Stat Header_Stat Mode_Stat State Path
2047 846 2047 DATA_0000 DATA_0000 REGULAR System UNKNOWN 1 0 3915952153 CACHED MEMBER ONLINE NORMAL /dev/sdc1
2047 852 2047 DATA_0001 DATA_0001 REGULAR System UNKNOWN 1 1 3915952152 CACHED MEMBER ONLINE NORMAL /dev/sdd1
2047 842 2047 DATA_0002 DATA_0002 REGULAR System UNKNOWN 1 2 3915952150 CACHED MEMBER ONLINE NORMAL /dev/sde1
2047 851 2047 DATA_0003 DATA_0003 REGULAR System UNKNOWN 1 3 3915952151 CACHED MEMBER ONLINE NORMAL /dev/sdf1
ASMディスクの状態を確認するビューとしてはV$ASM_DISKですが、SQL*Plusを使用してSELECT文を毎回書くのは面倒だという私にお薦めなのが、asmcmdユーティリティでの「lsdsk」コマンドですね。幾つか引数オプションがありますので、自分好みの表示を模索してみて下さいね。ちなみに私は上記の回答例の通り「-pk」です。色々な語呂と紐づけて覚えておけるので便利ですよー
でもって、上記のとおり、私の検証環境のASMディスク・グループ「DATA」は4本のASMディスクで構成されており、全てのASMディスクが「ONLINE」なので健全な状態ですね。これ以降の演習では、4本目のASMディスク（ASMディスク名=DATA_0003で、障害グループDATA_0003に属している）に模擬障害を発生させる予定です。
3. (おまけ) 演習1で作成したデータファイルのASMファイル番号を特定して下さい。
[grid@vm12c1 ~]$ sqlplus / as sysasm
SQL>
set lines 110 pages 500
col NAME for a32
col ALIAS_DIRECTORY for a16
select NAME, GROUP_NUMBER, FILE_NUMBER, FILE_INCARNATION, ALIAS_DIRECTORY
from V$ASM_ALIAS
where GROUP_NUMBER=1
order by 3,1 ;
NAME GROUP_NUMBER FILE_NUMBER FILE_INCARNATION ALIAS_DIRECTORY
-------------------------------- ------------ ----------- ---------------- ----------------
REGISTRY.253.841570641 1 253 841570641 N
orapwasm 1 256 841570641 N
pwdasm.256.841570641 1 256 841570641 N
Current.257.841575309 1 257 841575309 N
group_1.258.841575311 1 258 841575311 N
group_2.259.841575315 1 259 841575315 N
group_3.260.841575319 1 260 841575319 N
SYSTEM.261.841575323 1 261 841575323 N
SYSAUX.262.841575331 1 262 841575331 N
TBS49.263.925534375 1 263 925534375 N
TEMP.264.841575341 1 264 841575341 N
spfile.266.841576639 1 266 841576639 N
spfileorcl.ora 1 266 841576639 N
UNDOTBS.267.896676927 1 267 896676927 N
spfile.268.859269573 1 268 859269573 N
spfileorcl.ora_1411678772197 1 268 859269573 N
USERS.269.920275325 1 269 920275325 N
ASM 1 4294967295 4294967295 Y
ASMPARAMETERFILE 1 4294967295 4294967295 Y
CONTROLFILE 1 4294967295 4294967295 Y
DATAFILE 1 4294967295 4294967295 Y
ONLINELOG 1 4294967295 4294967295 Y
ORCL 1 4294967295 4294967295 Y
PARAMETERFILE 1 4294967295 4294967295 Y
PASSWORD 1 4294967295 4294967295 Y
TEMPFILE 1 4294967295 4294967295 Y
ちょっと脱線しますが、ASMの世界でもファイルという概念はあります。それはデータベースが扱っているファイルと同じ単位なので、例えば、データベース・ファイル=ASMファイルですね。じゃあ、それっぽい名前であるV$ASM_FILEビューを参照してみれば、ASMファイルの情報が確認できます。と思いますが、実は、V$ASM_FILEビューには、ASMファイル名を表示する列が存在しない・・・なんてことだ！
では、どうするのかと言うと、ASMファイル名はV$ASM_ALIASビューで保持されているのですね。そして、ASMファイルにもASMファイル番号なるものがあり、この番号はV$ASM_FILEビューとV$ASM_ALIASビューの両方で保持しているので、それを紐づける事になります。知らなくても困らないのですが、知っていると鼻高な情報だと思いまして、今回おまけとして記載してみました。
さらに、上記の回答例のV$ASM_ALIASビューを見て頂くと分かるように、ALIAS_DIRECTORY列に「Y」or「N」が入っていますが、これはその行の情報がディレクトリ情報なのか否かを示しています。FILE_NUMBER列も合わせてみて頂くと理解が進むと思いますが、ASMファイルにはASMファイル番号が振られています。ディレクトリ情報にはASMファイル番号が非常に大きな値となっていますね。と解説してくると疑問が沸きます。そのASMファイルのFull Pathはどうやって取得するのだ？
と言う事で、出血大サービスのSELECT文を公開しちゃいますよー
$ sqlplus / as sysasm
SQL>
select * from (
select CONCAT('+'||GNAME, SYS_CONNECT_BY_PATH(ANAME, '/'))
FULL_PATH,
SYSTEM_CREATED,
ALIAS_DIRECTORY,
FNO
from ( select B.NAME GNAME,
A.PARENT_INDEX PINDEX,
A.NAME ANAME,
A.REFERENCE_INDEX RINDEX,
A.FILE_NUMBER FNO,
A.SYSTEM_CREATED,
A.ALIAS_DIRECTORY,
C.TYPE FILE_TYPE
from V$ASM_ALIAS A,
V$ASM_DISKGROUP B,
V$ASM_FILE C
where A.GROUP_NUMBER = B.GROUP_NUMBER
and A.GROUP_NUMBER = C.GROUP_NUMBER(+)
and A.FILE_NUMBER = C.FILE_NUMBER(+)
and A.FILE_INCARNATION = C.INCARNATION(+)
)
START WITH (MOD(PINDEX, POWER(2, 24))) = 0
CONNECT BY PRIOR RINDEX = PINDEX)
where ALIAS_DIRECTORY = 'N' ;
FULL_PATH SYS ALI FNO
---------------------------------------------------------------- --- --- ----------
+DATA/ORCL/PASSWORD/pwdorcl.277.854489613 Y N 277
+DATA/ORCL/DATAFILE/UNDOTBS1.297.911148625 Y N 297
+DATA/ORCL/DATAFILE/USERS.285.911148639 Y N 285
+DATA/ORCL/DATAFILE/SYSTEM.298.911148613 Y N 298
+DATA/ORCL/DATAFILE/SYSAUX.290.911148621 Y N 290
+DATA/ORCL/CONTROLFILE/Current.301.911148591 Y N 301
+DATA/ORCL/ONLINELOG/group_1.280.911148591 Y N 280
+DATA/ORCL/ONLINELOG/group_3.296.911148607 Y N 296
+DATA/ORCL/ONLINELOG/group_2.284.911148599 Y N 284
+DATA/ORCL/PARAMETERFILE/spfile.304.911997209 Y N 304
+DATA/ORCL/TEMPFILE/TEMP.287.911148625 Y N 287
+DATA/ORCL/spfileorcl.ora N N 304
...(省略)...
如何ですか？是非是非、皆様のPC上に保管しておいて頂けると幸いです。
ちなみに、赤文字で記した二つのレコードを見比べてみて下さい。FNO列（ASMファイル番号）が「304」で同じだー何でだ―って驚いて下さい。実はこれ、「ASMエイリアス」っていう仕組みなのです。簡単に言えばシンボリック・リンク見たいなもので、「+DATA/ORCL/spfileorcl.ora」がシンボリック・リンクで、「+DATA/ORCL/PARAMETERFILE/spfile.304.911997209」が実態のファイルとなります。ユーザーが明示的にASMファイル名を指定するケースがあるかと思いますが、実際には、指定した名前のASMエイリアスが作成されて見えているのであって、実態のASMファイルは数字が後ろに沢山並んだ名前で作成されているのですよー。以上、おまけでした！
4. ASMディスクの疑似障害を発生させる目的で、ASMディスク・グループに所属するASMディスクを構成するデバイス・ファイルの所有者とグループを変更 して下さい。
### /dev/sdm1のパーミッションを確認(660) [grid@vm11204]$ ls -lrt /dev/sdf1 brw-rw----. 1 grid asmadmin 8, 81 Oct 18 05:41 /dev/sdf1 ### /dev/sdf1のパーミッションが自動的に変更されないようにudevのルールファイルを編集 [root@vm11204]# vi /etc/udev/rules.d/99-oracle.rules #KERNEL=="sd[c-j]1",ACTION=="add|change",OWNER="grid",GROUP="asmadmin",MODE="660" KERNEL=="sd[c-e]1",ACTION=="add|change",OWNER="grid",GROUP="asmadmin",MODE="660" KERNEL=="sd[g-j]1",ACTION=="add|change",OWNER="grid",GROUP="asmadmin",MODE="660" ### udevに編集したルールファイルを認識させる [root@vm11204]# udevadm control --reload-rules ### 念のため、所有者とグループを手動変更 [root@vm12c1 ~]# chown root:disk /dev/sdf1 [root@vm12c1 ~]# ls -lrt /dev/sdf1 brw-rw----. 1 root disk 8, 81 Oct 18 05:47 /dev/sdf1
いよいよ疑似障害を発生させてみました。
4本目のASMディスク（ASMディスク名=DATA_0003で、障害グループDATA_0003に属している）を構成するデバイス・ファイルの所有者とグループをroot : diskへ変更することで、gridユーザーで起動しているASMインスタンスが読み書き不可能になりますよね。ディスクが障害で見えなくなった状態とほぼほぼ似ている現象だと思います。
今回のASMディスク・グループはNormal Redundancyなので、一本のASMディスクで障害が発生しても問題無い構成となっています。繰り返しになりますが、くれぐれもExternal RedundancyのASMディスク・グループでは実行しないでくださいね。
5. TAB49表の全データを読み取れることを確認して下さい。
[oracle@vm12c1 ~]$ sqlplus /nolog
SQL>
-- Buffer Cacheからキャッシュの追い出し
connect / as sysdba
alter system flush buffer_cache ;
-- Table Full Scan
connect TRY/TRY12345
select count(*) from TAB49 ;
COUNT(*)
----------
28672
こちらの演習は問題無いでしょう。ASMのミラーリング機能がきちんと動作していることが確認出来たかと思います。
6. 疑似障害を発生させたASMディスクの状態を確認して下さい。
[grid@vm11204]$ sqlplus / as sysasm
SQL>
set lines 150 pages 500
col NAME for a17
col HEADER_STATUS for a8
col STATE for a8
col PATH for a9
col FAILGROUP for a12
select GROUP_NUMBER, DISK_NUMBER, HEADER_STATUS, STATE, PATH,
NAME, FAILGROUP, TOTAL_MB, FREE_MB, REPAIR_TIMER
from V$ASM_DISK
where GROUP_NUMBER = 1
order by 2 ;
GROUP_NUM DISK_NUM HEADER_S STATE PATH NAME FAILGROUP TOTAL_MB FREE_MB REPAIR_TIMER
--------- -------- -------- ------ --------- --------- --------- -------- ------- ------------
1 0 MEMBER NORMAL /dev/sdc1 DATA_0000 DATA_0000 2047 846 0
1 1 MEMBER NORMAL /dev/sdd1 DATA_0001 DATA_0001 2047 852 0
1 2 MEMBER NORMAL /dev/sde1 DATA_0002 DATA_0002 2047 842 0
1 3 UNKNOWN NORMAL DATA_0003 DATA_0003 2047 851 12960
はい、こちらも以前のASMの連載記事の中で確認して頂いていますので復習となります。
ASMディスクの障害を検出したので自動的にOFFLINE状態にしてくれていますね。そして、このOFFLINE状態で12960秒間経過した場合には、自動的にDROP Disk処理が開始される事を意味していますね。この辺りは必要であれば、「第35回 ASMのミラーリングによるデータ保護(2) ～高速ミラー再同期～」で復習しておいて下さいね。
7. 障害ディスクを空の新規ディスクと交換した状態を作り出す目的で、疑似障害を発生させたASMディスクを構成するデバイス・ファイルをゼロ埋めして下さい。
[root@vm12c1 ~]# dd if=/dev/zero of=/dev/sdf1 bs=1024000 count=200 oflag=direct 200+0 records in 200+0 records out 204800000 bytes (205 MB) copied, 1.7685 s, 116 MB/s
まさに演習問題文の通りです。ddコマンドの「oflag=direct」オプションは忘れずに指定しましょう。
申し訳ないですが、ここでは理由は割愛させて頂きますね。
8. 新規ディスクの所有者とグループ、パーミッションを元に戻すことで、ASMインスタンスが候補ディスクとして認識したのかを確認して下さい。
### ルールファイルを変更（元に戻す）
[root@vm11204]# vi /etc/udev/rules.d/99-oracle.rules
KERNEL=="sd[c-j]1",ACTION=="add|change",OWNER="grid",GROUP="asmadmin",MODE="660"
#KERNEL=="sd[c-e]1",ACTION=="add|change",OWNER="grid",GROUP="asmadmin",MODE="660"
#KERNEL=="sd[g-j]1",ACTION=="add|change",OWNER="grid",GROUP="asmadmin",MODE="660"
### udevに編集したルールファイルを認識させる
[root@vm11204]# udevadm control --reload-rules
### 念のため、所有者とグループ、パーミッションを手動変更
[root@vm12c1 ~]# chown grid:asmadmin /dev/sdf1
[root@vm12c1 ~]# chmod 660 /dev/sdf1
[root@vm12c1 ~]# ls -lrt /dev/sdf1
brw-rw----. 1 grid asmadmin 8, 81 Oct 18 05:48 /dev/sdf1
[grid@vm11204]$ sqlplus / as sysasm
SQL>
select GROUP_NUMBER, DISK_NUMBER, HEADER_STATUS, STATE, PATH,
NAME, FAILGROUP, TOTAL_MB, FREE_MB, REPAIR_TIMER
from V$ASM_DISK
order by 1,2 ;
GROUP_N DISK_N HEADER_ST STATE PATH NAME FAILGROUP TOTAL_MB FREE_MB REPAIR_TI
------- ------ --------- -------- --------- --------- --------- -------- ------- ---------
0 0 CANDIDATE NORMAL /dev/sdf1 0 0 0
1 0 MEMBER NORMAL /dev/sdc1 DATA_0000 DATA_0000 2047 846 0
1 1 MEMBER NORMAL /dev/sdd1 DATA_0001 DATA_0001 2047 852 0
1 2 MEMBER NORMAL /dev/sde1 DATA_0002 DATA_0002 2047 842 0
1 3 UNKNOWN NORMAL DATA_0003 DATA_0003 2047 851 12589
2 0 MEMBER NORMAL /dev/sdg1 FRA_0000 FRA_0000 2047 1549 0
2 1 MEMBER NORMAL /dev/sdh1 FRA_0001 FRA_0001 2047 1548 0
2 2 MEMBER NORMAL /dev/sdi1 FRA_0002 FRA_0002 2047 1547 0
2 3 MEMBER NORMAL /dev/sdj1 FRA_0003 FRA_0003 2047 1549 0
はい、如何でしょう？前半のデバイス・ファイルの所有者とグループ、パーミッションの変更は問題無いでしょう。これにより、gridユーザーで起動しているASMインスタンスが、そのデバイス・ファイルへアクセス可能な状態となります。
そして、V$ASM_DISKビューを覗いてみると・・・あれ？なんか2行出ているけど、間違っていない？と思いがちですが、実はここが結構重要なポイントです。このデバイス・ファイルは直前までASMディスクとして使用していましたよね。ASMディスクとして使用していたという情報は、そのデバイス・ファイルの先頭に記録されているのです。ASMインスタンスはASMディスクとなりうる候補デバイス・ファイルを見つけると（正確には、ASM_DISKSTRING初期化パラメータの設定に依存）、そのデバイス・ファイルの先頭をちょっと読み込みます。そこに、「俺は、xxxディスク・グループのxxxディスクだぜ！」って書いてあるか否かが重要なのです。今回は、演習7でデバイス・ファイルの先頭をゼロ埋めしたので空っぽですから、どのASMディスク・グループにも所属していない空っぽなデバイス・ファイルと認識されます。よって、上記の回答例の通り、「GROUP_NUMBER=0」のCANDIDATE（候補）ディスクとして「/dev/sdf1」が認識されているのです。
一方、「GROUP_NUMBER=1」のASMディスク「NAME=DATA_0003」に関しては、対象のデバイス・ファイルが見つからない状態となっている為に、HEADER_STATUSが「UNKNOWN」ですし、PATHも表示されていません。
9. ディスクの置換（Replace Diskコマンド）を実行し、V$ASM_OPERATIONビューからどのような処理が行われているのかを確認して下さい。
[grid@vm11204]$ sqlplus / as sysasm
SQL>
alter diskgroup DATA replace disk DATA_0003 with '/dev/sdf1' power 1 ;
SQL>
select * from V$ASM_OPERATION ;
GROUP_NUMBER OPERA PASS STAT POWER ACTUAL SOFAR EST_WORK EST_RATE EST_MINUTES
------------ ----- --------- ---- ----- ------ ----- -------- -------- -----------
1 REBAL RESYNC RUN 1 1 733 1193 2085 0
1 REBAL REBALANCE WAIT 1 1 0 0 0 0
1 REBAL COMPACT WAIT 1 1 0 0 0 0
(表示の都合上、一部の列を省略)
ようやく辿りつきましたが、今回の連載の目玉である「ディスクの置換」を実行してみた結果が上記の通りです。コマンド自体は非常にシンプルですね。こちらのマニュアルでもご確認下さいね。 今回のコマンドを具体的に表現すると、ASMディスク・グループ「DATA」のASMディスク「DATA_0003」をデバイス・ファイル「/dev/sdf1」に強度（power）「1」で置換して下さい。と命令しているだけです。「wait」オプションを付けることも可能ですよ。
そして、このコマンドを実行すると何が起きるのかをV$ASM_OPERATIONビューで確認してみると、「RESYNC」処理が流れているではありませんか。そうなのですよ。「REBALANCE」処理じゃないのですねー。これは非常に驚き。この処理中にdstatコマンド等でI/O量を見て頂ければ分かるように、既存のASMディスクから読み込みが発生し、新規ASMディスク（この場合は/dev/sdf1）に対してだけ書込みが発生していることも見えると思います。そういう意味で、「RESYNC」=再同期処理と言えるでしょう。
10. ディスクの置換が完了した後、V$ASM_DISKGROUPビューを使用してASMディスク名と障害グループ名が元通りになっているのかを確認して下さい。
[grid@vm11204]$ sqlplus / as sysasm
SQL>
select GROUP_NUMBER, DISK_NUMBER, HEADER_STATUS, STATE, PATH,
NAME, FAILGROUP, TOTAL_MB, FREE_MB, REPAIR_TIMER
from V$ASM_DISK
order by 1,2 ;
GROUP_NUM DISK_NUM HEADER_ST STATE PATH NAME FAILGROUP TOTAL_MB FREE_MB REPAIR_TI
--------- -------- --------- -------- --------- --------- --------- -------- ------- ---------
1 0 MEMBER NORMAL /dev/sdc1 DATA_0000 DATA_0000 2047 846 0
1 1 MEMBER NORMAL /dev/sdd1 DATA_0001 DATA_0001 2047 851 0
1 2 MEMBER NORMAL /dev/sde1 DATA_0002 DATA_0002 2047 846 0
1 3 MEMBER NORMAL /dev/sdf1 DATA_0003 DATA_0003 2047 848 0
2 0 MEMBER NORMAL /dev/sdg1 FRA_0000 FRA_0000 2047 1549 0
2 1 MEMBER NORMAL /dev/sdh1 FRA_0001 FRA_0001 2047 1548 0
2 2 MEMBER NORMAL /dev/sdi1 FRA_0002 FRA_0002 2047 1547 0
2 3 MEMBER NORMAL /dev/sdj1 FRA_0003 FRA_0003 2047 1549 0
と言う事で、見事に障害ディスクを正常ディスクに置換出来た結果が上記の通りです。ASMディスク名（NAME列）と障害グループ名（FILEGROUP列）の表示が、模擬障害発生前と全く同じですよね。素晴らしい！パチパチパチ
さて、Oracle Database 12c Release 1から実装された、ASMディスク・グループ内のディスクの置換（Replace Diskコマンド）を体験して頂きましたが、如何でしたでしょうか？
この機能が実装されるまではASMディスクに障害が発生した際には、基本的に冗長性回復の為に残ったASMディスクでリバランスを実行した後に、障害ディスクを正常ディスクに物理的に交換します。その後、正常ディスクから作り出したデバイス・ファイルを新たなASMディスクとして追加して再度リバランスを実行することになる為、リバランスを2回実行しなければなりませんでした。しかし、このディスクの置換（Replace Diskコマンド）を使用すれば、リバランスは1回で済んでしまうのですよ。リバランス処理はその強度を調節できるものの、完全にディスクI/Oを排除できるものではありません。そいう言う意味では、リバランス処理そのものの回数を減らすことが出来る事は、非常にメリットが大きいと私は思いますので、少しでも皆様の参考になったのであれば嬉しい限りです。
今回も最後までお付き合い頂きましてありがとうございました。是非、感想や質問をお待ちしておりますね。次回以降もどうぞよろしくお願い致します。