ASM を味わう ~ DISK の I/O をもう一度均等化してみる ~ その14

<ASM を味わう ~ DISK の I/O をもう一度均等化してみる ~ その14>
ペンネーム:ダーリン

前回の検証で、同一 DISK Group 内で偏っている DISK I/O をリバランスコマ
ンドで均等化できるかどうかを試してみました。結果としては、I/O バランス
はまったく変わらず、少なくとも I/O に関して ASM の機能でバランシングを
行っていないであろうことを確認しました。

では、今回は強引にデータを移動させて見ましょう。つまり、DISK を DROP &
ADD してみます。これならいやでもデータは移動するはずです。

ちなみに DISK Group に所属している DISK を DROP すると、当然その DISK
に配置されているデータが他の DISK に移動されます。ということは、今回の
ように、DISK I/O が偏っている場合は、I/O が集中している DISK のデータ
を他の DISK へ移動させてしまえば、I/O の集中は緩和されるはずです。仮に、
I/O が集中していない DISK を DROP しても、もともと少ない I/O なら DROP
後の I/O の偏りは大きくは変化しないはずです。

今回は、I/O の偏りを緩和できるかどうかと言う点に着目しているので、I/O
が集中している DISK_002 を DROP して見ましょう。

<>

          検索前    検索後   差分
          ------    ------   -----
DISK_001    1995      2010      15
DISK_002   17593     18817    1224
DISK_003    3741      3849     108
SQL> alter diskgroup dg_0001 drop disk disk_002;

Diskgroup altered.

さてデータが移動したかどうか確認しましょう。

<>

SQL> select a.name        dg_name
  2       , b.disk_number
  3       , b.total_mb
  4       , b.free_mb
  5       , b.name
  6       , b.path
  7   from v$asm_diskgroup a
  8      , v$asm_disk b
  9  where a.group_number = b.group_number
 10    and a.name = 'DG_0001';

DG_NAME    DISK_NUMBER   TOTAL_MB    FREE_MB NAME       PATH
---------- ----------- ---------- ---------- ---------- -------------
DG_0001              2      10236      10185 DISK_003   /dev/raw/raw5
DG_0001              1      10236      10183 DISK_002   /dev/raw/raw4
DG_0001              0      10236      10185 DISK_001   /dev/raw/raw3

<>

SQL> /

DG_NAME    DISK_NUMBER   TOTAL_MB    FREE_MB NAME       PATH
---------- ----------- ---------- ---------- ---------- -------------
DG_0001              2      10236      10176 DISK_003   /dev/raw/raw5
DG_0001              1      10236      10200 DISK_002   /dev/raw/raw4
DG_0001              0      10236      10177 DISK_001   /dev/raw/raw3

<>

SQL> /

DG_NAME    DISK_NUMBER   TOTAL_MB    FREE_MB NAME       PATH
---------- ----------- ---------- ---------- ---------- -------------
DG_0001              2      10236      10158 DISK_003   /dev/raw/raw5
DG_0001              0      10236      10161 DISK_001   /dev/raw/raw3

DISK_002 が切り離された様です。

では、前回と同じ検索を実施して I/O の状況を確認します。

SQL> select /*+ index(b ui_tbl001) */
  2         dbms_rowid.rowid_block_number(b.rowid) blk_num
  3       , b.c2
  4    from darling.tbl001 b
  5   where (   ( b.c1 >=    1 and b.c1 <=  124 )
  6          or ( b.c1 >=  377 and b.c1 <=  502 )
  7          or ( b.c1 >=  755 and b.c1 <=  880 )
  8          or ( b.c1 >= 1133 and b.c1 <= 1258 )
  9          or ( b.c1 >= 1511 and b.c1 <= 1636 )
 10          or ( b.c1 >= 1889 and b.c1 <= 2014 )
 11          or ( b.c1 >= 2267 and b.c1 <= 2392 )
 12          or ( b.c1 >= 2645 and b.c1 <= 2770 )
 13          or ( b.c1 >= 3032 and b.c1 <= 3148 )
 14          or ( b.c1 >= 3401 and b.c1 <= 3526 )
 15          or ( b.c1 >= 3779 and b.c1 <= 3840 ));

1311 rows selected.

Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=49 Card=1341 Bytes=2711502)
   1    0   TABLE ACCESS (BY INDEX ROWID) OF 'TBL001' (TABLE) (Cost=49 Card=1341 Bytes=2711502)
   2    1     INDEX (FULL SCAN) OF 'UI_TBL001' (INDEX (UNIQUE)) (Cost=26 Card=88)


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
       1408  consistent gets
       1320  physical reads
          0  redo size
    5285567  bytes sent via SQL*Net to client
       1469  bytes received via SQL*Net from client
         89  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
       1311  rows processed

