UNDO表空間用于存放UNDO數據,當執行DML操作(INSERT,UPDATE和DELETE)時,oracle會將這些操作執行前的舊數據 寫入到 UNDO段,在oracle9i之前,管理UNDO數據時使用(Rollback Segment)完成的.從oracle9i開始,管理UNDO數據不僅可以使用回滾段,還可以使用UNDO表空間.因為規劃和管理回滾段比較復雜,所有 oracle database 10g已經完全丟棄用回滾段.并且使用UNDO表空間來管理UNDO數據.

在網上找到相關的描述，大致內容如下：

回滾段可 以說是用來保持數據變化前映象而提供一致讀和保障事務完整性的一段磁盤存儲區域。當一個事務開始的時候，會首 先把變化前的數據和變化后的數據先寫入日志緩沖區，然后把變化前的數據寫入回滾段，最后才在數據緩沖區中修改（日志緩沖區內容在滿足一定的條件后可能被寫 入磁盤，但在事務提交的時候日志必須寫入磁盤，而數據緩沖區中的數據依賴于檢查點的發生和DBWR進程的活動） Rollback是一個代價昂貴的操作，如果一個系統的事務回退率過高，應該檢查系統是否正常或者程序設計思路是否存在問題。查詢數據庫啟動依賴的 事務回退率，如果發現太高，一定要引起重視。 --查詢回退率的sql SELECT NAME, VALUE FROM v$sysstat WHERE NAME IN ('user commits', 'transaction rollbacks'); 關于回滾段的數據，如果是delete操作，則回滾段將回記錄整個行的數據；如果是update，則只記錄被修改了的字段的變化前的數據（前映像）；如果 是insert，則只記錄插入記錄的rowid。所以，假如commit，那么回滾段中簡單標記該事務已經提交；假如rollback，則操作是 delete的話，把回滾段中的數據重新寫回數據塊，操作是update的話則把變化前的數據修改回去，操作是insert的話則根據rowid把該記錄 刪除。這個過程是保障事務的完整性，保障數據不會丟失。 一致性讀（consisitent reads) Oralce的查詢集是根據時間點來判定的。Oracle內部通過系統改變號SC作為相對時間點的標準，任何對數據庫的改變都會產生SCN，對數據塊的數 據改變的時候會把該改變所對應的SCN記錄在塊中。假設查詢開始的時候SCN為T，則在查詢所掃描的數據塊中，如果數據塊的COMMIT SCN小魚T，則查詢接受該數據，如果COMMIT SCN大于T或者說還沒有產生COMMIT SCN，則查詢會嘗試去回滾段中查找數據。這保證了數據的讀取時間點的一致性。 在通過回滾段中獲取數據的時候，本質上是把數據緩沖區中的數據塊做一個拷貝，然后將回滾段中記錄的內容恢復到該塊中，然后查詢使用這個塊來進行讀取。 系統回滾段和延遲回滾段 SYSTEM回滾段是創建在系統表空間中，主要用于系統級的事務和分配普通事務于其他回滾段上。當手工創建數據后需要創建普通回滾段之前必須首先創 建系統回滾段。按oracle文檔說，當普通事務異常多的事情可能會使用系統回滾段的情況。正常情況下，系統回滾段主要用于兩個方面：一是系統事務，不如 針對數據字典的操作的truncate table 和 drop table。如果truncate or drop table的過程中沒有成果，則系統會根據系統回滾段中的數據字典操作信息對該DDL操作進行回退。另一個方面，就是延遲回滾段(Deferred Rollback Segment)。延遲回滾段表示，當我們使一個表空間OFFLINE之后，由于表空間不可用，這個時候若有事務數據位于該空間并執行回滾命令，在 client看起來該事務已經回滾，但對于數據塊來說回滾并沒有真正完成，這個時候數據庫將該回滾信息寫入系統回滾段（這就是延遲回滾段），等表空間重新 ONLINE的時候，數據塊從系統回滾段中將回滾信息寫入表空間。 回退段的設置和管理 Oracle9i之前需要手動設置回退段，我們需要考慮如下問題： 1．系統并發事務數有多少 2．系統是否存在大查詢或者大事務，是否頻繁 3．能提供給系統回滾段的表空間的磁盤空間是多少 9i的UNDO TABLESPACE 從9i開始，推薦使用UNDO TABLESPACE,系統自動管理回滾段 Sql> show parameter undo undo_management?????????????????????? string??? AUTO undo_retention??????????????????????? integer?? 900 undo_tablespace?????????????????????? string??? UNDOTBS1 UNDO TABLESPACE變的很大，我們不能縮小，這個時候我們需要考慮創建新的UNDO TABLESPACE，然后換到新的表空間。這時即使UNDO表空間有事務也可以切換，只不過不能立即刪除該表空間，切換之后等到原來的表空間中所有的事 務出力完畢，并且達到undo_retention的時間后，就可以drop原來的UNDO表空間。 SQL> alter system set undo_tablespace = undotbs02; System altered. 切換了UNDO表空間后應該修改pfile或者spfile，使得下次啟動應用新的UNDO表空間。 回滾段著名的ORA-01555問題 從應用角度來看ORA-01555 1.查詢執行時間太長。首先是優化查詢，然后考慮在數據塊不繁忙的時候運行，最后考慮加大回滾段。 2.過渡頻繁的提交。把能夠成批提交的單條事務改成成批提交 3.exp的時候使用而來consistent = y. 這個參數主要是為了保證在exp的時候使得所有的到處的表在時間點上具有一致性，避免存在主外鍵關系的表由于不同的時間點的不一致而破壞了數據的完整性。 建議該操作在系統空閑的時候進行。 4.由于回滾段回縮導致回滾段還沒有循環使用的情況下就出現了回滾段中找不著數據的情況。只能加大回滾段增大optimal設置。 UNDO scripts 查詢數據塊當前某個session的事務所使用的回滾段大小 SELECT b.SID, a.xidusn, a.xidusn FROM v$transaction a, v$session b WHERE a.addr = b.taddr 回滾段表空間中的一個數據文件丟失或者損害的恢復方法 ……………. 由于對應的undo block/或者undo header slot信息被覆蓋,導致consistent read不能完成, 系統會報出ora-01555的錯誤信息.. 出現這種情況的原因可能有以下幾種. 1. 對于早期的manual undo, 可能是由于系統設置了optimal size, rollback segment wrap 導致部分undo信息被丟棄.. 2. 由于undo retention 設置的時間小于sql執行的長度,這樣從這條sql開始時候其他session產生的部分undo由于retention的原因被覆蓋,導致無法完成 consistent read. 3. 由于commit over fetch loop. 導致transaction slot 被覆蓋,無法完成consistent read .. ORA-01555錯誤淺析－－ http://www.hellodba.com/Doc/ORA-01555_analysis(1).htm 總結出以下方法來解決1555錯誤問題： 1、擴大回滾段 因為回滾段是循環使用的，如果回滾段足夠大，那么那些被提交的數據信息就能保存足夠長的時間是那些大事務完成一致性讀取。 2、增加undo_retention時間 在undo_retention規定的時間內，任何其他事務都不能覆蓋這些數據。 3、優化相關查詢語句，減少一致性讀。 減少查詢語句的一致性讀，就降低讀取不到回滾段數據的風險。這一點非常重要！ 4、減少不必要的事務提交 提交的事務越少，產生的回滾段信息就越少。 5、對大事務指定回滾段 通過以下語句可以指定事務的回滾段：

SET TRANSACTION USE ROLLBACK SEGMENT rollback_segment；

給 大事務指定回滾段，即降低大事務回滾信息覆蓋其他事務的回滾信息的幾率，又降低了他自身的回滾信息被覆蓋的幾率。大事務的存在，往往是1555錯誤產生的 誘因。 6、使用游標時盡量使用顯式游標，并且只在需要的時候打開游標，同時將所有可以在游標外做的操作從游標循環中拿出。 當游標打開時，查詢就開始了，直到游標關閉。減少游標的打開時間，就減少了1555錯誤發生的幾率。

轉載于:https://blog.51cto.com/itlaowu/959721

總結

以上是生活随笔為你收集整理的oracle undo的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。