这篇文章主要讲解了“Oracle ASM Rebalance执行过程是怎样的”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“Oracle ASM Rebalance执行过程是怎样的”吧！

磁盘组的rebalance什么时候能完成？这没有一个具体的数值，但ASM本身已经给你提供了一个估算值（GV$ASM_OPERATION.EST_MINUTES），想知道rebalance完成的精确的时间，虽然不能给出一个精确的时间，但是可以查看一些rebalance的操作细节，让你知道当前rebalance是否正在进行中，进行到哪个阶段，以及这个阶段是否需要引起你的关注。

理解rebalance
rebalance操作本身包含了3个阶段-planning, extents relocation 和 compacting，就rebalance需要的总时间而言，planning阶段需要的时间是非常少的，你通常都不用去关注这一个阶段，第二个阶段extent relocation一般会占取rebalance阶段的大部分时间，也是我们最为需要关注的阶段，最后我们也会讲述第三阶段compacting阶段在做些什么。

首先需要明白为什么会需要做rebalance，如果你为了增加磁盘组的可用空间，增加了一块新磁盘或者为了调整磁盘的空间，例如resizing或者删除磁盘，你可能也不会太去关注rebalance啥时候完成。但是，如果磁盘组中的一块磁盘损坏了，这个时候你就有足够的理由关注rebalance的进度了，假如，你的磁盘组是normal冗余的，这个时候万一你损坏磁盘的partner磁盘也损坏，那么你的整个磁盘组会被dismount，所有跑在这个磁盘组上的数据库都会crash，你可能还会丢失数据。在这种情况下，你非常需要知道rebalance什么时候完成，实际上，你需要知道第二个阶段extent relocation什么时候完成，一旦它完成了，整个磁盘组的冗余就已经完成了（第三个阶段对于冗余度来说并不重要，后面会介绍）。

Extents relocation

为了进一步观察extents relocation阶段，我删除了具有默认并行度的磁盘组上的一块磁盘：

SQL>showparameterpowerNAMETYPEVALUE----------------------------------------------------------------------------------------asm_power_limitinteger114:47:35SQL>selectgroup_number,disk_number,name,state,path,header_statusfromv$asm_diskwheregroup_number=5;GROUP_NUMBERDISK_NUMBERNAMESTATEPATHHEADER_STATUS-------------------------------------------------------------------------------------------------------50TESTDG_0000NORMAL/dev/raw/raw7MEMBER52TESTDG_0002NORMAL/dev/raw/raw13MEMBER51TESTDG_0001NORMAL/dev/raw/raw12MEMBER53TESTDG_0003NORMAL/dev/raw/raw14MEMBER14:48:38SQL>alterdiskgrouptestdgdropdiskTESTDG_0000;Diskgroupaltered.

下面视图GV$ASMOPERATION的ESTMINUTES字段给出了估算值的时间，单位为分钟，这里给出的估算时间为9分钟。

14:49:04SQL>selectinst_id,operation,state,power,sofar,est_work,est_rate,est_minutesfromgv$asm_operationwheregroup_number=5;INST_IDOPERATIONSTATEPOWERSOFAREST_WORKEST_RATEEST_MINUTES-----------------------------------------------------------------------------------------------------1REBALRUN1447484759

大约过了1分钟后，EST_MINUTES的值变为了0分钟：

14:50:22SQL>selectinst_id,operation,state,power,sofar,est_work,est_rate,est_minutesfromgv$asm_operationwheregroup_number=5;INST_IDOPERATIONSTATEPOWERSOFAREST_WORKEST_RATEEST_MINUTES-----------------------------------------------------------------------------------------------------1REBALRUN13030474824290

有些时候EST_MINUTES的值可能并不能给你太多的证据，我们还可以看到SOFAR（截止目前移动的UA数）的值一直在增加，恩，不错，这是一个很好的一个观察指标。ASM的alert日志中也显示了删除磁盘的操作，以及OS ARB0进程的ID，ASM用它用来做所有的rebalance工作。更重要的，整个过程之中，没有任何的错误输出：

