oracle undo段头的深度分析

发布时间:2020-08-11 14:44:22 作者:波仔strong
来源:ITPUB博客 阅读:169
产生一个事物
update set num=00 where id=1

查看事物信息,可以发现事物用的是3号段
select xid,xidusn,xidslot,xidsqn,ubablk,ubafil from v$transaction;

XID                 XIDUSN    XIDSLOT       XIDSQN     UBABLK     UBAFIL
---------------- ---------- ---------- ---------- ---------- ----------
01001E0007050000      3        30            1287       1566          3

回滚段的段头块
select * from v$rollname;
   USN NAME
---------- ------------------------------
     0 SYSTEM
     1 _SYSSMU1_3780397527$
     2 _SYSSMU2_2232571081$
     3 _SYSSMU3_2097677531$
     4 _SYSSMU4_1152005954$
     5 _SYSSMU5_1527469038$
     6 _SYSSMU6_2443381498$
     7 _SYSSMU7_3286610060$
     8 _SYSSMU8_2012382730$
     9 _SYSSMU9_1424341975$
    10 _SYSSMU10_3550978943$

查看3号回滚段的段头id 和块号
select header_block,header_file from dba_segments where segment_name='_SYSSMU3_2097677531$';
HEADER_BLOCK HEADER_FILE
------------ -----------
     160           3

转储回滚段头 查看当前会话的进程编号
alter system dump undo header '_SYSSMU3_2097677531$';

select spid from v$process where addr in (select paddr from v$session where sid=(select sid from v$mystat where rownum=1));

SPID
------------------------
38380
spid//server process ID 38380

查看trace的名称
select * from v$diag_info where name='Default Trace File';
INST_ID NAME                                 VALUE
---------- ---------------------------------------------------------------- --------------------------------------------------------------------------------
     1 Default Trace File                            /u01/app/oracle/diag/rdbms/hyyk/hyyk/trace/hyyk_ora_38380.trc


查看trace的文件,接下来一块一块分析
less /u01/app/oracle/diag/rdbms/hyyk/hyyk/trace/hyyk_ora_38380.trc
第一部分
********************************************************************************
Undo Segment:  _SYSSMU3_2097677531$ (3)
********************************************************************************
  Extent Control Header
  -----------------------------------------------------------------
  Extent Header:: spare1: 0      spare2: 0      #extents: 4      #blocks: 271   
                  last map  0x00000000  #maps: 0      offset: 4080  
      Highwater::  0x00c00da8  ext#: 3      blk#: 40     ext size: 128   
  #blocks in seg. hdr's freelists: 0     
  #blocks below: 0     
  mapblk  0x00000000  offset: 3     
                   Unlocked
     Map Header:: next  0x00000000  #extents: 4    obj#: 0      flag: 0x40000000

#extents: 4  表示3号UNDO段有4个区
#blocks: 271   表示3号UNDO回滚段两个区中有271个UNDO BLOCK可用。(如下下面的sql语句 8+8+128+128=272 为什么不是272个UNDO BLOCK块呢,因为去掉一个UNDO段头块)
ext#: 3      表示这个事务发生在第2个区(从0开始)
blk#: 30       表示这个事务发生在第2个区的第30个块上。
ext size: 128     表示第2个区上有128个UNDO BLOCK可用


通过dba_extents视图查出一共有4个区,共271个块
select extent_id,file_id,block_id,blocks,bytes from dba_extents where segment_name='_SYSSMU3_2097677531$';
EXTENT_ID    FILE_ID    BLOCK_ID     BLOCKS     BYTES
---------- ---------- ---------- ---------- ----------
     0                3         160                      8              65536
     1                3         344                      8               65536
     2                3        1024                  128              1048576
     3                3        3456                   128              1048576

通过dba_segments视图查出UNDO段头块,即3号文件的160号块是UNDO段头块  如上面的语句的第一行结果  0          3         160          8              65536
select header_file,header_block from dba_segments where segment_name='_SYSSMU3_2097677531$';

HEADER_FILE HEADER_BLOCK
----------- ------------
      3         160


