您好,登錄后才能下訂單哦!
這篇文章給大家介紹UNDO長時間回滾不釋放怎么辦,內容非常詳細,感興趣的小伙伴們可以參考借鑒,希望對大家能有所幫助。
凌晨3點多,接到客戶電話,說是昨天晚上數據庫殺了一個會話(會話已經報錯),然后這個會話產生的UNDO數據一直在回滾,從晚上九點開始,占用大量UNDO表空間,新的會話上去執行SQL的時候會報無法分配UNDO表空間的錯誤。
我們知道,諸如Insert,Delete,Update等操作都會在UNDO表空間其中的一個回滾段里面分配相應的空間以便生成UNDO回滾信息。當我們Rollback或者使用版本查詢、閃回表的時候都要用到UNDO信息,這里就有一個矛盾,如果UNDO信息保存的時間越長,那么這些特性被支持的力度也就越大,這個是我們很愿意看到的,但是凡事都有兩面性,在支持這些特性的同時,也會有相應的消耗,而且如果保持太長時間的信息的話,成本將成倍的增加。
這也就是我們要知道一個合適的平衡點兒,既可以最大限度的滿足我們對這些特性的需求,同時也減少存儲的需求。
另外一方面,如果這個時間設置的過小,那么當我們的一個比較長的SQL執行時間超過這個參數的時候,我們就會獲得一個ORA-01555快照過舊的錯誤,更何況我們的系統是一個OLAP系統。
其實最好的辦法是新建一個UNDO表空間,然后將新的UNDO表空間指定到當前實例上,讓老的UNDO表空間慢慢回滾,或者在原來的UNDO表空間里面增加數據文件。
但是這兩種方法都需要新的存儲空間支持。并且第二種在新增到原有UNDO表空間中以后想要縮小UNDO就很困難了。
對于UNDO表空間,好像Oracle并不想提供太多的管理手段給DBA,也行這也是為了保證數據的完整性,而做出的妥協吧。
在現場,我們試了將參數 UNDO_retention從原來的20800縮小到8000
SQL> alter system set UNDO_RETENTION=8000 sid='dw2' scope=both;
但是經過觀察,效果并不明顯,后來知道從Oracle 10g開始,有一個_undo_autotune的參數,根據undo表空間使用情況自動控制undo_retention的值,也就是在UNDO表空間自動擴展的時候,保證undo_retention設置的值為最低閥值,然后根據需要擴展UNDO表空間,如果UNDO表空間AutoExtend為OFF,那么就根據UNDO STATUS的信息來動態的設置undo_retention的值,那么問題就來了,我們系統中 _undo_autotune的值是TURE,也就是說undo_retention的值是由系統來決定的,我們所做的修改根本就沒有作用。
根據查詢系統的視圖得知,該回滾大概有220萬個blocks需要回滾,每小時大概20萬個,也就是說需要11到12個小時才能回滾完。
在不增加UNDO表空間或者不切換UNDO表空間的前提下,自動管理UNDO的模式下,實在是沒有什么好辦法可以做到在快速釋放UNDO空間(Oracle要保證回滾完成,以保證數據完整性,如果會話在則有會話進程來完成回滾,否則由SMON進程來完成)
我們做到只能是等待回滾完成,及時關閉節點,在重啟以后數據庫依然要完成回滾才可以的。如果大家有什么好辦法,歡迎一起來討論
我的建議是修改_undo_autotune參數為False,然后可以適當的縮小undo_retention的值,如果達不到預期的話,可以通過新建UNDO表空間并且替換之的辦法來解決問題.
SQL> create undo tablespace UNDO005 datafile '.......' size 20G autoextend off;
SQL> alter system set undo_tablespace=UNDO005;
等待到回滾完成以后再切換回來原來的UNDO表空間.
SQL> alter system set undo_tablespace=UNDO002;
建議:這種類型的大型數據庫,因為每個SQL執行時間都比較長,數據量比較大,有些一個語句都會參數幾十個G的UNDO數據,所以建議在回滾開始的時候,切換一個備用的UNDO表空間,讓其慢慢的回滾,待回滾完畢之后,再切換回來,當然,如果回滾段比較大,不影響使用的情況下也可以讓之慢慢回滾。
關于UNDO長時間回滾不釋放怎么辦就分享到這里了,希望以上內容可以對大家有一定的幫助,可以學到更多知識。如果覺得文章不錯,可以把它分享出去讓更多的人看到。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。