実行計画や統計値は前回と同様です。

では、I/O はどうでしょうか。うまく均等化されているでしょうか。
完全とまではいかなくても、データ量がほぼ同等に割り振られているので、必
然的に I/O が分散されていてもおかしくないはずです。

<>

SQL> select a.name
  2       , a.path
  3       , a.reads
  4       , a.writes
  5       , a.bytes_read
  6       , a.bytes_written
  7    from v$asm_disk a
  8       , v$asm_diskgroup b
  9   where a.group_number = b.group_number
 10    and b.name = 'DG_0001';

NAME       PATH             READS     WRITES BYTES_READ BYTES_WRITTEN
---------- --------------- ------ ---------- ---------- -------------
DISK_003   /dev/raw/raw5     5331       1102  228646912     111109120
DISK_001   /dev/raw/raw3     2371      35731  175112192     233034240

<>

SQL> /

NAME       PATH             READS     WRITES BYTES_READ BYTES_WRITTEN
---------- --------------- ------ ---------- ---------- -------------
DISK_003   /dev/raw/raw5     6617       1102  239423488     111109120
DISK_001   /dev/raw/raw3     2431      35737  176828416     233058816
          検索前    検索後   差分
          ------    ------   -----
DISK_001    2371      2431     60
DISK_003    5331      6617   1286

なんだこれ!? だめだめじゃん!!
データ量がほぼ均等に割り振られているのに、I/O が振り分けられないという
ことは、DISK_002 にあったデータが実は丸ごと DISK_003 に移動されただけ
なんでしょうか?
よし、ではもう一度挑戦します。次は今 DROP した DISK を追加します。

<>

SQL>  select a.name        dg_name
  2        , b.disk_number
  3        , b.total_mb
  4        , b.free_mb
  5        , b.name
  6        , b.path
  7    from v$asm_diskgroup a
  8       , v$asm_disk b
  9   where a.group_number = b.group_number
 10     and a.name = 'DG_0001'

DG_NAME    DISK_NUMBER   TOTAL_MB    FREE_MB NAME       PATH
---------- ----------- ---------- ---------- ---------- -------------
DG_0001              2      10236      10158 DISK_003   /dev/raw/raw5
DG_0001              0      10236      10161 DISK_001   /dev/raw/raw3

<>

SQL> /

DG_NAME    DISK_NUMBER   TOTAL_MB    FREE_MB NAME       PATH
---------- ----------- ---------- ---------- ---------- -------------
DG_0001              2      10236      10182 DISK_003   /dev/raw/raw5
DG_0001              1      10236      10188 DISK_002   /dev/raw/raw4
DG_0001              0      10236      10183 DISK_001   /dev/raw/raw3

追加出来たようです。各 DISK のデータ量は DISK を DROP する前とほぼ同じ
ような状態になっています。

では、同様の検索処理を実行して I/O の偏り状態を確認します。
今度はどうでしょうか。

<>

NAME       PATH             READS     WRITES BYTES_READ BYTES_WRITTEN
---------- --------------- ------ ---------- ---------- -------------
DISK_003   /dev/raw/raw5     6684       1178  264765440     111420416
DISK_002   /dev/raw/raw4       24         94      98304      50397184
DISK_001   /dev/raw/raw3     2496      36550  200073216     236392960

<>

NAME       PATH             READS     WRITES BYTES_READ BYTES_WRITTEN
---------- --------------- ------ ---------- ---------- -------------
DISK_003   /dev/raw/raw5     7918       1178  274870272     111420416
DISK_002   /dev/raw/raw4       80         94     921600      50397184
DISK_001   /dev/raw/raw3     2553      36562  201641984     236442112
          検索前    検索後   差分
          ------    ------   -----
DISK_001    2496      2553      57
DISK_002      24        80      56
DISK_003    6684      7918    1234

んー。
I/O が偏る DISK が入れ替わっただけで、結局問題解決にはなっていないよう
です。
DISK Group 内の DISK I/O の偏りについては、ASM 自体は何の効力も発揮し
てくれないようですね。しかし、DISK を DROP したらその DISK のデータが
特定の DISK にだけ再配置されるなんてどうにも納得できない。バランスでき
ていないじゃないか。

ASM は”サイジングが容易な大きな器”とだけ認識したほうがよさそうです。
I/O バランシングに関して過大に期待してはいけません。

さて、ASM に関しての検証は今回で一旦終了しますが、まだまだ検証したりな
い部分がたくさん出てきました。いずれ機会を見つけてご報告したいと思います。
では。

砂浜でなくしたカギが見つかりました。送ってくれた人、ありがとう。
茅ヶ崎にて