UNDO長(zhǎng)時(shí)間回滾不釋放怎么辦

這篇文章給大家介紹UNDO長(zhǎng)時(shí)間回滾不釋放怎么辦，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對(duì)大家能有所幫助。

數(shù)據(jù)庫(kù)環(huán)境:

數(shù)據(jù)庫(kù)版本:11.1.0.7.6    

操作系統(tǒng):HPUX IA64 B.11.31      

數(shù)據(jù)庫(kù)運(yùn)行模式:RAC,4節(jié)點(diǎn)          

UNDO表空間大小:每個(gè)節(jié)點(diǎn)200G         

系統(tǒng)類型：OLAP

    凌晨3點(diǎn)多，接到客戶電話，說(shuō)是昨天晚上數(shù)據(jù)庫(kù)殺了一個(gè)會(huì)話(會(huì)話已經(jīng)報(bào)錯(cuò))，然后這個(gè)會(huì)話產(chǎn)生的UNDO數(shù)據(jù)一直在回滾，從晚上九點(diǎn)開始，占用大量UNDO表空間,新的會(huì)話上去執(zhí)行SQL的時(shí)候會(huì)報(bào)無(wú)法分配UNDO表空間的錯(cuò)誤。

    我們知道，諸如Insert，Delete，Update等操作都會(huì)在UNDO表空間其中的一個(gè)回滾段里面分配相應(yīng)的空間以便生成UNDO回滾信息。當(dāng)我們Rollback或者使用版本查詢、閃回表的時(shí)候都要用到UNDO信息，這里就有一個(gè)矛盾，如果UNDO信息保存的時(shí)間越長(zhǎng)，那么這些特性被支持的力度也就越大，這個(gè)是我們很愿意看到的，但是凡事都有兩面性，在支持這些特性的同時(shí)，也會(huì)有相應(yīng)的消耗，而且如果保持太長(zhǎng)時(shí)間的信息的話，成本將成倍的增加。

    這也就是我們要知道一個(gè)合適的平衡點(diǎn)兒，既可以最大限度的滿足我們對(duì)這些特性的需求，同時(shí)也減少存儲(chǔ)的需求。

    另外一方面，如果這個(gè)時(shí)間設(shè)置的過(guò)小，那么當(dāng)我們的一個(gè)比較長(zhǎng)的SQL執(zhí)行時(shí)間超過(guò)這個(gè)參數(shù)的時(shí)候，我們就會(huì)獲得一個(gè)ORA-01555快照過(guò)舊的錯(cuò)誤，更何況我們的系統(tǒng)是一個(gè)OLAP系統(tǒng)。

    其實(shí)最好的辦法是新建一個(gè)UNDO表空間，然后將新的UNDO表空間指定到當(dāng)前實(shí)例上，讓老的UNDO表空間慢慢回滾，或者在原來(lái)的UNDO表空間里面增加數(shù)據(jù)文件。

    但是這兩種方法都需要新的存儲(chǔ)空間支持。并且第二種在新增到原有UNDO表空間中以后想要縮小UNDO就很困難了。

    對(duì)于UNDO表空間，好像Oracle并不想提供太多的管理手段給DBA，也行這也是為了保證數(shù)據(jù)的完整性，而做出的妥協(xié)吧。

    在現(xiàn)場(chǎng)，我們?cè)嚵藢?shù) UNDO_retention從原來(lái)的20800縮小到8000

SQL> alter system set UNDO_RETENTION=8000 sid='dw2' scope=both;

    但是經(jīng)過(guò)觀察,效果并不明顯,后來(lái)知道從Oracle 10g開始,有一個(gè)_undo_autotune的參數(shù)，根據(jù)undo表空間使用情況自動(dòng)控制undo_retention的值,也就是在UNDO表空間自動(dòng)擴(kuò)展的時(shí)候,保證undo_retention設(shè)置的值為最低閥值,然后根據(jù)需要擴(kuò)展UNDO表空間,如果UNDO表空間AutoExtend為OFF，那么就根據(jù)UNDO STATUS的信息來(lái)動(dòng)態(tài)的設(shè)置undo_retention的值,那么問題就來(lái)了，我們系統(tǒng)中 _undo_autotune的值是TURE，也就是說(shuō)undo_retention的值是由系統(tǒng)來(lái)決定的，我們所做的修改根本就沒有作用。

   根據(jù)查詢系統(tǒng)的視圖得知，該回滾大概有220萬(wàn)個(gè)blocks需要回滾，每小時(shí)大概20萬(wàn)個(gè)，也就是說(shuō)需要11到12個(gè)小時(shí)才能回滾完。

   在不增加UNDO表空間或者不切換UNDO表空間的前提下，自動(dòng)管理UNDO的模式下，實(shí)在是沒有什么好辦法可以做到在快速釋放UNDO空間（Oracle要保證回滾完成，以保證數(shù)據(jù)完整性，如果會(huì)話在則有會(huì)話進(jìn)程來(lái)完成回滾，否則由SMON進(jìn)程來(lái)完成）

我們做到只能是等待回滾完成，及時(shí)關(guān)閉節(jié)點(diǎn)，在重啟以后數(shù)據(jù)庫(kù)依然要完成回滾才可以的。如果大家有什么好辦法，歡迎一起來(lái)討論

我的建議是修改_undo_autotune參數(shù)為False，然后可以適當(dāng)?shù)目s小undo_retention的值,如果達(dá)不到預(yù)期的話,可以通過(guò)新建UNDO表空間并且替換之的辦法來(lái)解決問題.

SQL> create undo tablespace UNDO005 datafile '.......' size 20G autoextend off;

SQL> alter system set undo_tablespace=UNDO005;

等待到回滾完成以后再切換回來(lái)原來(lái)的UNDO表空間.

SQL> alter system set undo_tablespace=UNDO002;

建議:這種類型的大型數(shù)據(jù)庫(kù),因?yàn)槊總€(gè)SQL執(zhí)行時(shí)間都比較長(zhǎng),數(shù)據(jù)量比較大,有些一個(gè)語(yǔ)句都會(huì)參數(shù)幾十個(gè)G的UNDO數(shù)據(jù),所以建議在回滾開始的時(shí)候,切換一個(gè)備用的UNDO表空間,讓其慢慢的回滾,待回滾完畢之后,再切換回來(lái),當(dāng)然,如果回滾段比較大,不影響使用的情況下也可以讓之慢慢回滾。

關(guān)于UNDO長(zhǎng)時(shí)間回滾不釋放怎么辦就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。