這一次主題為單個session占用大量undo，導致資料庫效能急劇下降的問題總結。關於「
問題現象
問題原因
引申現象
資料庫中出現大量latch: undo global data」或者「wait for a undo record」
相關的等待，但在當前例項中查詢每個session的undo使用情況時，未發現有某個session占用大量undo。這種情況可能是由於其它例項的某個session使用大量undo導致，因此，需要所有例項上進行查詢。
資料庫中出現大量latch: undo global data」或者「wait for a undo record」
相關的等待，但是在資料庫的所有例項上查詢，未發現有某個session占用大量undo，這種情況可能是由於占用大量undo的session事務已經commit，但是sql語句效率下降的時間點是發生在事務未commit的時間段，主機cpu資源100%，由於排隊效應，資料庫整體執行效率低效，即使導致產生問題的事務提交完畢後，整個資料庫也無法馬上恢復正常，需要等待一段時間才能恢復正常（等待的時間未知，某些重要的系統，可能無法接受長時間的等待）
解決方法（僅供參考）
undo相關問題總結（一）」
如果查詢結果中未發現有session正在占用大量undo，如上「引申現象中的2」部分，說明造成問題的session已經commit，可以等待一段時間，資料庫會慢慢恢復正常。如果無法接受等待，可以考慮kill掉undo相關等待的連線，釋放cpu資源。
如果查詢結果中發現有session使用了大量undo（具體多少得看業務併發量，一般100m以上），首先得判斷session當前正在進行的事務完成進度。如果即將完成，可以考慮等待事務完成提交後，資料庫慢慢恢復正常，見步驟2。如果事務完成進度小於60%，可以考慮kill掉該session。判斷事務完成進度的可以根據步驟1查詢結構中的machine,program,module等資訊定位具體的連線資訊，然後詢問開發人員、語句執行人員（如果該語句為人為執行）、查詢v$session_longops也能有幫助。
kill掉使用大量undo的連線後，由於回滾kill掉的事務需要時間（特別是問題發生後，cpu資源100%，資料庫的任何操作都會特別緩慢，平時5分鐘能完成的回滾，可能在問題時間段1個小時都無法完成），資料庫效能惡劣的問題會持續很長一段時間，業務也極有可能根本不能接受這麼長時間的無法響應。因此，後續解決問題的關鍵轉化為怎麼讓事務回滾的更快。
評估回滾事務的完成進度，如下語句：
select usn, state, undoblockstotal "total", undoblocksdone "done", undoblockstotal-undoblocksdone "todo",
decode(cputime,0,'unknown',sysdate+(((undoblockstotal-undoblocksdone) / (undoblocksdone / cputime)) / 86400)) "estimated time to complete"
from v$fast_start_transactions;
過一段時間間隔後，再次使用上面的語句查詢事務的回滾進度，可以預估完成回滾大概時間。
也可以使用如下語句查詢回滾進度：
declare
l_start number;
l_end number;
begin
select ktuxesiz into l_start from x$ktuxe where ktuxeusn=194 and ktuxeslt=17;
dbms_lock.sleep(60);
select ktuxesiz into l_end from x$ktuxe where ktuxeusn=194 and ktuxeslt=17;
dbms_output.put_line('time est day:'|| round(l_end/(l_start -l_end)/60/24,2));
end;
/
加快事務回滾的解決方法，可劃分為三類（僅供參考）
資料庫可以重啟，可以考慮的解決辦法
設定回滾並行度為high
增加_cleanup_rollback_entries引數值（預設為100）
重啟資料庫，回滾完成後，開放給業務使用。
可以停止相關應用，
可以考慮的解決辦法
停止相關應用（涉及到這種表的查詢），停止應用後，如果連線未斷開，需要kill掉這些連線。
設定回滾並行度為high（可能smon已經在回滾，無法調整並行度，此時需要先禁用smon回滾，然後設定並行度，再恢復smon回滾）
回滾完成後，啟動相關應用
資料庫不能重啟，相關應用也不能停止，
可以考慮的解決辦法
rename正在回滾的表，同時新建一張空表替換（注意考慮索引，外來鍵，依賴性等等），將那些等待的undo的session kill掉，釋放cpu資源，最後將資料回插到空表（資料量大的情況下需分批插入和commit，避免undo量過大導致重複這類問題），這個解決方法的侷限性在於應用可否接受短暫的空表。
備註：rename正在回滾的表後，該錶不會存在訪問，同時後續訪問該錶的sql（被替換為空表了）也不會存在效率問題，cpu資源很快能回歸正常，因此問題時間段回滾速度特別慢的操作，現在也能很快完成。
常見討論
總結
一般oltp系統，不應該存在單個session使用過高undo的情況，如果有，需要調整和優化。如果是人為執行，可能需要進行宣貫和培訓；
針對這類情況的預防，可以考慮部署session undo的使用量監控；
olap系統，由於主要應用與分析和統計，單個session使用大量undo屬於正常現象，而且由於不會有大量併發訪問，因此也就不會產生上面討論的問題
還準備總結一篇undo段損壞問題的解決，也是undo相關問題總結系列的最後一篇。
UNDO相關問題總結（一）
第乙個主題 介紹undo表空間不足的問題 undo表空間不足的問題，基本可劃分兩類 針對這兩個情況的處理方法如下 僅供參考 1.通過下面語句查詢當前例項undo空間的使用情況 active unexpired型別段的佔比 select b.tablespace name,nvl used undo,...
UNDO自我理解總結
場景 當在更新資料的時候，發現更新的值寫錯了，這時就需要將已經更新的地方恢復到原始資料。基本概念 在更新的過程中，oracle會將原始的資料都放入到undo裡，這樣當以上情況發生後，就可以從undo中拿到原本的資料了。undo是在oracle 11g被提出的，由undo tablespace進行管理...
CocoaPods相關問題總結
關於pod install 和 pod update 第一次為專案新增依賴或者每一次修改podfile後使用pod install。當你執行pod install，它只會解決那些沒有在podfile.lock檔案中列出來的pods的依賴。對於沒有在podfile.lock中列出的pods，會去匹配p...