#ASM 翻译系列第二十五弹：ASM 高级知识 When will my rebalance complete

水深无声 2022-07-12 11:28 191阅读 0赞

> **原文：** [When will my rebalance complete][]  
> **作者：** Bane Radulovic  
> **译者：**魏兴华，沃趣科技高级技术专家，主要参与公司一体机产品、监控产品、容灾产品、DBaaS平台的研发和设计。曾就职于东软集团，阿里巴巴集团，Oracle ACE组成员，DBGEEK 用户组发起人，ITPUB认证博客专家，ACOUG、SHOUG核心成员。曾在中国数据库大会、Oracle技术嘉年华、ORCL-CON、YY分享平台等公开场合多次做过数据库技术专题分享。对Oracle 并行机制、数据库异常恢复方法、ASM等有深入的研究，人称”Oracle Internal达人”，对企业数据库架构设计、故障恢复、高并发下数据库性能调优有丰富的经验，擅长从等待事件角度分析解决数据库性能问题，是OWI方法论的提倡者和践行者。  
> **审校：**魏兴华  
> **责编：**仲培艺

“磁盘组的rebalance什么时候能完成？”，这个问题我经常被问到，但是如果你期望我给出一个具体的数值，那么你会失望，毕竟ASM本身已经给你提供了一个估算值（`GV$ASM_OPERATION.EST_MINUTES`），其实你想知道的是rebalance完成的精确时间。虽然我不能给你一个精确的时间，但是我可以给你一些rebalance的操作细节，让你知道当前rebalance是否正在进行中，进行到哪个阶段，以及这个阶段是否需要引起你的关注。

### Understanding the 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 ###

为了进一步观察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> /
    
       INST_ID OPERA STAT      POWER      SOFAR   EST_WORK   EST_RATE EST_MINUTES
    ---------- ----- ---- ---------- ---------- ---------- ---------- -----------
             3 REBAL WAIT          1
             2 REBAL RUN           1      19235      72210       2124          24
             4 REBAL WAIT          1

有些时候`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 relocating file +DATA1.316.788357201 (120 entries)
    ...

注意，跟踪目录下的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> /
    
       INST_ID OPERA STAT      POWER      SOFAR   EST_WORK   EST_RATE EST_MINUTES
    ---------- ----- ---- ---------- ---------- ---------- ---------- -----------
             2 REBAL RUN           1      74581      75825       2129           0
             3 REBAL WAIT          1
             4 REBAL WAIT          1

很快，ASM的alert日志中显示：

Disk emptied
    Disk header erased
    PST update completed successfully
    Disk closed
    Rebalance completed
    Wed Jul 11 17:17:32 2012
    NOTE: GroupBlock outside rolling migration privileged region
    NOTE: requesting all-instance membership refresh for group=1
    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
    NOTE: PST update grp = 1 completed successfully
    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: group 1 PST updated. Wed Jul 11 17:17:41 2012 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会花费你数小时甚至是数天的时间。

### Compacting ###

在下面的例子里，我们来看一下rebalance的compacting阶段，我把上面删除的磁盘加回来，同时设置rebalance的power为10：

17:26:48 SQL> alter diskgroup DATA1 add disk '/o/*/DATA1_CD_06_celll06' rebalance power 10;
    
    Diskgroup altered.

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;
    
       INST_ID OPERA STAT      POWER      SOFAR   EST_WORK   EST_RATE EST_MINUTES
    ---------- ----- ---- ---------- ---------- ---------- ---------- -----------
             2 REBAL RUN          10        489      53851       7920           6
             3 REBAL WAIT         10
             4 REBAL WAIT         10

大约10分钟后，`EST_MINUTES`的值变为0.

17:39:05 SQL> /
    
       INST_ID OPERA STAT      POWER      SOFAR   EST_WORK   EST_RATE EST_MINUTES
    ---------- ----- ---- ---------- ---------- ---------- ---------- -----------
             3 REBAL WAIT         10
             2 REBAL RUN          10      92407      97874       8716           0
             4 REBAL WAIT         10

这个时候我们在ASM的alert日志中观察到：

Wed Jul 11 17:39:49 2012
    NOTE: GroupBlock outside rolling migration privileged region
    NOTE: requesting all-instance membership refresh for group=1
    Wed Jul 11 17:39:58 2012
    GMON updating for reconfiguration, group 1 at 31 for pid 43, osid 115117
    NOTE: group 1 PST updated.
    Wed Jul 11 17:39:58 2012
    NOTE: membership refresh pending for group 1/0x6ecaf3e6 (DATA1)
    GMON querying group 1 at 32 for pid 19, osid 38421
    SUCCESS: refreshed membership for 1/0x6ecaf3e6 (DATA1)
    NOTE: Attempting voting file refresh on diskgroup DATA1

上面的输出意味着ASM已经完成了rebalance的第二个阶段，开始了第三个阶段compacting，如果我说的没错，通过pstack工具可以看到`kfdCompact()`函数，下面的输出显示，确实如此:

# pstack 103326
    #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 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)
    ARB0 relocating file +DATA1.321.788357323 (1 entries)
    ARB0 relocating file +DATA1.321.788357323 (1 entries)
    ...

compacting过程中，`V$ASM_OPERATION`视图的`EST_MINUTES`字段会显示为0（也是一个重要线索）：

17:42:39 SQL> /
    
       INST_ID OPERA STAT      POWER      SOFAR   EST_WORK   EST_RATE EST_MINUTES
    ---------- ----- ---- ---------- ---------- ---------- ---------- -----------
             3 REBAL WAIT         10
             4 REBAL WAIT         10
             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
    NOTE: stopping process ARB0
    SUCCESS: rebalance completed for group 1/0x6ecaf3e6 (DATA1)

在这个case中，第二阶段extents relocation花费了12分钟，第三阶段compacting话费了4分钟。

在真正的环境中，compacting阶段可能会占用掉比较可观的rebalance时间，曾经遭遇过一个案例，extents relocation花费了60分钟，而compacting操作花费了30分钟。但是其实compacting的消耗时间多少并不重要，因为一旦extents relocation完成，所有的数据就已经满足了冗余度的要求，不再会担心已经失败磁盘的partner磁盘再次失败而出现严重故障。

### Changing the power ###

Rebalance的power可以在磁盘组rebalance过程中动态地更改，如果你认为磁盘组的默认级别太低，可以很容易地增加它。但是增加到多少则需要你根据系统的IO负载、IO吞吐量来定。一般情况下，你可以先尝试增加到一个保守的值，例如5，过上十分钟看是否有所提升，以及是否影响到其他业务对IO的使用，如果你的IO性能非常强，那么可以继续增加power的值，但是就我的经验来看，很少能看到power的设置超过30后还能有较大提升的。

测试的关键点在于，你需要在你生产系统的正常负载下去测试，不同的业务压力、不同的存储系统都可能会让rebalance时间产生较大的差异。

[When will my rebalance complete]: http://asmsupportguy.blogspot.sg/2012/07/when-will-my-rebalance-complete.html