Oracle undo探索

IT那活儿 2022-03-26

1291

点击上方“IT那活儿”，关注后了解更多内容，不管IT什么活儿，干就完了！！！

概述

undo段又叫rollback段，undo的前身就是rollback，查询undo段。

大家都知道的，修改数据后，没有提交的数据写到硬盘上，修改前的数据放在undo segment上。虽然未提交的数据已经写入硬盘，但另外的会话查询时是从undo segment上读取数据，在事务没有结束前，undo里的数据不会清除。

若事务太大导致undo空间不够，此时这个事务就会失败。

实验前准备

先查出表内容：

SQL> select * from t2;ID NA---------- --1 A2 a3 b4 c

修改一行记录：

SQL> update t2 set NAME='ab' where id=4;1 row updated.

从逻辑层面获取块数据

查出该表的行数据所在的逻辑文件编号和块编号：

SQL> select dbms_rowid.rowid_relative_fno(rowid) fno,dbms_rowid.rowid_block_number(rowid) bn1 from t2;FNO BN1---------- ----------41    151994041    151994041    151994041    1519940

sys用户操作，查询dump文件路径，是用户进程，所以看user_dump_dest：

SQL> show parameter dumpNAME TYPE VALUE------------------------------------ ----------- ------------------------------background_core_dump string      partialbackground_dump_dest string      /u01/app/oracle/diag/rdbms/ocststdb/ocststdb/tracecore_dump_dest string      /u01/app/oracle/diag/rdbms/ocststdb/ocststdb/cdumpmax_dump_file_size string      unlimitedshadow_core_dump string      partialuser_dump_dest string      /u01/app/oracle/diag/rdbms/ocststdb/ocststdb/trace

生成逻辑编号是41，块编号是1519940的dump文件：

SQL> alter system dump datafile 41 block 1519940;System altered.

查询该session产生的dump文件，或者在没有其他session的前提下，直接看最新的dump文件：

SQL> select distinct sid from v$mystat;SID----------581SQL> select paddr from v$session where sid=581;PADDR----------------0000000253FCC010SQL> select spid from v$process where addr='0000000253FCC010';SPID------------------------8212

找到dump文件，下载到本地：

[oracle@ocsdbtest trace]$ pwd/u01/app/oracle/diag/rdbms/ocststdb/ocststdb/trace[oracle@ocsdbtest trace]$ ls *8212.trcocststdb_ora_8212.trc

用UE打开，主要最后面的：

.................Start dump data blocks tsn: 42 file#:41 minblk 1519940 maxblk 1519940.................Itl Xid Uba Flag Lck Scn/Fsc0x01 0x0003.017.002c083b 0x00c004f8.e3f0.06  C--- 0  scn 0x0e73.5c418bf90x02 0x0009.010.002c7c61 0x00c0032e.e670.23  ---- 1  fsc 0x0000.00000000bdba: 0x0a573144data_block_dump,data header at 0x7f0ea1953a64===============tsiz: 0x1f98hsiz: 0x1apbl: 0x7f0ea1953a6476543210flag=--------ntab=1nrow=4frre=-1fsbo=0x1afseo=0x1f6favsp=0x1f5atosp=0x1f5a0xe:pti[0] nrow=4  offs=00x12:pri[0] offs=0x1f900x14:pri[1] offs=0x1f880x16:pri[2] offs=0x1f800x18:pri[3] offs=0x1f6fblock_row_dump:tab 0, row 0, @0x1f90tl: 8 fb: --H-FL-- lb: 0x0 cc: 2col  0: [ 2] c1 02col  1: [ 1] 41tab 0, row 1, @0x1f88tl: 8 fb: --H-FL-- lb: 0x0 cc: 2col  0: [ 2] c1 03col  1: [ 1] 61tab 0, row 2, @0x1f80tl: 8 fb: --H-FL-- lb: 0x0 cc: 2col  0: [ 2] c1 04col  1: [ 1] 62tab 0, row 3, @0x1f6ftl: 9 fb: --H-FL-- lb: 0x2 cc: 2col  0: [ 2] c1 05col  1: [ 2] 61 62end_of_block_dumpEnd dump data blocks tsn: 42 file#: 41 minblk 1519940 maxblk 1519940

从物理磁盘层面获取块数据

再次dump绝对文件的内容：

SQL> alter system dump datafile '/oradata/ocststdb/TSSXCPMIS01.dbf' block 1519940;System altered.

由于在同一个session下dump的，trc文件也是一样的，再次下载，UE打开：

...............Start dump data block from file /oradata/ocststdb/TSSXCPMIS01.dbf minblk 1519940 maxblk 1519940.............Itl Xid Uba Flag Lck Scn/Fsc0x01   0x0003.017.002c083b 0x00c00b68.6795.07  C--- 0 scn 0x0e73.5c418bf90x02   0x0009.010.002c7c61 0x00c00b68.6795.0b ---- 1 fsc 0x0000.00000000bdba: 0x0a573144data_block_dump,data header at 0x7f0ea1953a64===============tsiz: 0x1f98hsiz: 0x1apbl: 0x7f0ea1953a6476543210flag=--------ntab=1nrow=4frre=-1fsbo=0x1afseo=0x1f6favsp=0x1f5atosp=0x1f5a0xe:pti[0] nrow=4  offs=00x12:pri[0] offs=0x1f900x14:pri[1] offs=0x1f880x16:pri[2] offs=0x1f800x18:pri[3] offs=0x1f6fblock_row_dump:tab 0, row 0, @0x1f90tl: 8 fb: --H-FL-- lb: 0x0 cc: 2col  0: [ 2] c1 02col  1: [ 1] 41tab 0, row 1, @0x1f88tl: 8 fb: --H-FL-- lb: 0x0 cc: 2col  0: [ 2] c1 03col  1: [ 1] 61tab 0, row 2, @0x1f80tl: 8 fb: --H-FL-- lb: 0x0 cc: 2col  0: [ 2] c1 04col  1: [ 1] 62tab 0, row 3, @0x1f6ftl: 9 fb: --H-FL-- lb: 0x2 cc: 2col  0: [ 2] c1 05col  1: [ 2] 61 62end_of_block_dumpEnd dump data block from file /oradata/ocststdb/TSSXCPMIS01.dbf minblk 1519940 maxblk 1519940

