ASM を味わう ～ DISK 別の I/O は？ ～ その９
＜ASM を味わう ～ DISK 別の I/O は？ ～ その９＞
ペンネーム：ダーリン
前回まで、ASM を利用して Oracle を構成した場合、DISK の追加や削除で ASM
がどのような挙動をしめすのかを、行き当たりばったりで見てきました。
どうやら、 DISK のステータスに関係なく DISK が DROP されれば、データを
勝手に移動し、また、ADD されればそれなりにデータを移動するようだという
ことがわかりました。 つまり、ASM としては、データの中身がどうであれ、
データをそれなりに再配置しているだけのように見えます。
運用する側として気をつけたいのが、DISK のステータスが通常ありえない状
況になっていても、ASM は気にせず、稼動し続ける可能性があるという点でし
ょうか。
では、仮に HEADER_STATUS が “CANDIDATE” とか STATE が “HUNG” になった
ときはどうするのが、BEST なのでしょうか。ASM としては、前回までの様に
HEADER_STATUS や STATE がおかしくなっていてもデータをそのまま正常な
DISK に再配置させようとしているので再配置されたデータには信用が置けま
せん、すぐにリカバリの準備をするべきなんでしょうね。
でも、仮にリカバリをしなくてはならないとするならば、何をリカバリすれば
よいのでしょうか？ もし、「その DISK Group に存在するすべてのデータファ
イルをリストアしてください」なんてことになったらかなりダメージが大きく
なります。この辺りは、RAID Group の話と似ています。障害影響範囲を極小化
するためには、DISK Group もある程度複数に分けて管理すべきでしょう。
まぁ、Oracle がデータの異常を検知してミラー側のデータで上書きしてくれ
れば助かるのですが。
ところで、ASM のもう 1 つのお話をしていませんでした。I/O 分散です。
Oracle ではホットスポットが発生しないと謳っていますが ASM の I/O 分散は
どのようになっているのでしょうか。
例えば、ASM では AU(Allocation Unit) 単位で分散しているはずです。ASM の
AU には、2 種類あります。1MB と 128 KB です。デフォルトでそれぞれのサ
イズをとる属性のファイルがあるようですが、通常のデータファイルについて
も、いずれか選択可能です。これらのサイズを変えることでレスポンスに与え
る影響はあるのでしょうか。
今回から、I/O に関する情報を探ってみましょう。
まずは、ASM インスタンスで I/O に関する情報を見てみます。
SQL> select disk_number 2 , name 3 , path 4 , reads 5 , writes 6 , read_errs 7 , write_errs 8 , read_time 9 , write_time 10 , bytes_read 11 , bytes_written 12 from v$asm_disk; DISK_NUMBER NAME PATH READS WRITES READ_ERRS WRITE_ERRS READ_TIME WRITE_TIME BYTES_READ BYTES_WRITTEN ----------- ---------- ------------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ------------- 0 /dev/raw/raw1 4 DATA_0004 /dev/raw/raw5 3901 44572 0 0 70 97 534023168 959152128 3 DATA_0003 /dev/raw/raw4 2999 43422 0 0 66 169 519790592 744956928 2 DATA_0002 /dev/raw/raw3 2631 33375 0 0 60 117 497568768 406916608 1 DATA_0001 /dev/raw/raw2 4795 52707 0 0 71 148 526945280 745371136 SQL> / DISK_NUMBER NAME PATH READS WRITES READ_ERRS WRITE_ERRS READ_TIME WRITE_TIME BYTES_READ BYTES_WRITTEN ----------- ---------- -------------- --------- ---------- ---------- ---------- ---------- ---------- ---------- ------------- 0 /dev/raw/raw1 4 DATA_0004 /dev/raw/raw5 3902 44642 0 0 70 97 534027264 960240640 3 DATA_0003 /dev/raw/raw4 3000 43498 0 0 66 169 519794688 745655296 2 DATA_0002 /dev/raw/raw3 2632 33410 0 0 60 117 497572864 407059968 1 DATA_0001 /dev/raw/raw2 4796 52779 0 0 71 149 526949376 746062336
v$asm_disk ビューから、各 DISK の I/O 情報が取得できるのですが、いつも
のごとくいずれも累計値です。ためにし 2 回取得してみました。これで差分が
取れるので、その間のアクティビティーを確認することが出来ます。詳細はマ
ニュアルに譲りますが、I/O 要求回数や、バイト数を取得することが出来ます。
この I/O 単位はというと
( 526949376 – 526945280 ) / ( 4796 – 4795 ) = 4096
上記では 1 I/O 当たり、4096 bytes 単位で I/O が発生している様子がわか
ります。 AU と I/O の単位は直接は関係ないようです。
ちなみに、上記の 4096 byte はたまたまそうなっただけのようです。
DBA_SOURCE を 検索しながら、同じようにDISK の I/O 状況をとってみると、
読み込みに関しては、4096 byte 単位でしたが、書き込みは 最小で 512 byte
になっているようです。512 byte ということは、OS の書き込み単位のように
思われます。 Oracle で OS レベルの書き込みが発生すると言うことは、、、
これはたぶん オンライン REDO ログファイルへの書き込みでしょう。
さて、I/O のバランスを確認してみると、、
(%) READS WRITE READ_TIME WRITE_TIME BYTES_READ BYTES_WRITE
------ ----- --------- ----------- ----------- ------------
DATA_0001 33.5 30.3 26.6 28.0 25.4 26.1
DATA_0002 18.4 19.2 22.5 22.0 23.9 14.2
DATA_0003 20.9 25.0 24.7 31.8 25.0 26.1
DATA_0004 27.2 25.6 26.2 18.2 25.7 33.6
必ずしもバランスが取れているとは言いにくい状況です。
ちなみに、データ量のバランスは、、
(%) BYTES
------
DATA_0001 24.5
DATA_0002 24.8
DATA_0003 25.2
DATA_0004 25.5
とほぼ均一になっています。
つまり、データはほぼ偏っていないのだが I/O は必ずしも均等にはなっていな
いということです。
今週はこの辺で。
10 cm ぐらいのクモがでた。朝グモは縁起がいいといわれても、、茅ヶ崎にて