RBS TUNNING

一 回滾段相關概念

    Every[1]   Oracle database must have a method of maintaining information that is used to roll back, or undo, changes to the database. Such information consists of records of the actions of transactions, primarily before they are committed. Oracle refers to these records collectively as undo。

 

    Undo records are used to:

    Roll back transactions when a ROLLBACK statement is issued

    Recover the database    

    Provide read consistency

 

    When a rollback statement is issued, undo records are used to undo changes that were made to the database by the uncommitted transaction.

    During database recovery, undo records are used to undo any uncommitted changes applied from the redo log to the datafiles.

    Undo records provide read consistency by maintaining the before image of the data for users who are accessing the data at the same time that another user is changing it.

 

    在 Oracle 9i 以前，Oracle使用回滾段來存儲 undo。對回滾段的空間管理相對較複雜。從Oracle 9i 開始，Oracle 提供另一種方法來存放undo，從而消除了管理回滾段空間的複雜性, 並允許DBAs 控制在undo 被覆蓋前，保留多長時間。這種方法使用一個 undo tablespace.

 

     You cannot use both methods in the same database instance, although for migration purposes it is possible, for example, to create undo tablespaces in a database that is using rollback segments, or to drop rollback segments in a database that is using undo tablespaces. However, you must shut down and restart your database in order to effect the switch to another method of managing undo.

 

在 Oracle 9i 以前，只能通過手工管理回滾段；從Oracle 9i 開始，既可選擇自動管理，也可選擇手工管理。建議使用自動管理的 undo 表空間。

 

二 有關ROLLBACK數據庫參數

自動管理的回滾段的參數：

在Oracle 9i 及以上，通過設置參數：

UNDO_MANAGEMENT=AUTO，啓用對回滾段的自動管理。儘管該參數缺省爲MANUAL，即與 9i 以前一致，但由於使用自動的回滾段管理，可以大大減少ora-1555錯誤的發生，以及可以啓用flash back query 功能，因而，對於9i 及以上，建議設置 undo_management=auto。

 

在自動管理的情況下，對回滾段表空間本身的參數設置僅爲：

UNDO_TABLESPACE  指定回滾段表空間的名稱

UNDO_RETENTION 指定保留 undo 的時長，缺省爲 900秒。

UNDO_SUPPRESS_ERRORS，指定在自動管理模式下，發出手工管理的sql命令是否報錯。缺省爲false,即，會報錯。

 

在 Oracle 9i 及以上，若未顯式地設置參數 UNDO_MANAGEMENT=auto，則其缺省爲 manual, 即，啓用對回滾段的手工管理。對回滾段的手工管理，則爲與oracle 9i 以前的管理方式一致。

手工管理的回滾段的參數：

通過設置參數 rollback_segments 進行：

ROLLBACK_SEGMENTS 定義數據庫啓動時將 online 的所有私有回滾段的名字（所有公有回滾段在數據庫實例啓動時是會自動online的。通過create public rollback segment 的命令創建公有回滾段，缺省時創建的爲私有回滾段）。

 

另一個可適當關注的與回滾相關的參數爲：

FAST_START_PARALLEL_ROLLBACK

其決定執行並行回滾時最大的進程數。對於長時間運行的大事務的回滾及大量併發事務的回滾較有用。

一般情況下，建議保持其缺省值(low)。Low 指的是可啓動2* cpu_count 的並行回滾進程，而high指的是可啓動4*cpu_count的並行回滾進程。False則表示不使用並行回滾。對於長時間運行的事務及大量併發事務的回滾，使用並行回滾可以提高回滾的速度。同時，可啓動的並行回滾進程的數量與參數 parallel_max_servers 及processes 參數相關。最多的並行回滾進程數不會超過parallel_max_servers的數目，同時，並行回滾進程數也不會導致數據庫所有運行的進程數超過processes參數的值。

Fast_start_paralle_rollback 參數在high/low之間可以在線動態修改，若設置了 high/low 後，未起作用，可以通過命令將其屬性進行多次轉換，實在未能按照參數設置生效，則考慮關閉數據庫，並在參數文件中設置相應的參數值，並重啓數據庫。在某些情況下，fast_start_parallel_rollback可能導致smon 繁忙而回滾速度並未加快，此時，可以考慮設置fast_start_parallel_rollback=false來關閉自動回滾。

一般而言，在smon進行大事務的回滾時，可通過查詢 $fast_start_transactions 視圖，如：

select * from v$fast_start_transactions

