UNDO_MANAGEMENT specifies which undo space management mode the system should use. When set to AUTO, the instance starts in automatic undo management mode. In manual undo management mode, undo space is allocated externally as rollback segments.

Automatic Undo Management

自動重做管理

Oracle 伺服器自動管理重做段的建立、分配、和調整

Manual Undo Management

手工管理重做

手工管理重做段的建立、分配、調整。這是Oracle9I之前的唯一方法

1、使用manual

1)回滾段的分配和使用

1>當事務產生的時候，資料庫會給事務分配一個回滾段。當然我們可以指定事務使用某個回滾段。在我的測試用的資料庫中，有如下回滾段

SQL> select SEGMENT_ID ,SEGMENT_NAME from dba_rollback_segs;

SEGMENT_ID SEGMENT_NAME

---------- ------------------------------

0 SYSTEM

1 RBS0

2 RBS1

3 RBS2

4 RBS3

5 RBS4

6 RBS5

7 RBS6

9 RBS12

9 rows selected.

SQL>

如果我們要指定事務使用某個回滾段，如下

SQL> set transaction use rollback segment rbs6;

Transaction set.

SQL> insert into t select * from all_objects;

25649 rows created.

SQL> commit;

Commit complete.

如果我們不人為的指定使用哪個回滾段，則資料庫會根據回滾段中事務來權衡，以使得所有回滾段中事務壓力盡可能平均。我們考慮存在非系統回滾段的情況（這也是絕大多數系統的情況，除非因為DBA嚴重錯誤才會使得系統只存在系統回滾段），在這種情況下我們發出的事務不會去使用系統回滾段，這時系統回滾段只用於系統級使用，比如create、drop、truncate等發生的時候的系統級的資料字典的回滾記錄。資料庫為我們發出的事務選擇非系統回滾段，同一個事務不能跨越回滾段，也就是說即使其他回滾段還很空閒，該大事務也只能使用被分配的回滾段即使該回滾段擴充套件。

接下來我們來考究單個回滾段內的使用、擴充套件、回縮的問題。一個回滾段至少包含2個extent。每個回滾段有一個回滾段頭，回滾段頭是一個block，裡面主要記錄了事務表資訊。當產生一個事務的時候，就在回滾段頭的事務表中記錄一條資訊，該資訊中包含了事務標誌、事務狀態、使用的回滾段塊數等等資訊。我們假定新建立的一個回滾段存在extent 1，2，3，4，5。當第一個事務分配到回滾段中的時候，除了事務表資訊，該事務從extent 1的第二個block開始使用，該事務提交後陸續不斷的事務到來並提交，假設我們已經使用到了extent 5的末尾。這時再來事務內容需要寫入，則重新使用extent 1 的第二個block。這樣迴圈使用回滾段空間。同理回滾段頭的事務表也是如此迴圈使用。迴圈的次數，可以透過如下查詢獲得

SQL> select usn,WRAPS from v$rollstat;

USN WRAPS

---------- ----------

0 0

1 15

2 15

3 15

4 15

5 12

6 15

7 17

9 12

9 rows selected.

SQL>

那麼我們會有一個問題，那就是既然回滾段是迴圈使用的，那為什麼會擴充套件呢？注意在上面的例子中，所有的事務都是迅速提交了的。那我們現在假定這樣一種情況，存在一個事務，假設在extent 3 中有一個事務一直沒有提交，然後回滾段一直迴圈使用到了extent 2。當extent 2使用完畢的時候發現extent 3中存在未提交事務，這是即使extent 4,5,1中的事務都已經提交，當前事務也不能越過extent 3而去使用後面的可使用的extent，這時該回滾段就擴充套件新的extent，假定為extent 2-1。在資料庫中實際上回滾段的extent之間是透過指標連起來的一個單向迴圈的連結串列結構。擴充套件的時候相當於在連結串列中插入一個節點extent 2-1，但節點2-1的下一個extent依然是 extent 3，假如2-1使用完畢發現extent 3仍然存在未提交事務回滾段會繼續擴充套件。

