OCP知识点讲解 之 Undo回滚基础知识

一、什么是回滚段？

     1.  回滚段表空间，Oracle的官方叫法为“还原表空间”：

     还原表空间可以有多个，但在任意一个时刻，只能有一个是当前还原表空间（也可以称为活动还原表空间）。可以使用如下声明随时转换活动还原表空间：alter system set undo_tablespace='还原表空间';

     2.  回滚段：

     在Oracle中，段是逻辑结构中最高一层。表就是段，我们称为表段，索引是索引段，等等。回滚段也是段，我们可以把它看作表，一种由系统自己创建的表。

     系统默认创建11个回滚段，当然，如果还原表空间太小，默认回滚段数量也可能小于这个数字，可如下查看它们的名字：

sys@MYTWO> select * from v$rollname;

       USN NAME

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

         0 SYSTEM

        11 _SYSSMU11$

        12 _SYSSMU12$

   ：     ：

   ：     ：

        19 _SYSSMU19$

        20 _SYSSMU20$

已选择11行。

将活动还原表空间切换到UNDOTBS3上再看：

sys@MYTWO> select * from v$rollname;

       USN NAME

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

         0 SYSTEM

        23 _SYSSMU23$

        24 _SYSSMU24$

        25 _SYSSMU25$

     因为UNDOTBS3只有512K，所以系统默认创建的回滚段只有3个。

     在切换还原表空间后，新还原表空间中的回滚段状态变为ONLINE，原还原表空间回滚段状态变为OFFLINE。可以在 dba_rollback_segs.status列看到这个变化。而v$rollstat.status列则显示非OFFLINE的回滚段的状态。如果发现某回滚段的V$rollstat.status列值为PENDING OFFLINE，说明此回滚段在切换前的还原表空间中，尚有末决事务。待到末决事务提交后，状态自然会变为OFFLINE。

还原表空间中回滚段的数量是会根据情况调整的。当繁忙时，系统将会自动创建更多的回滚段，空闲时系统也会自动回收回滚段。我们也可以从告警日志中看到回滚段的创建与回收。

3、观察UNDOTBS3回滚段：

     UNDOTBS3是我们后面的练习需要频繁使用的还原表空间，它共有512K字节，128个块。下面我们通过DBA_UNDO_EXTENTS观察一下UNDOTBS3中回滚段的区占用情况：

     sys@MYTWO> select * from dba_undo_extents where segment_name='_SYSSMU25$';（省去部分列）

OWN SEGMENT_NAME  TABLESPACE_NAME EXTENT_ID FILE_ID BLOCK_ID BYTES BLOCKS 

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

SYS _SYSSMU25$           UNDOTBS3            0            14         82        61440       15

SYS _SYSSMU25$           UNDOTBS3           1            14         97        65536       16

     从以上结果可以看到_SYSSMU25$回滚段占用两个区，0号区从第82号块开始到96号块，共15个块。1号区从97号块开始到112号块，共16个块。为什么1号区比0号区多一个块？这是因为第81块被作为了回滚段头，回滚段头要保存重要信息：事务表，下面马上就要讲到了。从第82号块开始才可以保存回滚记录。我们也可以从DBA_EXTENTS中得到同样的结果。

     用上面的命令观察一下UNDOTBS3中的每一个回滚段，画一个简要的关于每个回滚段空间占用情况的图，要对这些回滚段的区、块的分部有印象，这样才能更好的明白下面章节的内容。

UNDOTBS3中的回滚段，每个各占两个区，这是因为通常的回滚段，最小就是两个区。

二、相关参数介绍：

     1.UNDO_MANAGEMENT：这个参数确定了Undo空间的管理方式。该参数是个静态参数（不可以动态修改）。如果设置为MANUAL，则使用rollback-managed undo (RMU)管理模式；如果设置为AUTO，则使用system-managed undo (SMU) 或者automatically managed undo (AMU)管理模式。在Oracle 9i数据库中，AUTO是缺省值。

     2.UNDO_TABLESPACE：只有使用system-managed undo (SMU) 或者automatically managed undo (AMU)管理模式的时候才需要设置这个参数。它指定了SMU或者AMU所使用的Undo表空间（该表空间必须是已经创建的表空间）。这个设置可以通过ALTER SYSTEM命令动态改变。如果忽略设置这个参数，那么数据库中的第一个Undo表空间就会被使用，如果没有可用的Undo表空间，SYSTEM 回滚段就会被使用。创建Undo Tablespace的命令如下：

     SQL> CREATE UNDO TABLESPACE UNDO_TEST  DATAFILE 'E:\TEST_TEST.ora' SIZE 10M 