若其中僅一個process在進行事務回滾,則表明，不能利用並行修復，此時，可以將該參數設置爲false,若發現所有的進程均爲在進行事務的回滾，且其UNDOBLOCKSDONE 增長得較快（每進程每秒鐘回滾100個block左右），則表明其可以利用並行修復，此時，可以通過設置該參數爲HIGH，從而啓動更多的進程來進行並行修復。加快並行修復的過程。

 

常用的回滾段參數列表：

參數	值範圍	8i	9i 及以上	缺省
ROLLBACK_SEGMENTS	系統中的回滾段	有	在手工管理時指定
UNDO_MANAGEMENT	AUTO/MANUAL	無	有	MANUAL
UNDO_TABLESPACE	Undo表空間名	無	自動管理時指定	UNDOTBS1
UNDO_RETENTION	0至 0 to 232-1	無	自動管理時指定	900
UNDO_SUPPRESS_ERRORS	TRUE/FALSE	無	自動管理時指定	FALSE
FAST_START_PARALLEL_ROLLBACK	HIGH/LOW/FALSE	有	有	LOW

 

對於其它回滾段相關的參數，如 transactions[1], max_rollback_segments, transactions_per_rollback_segment, distributed_transactions 等，保留其缺省值即可，無需專門設置其參數值，除非遇到有所需要的值較缺省值大的情況。

---

[1]   transactions 缺省爲1.1 * sessions，sessions 缺省爲 1.1*processes +5; transactions_per_rollback 缺省爲 5
max_rollback_segments=max(30, transactions/transactions_per_rollback_segment)
假設 sessions 參數設置爲 3000, 其它參數爲缺省值，則max_rollback_segments=660

 

三 undo 調整原則

自動管理的undo段的調整原則

對於Oracle 9i 及以上，通過設置 undo_management=AUTO以便使用自動管理的回滾段表空間，可設置的參數僅有：

UNDO_TABLESPACE，指定表空間的名稱，對於該表空間，可調整的僅爲其表空間的尺寸。在undo 表空間報空間滿的情況下，若應用不存在導致回滾段異常增長的情況，則應考慮增大undo 表空間的尺寸。

 

UNDO_RETENTION，指定在 commit後，保留相應的extent 處於 unexpired 狀態的時間。對其的調整爲增大或減少其時間值。

UNDO_SUPPRESS_ERRORS 參數一般無需修改其缺省值。

若需要使用 flashback query 功能，則應使用自動管理的undo 表空間。

若想對回滾段有自己的控制，則可以使用手工管理的回滾段表空間。

但對 Oracle 9i 及以上，建議使用自動管理的回滾段表空間，同時，對於10.2以前的數據庫，在使用自動管理的回滾段表空間時，可考慮設置參數： event="10511 trace name context forever, level 2"，從而使得online的回滾段不會自動 offline。

對於Oracle 9i 及以上，使用手工管理的回滾段表空間，則其管理方法與8i及以前版本一致。

手工管理的undo 段的調整原則：

1．RBS 表空間的創建原則：

RBS 表空間的大小以滿足數據庫事務的需求爲原則。

對於8i及以上，建議將 RBS 表空間創建爲 local 管理的 uniform size 的表空間。一般而言，Uniform size 可以設置爲 1M 或是 2M爲單位，若數據庫的事務均較小，則可以設置更小的uniform size,如128KB,256KB,512KB。若爲dictionary管理的表空間，則應確保pct_increase=0，且initial extent=next extents

若表空間的pct_increase 非0，則應通過 

alter tablespace 表空間名 default storage (pctincrease 0); 

進行修改。

若表空間的 initial extent 與 next extent 不一致，則對於已有的表空間，可忽略，對於新建的表空間，應考慮設置爲一致。

建字典管理的回滾段表空間的示例：

create tablespace  rbs datafile ‘…’ size xxxx minimum extent xxxx default storage (initial xxxx next xxxx pctincrease 0);

建本地管理的回滾段表空間的示例

create tablespace  rbs datafile ‘…’ size xxxx  extent management local uniform size xxxx;

創建回滾段表空間後，可通過

create rollback segment rxxx tablespace rbs storage (minextents xxx optimal xxx );

來創建回滾段。

2．回滾段的創建原則：

回滾段一般建議爲最少含有 10個尺寸相同的extents，同時，建議設置optimal 值。

回滾段的數量應根據數據庫中事務量的多少來確定。

若發現存在大量回滾段頭或回滾段塊的爭用，則應考慮增加回滾段的數量。