SQL>alterdiskgrouptestdgdropdiskTESTDG_0000NOTE:GroupBlockoutsiderollingmigrationprivilegedregionNOTE:requestingall-instancemembershiprefreshforgroup=5TueJan1014:49:012017GMONupdatingforreconfiguration,group5at222forpid42,osid6197NOTE:group5PSTupdated.TueJan1014:49:012017NOTE:membershiprefreshpendingforgroup5/0x97f863e8(TESTDG)GMONqueryinggroup5at223forpid18,osid5012SUCCESS:refreshedmembershipfor5/0x97f863e8(TESTDG)NOTE:startingrebalanceofgroup5/0x97f863e8(TESTDG)atpower1StartingbackgroundprocessARB0SUCCESS:alterdiskgrouptestdgdropdiskTESTDG_0000TueJan1014:49:042017ARB0startedwithpid=39,OSid=25416NOTE:assigningARB0togroup5/0x97f863e8(TESTDG)with1parallelI/Ocellip.oranotfound.NOTE:F1X0copy1relocatingfrom0:2to2:2fordiskgroup5(TESTDG)NOTE:F1X0copy3relocatingfrom2:2to3:2599fordiskgroup5(TESTDG)TueJan1014:49:132017NOTE:AttemptingvotingfilerefreshondiskgroupTESTDGNOTE:RefreshcompletedondiskgroupTESTDG.Novotingfilefound.TueJan1014:51:052017NOTE:stoppingprocessARB0SUCCESS:rebalancecompletedforgroup5/0x97f863e8(TESTDG)TueJan1014:51:072017NOTE:GroupBlockoutsiderollingmigrationprivilegedregionNOTE:requestingall-instancemembershiprefreshforgroup=5TueJan1014:51:102017GMONupdatingforreconfiguration,group5at224forpid39,osid25633NOTE:group5PSTupdated.SUCCESS:grp5diskTESTDG_0000emptiedNOTE:erasingheaderongrp5diskTESTDG_0000NOTE:process_x000_+asm1(25633)initiatingofflineofdisk0.3915944675(TESTDG_0000)withmask0x7eingroup5NOTE:initiatingPSTupdate:grp=5,dsk=0/0xe96892e3,mask=0x6a,op=clearGMONupdatingdiskmodesforgroup5at225forpid39,osid25633NOTE:groupTESTDG:updatedPSTlocation:disk0001(PSTcopy0)NOTE:groupTESTDG:updatedPSTlocation:disk0002(PSTcopy1)NOTE:groupTESTDG:updatedPSTlocation:disk0003(PSTcopy2)NOTE:PSTupdategrp=5completedsuccessfullyNOTE:initiatingPSTupdate:grp=5,dsk=0/0xe96892e3,mask=0x7e,op=clearGMONupdatingdiskmodesforgroup5at226forpid39,osid25633NOTE:cacheclosingdisk0ofgrp5:TESTDG_0000NOTE:PSTupdategrp=5completedsuccessfullyGMONupdatingforreconfiguration,group5at227forpid39,osid25633NOTE:cacheclosingdisk0ofgrp5:(notopen)TESTDG_0000NOTE:group5PSTupdated.NOTE:membershiprefreshpendingforgroup5/0x97f863e8(TESTDG)GMONqueryinggroup5at228forpid18,osid5012GMONqueryinggroup5at229forpid18,osid5012NOTE:DiskTESTDG_0000inmode0x0markedforde-assignmentSUCCESS:refreshedmembershipfor5/0x97f863e8(TESTDG)TueJan1014:51:162017NOTE:AttemptingvotingfilerefreshondiskgroupTESTDGNOTE:RefreshcompletedondiskgroupTESTDG.Novotingfilefound.

因此ASM预估了9分钟的时间来完成rebalance，但实际上只使用了2分钟的时候,因此首先能知道rebalance正在做什么非常重要，然后才能知道rebalance什么时候能完成。注意，估算的时间是动态变化的，可能会增加或减少，这个依赖你的系统负载变化，以及你的rebalance的power值的设置，对于一个非常大容量的磁盘组来说，可能rebalance会花费你数小时甚至是数天的时间。

ARB0进程的跟踪文件也显示了，当前正在对哪一个ASM文件的extent的在进行重分配，也是通过这个跟踪文件，我们可以知道ARB0确实是在干着自己的本职工作，没有偷懒。