我們做個例子，在SQLPLUS 1 中執行不提交(我們在v$rollstat 和 dba_rollback_segs中分別查詢發現usn =5的回滾段對應了名字 rbs4)

SQL> select a.usn,b.segment_name from v$rollstat a,dba_rollback_segs b

2 where a.usn = b.segment_id;

USN SEGMENT_NAME

---------- ------------------------------

0 SYSTEM

1 RBS0

2 RBS1

3 RBS2

4 RBS3

5 RBS4

6 RBS5

7 RBS6

9 RBS12

9 rows selected.

SQL>

SQL> select usn,rssize "rollback segment size" from v$rollstat where usn = 5;

USN rollback segment size

---------- ---------------------

5 4186112

SQL> set transaction use rollback segment rbs4;

Transaction set.

SQL> update t_small set object_id = 1;

100 rows updated.

開啟SQLPLUS 2執行

begin

for i in 1..1000 loop

set transaction use rollback segment rbs4;

update t set object_id = i where rownum < 101;

commit;

end loop;

end;

SQL> select usn,rssize "rollback segment size" from v$rollstat where usn = 5;

USN rollback segment size

---------- ---------------------

5 55042048

現在我們來看在一個獨立的session中執行下面的查詢並對比查詢前後的回滾段變化。

SQL> select usn,rssize "rollback segment size" from v$rollstat where usn= 4;

USN rollback segment size

---------- ---------------------

4 4186112

SQL> begin

2 for i in 1..1000 loop

3 set transaction use rollback segment rbs3;

4 update t set object_id = i where rownum < 101;

5 commit;

6 end loop;

7 end;

8 /

PL/SQL procedure successfully completed.

SQL> select usn,rssize "rollback segment size" from v$rollstat where usn= 4;

USN rollback segment size

---------- ---------------------

4 4186112

SQL>

在這兩個例子中我們很明顯地看到了回滾段是否擴充套件的對比。那麼，做完第二個例子後，我再回過頭來查詢原來擴充套件的比較大的回滾段,發現又變成4M了

SQL> select usn,rssize "rollback segment size" from v$rollstat where usn= 5;

USN rollback segment size

---------- ---------------------

5 4186112

SQL>

回滾段在擴充套件後，是要回縮的。假設回滾段當前extent n,使用完畢將準備使用extent n+1 的時候(extent n+1 無活動事務)，如果設定了optimal並且回滾段大於 optimal設定的大小，檢查extent n+2 中是否有未提交事務，如果沒有，則回收extent n+2，本質上，就是在回滾段的連結串列上摘去extent n+2 ，然後繼續檢查extent n+3 決定是否回收,由此重複該動作。Optimal設定決定了回滾段最終回收後的大小，回滾段回縮後大小盡可能的接近optimal設定，如上面例子是4M，可透過下面查詢(shrinks表示回滾段回縮的次數，實際上v$rollstat提供了很多的回滾段資訊，大家可以參考oracle document)

SQL> select USN,OPTSIZE,SHRINKS from v$rollstat;

USN OPTSIZE SHRINKS

---------- ---------- ----------

0 0

1 4194304 0

2 4194304 0

3 4194304 0

4 4194304 0

5 4194304 10

6 4194304 0

7 4194304 0

9 0

9 rows selected.

2> 系統回滾段、非系統的回滾段與延遲迴滾段

SYSTEM Undo Segment

SYSTEM 回滾段是建立在系統表空間中，主要是用於系統級的事務和分配普通事務於其他回滾段上。當手工建立資料庫後需要建立普通回滾段之前必須首先建立系統回滾段。按照oracle文件說明，當普通事務異常多的事情可能會出現使用系統回滾段的情況。但正常情況下，系統回滾段主要用於兩個方面。一是系統事務，比如針對資料字典的操作的truncate table 和 drop table 。如果truncate table or drop table 的過程中沒有成功，則系統會根據系統回滾段中的資料字典操作資訊對該DDL操作進行回退。另一個方面，就是延遲迴滾段(Deferred Rollback Segment)。延遲迴滾段表示的是，當我們使一個表空間OFFLINE(exeample: alter tablespace users offline)之後，由於表空間不可用（不能進行讀寫），這個時候若有事務資料位於該表空間並且執行了回滾命令，回滾完成將顯示給client，對於client看起來該事務已經回滾，但是對於資料庫來說該回滾並沒有真正完成，這個時候資料庫將該回滾資訊寫入系統回滾段（這就是延遲迴滾段），等表空間重新ONLINE的時候，資料庫從系統回滾段中將回滾資訊寫入表空間。