第二部分
Extent Map
  -----------------------------------------------------------------
   0x00c00081  length: 7     
   0x00c00088  length: 8     
   0x00c00280  length: 128   
   0x00c00600  length: 128   
3号UNDO回滚段的区地图一共有4个区:
   第一个区对应的是3号文件161号块、162号块、163号块、164号块、165号块、166号块、167号块,共7个UNDO BLOCK
   第二个区对应的是3号文件344号块、10号块、11号块、12号块、13号块、14号块、15号块,16号块,共8个UNDO BLOCK
   第三个区对应的是3号文件1024号块...
   第四个区对应的是3号文件3456号块...

第三部分
Retention Table
  -----------------------------------------------------------
Extent Number:0  Commit Time: 1524377480
Extent Number:1  Commit Time: 1524377480
Extent Number:2  Commit Time: 1524384037
Extent Number:3  Commit Time: 1524384037
区的提交时间戳,是从1970年1月1号零晨开始的(以秒为单位记录)

第四部分
  TRN CTL:: seq: 0x0197 chd: 0x0000 ctl: 0x0013 inc: 0x00000000 nfb: 0x0000
            mgc: 0xb000 xts: 0x0068 flg: 0x0001 opt: 2147483646 (0x7ffffffe)
            uba: 0x00c00da8.0197.2f scn: 0x0000.00201605

seq: 0x0197  表示此事务修改前的值所在的UNDOBLOCK块被覆盖了407次,与下面的uba:  uba: 0x00c00da8.0197.2f中的0197对应。
chd:0x0000  表示发生一个新的事务,此时会在下面的TRNTBL::(事务表)的index=0x0000槽中放入新事务信息,即事务表的链头或叫入口。
ctl: 0x0013  表示事务表的链尾(实际上大家可以去TRN TBL::看index= 0x0013(0x013),它对应的SCN=0x0000.00201b8b是本事务表中最大的SCN,即此事务槽最后才会被覆盖)

nfb: 0x0000  表示UNDO块在空闲池的空闲块数,0x0000表示池中没有空闲UNDO块了,即FREE BLOCKPOOL::没空闲的块了。

flg: 0x0001  表示该块的用途,1=KTUUNDO HEADER(2=KTU UNDO BLOCK等等)

uba: 0x00c00da8.0197.2f  表示新事务的第一条UNDO记录(由三部分组成undo块的地址、UNDO块被重用的次数、在UNDO块的第几条记录)
    undo块的地址:        0x00c00da8  即3号文件的160号块
    UNDO块被重用的次数:  0197       即UNDO块被覆盖了407次
    在UNDO块的第几条记录  2f         即在UNDO块的第36条
0x0000.00201605 表示3号UNDO段头块中最小的提交的SCN。实际上这个SCN就是事务表中最小的SCN所对应的事务槽上的SCN

第5部分
FREE BLOCK POOL::
    uba: 0x00000000.0197.2e ext: 0x3  spc: 0xc46   
    uba: 0x00000000.0197.02 ext: 0x3  spc: 0x1f06  
    uba: 0x00000000.0197.0b ext: 0x3  spc: 0x15c0  
    uba: 0x00000000.0091.38 ext: 0x10 spc: 0x546   
    uba: 0x00000000.0000.00 ext: 0x0  spc: 0x0    
UNDO块的空闲池,当事务做了提交会把此事务所在的UNDO块加入空闲池中。
uba:  由三部分组成undo块的地址、UNDO块被重用的次数、在UNDO块的第几条记录,当undo块的地址为0说明UNDO块不是空闲的,即0x00000000
ext:   UNDO块是在哪个区(extent)

spc:    UNDO块中多少空闲空间,单位字节


