ASM REBLANCE引起的DG備庫停止同步問題ORA-16055

 

Automatic Storage Management(ASM) 是Oracle資料庫10g中推出的一個非常出色的新特性，它以平臺無關的方式提供了檔案系統、邏輯卷管理器以及軟體RAID等服務。其原理有點兒類似於Linux系統裡面LVM 邏輯卷, ASM Diskgroup 類似於Volume Group,由多個ASM disk構成(對應於LVM中的是 Physical Volume),而最終我們在ASM Diskgroup裡面建立的檔案則就相當於LV。ASM可以條帶化和映象磁碟，從而實現了在資料庫被載入的情況下新增或移除磁碟以及自動平衡 I/O 以刪除“熱點”，相比於傳統的檔案系統管理方式在IO效能上有較大的提高。

在介紹前我們先來說一個案例，某客戶資料庫採用了RAC + DG（主庫和備庫都使用了ASM管理方式），一次客戶反映資料庫表空間滿了，需要增加資料檔案來擴充套件，以為很簡單的一個問題,結果...加完一個8G資料檔案後 ,前臺應用可以正常繼續了,但是發現alert日誌有大量歸檔的報錯

ORA-16055: FAL request rejected

ARCH: FAL archive failed. Archiver continuing ，更奇怪的是找不到提示中的詳細跟蹤檔案，再次檢查發現原來是主庫傳遞迴檔到備庫的時候報錯了。此時檢查備庫同時發現mrp程式已經停止,以為是歸檔把asm磁碟組空間佔滿了,但是lsdg發現還剩餘100G空間(總共700多G) ,嘗試手工啟動mrp恢復程式,日誌又提示一個編號為183的資料檔案不存在（該檔案在生產庫上對應 +ASM_DATA/orcl/datafile/test10.dbf）,所以無法應用歸檔,嘗試手工建立該檔案。

SQL> alter database create datafile '/oracle/app/product/db1205/dbs/UNNAMED00183' as '+ASM_DATA/orcl/datafile/ts_emr10.dbf'; alter database create datafile '/oracle/app/product/db1205/dbs/UNNAMED00183' as '+ASM_DATA/orcl/datafile/test10.dbf'   ERROR at line 1: ORA-01119: error in creating database file '+ASM_DATA/orcl/datafile/ts_emr10.dbf' ORA-17502: ksfdcre:4 Failed to create file +ASM_DATA/orcl/datafile/test10.dbf ORA-15041: diskgroup space exhausted

前面檢查過磁碟組還有100G的剩餘容量，而這裡提示磁碟組空間耗盡，兩者之間肯定有一個是誤報，而該誤報的原因就是下面要講的ASM的reblance操作。

在詳細說明本節內容的情況下，需要普及一些小的知識點，當我們向ASM磁碟組中加入磁碟的時候，ASM會自動將磁碟組中每塊磁碟上取出部分AU（AU是最小空間分配單元，預設是1M，每個AU預設由8個128K條帶空間組成）, 寫入新加入的磁碟，使所有磁碟含有資料大致相同，當我們從磁碟組中刪除磁碟時，同樣被刪除磁碟中的AU會被平均分配到其他磁碟，這個過程就叫 再平衡(rebalance)。reblance的過程是自動進行的，我們可以設定asm_power_limit引數值來調整平衡的速度。

注：當發生新增/刪除磁碟組中磁碟的操作時，ASM能夠自動平衡。對於普通的刪除操作(無force選項)，被刪除的磁碟在該上資料被有效處理前並不會立刻釋放，同樣，新增磁碟時，在重分配工作完成前，該盤也不會承擔I/O負載的工作。 

ASM_POWER_LIMIT ：指定磁碟rebalance的程度，有0-11個級別，預設值為1，級別越高，rebalance的操作就會越快被完成(當然這也意味著reblance操作將佔用更多的資源，對資料庫的效能衝擊也越大)，指定級別較低的話，雖然rebalance操作會耗時更久，但對當前系統的IO及負載影響會更少，所以該操作需要根據實際情況慎重選擇。另外，這個引數指定的只是一個預設值，在操作過程中，即可以隨便動態修改，也可以在語句級命令列時指定power，