以一段時間爲基礎，使用語句：

select class, count from v$waitstat where class in (‘UNDO HEADER’,’UNDO BLOCK’);

查出該時段內，undo header及undo block爭用的情況。

在同一段時間，查出，

select sum(value) from v$sysstat where name in (‘DB BLOCK GETS’,’CONSISTENT GETS’);

對於以上查詢出來的值，應儘量保證：

undo_header/(db_block_gets+consistent gets) *100<1

undo_block/(db_block_gets+consistent gets)*100<1

將上面查出的每一 class 的 count 數據值與上面查出的邏輯讀的數量值相比較，若該段時間內，對undo header或undo block的爭用超過了邏輯讀的1%，則可考慮創建更多的回滾段以減少爭用。

回滾段的 optimal 值，爲在回滾段異常增長後，可以自動回縮。對於大量小的事務運行的數據庫，建議設置較低的 optimal 值。建立回滾段時，可以先設置optimal的尺寸爲min extents 的尺寸（extent_size * min_extents）

在確定optimal值是否合理前，請先確保應用設計中不存在：佔據回滾段後，長期不釋放，導致回滾段增長的情況。

在此基礎上，可通過查詢 v$rollstat 中的shrinks, aveshrink來了解optimal參數的設置。(shrinks 值與數據庫的事務量相關，判斷其是否高或低需要根據各個數據庫自己的特性來具體判斷)

若shrinks 次數較低，則表明optimal 值已足夠。但若同時aveshrink也低，且aveactive遠小於 optimal，則表明optimal 設置過大。可減少。（按照一次一個extents的方式來減少）

若shrinks次數較高，且aveshrink 尺寸較小，則表明optimal太小，應增大。（按照一次一個extents的方式來增加）

若shrinks 次數較高，且aveshrink尺寸較大，則表明可能有大的事務，或長的事務在運行，應檢查應用的設計。

select usn, [1]aveshrink, shinks, aveactive from v$rollstat;

Ad hoc querying of this view can help in determining the most advantageous setting for the OPTIMAL parameter. Assuming that an instance has equally sized rollback segments with comparably sized extents, OPTIMAL for a given rollback segment should be set slightly higher than AVEACTIVE. The following chart provides additional information on how to interpret the statistics given in this view.

 

回滾段extent的大小需根據事務對回滾段的使用情況來定。開始可考慮設置爲1M。同時，一般而言，回滾段的 optimal 值應爲對應10-20個extents。因而，可根據合適的optimal值來定義extent 的合適尺寸。

3．回滾段的使用原則：

事務在完畢後，應儘快commit或rollback。而不要進行完成事務後，佔據着回滾段，卻一直不commit，從而導致回滾段持續增長，同時，阻塞其它需要更新同一row的記錄的會話。

對於大的記錄量的更新，若可能，建議每1-10萬條一次commit操作。

4．自動管理的undo 表空間轉爲手工管理的回滾段的方法

1)  創建新的回滾段表空間

2)  在新的回滾段表空間中創建回滾段

3)  修改數據庫參數

屏蔽 undo_tablespace 參數的設置

修改 undo_management 參數的值爲 manual

設置 rollback_segments 參數，在其中包含各個新創建的回滾段的名稱

4)  關閉並重啓數據庫完成其轉換

5)  刪除原undo表空間中的回滾段及其表空間及相應的文件(可選)

5．手工管理的回滾段表空間轉爲自動管理的undo表空間的方法

1)  創建新的 undo表空間

create UNDO TABLESPACE "UNDOTBS1" DATAFILE ‘…’SIZE xxxxM AUTOEXTEND Off; 

 

2)  修改數據庫參數

屏蔽原 rollback_segments 參數的設置

設置 undo_tablespace 參數爲新建的 undo 表空間的名稱

修改 undo_management 參數的值爲 auto

設置 UNDO_RETENTION 參數的值爲相應的值（如 1800 秒）

3)  關閉並重啓數據庫

4)  刪除原回滾段表空間中的回滾段及其表空間及相應的文件(可選)

6．常見問題及解決辦法：

佔據少量回滾段，但不釋放，導致異常增長

1)  現象：

回滾段持續增長，同時，以下查詢返回有記錄。

<span style="font-family:Times New Roman;font-size:12px;color:#000000;">SELECT s.sid, s.serial#, t.start_time, t.xidusn,s.username
 FROM V$session s, V$transaction t, V$rollstat r
 WHERE s.saddr=t.ses_addr
 AND t.xidusn=r.usn
 AND ((r.curext=t.start_uext-1) OR
((r.curext=r.extents-1) AND t.start_uext=0));
</span>