第六部分  
TRN TBL::
  index  state cflags  wrap#    uel             scn                      dba            parent-xid                    nub                 stmt_num      cmt
  -------------------------------------------------------------------------------------------------------------------------------------------------
   0x00    9    0x00  0x05ba  0x0008  0x0000.00201611  0x00c00da5  0x0000.000.00000000  0x00000001   0x00000000  1524399079
   0x01    9    0x00  0x05ba  0x000a  0x0000.00201b14  0x00c00da8  0x0000.000.00000000  0x00000001   0x00000000  1524399864
   0x02    9    0x00  0x05b8  0x0001  0x0000.00201af3  0x00c00da8  0x0000.000.00000000  0x00000001   0x00000000  1524399845
   0x03    9    0x00  0x05b9  0x0018  0x0000.002016dc  0x00c00da5  0x0000.000.00000000  0x00000001   0x00000000  1524399201
   0x04    9    0x00  0x05bb  0x0009  0x0000.002018a8  0x00c00da8  0x0000.000.00000000  0x00000001   0x00000000  1524399442
   0x05    9    0x00  0x05ba  0x001e  0x0000.00201832  0x00c00da8  0x0000.000.00000000  0x00000001   0x00000000  1524399382
   0x06    9    0x00  0x05bc  0x0016  0x0000.00201879  0x00c00da8  0x0000.000.00000000  0x00000001   0x00000000  1524399409
   0x07    9    0x00  0x05ba  0x001c  0x0000.00201964  0x00c00da8  0x0000.000.00000000  0x00000001   0x00000000  1524399570
   0x08    9    0x00  0x05ba  0x0011  0x0000.0020161f  0x00c00da5  0x0000.000.00000000  0x00000001   0x00000000  1524399079
   0x09    9    0x00  0x05bb  0x000b  0x0000.002018e0  0x00c00da8  0x0000.000.00000000  0x00000001   0x00000000  1524399479
   0x0a    9    0x00  0x05bb  0x0013  0x0000.00201b39  0x00c00da8  0x0000.000.00000000  0x00000001   0x00000000  1524399875
   0x0b    9    0x00  0x05ba  0x001b  0x0000.00201914  0x00c00da8  0x0000.000.00000000  0x00000001   0x00000000  1524399510
   0x0c    9    0x00  0x05ba  0x001f  0x0000.0020177e  0x00c00da6  0x0000.000.00000000  0x00000001   0x00000000  1524399305
   0x0d    9    0x00  0x05bb  0x0006  0x0000.00201864  0x00c00da8  0x0000.000.00000000  0x00000001   0x00000000  1524399387
   0x0e    9    0x00  0x05ba  0x0003  0x0000.002016b7  0x00c00da5  0x0000.000.00000000  0x00000001   0x00000000  1524399173
   0x0f   10    0x80  0x05bc  0x0003  0x0000.00201b98  0x00c00da8  0x0000.000.00000000  0x00000001   0x00000000  0
   0x10    9    0x00  0x05bc  0x0017  0x0000.00201731  0x00c00da6  0x0000.000.00000000  0x00000001   0x00000000  1524399262
   0x11    9    0x00  0x05b9  0x0021  0x0000.00201623  0x00c00da5  0x0000.000.00000000  0x00000001   0x00000000  1524399079
   0x12    9    0x00  0x05bb  0x0015  0x0000.00201a68  0x00c00da8  0x0000.000.00000000  0x00000001   0x00000000  1524399753
   0x13    9    0x00  0x05bb  0xffff  0x0000.00201b8b  0x00c00da8  0x0000.000.00000000  0x00000001   0x00000000  1524399936
   0x14    9    0x00  0x05b9  0x000e  0x0000.0020169c  0x00c00da5  0x0000.000.00000000  0x00000001   0x00000000  1524399143
   0x15    9    0x00  0x05ba  0x0002  0x0000.00201a9d  0x00c00da8  0x0000.000.00000000  0x00000001   0x00000000  1524399783
   0x16    9    0x00  0x05bb  0x0004  0x0000.0020188f  0x00c00da8  0x0000.000.00000000  0x00000001   0x00000000  1524399419
   0x17    9    0x00  0x05ba  0x000c  0x0000.00201750  0x00c00da6  0x0000.000.00000000  0x00000001   0x00000000  1524399266
   0x18    9    0x00  0x05b9  0x0010  0x0000.0020170e  0x00c00da6  0x0000.000.00000000  0x00000001   0x00000000  1524399235
   0x19    9    0x00  0x05ba  0x0012  0x0000.00201a39  0x00c00da8  0x0000.000.00000000  0x00000001   0x00000000  1524399722
   0x1a    9    0x00  0x05b9  0x0005  0x0000.0020182b  0x00c00da8  0x0000.000.00000000  0x00000002   0x00000000  1524399382
   0x1b    9    0x00  0x05ba  0x0007  0x0000.00201936  0x00c00da8  0x0000.000.00000000  0x00000001   0x00000000  1524399540
   0x1c    9    0x00  0x05ba  0x001d  0x0000.0020198a  0x00c00da8  0x0000.000.00000000  0x00000001   0x00000000  1524399600
   0x1d    9    0x00  0x05ba  0x0019  0x0000.00201a01  0x00c00da8  0x0000.000.00000000  0x00000001   0x00000000  1524399683
   0x1e    9    0x00  0x05bb  0x000d  0x0000.00201849  0x00c00da8  0x0000.000.00000000  0x00000001   0x00000000  1524399382
   0x1f    9    0x00  0x05bb  0x0020  0x0000.002017b2  0x00c00da6  0x0000.000.00000000  0x00000001   0x00000000  1524399327
   0x20    9    0x00  0x05ba  0x001a  0x0000.002017f8  0x00c00da6  0x0000.000.00000000  0x00000001   0x00000000  1524399378
   0x21    9    0x00  0x05b9  0x0014  0x0000.0020162f  0x00c00da5  0x0000.000.00000000  0x00000001   0x00000000  1524399081