AUTOEXTEND ON NEXT 2M MAXSIZE 700M;

     表空间已创建。将刚才创建的回滚表空间设为当前回滚表空间：

         scott@MYTWO> alter system set undo_tablespace='UNDO_TEST';

     在创建回滚段表空间时，注意区管理只能是自动，段管理方式只能是手动。

     3.UNDO_RETENTION：只有使用system-managed undo (SMU) 或者automatically managed undo (AMU)管理模式的时候才需要设置这个参数。它指定了在重做表空间中保持重做的时间，这个设置可以通过ALTER SYSTEM命令动态改变，缺省是3小时。保留重做主要有两个目的，一个是为冗长查询保留非活动的（inactive）的正在被使用的数据，另一个是支持显示当前数据前一种状态的查询，即Oracle 9i中“Flashback Query”新特性。例如，如果设置UNDO_RETENTION = 10800，那么Oracle将尽最大可能将重做保留3小时，即3小时的查询不会报ORA-01555错误。

     4.UNDO_SUPPRESS_ERROR：当使用SMU管理模式时，你不能运行RMU管理模式的管理命令，比如说把一个回滚段联机或者脱机等等。这个参数决定了当使用SMU管理模式时，如果发出RMU管理模式的管理命令是否产生错误信息。这个设置可以通过ALTER SYSTEM命令动态改变，缺省值是FALSE，即不禁止错误信息。

三、回滚段的使用：

1. 事务表：

回滚段中第一个块是回滚段头，它控制着回滚段的改变数据的写。在此回滚段头中，有一个事务表，每一个活动的事务，在各回滚段事务表中都要占一行。

当还原表空间空间足够时，Oracle倾向于让每个事务各占一个回滚段。否则，会让多个事务占用一个回滚段。每回滚段的第一个块，又被称为回滚段头，通常被事务表占用。事务表中保存本回滚段中的所有事务信息。默认的事务表的数量根据块大小而不同，此数值不可增加，它根据块大小的不同而不同。事务表中的每一行，又称为一个事务槽（slot）。

2.  如果回滚段中有多个事务，回滚段中的区会被多个事务占用，但任一回滚块中只能有一个事务。

     下面我们用例子来看看回滚段的使用情况：

步1：

scott@MYTWO> update t8 set c='AA' where id=1;

已更新 1 行。

观察事务情况：（只显示相关列）

sys@MYTWO> select xidusn,xidslot,xidsqn,ubafil,ubablk,ubasqn,ubarec,status,

start_time,start_scnb,start_scnw,start_uext,start_ubafil,start_ubablk,start_ubasqn,

used_ublk,used_urec,log_io,phy_io,cr_get,cr_change from v$transaction;

sys@MYTWO> select xidusn,xidslot,xidsqn,ubafil,ubablk,ubasqn,ubarec,status,start_time,start_sc

    XIDUSN    XIDSLOT     XIDSQN     UBAFIL     UBABLK     UBASQN     UBAREC STATUS

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

        23          1         52         14         20         21          7 ACTIVE

可以看到，事务1占用23号回滚段中的20块。

步2：

继续打开不同的会话，更新T8表：

update t8 set c='AA' where id=2;

update t8 set c='AA' where id=3;

update t8 set c='AA' where id=4;

     UNDOTBS3中的空间比较小，默认的回滚段只有3个，并且随事务增多，并不会再新增回滚段，我们现在已经有四个事务了，此时应该会有两个事务共用一个回滚段了，显示如下：

    XIDUSN    XIDSLOT     XIDSQN     UBAFIL     UBABLK     UBASQN     UBAREC STATUS

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

        24         14         12         14         55          4          2 ACTIVE

        25         11         13         14         88          4          3 ACTIVE

        25         14         13         14         89          4          3 ACTIVE

        23          1         52         14         20         21          7 ACTIVE

     回滚段_SYSSMU25$中有两个事务，一个事务占用88块，一个占用89块，它们都在0号区中。上面我们提到过了，一个回滚块中只能有一个事务，但区中可以有多个事务。

     25号回滚段中的两个事务的槽号分别是11和14，即，它们占用事务表的第11和14行，下面我们DUMP回滚段头看看：

Alter system dump undo header ‘_SYSSMU25$’;

  index  state    cflags  wrap#    uel         scn            dba   

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

   0x00    9    0x00  0x000d  0x0001  0x0000.0084616a  0x03800054 

： ： ： ： ： ：

   0x0b   10    0x80  0x000d  0x0000  0x0000.008463ce  0x03800058 

： ： ： ： ： ：

   0x0e   10    0x80  0x000d  0x0000  0x0000.008463ee  0x03800059 

： ： ： ： ： ：

   0x15    9    0x00  0x000c  0x0000  0x0000.00845ff9  0x03800054 

     State列为10，代表此行是一个活动事务，相应的，活动事务的cflags列一般为0x80。Wrap#列就是V$transcation中的XIDSQN列，这一列也被称为“序列号”，它表示此回滚槽被重用的次数。例子中值是0x000d，即，是第13次被重用。回滚段编号、回滚段槽号和序列号它们三个和起来唯一的代表一个活动的事务。通常它们被称为事务序列号――XID。从V$transcation中的列名，已经可以看起来这一点。

事务表中的UEL列表示事务的当前区，上例中两个事务都在0号区。

     SCN列是事务开始的SCN，在V$transcation中START_SCNB列也有事务开始的SCN号。

     DBA是事务所占数据文件编号、块编号。

©著作权归作者所有：来自51CTO博客作者叶绍琛的原创作品，如需转载，请注明出处，否则将追究法律责任

oracleDBAOCP数据存储