則表明以上獲得的會話將導致（或已導致）回滾段持續增長。

2)  原因分析：

用戶進行查詢時，應用爲先將查詢出來的結果插入一個臨時表中，然後，並不commit; 待用戶退出相應的界面時，才自動rollback。

而用戶在實際使用中，爲上午上班時通過查詢查出相應的記錄，然後，便離開公司出外處理業務，下午下班時才返回辦公室，退出相應的界面。

於是，在上午上班時便佔據回滾段，至下午下班時才釋放回滾段。在此過程中，回滾段持續增長。直至回滾段表空間被用完，其它事務無法使用回滾段而報錯。同時，有可能在下午高峯期時，用戶退出界面，導致自動回滾，釋放相應的回滾段extent,而在其它事務需要wrap該回滾段的extent時，shrink回滾段，釋放其在 optimal 上過多的空間，而使得smon繁忙，需要smon進行空間分配，臨時段分配的事務掛起。

8i 中的 dataguard 進程在啓動後不久，也會由於一個僅佔用1個回滾段block的update，並且不釋放，導致回滾段持續增長。

在分佈式事務查詢中，本地回滾段中也會創建一個entry，若執行分佈式事務後，不進行commit，則會導致回滾段持續增長。

同時，此種情況也可能導致鎖等待。其它用戶等待更新該事務更新的記錄。

3)  應急方法：

最首要的是查出該用戶曾執行的sql，並聯系用戶瞭解其進行了何種操作，從而聯繫開發員進行程序上的改進。（如，對於第一種情況，在插入臨時表後，便加上 commit，而不要等用戶退出系統時自動回滾。）

其次是看有無請用戶提交或回退進行的改動，以釋放回滾段。或是通過alter system kill session 中止用戶的會話。

在請用戶提交或回退改動前，及中止用戶會話前，請評估回滾段已被推高的情況，決定是在系統空閒時進行，還是立即進行。以免由於在高峯期對回滾段的大量回縮影響數據庫的性能。

4)  改進措施：

開發員設計程序時，應在事務完成時，儘快commit；而不是在事務完成後，進行一系列其它的操作才commit或rollback。

對於8i的dataguard,應每1-2小時重啓其進程一次，或是通過設置參數 ENABLE_PROD_INSTANCE=false 來避免。

在通過dblink 進行分佈式查詢時，即使爲純select 語句，除非在開始事務前發出 SET TRANSACTION READ ONLY; 否則，在使用完畢，應執行 commit 語句。

5)  監控方法：

SELECT s.sid, s.serial#, t.start_time, t.xidusn,s.username,s.last_call_et

 FROM V$session s, V$transaction t, V$rollstat r

 WHERE s.saddr=t.ses_addr

 AND t.xidusn=r.usn

 AND ((r.curext=t.start_uext-1) OR

((r.curext=r.extents-1) AND t.start_uext=0));

若其中返回有記錄，則應予以關注。

佔據過多回滾段，不斷增長

1）現象

某回滾段尺寸超過optimal的值，同時，從 v$transaction 中查出爲由於一個會話，其used_ublk 不斷增大。

2）原因分析：

也許是一個大的批處理事務在進行，也有可能是由於開發員在程序中忘記寫commit語句。

3）應急方法：

若佔用大量回滾段，同時，未寫commit語句，導致其在推高回滾段後，又會自動進行回滾，或是，其佔據大量回滾段，同時，阻塞住大量用戶，管理員需要將其會話中止，導致其進行大量的回滾；或是，其佔據大量的回滾段，同時，管理員需要停止數據庫的運行，而其尚還有較長時間纔會運行至commit部分，直接停止數據庫需要進行大量的回滾。大量的回滾，將影響系統的性能，同時，影響數據庫的正常關閉。

對於這種情況，若檢查 v$fast_start_transactions中發現有多個進程在進行並行的回滾，且其UNDOBLOCKSDONE 增長得較快（每進程每秒鐘回滾100個block左右），則表明其可以利用並行回滾進行快速回滾，故可通過設置數據庫參數:

fast_start_parallel_rollback=high，以加快其回滾，然後，在回滾完成後，恢復該參數的設置爲 low。