TRN TBL::(事务表)是UNDO段头块最重要的。我们一一来解释每个字段的意思:
index 表示事务表中槽号,只是一个序列而已,从0x00开始到0x21结束,11g的版本有34个槽。
state 表示事务状态:9代表事务不活动,10代表事务正在活动,从这里我们看出16进制第0x17号槽上的事务正在活动。大家有没有发现,我们在发生事务前,Oracle会找事务控制列表中的chd=0x0017,说白了就是重从index=0x17的槽,存放当前最新的事务:
  注:下面的事务控制,是我在发生事务前(即做update gyj_test set name='GGGGG' where id=1;前所DUMP的事务控制)
   TRN CTL:: seq: 0x000d chd: 0x0017 ctl: 0x000b inc: 0x00000000 nfb:0x0001
           mgc: 0xb000 xts: 0x0068 flg: 0x0001 opt: 2147483646 (0x7ffffffe)
           uba: 0x0280000a.000d.2b scn: 0x0000.0028a26a
cflags 表示正在使用穿上事务槽的事务的状态:0x00表示非活动事务、0x80表示活动事务、0x10表示死事务、0x90表示被回滚的死事务
     平时我们看到的最多就是0x00表示非活动事务、0x80表示活动事务,后面的很少发生。
wrap# 表示事务表上的事务槽被重用的次数,它是XID的一部分。0x001d表示此时事务槽被重用了29次。
uel   表示当前活动事务所在事务槽的下一个事务槽的指针(即如果又发生一个新的事务,此时就会用到UEL指向的事务槽上的index)。
oracle undo段头的深度分析

scn   表示务事启动、提交、回滚的SCN.
dba   表示uba:第一部分的undo块地址,这个DBA是(rollback)回滚的起始点,也就是说是记录事务修改的最后一条记录所在UNDO块的地址。
nub   表示当前事务所用到的UNDO块的个数。
cmt   表示最接近当前的提交时间戳,是从1970年1月1号零晨开始的(以秒为单位记录)。0表示事务正在活动。







推荐阅读:
  1. Oracle 等待事件之 buffer busy waits
  2. Oracle undo表空间文件丢失的情况有哪些

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

oracle undo 段头

上一篇:群集架构批量分发管理方案介绍及案例说明(SSHKEY)

下一篇:如何解决织梦dedecms5.7生成首页提示404错误的问题

相关阅读

您好,登录后才能下订单哦!

密码登录
登录注册
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》