Oracle數據遷移後歸檔文件暴增怎麼辦？

數據遷移是DBA的平常工做，對於相應的方法、命令等，相信不少人早已瞭如指掌。圓滿的數據遷移流程不僅僅指將數據從數據庫A備份恢復到數據庫B，並且要保證遷移先後數據的完整性、服務的可用性。

 

近日，在給客戶作了單機到集羣的數據遷移後，發現集羣的在線重作日誌切換頻繁，進而產生了大量的歸檔日誌，對服務器形成了不小的壓力。本文是對上述問題的分析處理過程。

 

發現問題

1. 日誌歸檔頻繁

在遷移完成後，須要對集羣進行一段時間的深度觀察。經過v$archived_log視圖，分析數據庫歷史的歸檔狀況，能夠發現整個庫的業務活動狀況。

觀察上圖，不難發現遷移（6月15日）先後是一個明顯得變化點，天天日誌歸檔頻率由原來的100屢次變成400屢次。這種狀況要麼是遷入的系統業務量確實很大，要麼是遷入的數據庫用戶配置有問題。

2. 業務狀況確認

通過與新遷入系統的運維人員溝通確認，該系統的使用人數雖然多，但都是以查詢類的動做偏多，不該該帶來這麼大量的日誌。由於集羣中還有其它系統，不能直接判斷是新系統的問題。假設運維所說狀況屬實，那麼問題的關鍵點就是要找到產生大量日誌的操做語句，進而找到對應的應用，再確認歸檔狀況是否正常。

 

問題分析

1. 追根溯源

日誌歸檔頻繁，說明在線重作日誌切換頻繁，通常是因爲產生了大量的redo。這裏經過awr檢查redo的生成狀況。

 

一天內日誌歸檔的詳細狀況

 

這裏選擇6月18日上午10點到11點間集羣2節點的awr報告

 

節點1：

 

觀察上圖，能夠看到在1小時內，節點1的redo的產生速率約爲3.38MB/S，那麼一小時就有約11.88GB。

 

節點2：

觀察上圖，能夠看到在1小時內，節點2的redo的產生速率約爲0.26MB/S，那麼一小時就有約0.9GB。

 

經過查詢v$archived_log視圖，分類計算出10點到11點間所產生的歸檔日誌大小約爲12.3GB，這與根據awr報告推算出來的值12.78GB很是接近，能夠說明以上兩份awr報告的可參考性很高。

 

2. 順藤摸瓜

如今已經確認是歸檔頻繁是由大量的redo引發的，那麼就須要看在問題時間區間內，致使數據塊變化的緣由（sql），這個能夠從awr報告的「Segments by DB Blocks Changes」部分能夠找到答案：

 

節點1：

節點2：

 

由上邊2個截圖能夠發現，用戶YK***FT名下的有3個表（US***4二、US***3九、US***06）的數據塊被頻繁的操做，而這個用戶正是新遷入系統的數據庫用戶。

 

爲了更進一步瞭解對該3個表作了哪些操做，能夠在awr報告中分別搜索表名稱，找出相關的sql語句。

 

 

由上圖能夠看出，在1小時以內，對該3個表分別執行了60次update操做，具體的sql語句以下：

 

 

這裏注意到一個數字60，看樣子像是一個定時任務，首先想到的是job。通過查詢，發現yk***ft用戶下確實存在一個job，並且正好是每分鐘執行一次！

 

 

進一步查看job執行的存儲過程發現正是上邊的3條語句：

 

 

經過分析US***4二、US***3九、US***06這個3個表和update中的where語句，發現那3條update語句頗有問題，符合where的數據量大，且只增不減，必需要調整。

 

 

 

解決問題

1. 業務狀況再確認

根據前邊找到的線索，跟運維人員確認job(24)的業務做用，獲得的反饋是以前有個需求是按期把符合要求的字段A的值寫到字段B，如今該需求已再也不須要，能夠刪除。

2. 調整並觀察

禁用job

雖然業務確承認以刪除，但爲了保險起見，這裏將job(24)禁用，經過調用dbms_job.broken完成。

 

 

觀察redo

這裏選擇調整以後的6月20日上午10點到11點間集羣2節點的awr報告

 

節點1：

 

節點2：

 

由上述節點1和節點2相同時間內的awr報告的來看，redo產生速率有了很大的下降。經過觀察歸檔日誌的生成狀況，發現歸檔頻率也下降了。

 

總結提升

通過回顧整個問題的發現、分析和解決過程，能夠發現其實並無什麼技術難點，問題的緣由主要仍是出在業務溝通上。在遷移以前，最好可以跟應用管理員確認清楚業務的特色，包括現有業務的壓力狀況、已發現的性能瓶頸、再也不須要的各種數據庫對象（索引、視圖、存儲過程、函數、觸發器等），提早作好應對措施，保證數據遷移的圓滿完成。

做者：張世城

 

其餘優質話題

Docker操做實踐(3)：Docker的操做詳解

Docker操做實踐(2)：Docker的安裝及架構介紹

Docker操做實踐(1)：什麼是容器的本質？

使用sqlplus進行Oracle數據庫批量自動發佈

業務複雜、數據龐大、應用廣怎辦？瞭解下分佈式事務的解決思路！