第十二回 RMAN 在NBU 下備份效能時低落

今天和同事約好要去之前曾去美國出差過的某海運公司，原因是 NBU 透過 RMAN 備份時的效能有點奇怪，問題就是每次開始備份時，明明 Schedule 已經啟動了，而且 NBU 下的 Device 都閒置著，但是 RMAN 就是沒有動作， NBU 的狀態也沒有 LOG 表示有動作，必須要在過了 10~40分鐘不等的狀態下，才會將磁帶 Volume 掛載到磁帶館中，並開始做備份寫入動作。

因為同時間同一台資料庫下的同一個 Instance 也有 Archive Log 備份的工作剛正常結束，只有接之在後面的 Full Database Backup Schedule 有這個問題，所以把 RMAN 的 Scripts 整個叫出來看，其實也很一般就是正常的 RMAN Scripts 而己。

只不過這台資料庫主機內存在了兩個資料庫，其中一個備份的啟動是正常的，馬上可以取得備份的資源就開始做備份，只有我描述過那個資料庫會有問題，而這個資料庫的大小約 2.2TB ，剛開始我懷疑是因為這個資料庫比較大，所以在需要寫入前會有一些處理時間，但最短10分鐘，最長40分鐘，實在是太離譜了，別說是客戶，連我都無法接受，所以我花了一些時間查看這台資料庫在備份的時候到底在做什麼事，因為這台其實是 Product 的 Standby Database ，也就是 Database 的 Target 端，所以這台設備唯一的 Loading 就是傳輸 Archive Log 和 Apply Log 而己，特別對照了需要執行到 40 分鐘的那幾天有什麼特別的交易，看起來也沒有。

最後我比較了同一台資料庫下，兩個 Instance 登入到 RMAN 的方式，其中有問題的資料庫是使用 Catalog DB ，而沒有問題的那台則是 Nocatalog Mode 下面執行的。

所以我試著寫了一個備份該資料庫最小單一檔案的 RMAN Scripts 測試，分別使用 Catalog 和 Nocatalog Mode 去備，同樣的一個 20MB 的檔案，在Catalog Mode 之下，光 RMAN 在 Allocate Channel 指令送出去後，就沒有下文了，一直等到快 10 分鐘後，才有下一個作業被呼叫，且連備份完成後 Release Channel 的動作也是慢到無法接受；而在 Nocatalog Mode 之下處理時，則是一 Allocate Channel 後就開始備份，所以我想起了多年前那家書局 Catalog 久未維護所造成的問題，因此我就跟客戶先解釋一下可能發生的原因，然後詢問了上次整理 Catalog DB 的時間，客戶說並不是很清楚，只記得以前有重整過。

所以這下原因找到了，一樣就是 Catalog 未整理的狀態下，不只 Restore 時的效果非常差，連備份都會受到影響，雖然重整 Catalog DB 沒什麼了不起的，我還是決定先判定原因，待下次大家有機會開個會坐下討論時，再說明一次這件事後再來做處理，以免以後大家又忘記了。

最後因為該公司另一家關係企業的資料庫發生問題，我們要趕過去看，所以就先走了。這件事就這樣處理完畢。