结论
1,未提交事务前数据块的ITL会保存旧表的ITL条目信息，且其ITL条目的FLAG为U,表明快速清除2,快速清除的概念还不太理解，将于另一文章进行测试
3,已提交事务的数据块，且此数据块仍在缓冲池，其ITL条目不会发生变化
4,只要已提交事务的数据块不在缓冲池，重从磁盘读入缓冲池，其ITL条目才会发生变化，FLAG及LCK和SCN/CSC会发生变化
其中FLAG由空变成了C，且LCK由1变成0，SCN/CSC由空变成有值
而ITL的XID及UBA没有变化
5，ITL条目相关列含义请见下述第7
引发新问题
1,itl条目何时可以重用呢？标准是什么？
2,快速清除及延迟块清除的区别及概念各是什么？
2,快速清除及延迟块清除的区别及概念各是什么？
测试
1，数据库版本oracle 11.2.0.1
2,创建测试表并插入数据不提交，查看数据块
SQL> create table t_clean(a int);
Table created.
SQL> insert into t_clean values(1);
1 row created.
SQL> select object_name,object_id from user_objects where object_name='T_CLEAN';
OBJECT_NAME OBJECT_ID
-------------------------------------------------- ----------
T_CLEAN 74434
SQL> select DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID),DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID) from t_clean;
DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID) DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID)
------------------------------------ ------------------------------------
4 98974
SQL> alter session set tracefile_identifier='session2_uncommit';
Session altered.
SQL> alter system dump datafile 4 block 98974;
System altered.
数据块scn
scn: 0x0000.00b3db1a seq: 0x01 flg: 0x06 tail: 0xdb1a0601
之前旧表的对象信息
dbwrid: 0 obj: 74434 objn: 74434 tsn: 4 afn: 4 hint: f
obj-flags: object_ckpt_list
ckptq: [0xa9fa1158,0xacfdcae8] fileq: [0xda7259c0,0xacfdcaf8] objq: [0xb0fc8c88,0xb9f7b008]
Object id on Block? Y
seg/obj: 0x12223 csc: 0x00.b3d917 itc: 2 flg: E typ: 1 - DATA
ITL信息
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0040.021.0000062e 0x01400148.013c.04 --U- 484 fsc 0x0000.00b3db1a
0x02 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
可见flag标记为u,lck为484
3，提交，查看数据块
SQL> commit;
Commit complete.
数据块scn,较前已变化
scn: 0x0000.017aefd6 seq: 0x03 flg: 0x04 tail: 0xefd60603
较前，表对象只保存当前测试表t_clean信息
dbwrid: 0 obj: 74434 objn: 74434 tsn: 4 afn: 4 hint: f
obj-flags: object_ckpt_list
ckptq: [0xda728b60,0xda728b60] fileq: [0xda7259c0,0xda7259c0] objq: [0xd2817110,0xd2817110]
Object id on Block? Y
seg/obj: 0x122c2 csc: 0x00.17aefd6 itc: 2 flg: E typ: 1 - DATA
itl信息
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x009c.014.00000844 0x01c00094.01f2.25 ---- 1 fsc 0x0000.00000000
0x02 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
较前，flag有变化，成空，xid及uba和lck全变化了，变成当前测试表的事务信息
这个时侯按理说事务已提交，应清除ITL的条目信息，我想不清除的原因，一是考虑到性能，假如某个DML事务非常大，在提交时，可能有些数据块已经从缓冲池刷新到磁盘中，这块如果清除ITL条目，
势必要从磁盘重读这些数据块到缓冲池，加大IO压力
二者考虑到构建一致性查询，因为表的数据会由不同的DML会话或查询会话同时并发修改，你查询某个数据块信息时，可能其它会话正在进行DML变更，所以要从数据块的UBA中获取数据块的镜镜像，构建
刚开始运行查询SCN哪个时间点对应的数据块内容
4,在其它会话查询表，查看数据块
SQL> select * from t_clean;
A
----------
1
数据块SCN，较前未变化
scn: 0x0000.017aefd6 seq: 0x03 flg: 0x04 tail: 0xefd60603
较前，表对象没有变化
dbwrid: 0 obj: 74434 objn: 74434 tsn: 4 afn: 4 hint: f
obj-flags: object_ckpt_list
ckptq: [0xda728b60,0xda728b60] fileq: [0xda7259c0,0xda7259c0] objq: [0xd2817110,0xd2817110]
Object id on Block? Y
seg/obj: 0x122c2 csc: 0x00.17aefd6 itc: 2 flg: E typ: 1 - DATA
itl信息
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x009c.014.00000844 0x01c00094.01f2.25 ---- 1 fsc 0x0000.00000000
0x02 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
较前，没有变化
可见事务提交后运行SQL查询，数据块ITL的条目信息不会发生变化
5,产生一个事务不提交，查看数据块
SQL> update t_clean set a=38;
1 row updated.
数据块scn,较前未变化
scn: 0x0000.017aefd6 seq: 0x03 flg: 0x04 tail: 0xefd60603
较前，表对象没有变化
dbwrid: 0 obj: 74434 objn: 74434 tsn: 4 afn: 4 hint: f
obj-flags: object_ckpt_list
ckptq: [0xb3fc2428,0xb2fc8458] fileq: [0xda7259c0,0xda7259c0] objq: [0xd2817110,0xd2817110]
dbwrid: 0 obj: 74434 objn: 74434 tsn: 4 afn: 4 hint: f
ckptq: [NULL] fileq: [NULL] objq: [NULL]
Object id on Block? Y
seg/obj: 0x122c2 csc: 0x00.17aefd6 itc: 2 flg: E typ: 1 - DATA
itl信息
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x009c.014.00000844 0x01c00094.01f2.25 ---- 1 fsc 0x0000.00000000
0x02 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
可见ITL条目未变化
6，强制刷新缓冲池，查看数据块
数据块scn,较前有变化
scn: 0x0000.017c8536 seq: 0x01 flg: 0x04 tail: 0x85360601
较前，表对象无变化
dbwrid: 0 obj: 74434 objn: 74434 tsn: 4 afn: 4 hint: f
ckptq: [NULL] fileq: [NULL] objq: [NULL]
dbwrid: 0 obj: 74434 objn: 74434 tsn: 4 afn: 4 hint: f
ckptq: [NULL] fileq: [NULL] objq: [NULL]
seg/obj: 0x122c2 csc: 0x00.17c8525 itc: 2 flg: E typ: 1 - DATA
itl信息
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x009c.014.00000844 0x01c00094.01f2.25 C--- 0 scn 0x0000.017b726d
0x02 0x009b.016.0000085f 0x01c00086.01ec.20 ---- 1 fsc 0x0000.00000000
可见此时itl条目发生了变化，其中xid及uba没有变化，而flag由空变成c,lck标记已经由1变成了0，且scn/fsc也发生了变化，由空变成了某个非空的数值
同时上述新增的UPDATE事务分配在第2个ITL条目中
7,摘录下上述itl条目的相关列的含义
flag：事务标志位；
有几个值：
----- 表示事务是活动的，或块清除前提交事务
C---- 事务已提交并且清除了行锁定
-B--- this undo record contains the undo for this ITL entry
-U-- 事务已提交(scn已是最大值),但锁定未清除（快速清除）
---T 当块清除的scn被记录时,该事务仍是活动的，块上如果有已提交的事务
那么在clean out时，块会被清除，但块里面的事务不会被清除
lock:影响的记录数
scn/fsc:快速提交(fast commit)的scn或commit scn
个人简介
8年oracle从业经验，具备丰富的oracle技能，目前在国内北京某专业oracle服务公司从事高级技术顾问。
服务过的客户：
中国电信
中国移动
中国联通
中国电通
国家电网
四川达州商业银行
湖南老百姓大药房
山西省公安厅
中国邮政
北京302医院
河北廊坊新奥集团公司
项目经验:
中国电信3G项目AAA系统数据库部署及优化
中国联通4G数据库性能分析与优化
中国联通4G数据库性能分析与优化
中国联通CRM数据库性能优化
中国移动10086电商平台数据库部署及优化
湖南老百姓大药房ERR数据库sql优化项目
四川达州商业银行TCBS核心业务系统数据库模型设计和RAC部署及优化
四川达州商业银行TCBS核心业务系统后端批处理存储过程功能模块编写及优化
北京高铁信号监控系统RAC数据库部署及优化
河南宇通客车数据库性能优化
中国电信电商平台核心采购模块表模型设计及优化
中国邮政储蓄系统数据库性能优化及sql优化
北京302医院数据库迁移实施
河北廊坊新奥data guard部署及优化
山西公安厅身份证审计数据库系统故障评估
国家电网上海灾备项目4 node rac+adg
贵州移动crm及客服数据库性能优化项目
贵州移动crm及客服务数据库sql审核项目
深圳穆迪软件有限公司数据库性能优化项目
贵州移动crm及客服数据库性能优化项目
贵州移动crm及客服务数据库sql审核项目
深圳穆迪软件有限公司数据库性能优化项目
联系方式：
手机：18201115468
qq : 305076427
qq微博: wisdomone1
新浪微博：wisdomone9
qq群：275813900
itpub博客名称：wisdomone1 http://blog.itpub.net/9240380/
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/9240380/viewspace-1815367/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/9240380/viewspace-1815367/
803
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