[grid@jyrac1trace]$tail-f+ASM1_arb0_25416.trc***2017-01-1014:49:20.160ARB0relocatingfile+TESTDG.256.932913341(120entries)***2017-01-1014:49:24.081ARB0relocatingfile+TESTDG.256.932913341(120entries)***2017-01-1014:49:28.290ARB0relocatingfile+TESTDG.256.932913341(120entries)***2017-01-1014:49:32.108ARB0relocatingfile+TESTDG.256.932913341(120entries)***2017-01-1014:49:35.419ARB0relocatingfile+TESTDG.256.932913341(120entries)***2017-01-1014:49:38.921ARB0relocatingfile+TESTDG.256.932913341(120entries)***2017-01-1014:49:43.613ARB0relocatingfile+TESTDG.256.932913341(120entries)***2017-01-1014:49:47.523ARB0relocatingfile+TESTDG.256.932913341(120entries)***2017-01-1014:49:51.073ARB0relocatingfile+TESTDG.256.932913341(120entries)***2017-01-1014:49:54.545ARB0relocatingfile+TESTDG.256.932913341(120entries)***2017-01-1014:49:58.538ARB0relocatingfile+TESTDG.256.932913341(120entries)***2017-01-1014:50:02.944ARB0relocatingfile+TESTDG.256.932913341(120entries)***2017-01-1014:50:06.428ARB0relocatingfile+TESTDG.256.932913341(120entries)***2017-01-1014:50:10.035ARB0relocatingfile+TESTDG.256.932913341(120entries)***2017-01-1014:50:13.507ARB0relocatingfile+TESTDG.256.932913341(120entries)***2017-01-1014:50:17.526ARB0relocatingfile+TESTDG.256.932913341(120entries)***2017-01-1014:50:21.692ARB0relocatingfile+TESTDG.256.932913341(120entries)***2017-01-1014:50:25.649ARB0relocatingfile+TESTDG.256.932913341(120entries)***2017-01-1014:50:29.360ARB0relocatingfile+TESTDG.256.932913341(120entries)***2017-01-1014:50:33.233ARB0relocatingfile+TESTDG.256.932913341(120entries)***2017-01-1014:50:37.287ARB0relocatingfile+TESTDG.256.932913341(120entries)***2017-01-1014:50:40.843ARB0relocatingfile+TESTDG.256.932913341(120entries)***2017-01-1014:50:44.356ARB0relocatingfile+TESTDG.256.932913341(120entries)***2017-01-1014:50:48.158ARB0relocatingfile+TESTDG.256.932913341(120entries)***2017-01-1014:50:51.854ARB0relocatingfile+TESTDG.256.932913341(120entries)***2017-01-1014:50:55.568ARB0relocatingfile+TESTDG.256.932913341(120entries)***2017-01-1014:50:59.439ARB0relocatingfile+TESTDG.256.932913341(120entries)***2017-01-1014:51:02.877ARB0relocatingfile+TESTDG.256.932913341(50entries)

注意，跟踪目录下的arb0的跟踪文件可能会有很多，因此我们需要知道arb0的OS是进程号，是哪一个arb0在实际做rebalance的工作，这个信息在ASM实例执行rebalance操作的时候，alert文件中会有显示。我们还可以通过操作系统命令pstack来跟踪ARB0进程，查看具体它在做什么，如下，它向我们显示了，ASM正在重分配extent（在堆栈中的关键函数 kfgbRebalExecute - kfdaExecute - kffRelocate):

[root@jyrac1~]#pstack25416#00x0000003aa88005f4in??()from/usr/lib64/libaio.so.1#10x0000000002bb9b11inskgfrliopo()#20x0000000002bb9909inskgfospo()#30x00000000086c595finskgfrwat()#40x00000000085a4f79inksfdwtio()#50x000000000220b2a3inksfdwat_internal()#60x0000000003ee7f33inkfk_reap_ufs_async_io()#70x0000000003ee7e7binkfk_reap_ios_from_subsys()#80x0000000000aea0acinkfk_reap_ios()#90x0000000003ee749einkfk_io1()#100x0000000003ee7044inkfkRequest()#110x0000000003eed84ainkfk_transitIO()#120x0000000003e40e7ainkffRelocateWait()#130x0000000003e67d12inkffRelocate()#140x0000000003ddd3fbinkfdaExecute()#150x0000000003ec075binkfgbRebalExecute()#160x0000000003ead530inkfgbDriver()#170x00000000021b37dfinksbabs()#180x0000000003ec4768inkfgbRun()#190x00000000021b8553inksbrdp()#200x00000000023deff7inopirip()#210x00000000016898bdinopidrv()#220x0000000001c6357finsou2o()#230x00000000008523cainopimai_real()#240x0000000001c6989dinssthrdmain()#250x00000000008522c1inmain()

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

17:26:48SQL>alterdiskgrouptestdgadddisk'/dev/raw/raw7'rebalancepower2;Diskgroupaltered.

ASM给出的rebalance的估算时间为6分钟：

16:07:13SQL>selectINST_ID,OPERATION,STATE,POWER,SOFAR,EST_WORK,EST_RATE,EST_MINUTESfromGV$ASM_OPERATIONwhereGROUP_NUMBER=1;INST_IDOPERASTATPOWERSOFAREST_WORKEST_RATEEST_MINUTES----------------------------------------------------------------------1REBALRUN104895385179206

大约10秒后，EST_MINUTES的值变为0.

16:07:23SQL>/INST_IDOPERASTATPOWERSOFAREST_WORKEST_RATEEST_MINUTES----------------------------------------------------------------------1REBALRUN10924079787487160

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

