“磁盤組的rebalance什么時候能完成？”，這個問題我經(jīng)常被問到，但是如果你期望我給出一個具體的數(shù)值，那么你會失望，畢ASM本身已經(jīng)給你提供了一個估算值（GV$ASM_OPERATION.EST_MINUTES），其實你想知道的是rebalance完成的精確時間。雖然我不能給你一個精確的時間，但是我可以給你一些rebalance的操作細節(jié)，讓你知道當前rebalance是否正在進行中，進行到哪個階段，以及這個階段是否需要引起你的關注。
就像在本ASM系列文章的“rebalancing act”章介紹過的，rebalance操作本身包含了3個階段：planning、extents relocation 和 compacting，就rebalance需要的總時間而言，planning階段需要的時間是非常少的，你通常都不用去關注這一個階段；第二個階段extent relocation一般會占取rebalance階段的大部分時間，也是我們需要關注的階段；后我們也會講述第三階段compacting階段在做些什么。
首先需要明白為什么會需要做rebalance，如果你為了增加磁盤組的可用空間，增加了一塊新磁盤，你可能并不太會關注rebalance什么時候完成，好吧，也可能確實你需要關注，比如你的歸檔空間所在的DG滿了，導致數(shù)據(jù)庫HANG了。相似的，如果你為了調(diào)整磁盤的空間，例如resizing或者刪除磁盤，你可能也不會太去關注rebalance什么時候完成。
但是，如果磁盤組中的一塊磁盤損壞了，這個時候你就有足夠的理由去關注rebalance的進度。假如你的磁盤組是normal冗余的，這個時候萬一你損壞磁盤的partner磁盤也損壞，那么你的整個磁盤組會被dismount，所有跑在這個磁盤組上的數(shù)據(jù)庫都會crash，你可能還會丟失數(shù)據(jù)。在這種情況下，你非常需要知道rebalance什么時候完成。實際上，你需要知道第二個階段extent relocation什么時候完成，一旦它完成了，整個磁盤組的冗余就已經(jīng)完成了（第三個階段對于冗余度來說并不重要，后面會介紹）。
為了進一步觀察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的值變?yōu)?4分鐘：
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的值可能并不能給你太多的證據(jù)，我們還可以看到SOFAR（截止目前移動的UA數(shù)）的值一直在增加，恩，不錯，這是一個很好的一個觀察指標。
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實例執(zhí)行rebalance操作的時候，alert文件中會有顯示。
我們還可以通過操作系統(tǒng)命令pstack來跟蹤ARB0進程，查看它具體在做什么，如下，它向我們顯示了，ASM正在重分配extent（在堆棧中的關鍵函數(shù)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的值變?yōu)榱?:
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什么時候能完成。
注意，估算的時間是動態(tài)變化的，可能會增加或減少，這個依賴你的系統(tǒng)負載變化，以及rebalance的power值的設置，對于一個非常大容量的磁盤組而言，可能rebalance會花費你數(shù)小時甚至是數(shù)天的時間。
在下面的例子里，我們來看一下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的值變?yōu)?.
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已經(jīng)完成了rebalance的第二個階段，開始了第三個階段compacting，如果我說的沒錯，通過pstack工具可以看到kfdCompact()函數(shù)，下面的輸出顯示，確實如此:
# 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的跟蹤文件，發(fā)現(xiàn)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
固態(tài)表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分鐘。
在真正的環(huán)境中，compacting階段可能會占用掉比較可觀的rebalance時間，曾經(jīng)遭遇過一個案例，extents relocation花費了60分鐘，而compacting操作花費了30分鐘。但是其實compacting的消耗時間多少并不重要，因為一旦extents relocation完成，所有的數(shù)據(jù)就已經(jīng)滿足了冗余度的要求，不再會擔心已經(jīng)失敗磁盤的partner磁盤再次失敗而出現(xiàn)嚴重故障。
Rebalance的power可以在磁盤組rebalance過程中動態(tài)地更改，如果你認為磁盤組的默認級別太低，可以很容易地增加它。但是增加到多少則需要你根據(jù)系統(tǒng)的IO負載、IO吞吐量來定。一般情況下，你可以先嘗試增加到一個保守的值，例如5，過上十分鐘看是否有所提升，以及是否影響到其他業(yè)務對IO的使用，如果你的IO性能非常強，那么可以繼續(xù)增加power的值，但是就我的經(jīng)驗來看，很少能看到power的設置超過30后還能有較大提升的。
測試的關鍵點在于，你需要在你生產(chǎn)系統(tǒng)的正常負載下去測試，不同的業(yè)務壓力、不同的存儲系統(tǒng)都可能會讓rebalance時間產(chǎn)生較大的差異。
本站文章版權歸原作者及原出處所有 。內(nèi)容為作者個人觀點， 并不代表本站贊同其觀點和對其真實性負責，本站只提供參考并不構(gòu)成任何投資及應用建議。本站是一個個人學習交流的平臺，網(wǎng)站上部分文章為轉(zhuǎn)載，并不用于任何商業(yè)目的，我們已經(jīng)盡可能的對作者和來源進行了通告，但是能力有限或疏忽，造成漏登，請及時聯(lián)系我們，我們將根據(jù)著作權人的要求，立即更正或者刪除有關內(nèi)容。本站擁有對此聲明的最終解釋權。
