Oracle數(shù)據(jù)遷移后歸檔文件暴增怎么辦？

數(shù)據(jù)遷移是DBA的日常工作，對于相應(yīng)的方法、命令等，相信很多人早已了如指掌。圓滿的數(shù)據(jù)遷移流程不單單指將數(shù)據(jù)從數(shù)據(jù)庫A備份恢復(fù)到數(shù)據(jù)庫B，而且要保證遷移前后數(shù)據(jù)的完整與服務(wù)的可用性。

近日，在給客戶做了單機到集群的數(shù)據(jù)遷移后，發(fā)現(xiàn)集群的在線重做日志切換頻繁，進而產(chǎn)生了大量的歸檔日志，對服務(wù)器造成了不小的壓力。本文是對上述問題的分析處理過程。

發(fā)現(xiàn)問題

1. 日志歸檔頻繁

在遷移完成后，需要對集群進行一段時間的深度觀察。通過v$archived_log視圖，分析數(shù)據(jù)庫歷史的歸檔情況，可以發(fā)現(xiàn)整個庫的業(yè)務(wù)活動情況。

觀察上圖，不難發(fā)現(xiàn)遷移（6月15日）前后是一個明顯得變化點，每天日志歸檔頻率由原來的100多次變成400多次。這種情況要么是遷入的系統(tǒng)業(yè)務(wù)量確實很大，要么是遷入的數(shù)據(jù)庫用戶配置有問題。

2. 業(yè)務(wù)情況確認

經(jīng)過與新遷入系統(tǒng)的運維人員溝通確認，該系統(tǒng)的使用人數(shù)雖然多，但都是以查詢類的動作偏多，不應(yīng)該帶來這么大量的日志。因為集群中還有其它系統(tǒng)，不能直接判斷是新系統(tǒng)的問題。假設(shè)運維所說情況屬實，那么問題的關(guān)鍵點就是要找到產(chǎn)生大量日志的操作語句，進而找到對應(yīng)的應(yīng)用，再確認歸檔情況是否正常。

問題分析

1.?追根溯源

日志歸檔頻繁，說明在線重做日志切換頻繁，一般是由于產(chǎn)生了大量的redo。這里通過awr檢查redo的生成情況。

一天內(nèi)日志歸檔的詳細情況

這里選擇6月18日上午10點到11點間集群2節(jié)點的awr報告

節(jié)點1：

觀察上圖，可以看到在1小時內(nèi)，節(jié)點1的redo的產(chǎn)生速率約為3.38MB/S，那么一小時就有約11.88GB。

節(jié)點2：

觀察上圖，可以看到在1小時內(nèi)，節(jié)點2的redo的產(chǎn)生速率約為0.26MB/S，那么一小時就有約0.9GB。

通過查詢v$archived_log視圖，分類計算出10點到11點間所產(chǎn)生的歸檔日志大小約為12.3GB，這與根據(jù)awr報告推算出來的值12.78GB非常接近，可以說明以上兩份awr報告的可參考性很高。

2.?順藤摸瓜

現(xiàn)在已經(jīng)確認是歸檔頻繁是由大量的redo引起的，那么就需要看在問題時間區(qū)間內(nèi)，導(dǎo)致數(shù)據(jù)塊變化的原因（sql），這個可以從awr報告的“Segments by DB Blocks Changes”部分可以找到答案：

節(jié)點1：

節(jié)點2：

由上邊2個截圖可以發(fā)現(xiàn)，用戶YK***FT名下的有3個表（US***42、US***39、US***06）的數(shù)據(jù)塊被頻繁的操作，而這個用戶正是新遷入系統(tǒng)的數(shù)據(jù)庫用戶。

為了更進一步了解對該3個表做了哪些操作，可以在awr報告中分別搜索表名稱，找出相關(guān)的sql語句。

由上圖可以看出，在1小時之內(nèi)，對該3個表分別執(zhí)行了60次update操作，具體的sql語句如下：

這里注意到一個數(shù)字60，看樣子像是一個定時任務(wù)，首先想到的是job。經(jīng)過查詢，發(fā)現(xiàn)yk***ft用戶下確實存在一個job，而且正好是每分鐘執(zhí)行一次！

進一步查看job執(zhí)行的存儲過程發(fā)現(xiàn)正是上邊的3條語句：

通過分析US***42、US***39、US***06這個3個表和update中的where語句，發(fā)現(xiàn)那3條update語句很有問題，符合where的數(shù)據(jù)量大，且只增不減，必須要調(diào)整。

解決問題

1.?業(yè)務(wù)情況再確認

根據(jù)前邊找到的線索，跟運維人員確認job(24)的業(yè)務(wù)作用，得到的反饋是之前有個需求是定期把符合要求的字段A的值寫到字段B，現(xiàn)在該需求已不再需要，可以刪除。

2.?調(diào)整并觀察

禁用job

雖然業(yè)務(wù)確認可以刪除，但為了保險起見，這里將job(24)禁用，通過調(diào)用dbms_job.broken完成。

觀察redo

這里選擇調(diào)整之后的6月20日上午10點到11點間集群2節(jié)點的awr報告

節(jié)點1：

節(jié)點2：

由上述節(jié)點1和節(jié)點2相同時間內(nèi)的awr報告的來看，redo產(chǎn)生速率有了很大的降低。通過觀察歸檔日志的生成情況，發(fā)現(xiàn)歸檔頻率也降低了。

總結(jié)提高

經(jīng)過回顧整個問題的發(fā)現(xiàn)、分析和解決過程，可以發(fā)現(xiàn)其實并沒有什么技術(shù)難點，問題的原因主要還是出在業(yè)務(wù)溝通上。在遷移之前，最好能夠跟應(yīng)用管理員確認清楚業(yè)務(wù)的特點，包括現(xiàn)有業(yè)務(wù)的壓力情況、已發(fā)現(xiàn)的性能瓶頸、不再需要的各類數(shù)據(jù)庫對象（索引、視圖、存儲過程、函數(shù)、觸發(fā)器等），提前做好應(yīng)對措施，保證數(shù)據(jù)遷移的圓滿完成。

其他優(yōu)質(zhì)話題

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

Docker操作實踐(2)：Docker的安裝及架構(gòu)介紹

Docker操作實踐(1)：容器的本質(zhì)是什么？容器從何而來？

使用sqlplus進行Oracle數(shù)據(jù)庫批量自動發(fā)布

業(yè)務(wù)復(fù)雜、數(shù)據(jù)龐大、應(yīng)用廣怎辦？了解下分布式事務(wù)的解決思路！