SQL>alterdiskgrouptestdgadddisk'/dev/raw/raw7'rebalancepower2NOTE:GroupBlockoutsiderollingmigrationprivilegedregionNOTE:Assigningnumber(5,0)todisk(/dev/raw/raw7)NOTE:requestingall-instancemembershiprefreshforgroup=5NOTE:initializingheaderongrp5diskTESTDG_0000NOTE:requestingall-instancediskvalidationforgroup=5TueJan1016:07:122017NOTE:skippingrediscoveryforgroup5/0x97f863e8(TESTDG)onlocalinstance.NOTE:requestingall-instancediskvalidationforgroup=5NOTE:skippingrediscoveryforgroup5/0x97f863e8(TESTDG)onlocalinstance.TueJan1016:07:122017GMONupdatingforreconfiguration,group5at230forpid42,osid6197NOTE:group5PSTupdated.NOTE:initiatingPSTupdate:grp=5GMONupdatinggroup5at231forpid42,osid6197NOTE:PSTupdategrp=5completedsuccessfullyNOTE:membershiprefreshpendingforgroup5/0x97f863e8(TESTDG)GMONqueryinggroup5at232forpid18,osid5012NOTE:cacheopeningdisk0ofgrp5:TESTDG_0000path:/dev/raw/raw7GMONqueryinggroup5at233forpid18,osid5012SUCCESS:refreshedmembershipfor5/0x97f863e8(TESTDG)NOTE:startingrebalanceofgroup5/0x97f863e8(TESTDG)atpower1SUCCESS:alterdiskgrouptestdgadddisk'/dev/raw/raw7'StartingbackgroundprocessARB0TueJan1016:07:142017ARB0startedwithpid=27,OSid=982NOTE:assigningARB0togroup5/0x97f863e8(TESTDG)with1parallelI/Ocellip.oranotfound.TueJan1016:07:232017NOTE:AttemptingvotingfilerefreshondiskgroupTESTDG

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

#pstack982#00x0000003957ccb6efinpoll()from/lib64/libc.so.6...#90x0000000003d711e0inkfk_reap_oss_async_io()#100x0000000003d70c17inkfk_reap_ios_from_subsys()#110x0000000000aea50einkfk_reap_ios()#120x0000000003d702aeinkfk_io1()#130x0000000003d6fe54inkfkRequest()#140x0000000003d76540inkfk_transitIO()#150x0000000003cd482binkffRelocateWait()#160x0000000003cfa190inkffRelocate()#170x0000000003c7ba16inkfdaExecute()#180x0000000003c4b737inkfdCompact()#190x0000000003c4c6d0inkfdExecute()#200x0000000003d4bf0einkfgbRebalExecute()#210x0000000003d39627inkfgbDriver()#220x00000000020e8d23inksbabs()#230x0000000003d4faaeinkfgbRun()#240x00000000020ed95dinksbrdp()#250x0000000002322343inopirip()#260x0000000001618571inopidrv()#270x0000000001c13be7insou2o()#280x000000000083cebainopimai_real()#290x0000000001c19b58inssthrdmain()#300x000000000083cda1inmain()

通过tail命令查看ARB0的跟踪文件，发现relocating正在进行，而且一次只对一个条目进行relocating。（这是正进行到compacting阶段的另一个重要线索）：

$tail-f+ASM1_arb0_25416.trcARB0relocatingfile+DATA1.321.788357323(1entries)ARB0relocatingfile+DATA1.321.788357323(1entries)ARB0relocatingfile+DATA1.321.788357323(1entries)...

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

16:08:56SQL>/INST_IDOPERASTATPOWERSOFAREST_WORKEST_RATEEST_MINUTES----------------------------------------------------------------------2REBALRUN10982719830579190

固态表X$KFGMG的REBALST_KFGMG字段会显示为2，代表正在compacting。

16:09:12SQL>selectNUMBER_KFGMG,OP_KFGMG,ACTUAL_KFGMG,REBALST_KFGMGfromX$KFGMG;NUMBER_KFGMGOP_KFGMGACTUAL_KFGMGREBALST_KFGMG-----------------------------------------------11102

一旦compacting阶段完成，ASM的alert 日志中会显示stopping process ARB0 和rebalance completed:

TueJan1016:10:192017NOTE:stoppingprocessARB0SUCCESS:rebalancecompletedforgroup5/0x97f863e8(TESTDG)

一旦extents relocation完成，所有的数据就已经满足了冗余度的要求，不再会担心已经失败磁盘的partern磁盘再次失败而出现严重故障。

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

感谢各位的阅读，以上就是“Oracle ASM Rebalance执行过程是怎样的”的内容了，经过本文的学习后，相信大家对Oracle ASM Rebalance执行过程是怎样的这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是亿速云，小编将为大家推送更多相关知识点的文章，欢迎关注！