ASM を味わう ~ DISK 別の I/O は? ~ その9

<ASM を味わう ~ DISK 別の I/O は? ~ その9>
ペンネーム:ダーリン

前回まで、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 ぐらいのクモがでた。朝グモは縁起がいいといわれても、、茅ヶ崎にて