oracle RMAN備份報錯的診斷過程（二）跟蹤錯誤資訊及尋找定位問題的方向

今天檢查資料庫中的備份輸出指令碼時，發現RMAN備份出現了錯誤。

這一篇跟蹤錯誤資訊，尋找定位問題的方向。

根據前面的問題描述，發現問題越來越複雜，從一個簡單的RMAN備份報錯，牽扯到系統中有3個長時間啟動並執行JOB，以及RAC環境當前節點存在了大量的RACGMAIN CHECK進程的存在。

雖然問題很複雜，就不要急於盲目操作，先簡單分析一下當前的狀況。

發現問題是由於RMAN備份指令碼報錯造成的，但是根據錯誤資訊和隨後的測試發現，問題是可以重現的，並不是簡單的RMAN問題，導致問題的原因應該是共用資源被佔用，RMAN在長時間無法得多資源後被關閉。

在資料庫中檢查共用資源時，發現V$LOCK視圖中有3個可疑會話持有鎖資訊，進一步查詢發現是3個JOB對應的會話，這3個JOB都運行了很長時間，既沒有結束，也沒有報錯。

而在檢查作業系統的進程時，發現當前系統存在大量的racgmain check進程，數量居然有四百多個，這是很不正常的，檢查其他正常的RAC環境並未發現這個進程的存在。

這3個問題可能是相互關聯的，也可能是獨立的3個問題，如果3個問題彼此沒有聯絡，那麼就要分別去分析並解決這3個問題，如果3個問題是關聯的，那麼需要尋找一個突破口來快速的定位問題的原因。

根據上一篇文章描述的現象進行推斷，這3個問題多半是相關聯的，因為RMAN報錯並不是普通的RMAN配置問題，根據alert檔案中給出的資訊，問題是由於共用資源被佔有所造成的，而隨後查詢V$LOCK時，就看到3個長時間沒有完成的JOB，這並不是偶然的，雖然還沒有看到這3個JOB在做什麼，但是懷疑RMAN等待的資源正是被JOB所佔用。這說明第一個問題和第二個問題是有聯絡的，而alert檔案給出的共用資源資訊本身就和RAC環境關係密切，LMD進程——GLOBAL ENQUEUE SERVICE DAEMON是RAC環境相關的進程，這說明3個問題並非是3個獨立的問題，而是彼此相關的問題。

既然3個問題是有關的，那麼從那個問題入手呢，原則上講從哪個分析都可以，因為最終導致問題的原因是同一個。但是實際分析的問題的時候還是有選擇的，而不是盲目選擇一個問題就開始分析，那樣的話很可能事倍功半。一般來說，選擇問題的突破點有兩個考慮，一個是尋找跟接近導致問題原因的現象來進行分析。如果現象A導致了現象B，那麼就選擇分析現象A，因為現象B分析的價值已經不大了，現在A更加進行導致問題的原因。另一點考慮就是入手的難易程度，優先分析那些很容易上手的現象，這樣解決問題會更加迅速，而且即使發現走錯了路，也可以很快的發現。

針對當前的3個問題，RMAN串連報錯初步懷疑和JOB運行有關，也就是說RMAN的問題很可能就是JOB運行問題所引起的，那麼這裡就應該有限分析JOB問題。而JOB問題和RACGMAIN CHECK進程之間暫時無法確定依賴關係，因此不好確定分析的優先順序。下面再來對應兩個問題分析的難易程度，JOB啟動並執行資訊全部儲存在資料庫中，有很多的視圖可供參考，分析起來輕車熟路；而racgmain check進程則完全的不透明，即使有個別的trace檔案，其內容也有如天書一般，分析起來肯定會吃力得很。顯然應該優先分析資料庫中未完成的JOB。

順便說一句，上面給出的方法適用於大多數的情況，但是有的時候則不盡然。還是以上面3個問題而言，根據目前所擷取的資訊來看，如果需要查詢metalink來擷取協助的話，則應該有限考慮RMAN問題，因為RMAN問題中包含大量的明確的資訊，既有RMAN報錯資訊，也有導致報錯資訊的命令，因此可以很容易的找到最相關的問題描述。對於racgmain check進程問題而言，racgmain check本身就是一個很好的查詢關鍵詞，很容易在metalink中找到相關的資訊。而對於JOB問題而言，並不是搜尋不到資訊，而是當前擷取的資訊不足以通過搜尋來找到有意義的資訊，需要進一步發掘JOB未發成的其他原因，找到適合搜尋的關鍵點資訊。雖然RMAN問題和RACGMAIN CHECK進程問題適合進行搜尋，但是不幸的是，搜尋解決和當前情況比較類似的不多，而且很難確定當前的問題和metalink中描述的是同一個問題，因此還是應該繼續分析Oracle中的JOB資訊。

SQL> SELECT SID, JOB FROM DBA_JOBS_RUNNING;

SID        JOB

---------- ----------

118          4

102         74

289         27

SQL>COLWHAT FORMAT A60

SQL> SELECT JOB, LOG_USER, WHAT

2  FROM DBA_JOBS

3  WHERE JOB IN (4, 27, 74);

JOB LOG_USER             WHAT

---------- -------------------- --------------------------------------------------------

4 NDMAIN               DBMS_STATS.GATHER_SCHEMA_STATS(USER, CASCADE => TRUE);

27ZHEJIANG             dbms_stats.gather_schema_stats(user, cascade => true);

74 GPO                  P_Project_Stat;

根據JOB資訊，前面兩個JOB運行都是和統計資訊有關，第3個JOB啟動並執行過程是使用者自訂的過程。

SQL> SELECT SID, TYPE, ID1, ID2, LMODE, REQUEST, CTIME, BLOCK

2  FROM V$LOCK

3  WHERE SID IN (102, 118, 289)

4  ORDER BY CTIME DESC;

SID TY        ID1        ID2      LMODE    REQUEST      CTIME      BLOCK

---------- -- ---------- ---------- ---------- ---------- ---------- ----------

118 JQ          0          4          6          0     151090          2

118 TO     196404          1          3          0     151087          2

118 TX     262181      87690          6          0     151087          2