Non-SYSTEM Undo Segments

非系統重做段
資料庫擁有多個表空間時需要至少一個非系統的手工模式重做段或者自動模式的重做表空間

2）回滾段的設定和管理

事實上，對於作為個人意見來說，回滾段的管理本不應該是作為DBA的複雜的任務來對待的，因為回滾段的管理本來就可以使其很簡單。幾乎所有的系統出現回滾段問題，不外乎都是回滾段大小不足、回滾段個數太少。9i以前的版本因為對於我們來說，無非也就是這兩個問題。

關於回滾段表空間大小、回滾段資料檔案的擴充套件、回滾段的擴充套件等建立時指定的引數問題，我想參考建立語法就足夠了，沒有必要在這上去糾纏max extents是100還是200，你會發現去考慮這些引數沒有實質上的意義了。所有的一切設定，我只需要問幾個問題就足夠了：

1：系統併發事務數有多少？

2：系統是否存在大查詢或者大是事務？頻繁麼？

3：能提供給系統的回滾段表空間的磁碟空間是多少？

在初始化引數檔案中存在引數transactions_per_rollback_segment和transactions，共同決定了例項啟動的時候將嘗試聯機的最大回滾段個數，transactions決定了同時存在的最大事務數。在這裡順便提及的2個初始化引數

max_rollback_segments 系統允許的最大回滾段個數

rollback_segments 該引數是一個引數列表，假如建立回滾段的時候是PUBLIC型別，則跟該引數無關，假如是PRIVATE型別的，則必須使得回滾段出現在該引數列表裡面，否則資料庫啟動之後這些回滾段不會自動聯機(可手動)。在OPS/RAC中，PUBLIC型別的回滾段表示所有的INSTANCE都可以聯機這些回滾段（但同一時刻只能有一個例項聯機），相當於是一個公共回滾段池。

在例項啟動的時候，例項嘗試聯機rollback_segments中設定的回滾段，直到達到個數為min(CEIL(transactions/transactions_per_rollback_segment), max_rollback_segments)。若沒有達到這個值，則例項嘗試在PUBLIC型別的回滾段池中嘗試聯機回滾段，直到達到該值或者不再有回滾段可聯機。

當一個例項啟動後其聯機回滾段的個數是否足夠，跟併發事務數有關，若每個回滾段上活動事務過多可能導致嚴重的回滾段爭用。

這裡說了問題一相關內容，我們再看後面兩個問題。由於回滾段的擴充套件和回收是昂貴代價的操作，通常我們是要避免的。如果存在大的查詢，就算不會去寫回滾段，但是由於一致讀，我們也可以參照前面內容，知道如果這期間事務繁忙回滾段被迴圈使用覆蓋過，可能出現著名的ORA-01555錯誤。又由於事務產生的時候除非人為指定使用哪個回滾段，否則事務使用哪個回滾段對於我們應用來說是透明的，同時我們能指定事務使用哪個回滾段但並不能阻止別的事務不使用某個回滾段，這樣我們就必須認識到，回滾段設定成大小不一致是不合適的，幾乎是沒有意義的，因為瓶頸總是決定於最小的一個回滾段(這類似於木桶原理，決定裝水量的多少是由最短的片所決定的)。所以我們應該統一回滾段的大小。那通常對於一個系統來說，幾百M的磁碟空間甚至幾G的磁碟空間根本不是問題，所以我們沒有理由在這裡研究回滾段到底是使用4M大小還是10M大小，我們根據能提供的磁碟空間的估計，完全可以設定回滾段為50M/100M甚至更大的大小，這主要決定於在大查詢執行期間每個回滾段上可能的事務生成量，以及單個事務可能產生的回滾資料的大小。假如系統偶爾存在批次作業的時候可能使得某個回滾段擴充套件到1G，但平常我們的回滾段大小在50M就不會出現回縮現象。那這個特定的時候如果資料庫不繁忙只有大作業我們可以建立幾個很大的回滾段，然後是其他回滾段offline,等批作業完成然後再online其他回滾段，使大回滾段offline。當然可能的話也可以指定批作業使用大的回滾段。或者，我們可以為所有回滾段設定optimal為50M，任其特定時刻擴充套件然後回縮（注意所有回滾段的optimal必須設定一樣大小）。

