“磁盘组的rebalance什么时候能完成？”，这个问题我经常被问到，但是如果你期望我给出一个具体的数值，那么你会失望，毕竟asm本身已经给你提供了一个估算值（gv$asm_operation.est_minutes），其实你想知道的是rebalance完成的精确的时间。虽然我不能给你一个精确的时间，但是我可以给你一些rebalance的操作细节，让你知道当前rebalance是否正在进行中，进行到哪个阶段，以及这个阶段是否需要引起你的关注。
就像在本asm系列文章的“rebalancing act”章介绍过的，rebalance操作本身包含了3个阶段-planning, extents relocation 和 compacting，就rebalance需要的总时间而言，planning阶段需要的时间是非常少的，你通常都不用去关注这一个阶段，第二个阶段extent relocation一般会占取rebalance阶段的大部分时间，也是我们最为需要关注的阶段，最后我们也会讲述第三阶段compacting阶段在做些什么。
首先需要明白为什么会需要做rebalance，如果你为了增加磁盘组的可用空间，增加了一块新磁盘，你可能并不太会关注rebalance什么时候完成，好吧，也可能确实你需要关注，比如你的归档空间所在的dg满了，导致数据库hang了。相似的，如果你为了调整磁盘的空间，例如resizing或者删除磁盘，你可能也不会太去关注rebalance啥时候完成。
但是，如果磁盘组中的一块磁盘损坏了，这个时候你就有足够的理由关注rebalance的进度了，假如，你的磁盘组是normal冗余的，这个时候万一你损坏磁盘的partner磁盘也损坏，那么你的整个磁盘组会被dismount，所有跑在这个磁盘组上的数据库都会crash，你可能还会丢失数据。在这种情况下，你非常需要知道rebalance什么时候完成，实际上，你需要知道第二个阶段extent relocation什么时候完成，一旦它完成了，整个磁盘组的冗余就已经完成了（第三个阶段对于冗余度来说并不重要，后面会介绍）。
为了进一步观察extents relocation阶段，我删除了具有默认并行度的磁盘组上的一块磁盘：
sql> show parameter power
name type value
------------------------------------ ----------- ----------------
asm_power_limit integer 1
sql> set time on
16:40:57 sql> alter diskgroup data1 drop disk data1_cd_06_cell06;
diskgroup altered.
asm的视图gv$asmoperation的estminutes字段给出了估算值的时间，单位为分钟，这里给出的估算时间为26分钟。
16:41:21 sql> select inst_id, operation, state, power, sofar, est_work, est_rate, est_minutes from gv$asm_operation where group_number=1;
inst_id opera stat power sofar est_work est_rate est_minutes
---------- ----- ---- ---------- ---------- ---------- ---------- -----------
3 rebal wait 1
2 rebal run 1 516 53736 2012 26
4 rebal wait 1
大约过了10分钟后，est_minutes的值变为了24分钟：
16:50:25 sql> /
2 rebal run 1 19235 72210 2124 24
有些时候est_minutes的值可能并不能给你太多的证据，我们还可以看到sofar（截止目前移动的ua数）的值一直在增加，恩，不错，这是一个很好的一个观察指标。
asm的alert日志中也显示了删除磁盘的操作，以及os arb0进程的id，asm用它用来做所有的rebalance工作。更重要的，整个过程之中，没有任何的错误输出：
wed jul 11 16:41:15 2012
sql> alter diskgroup data1 drop disk data1_cd_06_cell06
note: groupblock outside rolling migration privileged region
note: requesting all-instance membership refresh for group=1
...
note: starting rebalance of group 1/0x6ecaf3e6 (data1) at power 1
starting background process arb0
wed jul 11 16:41:24 2012
arb0 started with pid=41, os id=58591
note: assigning arb0 to group 1/0x6ecaf3e6 (data1) with 1 parallel i/o
note: f1x0 copy 3 relocating from 0:2 to 55:35379 for diskgroup 1 (data1)
arb0进程的跟踪文件也显示了，当前正在对哪一个asm文件的extent的在进行重分配，也是通过这个跟踪文件，我们可以知道arb0确实是在干着自己的本职工作，没有偷懒。
$ tail -f /u01/app/oracle/diag/asm/+asm/+asm2/trace/+asm2_arb0_58591.trc
arb0 relocating file +data1.282.788356359 (120 entries)
*** 2012-07-11 16:48:44.808
arb0 relocating file +data1.283.788356383 (120 entries)
*** 2012-07-11 17:13:11.761
arb0 relocating file +data1.316.788357201 (120 entries)
*** 2012-07-11 17:13:16.326
注意，跟踪目录下的arb0的跟踪文件可能会有很多，因此我们需要知道arb0的os是进程号，是哪一个arb0在实际做rebalance的工作，这个信息在asm实例执行rebalance操作的时候，alert文件中会有显示。
我们还可以通过操作系统命令pstack来跟踪arb0进程，查看具体它在做什么，如下，它向我们显示了，asm正在重分配extent（在堆栈中的关键函数 kfgbrebalexecute - kfdaexecute - kffrelocate):
# pstack 58591
#0 0x0000003957ccb6ef in poll () from /lib64/libc.so.6
#9 0x0000000003d711e0 in kfk_reap_oss_async_io ()
#10 0x0000000003d70c17 in kfk_reap_ios_from_subsys ()
#11 0x0000000000aea50e in kfk_reap_ios ()
#12 0x0000000003d702ae in kfk_io1 ()
#13 0x0000000003d6fe54 in kfkrequest ()
#14 0x0000000003d76540 in kfk_transitio ()
#15 0x0000000003cd482b in kffrelocatewait ()
#16 0x0000000003cfa190 in kffrelocate ()
#17 0x0000000003c7ba16 in kfdaexecute ()
#18 0x0000000003d4beaa in kfgbrebalexecute ()
#19 0x0000000003d39627 in kfgbdriver ()
#20 0x00000000020e8d23 in ksbabs ()
#21 0x0000000003d4faae in kfgbrun ()
#22 0x00000000020ed95d in ksbrdp ()
#23 0x0000000002322343 in opirip ()
#24 0x0000000001618571 in opidrv ()
#25 0x0000000001c13be7 in sou2o ()
#26 0x000000000083ceba in opimai_real ()
#27 0x0000000001c19b58 in ssthrdmain ()
#28 0x000000000083cda1 in main ()
大约过了35分钟后est_minutes的值变为了0
17:16:54 sql> /
2 rebal run 1 74581 75825 2129 0
很快的，asm的alert日志中显示：
disk emptied
disk header erased
pst update completed successfully
disk closed
rebalance completed
wed jul 11 17:17:32 2012
wed jul 11 17:17:41 2012
gmon updating for reconfiguration, group 1 at 20 for pid 38, osid 93832
note: group 1 pst updated.
success: grp 1 disk data1_cd_06_cell06 emptied
note: erasing header on grp 1 disk data1_cd_06_cell06
note: process _x000_+asm2 (93832) initiating offline of disk 0.3916039210 (data1_cd_06_cell06) with mask 0x7e in group 1
note: initiating pst update: grp = 1, dsk = 0/0xe96a042a, mask = 0x6a, op = clear
gmon updating disk modes for group 1 at 21 for pid 38, osid 93832
note: pst update grp = 1 completed successfully
note: initiating pst update: grp = 1, dsk = 0/0xe96a042a, mask = 0x7e, op = clear
gmon updating disk modes for group 1 at 22 for pid 38, osid 93832
note: cache closing disk 0 of grp 1: data1_cd_06_cell06
gmon updating for reconfiguration, group 1 at 23 for pid 38, osid 93832
note: cache closing disk 0 of grp 1: (not open) data1_cd_06_cell06
note: membership refresh pending for group 1/0x6ecaf3e6 (data1)
gmon querying group 1 at 24 for pid 19, osid 38421
gmon querying group 1 at 25 for pid 19, osid 38421
note: disk in mode 0x8 marked for de-assignment
success: refreshed membership for 1/0x6ecaf3e6 (data1)
note: stopping process arb0
success: rebalance completed for group 1/0x6ecaf3e6 (data1)
note: attempting voting file refresh on diskgroup data1
因此asm预估了26分钟的时间来完成rebalance，但实际上却使用了36分钟的时候（在这个场景里compacting阶段只花取了不到一分钟的时候，我们忽略它好了），因此首先能知道rebalance正在做什么非常重要，然后才能知道rebalance什么时候能完成。
注意，估算的时间是动态变化的，可能会增加或减少，这个依赖你的系统负载变化，以及你的rebalance的power值的设置，对于一个非常大容量的磁盘组来说，可能rebalance会花费你数小时甚至是数天的时间。
在下面的例子里，我们来看下rebalance的compacting阶段，我把上面删除的磁盘加回来，同时设置rebalance的power为10：
17:26:48 sql> alter diskgroup data1 add disk '/o/*/data1_cd_06_celll06' rebalance power 10;
asm给出的rebalance的估算时间为6分钟：
17:27:22 sql> select inst_id, operation, state, power, sofar, est_work, est_rate, est_minutes from gv$asm_operation where group_number=1;
2 rebal run 10 489 53851 7920 6
3 rebal wait 10
4 rebal wait 10
大约10分钟后，est_minutes的值变为0.
17:39:05 sql> /
2 rebal run 10 92407 97874 8716 0
这个时候我们在asm的alert日志中观察到：
wed jul 11 17:39:49 2012
wed jul 11 17:39:58 2012
gmon updating for reconfiguration, group 1 at 31 for pid 43, osid 115117
gmon querying group 1 at 32 for pid 19, osid 38421
上面的输出意味着asm已经完成了rebalance的第二个阶段，开始了第三个阶段compacting，如果我说的没错，通过pstack工具可以看到kfdcompact()函数，下面的输出显示，确实如此；
# pstack 103326
#18 0x0000000003c4b737 in kfdcompact ()
#19 0x0000000003c4c6d0 in kfdexecute ()
#20 0x0000000003d4bf0e in kfgbrebalexecute ()
#21 0x0000000003d39627 in kfgbdriver ()
#22 0x00000000020e8d23 in ksbabs ()
#23 0x0000000003d4faae in kfgbrun ()
#24 0x00000000020ed95d in ksbrdp ()
#25 0x0000000002322343 in opirip ()
#26 0x0000000001618571 in opidrv ()
#27 0x0000000001c13be7 in sou2o ()
#28 0x000000000083ceba in opimai_real ()
#29 0x0000000001c19b58 in ssthrdmain ()
#30 0x000000000083cda1 in main ()
通过tail命令查看arb0的跟踪文件，发现relocating正在进行，而且一次只对一个条目进行relocating。（这是正进行到compacting阶段的另一个重要线索）：
$ tail -f /u01/app/oracle/diag/asm/+asm/+asm2/trace/+asm2_arb0_103326.trc
arb0 relocating file +data1.321.788357323 (1 entries)
compacting过程中，v$asm_operation视图的est_minutes字段会显示为0（也是一个重要线索）：
17:42:39 sql> /
2 rebal run 10 98271 98305 7919 0
固态表x$kfgmg的rebalst_kfgmg字段会显示为2，代表正在compacting。
17:42:50 sql> select number_kfgmg, op_kfgmg, actual_kfgmg, rebalst_kfgmg from x$kfgmg;
number_kfgmg op_kfgmg actual_kfgmg rebalst_kfgmg
------------ ---------- ------------ -------------
1 1 10 2
一旦compacting阶段完成，asm的alert 日志中会显示stopping process arb0 和rebalance completed:
wed jul 11 17:43:48 2012
在这个case中，第二阶段extents relocation花费了12分钟，第三阶段compacting话费了4分钟。
在真正的环境中，compacting阶段可能会占用掉比较可观的rebalance时间，曾经遭遇过一个案例，extents relocation 花费了60分钟，而compacting操作花费了30分钟。但是其实compacting的消耗时间多少并不重要，因为一旦extents relocation完成，所有的数据就已经满足了冗余度的要求，不再会担心已经失败磁盘的partern磁盘再次失败而出现严重故障。
rebalance的power可以在磁盘组rebalance过程中动态的更改，如果你认为磁盘组的默认级别太低了，可以去很容易的增加它。但是增加到多少呢？这个需要你根据你系统的io负载，io吞吐量来定。一般情况下，你可以先尝试增加到一个保守的值，例如5，过上十分钟看是否有所提升，以及是否影响到了其他业务对io的使用，如果你的io性能非常强，那么可以继续增加power的值，但是就我的经验来看，很少能看到power 的设置超过30后还能有较大提升的。
测试的关键点在于，你需要在你生产系统的正常负载下去测试，不同的业务压力，不同的存储系统，都可能会让rebalance时间产生较大的差异。
<b>本文来自云栖社区合作伙伴“dbgeek”</b>
![【MySQL数据库】数据库索引事务1.索引2.事务[图]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)