ASM を味わう ~ DISK の I/O を均等化してみる ~ その13

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

前回の検証で、DISK I/O を偏らせてみました。これを均等化することは出来
るでしょうか。
ASM の資料の中には、「ホットスポットを発生させない」と言ううたい文句も
あります。ということは、前回の検証のように I/O が偏るケースがあった場
合、これを自動的に再配置してくれたりするのでしょうか。では、前回の環境
でリバランスを試してみます。リバランスとは、今回の ASM の検証の初めに
DISK Group を構成している DISK を DROP したり、反対に ADD した際にデー
タの再配置をしてくれたあの機能です。
そもそも DISK を DROP や ADD しなくても リバランスは可能なのでしょうか?
では、今回は手動でリバランスの効果の有無を試して見ましょう。

まずは、リバランス実行。でゃ!

SQL> alter diskgroup dg_0001 rebalance;

Diskgroup altered.

言わずもがな、ASM インスタンスで実行してください。

もし、データが移動されていれば各 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    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    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

んんー。まったく違いがない様に見えます。

では、I/O はどうでしょうか。

検索パターンは前回と同じで、特定の EXTENT のレコードのみを検索するよう
にします。(完全には偏りませんでしたが)

SQ> 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 ));

.....................
.....................

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

物理読み込みは前回と同じです。
さて、、

<>

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    3741    951  187613184      65561600
DISK_002   /dev/raw/raw4   17593    912  310063104      68220416
DISK_001   /dev/raw/raw3    1995  17343  159178752     131596800

<>

SQL> /

NAME       PATH            READS WRITES BYTES_READ BYTES_WRITTEN
---------- --------------- ----- ------ ---------- -------------
DISK_003   /dev/raw/raw5    3849    951  189108224      65561600
DISK_002   /dev/raw/raw4   18817    912  320086016      68220416
DISK_001   /dev/raw/raw3    2010  17352  160157696     131633664

          検索前    検索後   差分
          ------    ------   -----
DISK_001    1995      2010      15
DISK_002   17593     18817    1224
DISK_003    3741      3849     108

あらら。リバランス前とまったく同じです。
念のため、レコードと EXTENT の関連も確認しておきましょう。

  1  select extent_id,count(*),min(min_c1),max(max_c1) from (
  2  select min(b.c1) over (partition by a.extent_id) min_c1
  3        ,max(b.c1) over (partition by a.extent_id) max_c1
  4        ,a.extent_id
  5  from dba_extents a
  6     , darling.tbl001 b
  7  where dbms_rowid.rowid_block_number(b.rowid) >= a.block_id
  8    and dbms_rowid.rowid_block_number(b.rowid) < a.block_id + a.blocks
  9    and a.segment_name = 'TBL001'
 10  )
 11* group by extent_id
SQL> /

 EXTENT_ID   COUNT(*) MIN(MIN_C1) MAX(MAX_C1)
---------- ---------- ----------- -----------
         0        124           1         124
         1        126         125         250
         2        126         251         376
         3        126         377         502
         4        126         503         628
         5        126         629         754
      ....       ....       .....       .....
        25        126        3149        3274
        26        126        3275        3400
        27        126        3401        3526
        28        126        3527        3652
        29        126        3653        3778
        30         62        3779        3840

31 rows selected.

こちらも、特に変化はなさそうです。

ということは、ASM のリバランス機能としては、I/O バランスはとってくれな
いようですね。果たして”ホットスポットは発生しない”という表現は正しい
のだろうか?

そろそろヒーターが恋しい 茅ヶ崎にて