對於回滾段除了按照我們對系統狀況估計進行建立、刪除外，還有使回滾段聯機和離線，我們要注意的是如果回滾段處於聯機並且裡面有活動事務的時候，若想使回滾段離線(offline)，則這時回滾段處於一種懸置的狀態，也就是新的事務將不能使用該回滾段，而原有的事務繼續存在，等待回滾段中所有事務完畢後，回滾段成為離線狀態。

使用manual時，涉及使用的一初始化些引數：

【undo_namanement=manual;】

【rollback_segments=(segment_name[, segment_name]……)

ROLLBACK_SEGMENTS allocates one or more rollback segments by name to this instance. If you set this parameter, the instance acquires all of the rollback segments named in this parameter, even if the number of rollback segments exceeds the minimum number required by the instance (calculated as TRANSACTIONS / TRANSACTIONS_PER_ROLLBACK_SEGMENT).

You cannot change the value of this parameter dynamically, but you can change its value and then restart the instance. Although this parameter usually specifies private rollback segments, it can also specify public rollback segments if they are not already in use.

To find the name, segment ID number, and status of each rollback segment in the database, query the data dictionary view DBA_ROLLBACK_SEGS.

When UNDO_MANAGEMENT is set to AUTO, ROLLBACK_SEGMENTS is ignored.】

3）建立rollback segment

Creating a Rollback Segment: Example The following statement creates a rollback segment with default storage values in an appropriately configured tablespace:

CREATE TABLESPACE rbs_ts
   DATAFILE 'rbs01.dbf' SIZE 10M
   EXTENT MANAGEMENT LOCAL UNIFORM. SIZE 100K;

/* This example and the next will fail if your database is in 
   automatic undo mode.
*/
CREATE ROLLBACK SEGMENT rbs_one
   TABLESPACE rbs_ts;

The preceding statement is equivalent to the following:

CREATE ROLLBACK SEGMENT rbs_one
   TABLESPACE rbs_ts
   STORAGE
   ( INITIAL 10K
     NEXT 10K
     MAXEXTENTS UNLIMITED );

2、當使用auto時：

1）概要：Oracle provides a fully automated mechanism, referred to as automatic undo management, for managing undo information and space. In this management mode, you create an undo tablespace, and the server automatically manages undo segments and space among the various active sessions.

You set the UNDO_MANAGEMENT initialization parameter to AUTO to enable automatic undo management. A default undo tablespace is then created at database creation. An undo tablespace can also be created explicitly.

When the instance starts, the database automatically selects the first available undo tablespace. If no undo tablespace is available, then the instance starts without an undo tablespace and stores undo records in the SYSTEMtablespace. This is not recommended in normal circumstances, and an alert message is written to the alert log file to warn that the system is running without an undo tablespace.

If the database contains multiple undo tablespaces, you can optionally specify at startup that you want to use a specific undo tablespace. This is done by setting the UNDO_TABLESPACE initialization parameter, as shown in this example:

UNDO_TABLESPACE = undotbs_01

In this case, if you have not already created the undo tablespace (in this example, undotbs_01), the STARTUP command fails. The UNDO_TABLESPACE parameter can be used to assign a specific undo tablespace to an instance in an Oracle Real Application Clusters environment.