这一行意思开始dump文件“/oradata/ocststdb/TSSXCPMIS01.dbf”，块“1519940”：

Start dump data block from file /oradata/ocststdb/TSSXCPMIS01.dbf minblk 1519940 maxblk 1519940

有4行数据：

nrow=4

改行数据有锁，0x2，没锁的是0x0：

tl: 9 fb: --H-FL-- lb: 0x2 cc: 2

最后一行内容是2列：

col  0: [ 2] c1 05col  1: [ 2] 61 62

从undo段获取块数据

截取地址（Uba：0x00c00b68.6795.07），0x和第一个“.”之间内容，00c00b68，这是个16进制的地址，通过这个地址获取文件编号和块编号。

先转换成10进制数：

SQL> select to_number('00c00b68','xxxxxxxxxx') from dual;TO_NUMBER('00C00B68','XXXXXXXXXX')----------------------------------12585832

获取文件编号：

SQL> select dbms_utility.data_block_address_file(12585832) from dual;DBMS_UTILITY.DATA_BLOCK_ADDRESS_FILE(12585832)----------------------------------------------3

获取块编号：

SQL> select dbms_utility.data_block_address_block(12585832) from dual;DBMS_UTILITY.DATA_BLOCK_ADDRESS_BLOCK(12585832)-----------------------------------------------2920

查看当前undo使用的那个表空间：

SQL> show parameter undo_tablespaceNAME TYPE VALUE------------------------------------ ----------- ------------------------------undo_tablespace string UNDOTBS1

查询UNDOTBS的文件编号：

SQL> select file_id from dba_data_files where tablespace_name='UNDOTBS1';FILE_ID----------3

由此确认通过Uba获取的文件编号的正确。

将这个文件dump出来：

SQL> alter system dump datafile 3 block 2920;System altered.

地址（Uba：0x00c00b68.6795.07）最后一位是07地址，打开dump文件找到地址为07的，看到它的值是63，即“c”，也就是原数据存放到undo表空间去了：

*-----------------------------* Rec #0x7 slt: 0x1a objn: 176942(0x0002b32e) objd: 176942  tblspc: 42(0x0000002a)* Layer: 11 (Row) opc: 1   rci 0x00Undo type: Regular undo    Begin trans Last buffer split:  NoTemp Object:  NoTablespace Undo: Nordba: 0x00000000Ext idx: 0flg2: 0*-----------------------------uba: 0x00c00b68.6795.06 ctl max scn: 0x0e73.5c4ac77d prv tx scn: 0x0e73.5c4ac783txn start scn: scn: 0x0e73.5c4a9dce logon user: 130prev brb: 12585831 prev bcl: 0KDO undo record:KTB Redoop: 0x03 ver: 0x01compat bit: 4 (post-11) padding: 1op: ZKDO Op code: URP row dependencies Disabledxtype: XA flags: 0x00000000 bdba: 0x0a573144 hdba: 0x0a573142itli: 2  ispac: 0  maxfr: 4858tabn: 0 slot: 3(0x3) flag: 0x2c lock: 0 ckix: 0ncol: 2 nnew: 1 size: -1col  1: [ 1] 63

查出“a”和“b”的ASSIC值：

SQL> select ascii('a') from dual;ASCII('A')----------97SQL> select ascii('b') from dual;ASCII('B')----------98

将97和98转换成16进制，则是61和62，正式最后一行的内容：

SQL> select to_char(97,'XX') from dual;TO_---61SQL> select to_char(98,'XX') from dual;TO_---62

各层面获取的数据对比

可以看到第一个dump文件，逻辑文件编号出来的文件，和第二个dump文件，绝对文件编号出来的文件，在最后一行的内容都是一致的：

col  1: [ 2] 61 62

即从内存中读取出来的内容和从硬盘读取出来的内容是一样的，未commit就已经写到磁盘上了。

没提交的数据是有标记的，是有锁的，其他session是查不到的。其他session查询该数据，读到这个块时发现有锁，“tl: 9 fb: --H-FL-- lb: 0x2 cc: 2”，可以看到Lck是“1”，表示有1条数据锁定。

总结

通过dump数据得到验证，表的逻辑数据和磁盘数据都保存的是新数据，undo段里则保存原始数据。

本文作者：胡伟

本文来源：IT那活儿（上海新炬王翦团队）

oracle

文章转载自IT那活儿，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

Oracle undo探索

点击上方“IT那活儿”，关注后了解更多内容，不管IT什么活儿，干就完了！！！

本文作者：胡 伟

本文来源：IT那活儿（上海新炬王翦团队）

评论

本文作者：胡伟