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%。