The following is a summary of the initialization parameters for automatic undo management:

Initialization Parameter	Description
UNDO_MANAGEMENT	If AUTO, use automatic undo management. The default is MANUAL.
UNDO_TABLESPACE	An optional dynamic parameter specifying the name of an undo tablespace. This parameter should be used only when the database has multiple undo tablespaces and you want to direct the database instance to use a particular undo tablespace.

When automatic undo management is enabled, if the initialization parameter file contains parameters relating to manual undo management, they are ignored.

2）使用：從oracle9i 開始，推薦使用UNDO TABLESPACE，讓系統自動管理回滾段。

SQL> show parameters undo

NAME TYPE VALUE

------------------------------------ ------- -------------

undo_management string AUTO

undo_retention integer 10800

undo_suppress_errors Boolean FALSE

undo_tablespace string UNDOTBS1

SQL>

初始化引數undo_management 決定資料庫使用的回滾段是否使用自動管理模式。AUTO表示自動管理，MANUAL表示手工管理，也就是跟8i中一樣。undo_tablespace指定在自動管理模式下INSTANCE使用哪個表空間，undo_retention表示在自動管理模式下，回滾段中的資料在被覆蓋前保留多長的時間，單位是秒。這個引數應該決定於系統所中一些大查詢執行的時間長度，以避免ORA-01555錯誤。當然，實際上由於9i提供的flashback功能，可根據需要決定該引數設定的時間長度。設定undo_retention的同時要估計這樣長的時間內系統所產生的回滾資料的大小，結合硬體所提供的磁碟空間來綜合考慮。undo_suppress_errors引數如果設定為true在自動管理模式下，如果我們嘗試在建立回滾段，則不返回錯誤資訊，但實際上是無效的，設定為false則嘗試建立回滾段會返回錯誤資訊。

回滾段成為了自動管理，一方面驗證了前面所說的回滾段的管理的問題本不是一個複雜的問題，另一方面，自動管理讓我們覺得無所適從，幾乎人為的難以控制它了。比如UNDO表空間變的很大，我們卻不能縮小。這個時候我們可以考慮建立新的UNDO表空間，然後換到新的表空間，這時即使UNDO表空間中有事務也可以切換，只不過不能立即刪除該表空間，切換之後等到原來的表空間中的所有事務處理完畢並且達到undo_retention所限定時間之後，就可以drop原來的UNDO表空間。這樣可以解決UNDO表空間變的太大而無法縮小的問題。命令如下：

SQL> alter system set undo_tablespace = undotbs1;

System altered.

這裡要注意若切換了UNDO表空間後應該修改pfile或者spfile使得下次啟動應用新的UNDO表空間。

在自動管理模式下的UNDO表空間中的回滾段的個數是變化的，裡面回滾段依然存在著聯機和離線的狀況，只不過是系統自己管理。若在離線的時候回滾段中還存在著活動事務，這時也出現前面所講的一種懸置的狀態。這個時候系統可能會為此而生成提示資訊的trace檔案，這是沒有關係的，對系統沒有影響。

在9i下建立非自動管理的回滾段而不使用UNDO 表空間，則設定undo_management為MANUAL，然後在系統表空間中建立一個回滾段(注意這是必須的)，建立自己的回滾段表空間，這時可以在回滾段表空間中建立回滾段，建立完畢刪除系統表空間中的回滾段。

順便提及幾點，UNDO表空間在做含有LOB型別資料的EXP的時候如果資料量過大（也許是超過5G）可能出現BUG，ORACLE9.2.中如果UNDO是ASSM，若設定undo_retention不當等因素導致擴充套件過大，也會出現BUG，導致系統崩潰只能進行介質恢復。當然，建議管理生產資料庫的DBA們有空多瀏覽metalink，瞭解各種版本的特性和BUG。

其他介紹連線：

http://blog.csdn.net/liuya1985liuya/article/details/1815868

---The End---

【paramter】undo_management設定為auto與manaul的區別

相關文章