結論

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,快速清除及延遲塊清除的區別及概念各是什麼？

測試

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資料庫效能分析與最佳化

中國聯通CRM資料庫效能最佳化

中國移動10086電商平臺資料庫部署及最佳化

湖南老百姓大藥房ERR資料庫sql最佳化專案

四川達州商業銀行TCBS核心業務系統資料庫模型設計和RAC部署及最佳化

四川達州商業銀行TCBS核心業務系統後端批處理儲存過程功能模組編寫及最佳化

北京高鐵訊號監控系統RAC資料庫部署及最佳化

河南宇通客車資料庫效能最佳化

中國電信電商平臺核心採購模組表模型設計及最佳化

中國郵政儲蓄系統資料庫效能最佳化及sql最佳化

北京302醫院資料庫遷移實施

河北廊坊新奧data guard部署及最佳化

山西公安廳身份證審計資料庫系統故障評估

國家電網上海災備專案4 node rac+adg
貴州移動crm及客服資料庫效能最佳化專案
貴州移動crm及客服務資料庫sql稽核專案
深圳穆迪軟體有限公司資料庫效能最佳化專案

聯絡方式：

手機：18201115468

qq : 305076427

qq微博: wisdomone1

新浪微博：wisdomone9

qq群：275813900

itpub部落格名稱：wisdomone1 http://blog.itpub.net/9240380/

表使用的資料塊在事務未提交及提交且強制重新整理緩衝池的itl條目變化之系列一

結論

引發新問題

測試

個人簡介

相關文章