日期:2014-05-16 浏览次数:20565 次
undo表空间有个脾气,就是新事务优先,长查询滞后!
情况有两:查询在前、查询在后
查询在后:
if [查scn>提交scn]
if [查sid = 提交 sid]
返回新值;
else
返回旧值;
end if;
查询在前:
第一个if条件就不满足,直接跑去构造CR块。
如果在整个交易的过程中,运行了很长时间,但突然在交易尾巴出错了,则只是单独rollback这一个,而不是整个交易全部回滚掉。
工业环境,undo表空间布局的原则是:以空间换时间!也就是undo表空间当尽量大。保持自动扩展,且要注意maxsize。
oracle数据块头部有个事务槽(ITL)。当多个事务槽同时修改数据块,而且,此时,pctfree(数据块空闲空间的比例)不足10%,则会出现ITL争用。这种现象容易发生在update和delete身上。因为,insert时,oracle会优先分散地插入其他空闲块。如:
看一下表a有多少个事务槽:
sys@ORCL> select ini_trans,max_trans from dba_tables 2 where owner='HR' and table_name='A'; INI_TRANS MAX_TRANS ---------- ---------- 1 255
缺省下是1个,最多可以有255个
看一下表a用了多少个数据块:
hr@ORCL> select dbms_rowid.rowid_relative_fno(rowid), 2 dbms_rowid.rowid_block_number(rowid), 3 id 4 from a; DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID) DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID) ID ------------------------------------ ------------------------------------ ---------- 4 460 1 4 460 2 4 460 3 4 460 1
可知:表a在4号文件上,第460个数据块。
可以把id=2,数据块为460的4号文件dump出来,看一下块头的ITL:
alter system dump datafile 4 block 460 sys@ORCL> select spid from v$process where addr in (select paddr from v$session 2 where sid in (select sid from v$mystat where rownum=1)); SPID ------------ 10696
ITL部分内容摘入如下:
Block header dump: 0x010001cc Object id on Block? Y seg/obj: 0xce9d csc: 0x00.15a47b itc: 2 flg: E typ: 1 - DATA brn: 0 bdba: 0x10001c9 ver: 0x01 opc: 0 inc: 0 exflg: 0 Itl Xid Uba Flag Lck Scn/Fsc 0x01 0x0003.025.000001fa 0x01c00566.0293.1e ---- 2 fsc 0x0000.00000000 0x02 0x0004.020.00000151 0x0080068f.0144.11 C--- 0 scn 0x0000.000f71fa
注释:
Itl:事务槽编号
Xid:指向事务表
Uba:指向具体的回滚块
Flag:是否已提交
Lck:锁定的标志
Scn/Fsc:提交的时间点
&nbs