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

原作者:Bane Radulovic

译者: 魏兴华

审核: 魏兴华

DBGeeK社群联合出品

When will my rebalance complete

“磁盘组的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完成,所有的数据就已经满足了冗余度的要求,不再会担心已经失败磁盘的partern磁盘再次失败而出现严重故障。

Changing the power

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

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

关于译者

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

原文发布于微信公众号 - 沃趣科技(woqutech)

原文发表时间:2016-08-22

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏程序猿

周五推荐时间:博客3期

“ 已经推荐两期了,这是第三期,菜单可以查看往期推荐,以下博客有Java Web专题:SSM系列讲解;墙裂推荐;还有第三位,讲解了比较复杂的SQL查询是如何完成...

11610
来自专栏Albert陈凯

2018-11-06 成为一个专业的程序员前言

https://github.com/stanzhai/be-a-professional-programmer

92320
来自专栏SAP最佳业务实践

从SAP最佳业务实践看企业管理(91)-PP-249委外加工

PP249委外加工 目的 业务情景外包制造基于最佳实践按库存生产-离散行业(145)并专注于SAPERP的外包可能性(请参见业务情景145的目的)。在MTS流程...

68560
来自专栏顶级程序员

Python 2要凉了,RedHat也正式宣布弃坑

源 / 顶级程序员 文 / An先生 (RedHat 官网截图) 近日,Red Hat 宣布,它的企业级发行版 RHEL 下个大版本将用 Python...

38680
来自专栏CSDN技术头条

最有趣的代码注释,一次看过瘾!

代码注释的作用,不需要对程序员解释了。有时在查看他人代码,能看到一些令人不禁大笑的注释。比如:

21820
来自专栏SDNLAB

SDN实战团分享(三十一):Segment Routing meet SDN

一、介绍 ? 在1990年代Yakov, Eric Rosen, Kompella很多业界先驱(仅列举了Juniper公司的MPLS业界领袖,其他公司也有 很多...

774160
来自专栏SDNLAB

SDNLAB技术分享(七):开源SDN控制器DCFabric及云计算高效网络

1.DCFabric控制器的由来 1.1 SDN是云计算数据中心网络技术发展的必然要求 随着以虚拟化为基础的云数据中心的发展和成熟, 应用数据猛增,虚拟服...

38960
来自专栏牛客网

九月初,终于稳了一波,可以放松一下了嘛 附面经

最近几年的经历教会我一个道理,那就是,只要你努力,世界上没有什么事搞不砸的。——尼克·霍恩比

12410
来自专栏SDNLAB

云数据中心网络虚拟化——大二层技术巡礼之控制平面多虚一

控制平面多虚一,指的是将两台或者多台设备的资源(包括操作系统、转发实例、转发表、端口等)进行整合,对外表现为一台逻辑设备,以Cisco VSS,Huawei C...

44850
来自专栏顶级程序员

你写过什么有趣的程序?最后一个笑出猪叫

源 / 程序员之家 苍冥说: 我们从高一到高三都强制采用图形计算器,可以画函数图像的那种。我们用的是德州仪器系列,Ti-Nspire,贵的要死要死的。然而我却买...

447110

扫码关注云+社区

领取腾讯云代金券