數(shù)據(jù)遷移是DBA的日常工作,對于相應的方法、命令等,相信很多人早已了如指掌。圓滿的數(shù)據(jù)遷移流程不單單指將數(shù)據(jù)從數(shù)據(jù)庫A備份恢復到數(shù)據(jù)庫B,而且要保證遷移前后數(shù)據(jù)的完整與服務的可用性。
近日,在給客戶做了單機到集群的數(shù)據(jù)遷移后,發(fā)現(xiàn)集群的在線重做日志切換頻繁,進而產生了大量的歸檔日志,對服務器造成了不小的壓力。本文是對上述問題的分析處理過程。
在遷移完成后,需要對集群進行一段時間的深度觀察。通過v$archived_log視圖,分析數(shù)據(jù)庫歷史的歸檔情況,可以發(fā)現(xiàn)整個庫的業(yè)務活動情況。
觀察上圖,不難發(fā)現(xiàn)遷移(6月15日)前后是一個明顯得變化點,每天日志歸檔頻率由原來的100多次變成400多次。這種情況要么是遷入的系統(tǒng)業(yè)務量確實很大,要么是遷入的數(shù)據(jù)庫用戶配置有問題。
經(jīng)過與新遷入系統(tǒng)的運維人員溝通確認,該系統(tǒng)的使用人數(shù)雖然多,但都是以查詢類的動作偏多,不應該帶來這么大量的日志。因為集群中還有其它系統(tǒng),不能直接判斷是新系統(tǒng)的問題。假設運維所說情況屬實,那么問題的關鍵點就是要找到產生大量日志的操作語句,進而找到對應的應用,再確認歸檔情況是否正常。
日志歸檔頻繁,說明在線重做日志切換頻繁,一般是由于產生了大量的redo。這里通過awr檢查redo的生成情況。
一天內日志歸檔的詳細情況
這里選擇6月18日上午10點到11點間集群2節(jié)點的awr報告
節(jié)點1:
觀察上圖,可以看到在1小時內,節(jié)點1的redo的產生速率約為3.38MB/S,那么一小時就有約11.88GB。
節(jié)點2:
觀察上圖,可以看到在1小時內,節(jié)點2的redo的產生速率約為0.26MB/S,那么一小時就有約0.9GB。
通過查詢v$archived_log視圖,分類計算出10點到11點間所產生的歸檔日志大小約為12.3GB,這與根據(jù)awr報告推算出來的值12.78GB非常接近,可以說明以上兩份awr報告的可參考性很高。
現(xiàn)在已經(jīng)確認是歸檔頻繁是由大量的redo引起的,那么就需要看在問題時間區(qū)間內,導致數(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報告中分別搜索表名稱,找出相關的sql語句。
由上圖可以看出,在1小時之內,對該3個表分別執(zhí)行了60次update操作,具體的sql語句如下:
這里注意到一個數(shù)字60,看樣子像是一個定時任務,首先想到的是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ù)量大,且只增不減,必須要調整。
根據(jù)前邊找到的線索,跟運維人員確認job(24)的業(yè)務作用,得到的反饋是之前有個需求是定期把符合要求的字段A的值寫到字段B,現(xiàn)在該需求已不再需要,可以刪除。
禁用job
雖然業(yè)務確認可以刪除,但為了保險起見,這里將job(24)禁用,通過調用dbms_job.broken完成。
觀察redo
這里選擇調整之后的6月20日上午10點到11點間集群2節(jié)點的awr報告
節(jié)點1:
節(jié)點2:
由上述節(jié)點1和節(jié)點2相同時間內的awr報告的來看,redo產生速率有了很大的降低。通過觀察歸檔日志的生成情況,發(fā)現(xiàn)歸檔頻率也降低了。
經(jīng)過回顧整個問題的發(fā)現(xiàn)、分析和解決過程,可以發(fā)現(xiàn)其實并沒有什么技術難點,問題的原因主要還是出在業(yè)務溝通上。在遷移之前,最好能夠跟應用管理員確認清楚業(yè)務的特點,包括現(xiàn)有業(yè)務的壓力情況、已發(fā)現(xiàn)的性能瓶頸、不再需要的各類數(shù)據(jù)庫對象(索引、視圖、存儲過程、函數(shù)、觸發(fā)器等),提前做好應對措施,保證數(shù)據(jù)遷移的圓滿完成。
另外有需要云服務器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn,海內外云服務器15元起步,三天無理由+7*72小時售后在線,公司持有idc許可證,提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業(yè)上云的綜合解決方案,具有“安全穩(wěn)定、簡單易用、服務可用性高、性價比高”等特點與優(yōu)勢,專為企業(yè)上云打造定制,能夠滿足用戶豐富、多元化的應用場景需求。
網(wǎng)站欄目:Oracle數(shù)據(jù)遷移后歸檔文件暴增怎么辦?-創(chuàng)新互聯(lián)
文章URL:http://jinyejixie.com/article36/dphosg.html
成都網(wǎng)站建設公司_創(chuàng)新互聯(lián),為您提供自適應網(wǎng)站、商城網(wǎng)站、小程序開發(fā)、建站公司、微信小程序、電子商務
聲明:本網(wǎng)站發(fā)布的內容(圖片、視頻和文字)以用戶投稿、用戶轉載內容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內容未經(jīng)允許不得轉載,或轉載時需注明來源: 創(chuàng)新互聯(lián)
猜你還喜歡下面的內容