如: ALTER DISKGROUP <group_name> REBALANCE POWER 5

ASM 磁碟的相關檢視 
v$asm_disk[_stat]      -- 檢視磁碟及其狀態資訊
v$asm_diskgroup[_stat]     -- 檢視磁碟組及其狀態資訊
v$asm_operation       -- 檢視當前磁碟的操作資訊
v$asm_client        -- 檢視當前連線的客戶端例項資訊
v$asm_file         -- 檢視 asm 檔案的相關資訊
v$asm_template       -- 檢視 asm 檔案樣本的相關資訊
v$asm_alias         -- 檢視 asm 檔案的別名資訊

先查詢一下當前ASM磁碟的狀態

SQL> select path,total_mb,free_mb from v$asm_disk_stat; PATH                             TOTAL_MB    FREE_MB ------------------------------ ---------- ---------- /dev/vg00/rasm_disk1               153600      20529 /dev/vg00/rasm_disk2               153600      20527 /dev/vg00/rasm_disk3               153600      20532 /dev/vg00/rasm_disk4               153600      20529 /dev/vg00/rasm_disk5               128        0 # 這個 lv 已經完全用光 /dev/vg00/rasm_disk6               102400      13830

從這裡可以看出，這6個ASM disk都是在OS裡面建立的lv，且/dev/vg00/rasm_disk5這個ASM disk已經完全用完，該盤只有128MB的總容量，應該屬於誤操作加入的磁碟，由於這個磁碟沒有剩餘空間，而建立資料檔案ASM又需要將資料打散到這6個ASM disk上，這就導致了明明磁碟組還有剩餘空間，而建立資料檔案卻提示磁碟組空間耗盡。

在上述的客戶案例中，因為問題出在DG備庫上，所以決定修改asm_power_limit引數後重啟ASM例項來完成reblance操作。如下

SQL> alter system set asm_power_limit=5 scope=spfile;; System altered. SQL> shutdown immediate ASM diskgroups dismounted  ASM instance shutdown  SQL> startup SQL> select * from v$asm_operation; no rows selected SQL> / no rows selected 檢查發現沒有進行 reblance 操作，繼續調整，使用最大值進行 SQL 〉 alter diskgroup ASM_DATA rebalance power 11 wait; Diskgroup altered.

再次查詢v$asm_operation終於看到在rebalance了,按提示估計30分鐘就完了,這個提示只是預估值，實際情況一般要比這個長 ,比如我這裡大概2個多小時後才完成,此時/dev/vg00/rasm_disk5 的free_mb變為15，隱約覺得這個值還是太小,決定先再次嘗試重建183號資料檔案，10分鐘後提示完成,接著開啟mrp程式,因為該伺服器物理磁碟效能不佳，應用歸檔比較慢,2小時候，再次出現ORA-15041: diskgroup space exhausted錯誤,查詢顯示/dev/vg00/rasm_disk5這個asm磁碟再次用光,看來這個lv太小導致拖reblance操作的後腿 ,此時為了保險關掉備庫資料庫例項,然後刪除這個asm磁碟。

SQL>  alter diskgroup asm_data drop disk ASM_DATA_0004   Diskgroup altered.    SQL> select path,total_mb,free_mb from v$asm_disk_stat;   PATH                             TOTAL_MB    FREE_MB ------------------------------ ---------- ---------- /dev/vg00/rasm_disk1               153600      20556 /dev/vg00/rasm_disk2               153600      20556 /dev/vg00/rasm_disk3               153600      20558 /dev/vg00/rasm_disk4               153600      20555 /dev/vg00/rasm_disk6               102400      13704

經歷了4個小時自動rebalance, 128MB的磁碟被順利刪除，可以看到此時剩餘的5個asm磁碟使用率較為平均，此時再次開啟mrp恢復程式,直至追平生產庫的歸檔。