本文主要介绍下undo段头的基本信息,以及在undo段出现问题时的处理步骤
在数据库启动过程中,smon进程会扫描undo段头的信息,来确定是否进行回滚,因此undo段头的信息很重要。
SQL> create table t3 as select * from scott.t1;
Table created.
SQL> select count(*) from t3;
COUNT(*)
----------
30717
SQL> delete from t3 where rownum<10000;
9999 rows deleted.
SQL> select XIDUSN,XIDSLOT,XIDSQN,UBAFIL,UBABLK,START_SCNB from v$transaction;
XIDUSN XIDSLOT XIDSQN UBAFIL UBABLK START_SCNB
---------- ---------- ---------- ---------- ---------- ----------
7 42 342 2 1588 3935351937
XIDUSN:事务使用的回滚段
XIDSLOT:事务使用的回滚段事务槽
XIDSQN:该回滚段事务槽被覆盖的次数
UBAFIL:事务使用回滚段所在的文件号
UBABLK:事务使用的回滚段的块
START_SCNB:事务开始时的SCN
SQL> desc dba_rollback_Segs
Name Null? Type
----------------------------------------- -------- ----------------------------
SEGMENT_NAME NOT NULL VARCHAR2(30)
OWNER VARCHAR2(6)
TABLESPACE_NAME NOT NULL VARCHAR2(30)
SEGMENT_ID NOT NULL NUMBER
FILE_ID NOT NULL NUMBER
BLOCK_ID NOT NULL NUMBER
INITIAL_EXTENT NUMBER
NEXT_EXTENT NUMBER
MIN_EXTENTS NOT NULL NUMBER
MAX_EXTENTS NOT NULL NUMBER
PCT_INCREASE NUMBER
STATUS VARCHAR2(16)
INSTANCE_NUM VARCHAR2(40)
RELATIVE_FNO NOT NULL NUMBER
SQL> select SEGMENT_NAME,TABLESPACE_NAME from dba_rollback_Segs where SEGMENT_ID=7;
SEGMENT_NAME TABLESPACE_NAME
------------------------------ ------------------------------
_SYSSMU7$ UNDOTBS1
SQL> select file_id,file_name from dba_data_files;
FILE_ID FILE_NAME
---------- ----------------------------------------------------------------------
5 /u01/app/oracle/oradata/orcl/example01.dbf
4 /u01/app/oracle/oradata/orcl/users01.dbf
3 /u01/app/oracle/oradata/orcl/sysaux01.dbf
2 /u01/app/oracle/oradata/orcl/undotbs01.dbf
1 /u01/app/oracle/oradata/orcl/system01.dbf
6 /u01/app/oracle/oradata/orcl/test01.dbf
7 /u01/app/oracle/oradata/orcl/test02.dbf
使用dump undo header也可以实现对这些信息的抓取:
alter system dump undo header '_SYSSMU7$';
TRN CTL:: seq: 0x013e chd: 0x0020 ctl: 0x0029 inc: 0x00000000 nfb: 0x0000
mgc: 0x8201 xts: 0x0068 flg: 0x0001 opt: 2147483646 (0x7ffffffe)
uba: 0x0080039e.013a.19 scn: 0x0100.ea8f17fe
chd:在该回滚段中最先执行的事务槽号
ctl:在给回滚段中最近执行的事务槽号
scn:最近被覆盖的事务槽对应的SCN
index state cflags wrap# uel scn dba parent-xid nub stmt_num cmt
------------------------------------------------------------------------------------------------
0x00 9 0x00 0x0156 0x000f 0x0100.ea8f181c 0x0080039c 0x0000.000.00000000 0x00000001 0x00000000 1411486674
0x01 9 0x00 0x0156 0x0005 0x0100.ea8f1859 0x0080039c 0x0000.000.00000000 0x00000001 0x00000000 1411486674
0x02 9 0x00 0x0156 0x002d 0x0100.ea8f183b 0x0080039c 0x0000.000.00000000 0x00000001 0x00000000 1411486674
0x03 9 0x00 0x0156 0x000e 0x0100.ea8f1c0e 0x0080039d 0x0000.000.00000000 0x00000001 0x00000000 1411489074
0x04 9 0x00 0x0156 0x0009 0x0100.ea8f1a78 0x0080039d 0x0000.000.00000000 0x00000001 0x00000000 1411488046
0x05 9 0x00 0x0156 0x000d 0x0100.ea8f19f5 0x0080039c 0x0000.000.00000000 0x00000001 0x00000000 1411487874
0x06 9 0x00 0x0156 0x0001 0x0100.ea8f184f 0x0080039c 0x0000.000.00000000 0x00000001 0x00000000 1411486674
0x07 9 0x00 0x0156 0x0004 0x0100.ea8f1a65 0x0080039d 0x0000.000.00000000 0x00000001 0x00000000 1411488045
0x08 9 0x00 0x0156 0x0019 0x0100.ea8f1c22 0x0080039d 0x0000.000.00000000 0x00000001 0x00000000 1411489074
0x09 9 0x00 0x0156 0x000b 0x0100.ea8f1bdc 0x0080039d 0x0000.000.00000000 0x00000001 0x00000000 1411489074
0x0a 9 0x00 0x0156 0x001a 0x0100.ea8f2104 0x0080039e 0x0000.000.00000000 0x00000001 0x00000000 1411492244
0x0b 9 0x00 0x0156 0x000c 0x0100.ea8f1be6 0x0080039d 0x0000.000.00000000 0x00000001 0x00000000 1411489074
0x0c 9 0x00 0x0156 0x0011 0x0100.ea8f1bf0 0x0080039d 0x0000.000.00000000 0x00000001 0x00000000 1411489074
0x0d 9 0x00 0x0156 0x0007 0x0100.ea8f1a37 0x0080039d 0x0000.000.00000000 0x00000002 0x00000000 1411488033
0x0e 9 0x00 0x0156 0x0008 0x0100.ea8f1c18 0x0080039d 0x0000.000.00000000 0x00000001 0x00000000 1411489074
0x0f 9 0x00 0x013f 0x002c 0x0100.ea8f1827 0x0080039c 0x0000.000.00000000 0x00000001 0x00000000 1411486674
0x10 9 0x00 0x0156 0x0016 0x0100.ea8f1c5e 0x0080039d 0x0000.000.00000000 0x00000001 0x00000000 1411489074
0x11 9 0x00 0x0156 0x002f 0x0100.ea8f1bfa 0x0080039d 0x0000.000.00000000 0x00000001 0x00000000 1411489074
0x12 9 0x00 0x0156 0x0014 0x0100.ea8f1fb6 0x0080039d 0x0000.000.00000000 0x00000001 0x00000000 1411491473
0x29 9 0x00 0x0156 0xffff 0x0100.ea90b123 0x00000000 0x0000.000.00000000 0x00000000 0x00000000 1415290555
0x2a 10 0x80 0x0156 0x0004 0x0100.ea90b481 0x00800634 0x0000.000.00000000 0x00000125 0x00000000 0
0x2b 9 0x00 0x0156 0x002e 0x0100.ea8f2231 0x0080039e 0x0000.000.00000000 0x00000001 0x00000000 1411492569
0x2c 9 0x00 0x0155 0x0002 0x0100.ea8f1831 0x0080039c 0x0000.000.00000000 0x00000001 0x00000000 1411486674
index 事务槽号
state 事务槽的状态 若为10则表示该事务槽有一个活动的事务,活动事务对应的cflags一般为0x80,
wrap# 表示该事务槽被重用的次数
scn: 表示事务开始时的SCN
dba:表示最近使用的undo文件和数据块
如果数据库异常,那么数据库在启动时smon会扫描所有online的回滚段头中的事务槽,以判断是否有事务未提交。如果有,进行回滚。
在异常情况下,smon进程回滚事务时会出错,进而导致数据库无法打开。
ORACLE Instance syncard (pid=9) - Error 600 encountered while
recovering transaction (10,10) on object 92826.
在alert警告日志信息中非常明显的指出在undo回滚事务的时候报错,此时,数据库已经mount,可以使用10513屏蔽smon回滚事务,但是会产生后遗症,会产生很多的一致性读,从而影响数据库的性能。
alter system set event '10513 trace name context forever,level 2' scope=spfile;
但是在数据库由于回滚段异常而无法启动时,可能需要设置10015事件和隐含参数_smu_debug_mode=1来跟踪损块的回滚段详细信息。
alter system set event '10015 trace name context forever,level 10' scope=spfile;
也可以通过操作系统命令从system数据文件中获取undo回滚段的名字
starings system01.dbf | grep _SYSSMU|cut -d $ -f l | sort -u
在数据库启动过程中,smon进程会扫描undo段头的信息,来确定是否进行回滚,因此undo段头的信息很重要。
SQL> create table t3 as select * from scott.t1;
Table created.
SQL> select count(*) from t3;
COUNT(*)
----------
30717
SQL> delete from t3 where rownum<10000;
9999 rows deleted.
SQL> select XIDUSN,XIDSLOT,XIDSQN,UBAFIL,UBABLK,START_SCNB from v$transaction;
XIDUSN XIDSLOT XIDSQN UBAFIL UBABLK START_SCNB
---------- ---------- ---------- ---------- ---------- ----------
7 42 342 2 1588 3935351937
XIDUSN:事务使用的回滚段
XIDSLOT:事务使用的回滚段事务槽
XIDSQN:该回滚段事务槽被覆盖的次数
UBAFIL:事务使用回滚段所在的文件号
UBABLK:事务使用的回滚段的块
START_SCNB:事务开始时的SCN
SQL> desc dba_rollback_Segs
Name Null? Type
----------------------------------------- -------- ----------------------------
SEGMENT_NAME NOT NULL VARCHAR2(30)
OWNER VARCHAR2(6)
TABLESPACE_NAME NOT NULL VARCHAR2(30)
SEGMENT_ID NOT NULL NUMBER
FILE_ID NOT NULL NUMBER
BLOCK_ID NOT NULL NUMBER
INITIAL_EXTENT NUMBER
NEXT_EXTENT NUMBER
MIN_EXTENTS NOT NULL NUMBER
MAX_EXTENTS NOT NULL NUMBER
PCT_INCREASE NUMBER
STATUS VARCHAR2(16)
INSTANCE_NUM VARCHAR2(40)
RELATIVE_FNO NOT NULL NUMBER
SQL> select SEGMENT_NAME,TABLESPACE_NAME from dba_rollback_Segs where SEGMENT_ID=7;
SEGMENT_NAME TABLESPACE_NAME
------------------------------ ------------------------------
_SYSSMU7$ UNDOTBS1
SQL> select file_id,file_name from dba_data_files;
FILE_ID FILE_NAME
---------- ----------------------------------------------------------------------
5 /u01/app/oracle/oradata/orcl/example01.dbf
4 /u01/app/oracle/oradata/orcl/users01.dbf
3 /u01/app/oracle/oradata/orcl/sysaux01.dbf
2 /u01/app/oracle/oradata/orcl/undotbs01.dbf
1 /u01/app/oracle/oradata/orcl/system01.dbf
6 /u01/app/oracle/oradata/orcl/test01.dbf
7 /u01/app/oracle/oradata/orcl/test02.dbf
使用dump undo header也可以实现对这些信息的抓取:
alter system dump undo header '_SYSSMU7$';
TRN CTL:: seq: 0x013e chd: 0x0020 ctl: 0x0029 inc: 0x00000000 nfb: 0x0000
mgc: 0x8201 xts: 0x0068 flg: 0x0001 opt: 2147483646 (0x7ffffffe)
uba: 0x0080039e.013a.19 scn: 0x0100.ea8f17fe
chd:在该回滚段中最先执行的事务槽号
ctl:在给回滚段中最近执行的事务槽号
scn:最近被覆盖的事务槽对应的SCN
index state cflags wrap# uel scn dba parent-xid nub stmt_num cmt
------------------------------------------------------------------------------------------------
0x00 9 0x00 0x0156 0x000f 0x0100.ea8f181c 0x0080039c 0x0000.000.00000000 0x00000001 0x00000000 1411486674
0x01 9 0x00 0x0156 0x0005 0x0100.ea8f1859 0x0080039c 0x0000.000.00000000 0x00000001 0x00000000 1411486674
0x02 9 0x00 0x0156 0x002d 0x0100.ea8f183b 0x0080039c 0x0000.000.00000000 0x00000001 0x00000000 1411486674
0x03 9 0x00 0x0156 0x000e 0x0100.ea8f1c0e 0x0080039d 0x0000.000.00000000 0x00000001 0x00000000 1411489074
0x04 9 0x00 0x0156 0x0009 0x0100.ea8f1a78 0x0080039d 0x0000.000.00000000 0x00000001 0x00000000 1411488046
0x05 9 0x00 0x0156 0x000d 0x0100.ea8f19f5 0x0080039c 0x0000.000.00000000 0x00000001 0x00000000 1411487874
0x06 9 0x00 0x0156 0x0001 0x0100.ea8f184f 0x0080039c 0x0000.000.00000000 0x00000001 0x00000000 1411486674
0x07 9 0x00 0x0156 0x0004 0x0100.ea8f1a65 0x0080039d 0x0000.000.00000000 0x00000001 0x00000000 1411488045
0x08 9 0x00 0x0156 0x0019 0x0100.ea8f1c22 0x0080039d 0x0000.000.00000000 0x00000001 0x00000000 1411489074
0x09 9 0x00 0x0156 0x000b 0x0100.ea8f1bdc 0x0080039d 0x0000.000.00000000 0x00000001 0x00000000 1411489074
0x0a 9 0x00 0x0156 0x001a 0x0100.ea8f2104 0x0080039e 0x0000.000.00000000 0x00000001 0x00000000 1411492244
0x0b 9 0x00 0x0156 0x000c 0x0100.ea8f1be6 0x0080039d 0x0000.000.00000000 0x00000001 0x00000000 1411489074
0x0c 9 0x00 0x0156 0x0011 0x0100.ea8f1bf0 0x0080039d 0x0000.000.00000000 0x00000001 0x00000000 1411489074
0x0d 9 0x00 0x0156 0x0007 0x0100.ea8f1a37 0x0080039d 0x0000.000.00000000 0x00000002 0x00000000 1411488033
0x0e 9 0x00 0x0156 0x0008 0x0100.ea8f1c18 0x0080039d 0x0000.000.00000000 0x00000001 0x00000000 1411489074
0x0f 9 0x00 0x013f 0x002c 0x0100.ea8f1827 0x0080039c 0x0000.000.00000000 0x00000001 0x00000000 1411486674
0x10 9 0x00 0x0156 0x0016 0x0100.ea8f1c5e 0x0080039d 0x0000.000.00000000 0x00000001 0x00000000 1411489074
0x11 9 0x00 0x0156 0x002f 0x0100.ea8f1bfa 0x0080039d 0x0000.000.00000000 0x00000001 0x00000000 1411489074
0x12 9 0x00 0x0156 0x0014 0x0100.ea8f1fb6 0x0080039d 0x0000.000.00000000 0x00000001 0x00000000 1411491473
0x29 9 0x00 0x0156 0xffff 0x0100.ea90b123 0x00000000 0x0000.000.00000000 0x00000000 0x00000000 1415290555
0x2a 10 0x80 0x0156 0x0004 0x0100.ea90b481 0x00800634 0x0000.000.00000000 0x00000125 0x00000000 0
0x2b 9 0x00 0x0156 0x002e 0x0100.ea8f2231 0x0080039e 0x0000.000.00000000 0x00000001 0x00000000 1411492569
0x2c 9 0x00 0x0155 0x0002 0x0100.ea8f1831 0x0080039c 0x0000.000.00000000 0x00000001 0x00000000 1411486674
index 事务槽号
state 事务槽的状态 若为10则表示该事务槽有一个活动的事务,活动事务对应的cflags一般为0x80,
wrap# 表示该事务槽被重用的次数
scn: 表示事务开始时的SCN
dba:表示最近使用的undo文件和数据块
如果数据库异常,那么数据库在启动时smon会扫描所有online的回滚段头中的事务槽,以判断是否有事务未提交。如果有,进行回滚。
在异常情况下,smon进程回滚事务时会出错,进而导致数据库无法打开。
ORACLE Instance syncard (pid=9) - Error 600 encountered while
recovering transaction (10,10) on object 92826.
在alert警告日志信息中非常明显的指出在undo回滚事务的时候报错,此时,数据库已经mount,可以使用10513屏蔽smon回滚事务,但是会产生后遗症,会产生很多的一致性读,从而影响数据库的性能。
alter system set event '10513 trace name context forever,level 2' scope=spfile;
但是在数据库由于回滚段异常而无法启动时,可能需要设置10015事件和隐含参数_smu_debug_mode=1来跟踪损块的回滚段详细信息。
alter system set event '10015 trace name context forever,level 10' scope=spfile;
也可以通过操作系统命令从system数据文件中获取undo回滚段的名字
starings system01.dbf | grep _SYSSMU|cut -d $ -f l | sort -u