TS, work out the trace file name
--
select
spid
into
m_process
from
v$session se,
v$process pr
where
--
-- The first option is the 9.2 version for checking the SID
-- The second is a quick and dirty option for 8.1.7
-- provided SYS has made v$mystat visible (or this is the sys account)
--
-- se.sid = (select dbms_support.mysid from dual)
se.sid = (select sid from v$mystat where rownum = 1)
and pr.addr = se.paddr
;
dbms_output.new_line;
dbms_output.put_line('Trace file name includes: ' || m_process);
dbms_output.new_line;
exception
when others then
dbms_output.new_line;
dbms_output.put_line('Unspecified error.');
dbms_output.put_line('Check syntax.');
dbms_output.put_line('dump_table_block({table_name},[{owner}]');
dbms_output.new_line;
raise;
end;
.
/
show errors
drop public synonym dump_table_block;
create public synonym dump_table_block for dump_table_block;
grant execute on dump_table_block to public;
3.1.4 转储表t1的第一个数据块
?
?
execute dump_table_block('t1')
?
3.1.5 我们会看到：Trace file name includes: 4292这样的字样，到oracle 的trace目录找到这个跟踪文件，我的电脑入戏所示：
E:\app\Administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_4292.trc, 双击用记事本打开，可以看到如下内容：
?
Block header dump: 0x00416169
Object id on Block? Y
seg/obj: 0x12e7a csc: 0x00.326fb7 itc: 2 flg: O typ: 1 - DATA
fsl: 0 fnx: 0x0 ver: 0x01
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0002.005.000005f5 0x00c00b18.0121.0d --U- 3 fsc 0x0000.00326fb8
0x02 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
bdba: 0x00416169
data_block_dump,data header at 0x1e256e5c
===============
tsiz: 0x1fa0
hsiz: 0x18
pbl: 0x1e256e5c
76543210
flag=--------
ntab=1
nrow=3
frre=-1
fsbo=0x18
fseo=0x1f85
avsp=0x1f6d
tosp=0x1f6d
0xe:pti[0] nrow=3 offs=0
0x12:pri[0] offs=0x1f97
0x14:pri[1] offs=0x1f8e
0x16:pri[2] offs=0x1f85
block_row_dump:
tab 0, row 0, @0x1f97
tl: 9 fb: --H-FL-- lb: 0x1 cc: 2
col 0: [ 2] c1 02
col 1: [ 2] c1 02
tab 0, row 1, @0x1f8e
tl: 9 fb: --H-FL-- lb: 0x1 cc: 2
col 0: [ 2] c1 03
col 1: [ 2] c1 03
tab 0, row 2, @0x1f85
tl: 9 fb: --H-FL-- lb: 0x1 cc: 2
col 0: [ 2] c1 04
col 1: [ 2] c1 04
end_of_block_dump
End dump data blocks tsn: 0 file#: 1 minblk 90473 maxblk 90473
Start dump data blocks tsn: 0 file#:1 minblk 90473 maxblk 90473
3.2 事务列表
这一节，简要介绍一下转储出来的数据块中事务槽的信息，上面数据块的事务槽如下：
?
?
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0002.005.000005f5 0x00c00b18.0121.0d --U- 3 fsc 0x0000.00326fb8
0x02 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
Itl：列表的数组索引，该值未真正存储在数据块中，它由执行转储的代码生成。该值用在行的锁字节(lb:)中以显示哪个事务锁住了该行。
?
Xid: 最近更改该块的事务的事务id，格式是undo段.undo槽.undo序列号.
Uba: undo记录地址，是事务为该块最近生成的undo记录所在块的序列号。
Flag: 标识事务当前状态
---- 活动（当Xid中每一个字段为0时表示，无事务）
--U- 上界提交（表明这个事务已经提交，只是还没有清除一些标记）
C---： 已提交并清除（所有标记已清除，比如相关的锁字节都被置0了）
Lck：块中由该事务锁住的行数
Scn/Fsc：表示提交SCN或者快速提交SCN。
在我们这个例子中，占用了一个事务槽，flag是--U-表明，事务已经快速提交，但是Lck为3，表明还没有清除锁标记，快速提交的scn是326fb8. Uba指向了最后一条插入的undo记录，这条undo记录会指向上一条插入的undo记录，上一条undo记录指向了上上条插入的undo记录。这样，如果事务失败，或者人工回滚，沿着这条undo链重做就好了。在oracle10g之后，一个数据块的事务槽被硬性规定为169个。（8KB大小的情况下）
3.3 并发操作
我们需要开启4个事务，如下所示：
?
session1: update t1 set n1=101 where id = 1;
session2: update t1 set n1=102 where id = 2;
commit;alter system checkpoint;
My session: set transaction read