但若在設置 fast_start_parallel_rollback = high後，數據庫掛起，或是smon及其parallel server佔據很高的 CPU，同時，檢查 V$fast_start_transactions 發現UNDOBLOCKSDONE 未增長，或是增長得十分緩慢，則表明該事務不適合於使用parallel rollback。此時，應考慮設置 fast_start_parallel_rollback=false來使其進行serial rollback,必要時，需要緊急關閉數據庫，並修改該項參數爲false再啓動數據庫。

在數據庫關閉前或是中止用戶的session 前，可從 v$rollstat 中查看 used_ublk 的情況，瞭解回滾的進展。若其值一直在減少，表明爲在回滾。

4）改進措施：

開發員應避免程序中出現大量記錄的更新後，漏寫commit語句的程序。

在Oracle 9i 及以上，開發員在編寫大的批處理程序時及進行分佈式事務時，可考慮在事務開始前，加入：

set transaction name ‘文本串’;

如:

set transaction name ‘批量更新用戶信息’;

這樣，數據庫管理員便可從 v$transaction 的 name 列中獲得該事務的相應信息。

管理員終止用戶會話前及關閉數據庫前，應先檢查會話對回滾段的佔用情況。若佔用較多的回滾段，則應考慮通知用戶提交相應的事務。必要時，獲得該會話曾經執行的sql，以便由開發員改進相關程序對事務的設計。

5）監控方法：

檢查 v$rollstat 中的 rssize，當其 rssize 超過一定的閥值時（可考慮設置閥值爲 optimal_size *2 ），進一步檢查 v$transaction 中的 used_ublk 值，若其達到一定的閥值(可考慮以optimal_size做爲閥值)，則產生警報。

 

四 RBS 調整方法

 

對於自動管理的回滾段表空間，需要調整的僅表空間的尺寸與undo_retention的值。在 10g中，甚至可以不設置 undo_retention參數，由其自動調整。

 

對於手工管理的回滾段表空間，在已使用local管理的表空間的情況下，需要調整的主要是表空間的尺寸，以及optimal 的值。

 

在使用dictionary 管理的表空間的情況下，需要調整的包括 extent 的尺寸及optimal的值。

修改回滾段的參數值爲：

alter rollback segment … storage (next xxx  optimal  xxx);

 

若對回滾段進行了增刪，需要相應地調整 rollback_segments 參數。

 

五 RBS調整的驗證

 

 

5.1回滾段參數的調整

若是由於optimal參數值設置不合理而進行的調整，可通過檢查一段時間的 v$rollstat中的 aveshrink, shrinks, aveactive來得以驗證。

檢查 optimal參數的語句：

select usn, aveshrink, shinks, aveactive

from v$rollstat;

將檢查結果與調整前進行對比。

在確定optimal值是否合理前，請先確保應用設計中不存在：佔據回滾段後，長期不釋放，導致回滾段增長的情況。

在此基礎上，若調整後shrinks降低，且aveshrink 較低，則表明optimal太小，應增大。

若shrinks較高，且aveshrink也高，則表明可能有大的事務，或長的事務在運行，應檢查應用的設計，也可考慮增大optimal的值，直至shrinks降低。

 

5.2回滾段個數的調整

若是由於回滾段爭用而進行的調整，可檢查調整後，一段時間內，回滾段塊的爭用情況來驗證其問題是否已緩解。

檢查回滾段爭用的語句：

以一段時間爲基礎，使用語句：

select class, count from v$waitstat where class in (‘UNDO HEADER’,’UNDO BLOCK’);

查出該時段內，undo header及undo block爭用的情況。

在同一段時間，查出，

select sum(value) from v$sysstat where name in (‘DB BLOCK GETS’,’CONSISTENT GETS’);

將上面查出的每一 class 的 count 數據值與上面查出的邏輯讀的數量值相比較。

Select undo_header/ (db_block_gets+consistent_gets) *100 From dual;

上面語句中 undo_header 值爲兩個時間點間 undo header 值的差值

db_block_gets 值爲兩個時間點 DB BLOCK GETS 的值的差值

consistent_gets 值爲兩個時間點 CONSISTENT GETS 的值的差值

若發現以上查詢的結果大於1%，則應考慮增加更多的回滾段。

若其查詢的結果已由 >1% 變爲 <1%，則表明調整已減少了回滾段的爭用。

同樣，若對undo block 的兩個時間點差值與當時邏輯讀的數量之比少於1%，則表明已減少了回滾段的爭用。

若發現以上查詢的結果值遠小於1%，且系統中有較多的回滾段，則可以考慮適當刪除原有的回滾段，同時保證其值小於1%。