[20120228]IOT索引組織表相關資訊的學習.txt
[20120228]IOT索引組織表相關資訊的學習.txt
IOT 是一種特殊的索引結構,使用它能夠解決特定場合的應用問題,但是在許多應用中很少使用,更多的是使用堆表。
我僅僅在生產系統中對3個表使用,我偏向使用靜態以及"只讀"的小表。
如果IOT表存在除主鍵外的第2索引,如果使用它存在物理猜"physical guess",我以前的理解一直是第2索引記錄了主鍵資訊,
透過這個資訊就可以定位IOT表中對應的資料,一直沒有很好的測試與理解。我最近也看了兩個連結,介紹了IOT的內容:
今天測試看看,看了以前的理解存在很大的偏差!
1.測試環境:
2.轉儲IOT塊的資訊:
僅僅佔用1個塊。HEADER_BLOCK=954,根節點=955.
SQL> alter system dump datafile 4 block 955 ;
Block header dump: 0x010003bb
Object id on Block? Y
seg/obj: 0x145fd csc: 0x00.63a965 itc: 2 flg: E typ: 2 - INDEX
brn: 0 bdba: 0x10003b8 ver: 0x01 opc: 0
inc: 0 exflg: 0
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
0x02 0x0002.020.00000c9f 0x00c00b1b.066e.02 --U- 9 fsc 0x0000.0063a9ce
Leaf block dump
===============
header address 182924431972=0x2a97255264
kdxcolev 0
KDXCOLEV Flags = - - -
kdxcolok 0
kdxcoopc 0x90: pcode=0: iot flags=I-- is converted=Y
kdxconco 1
kdxcosdc 0
kdxconro 9
kdxcofbo 54=0x36
kdxcofeo 7897=0x1ed9
kdxcoavs 7843
kdxlespl 0
kdxlende 0
kdxlenxt 0=0x0
kdxleprv 0=0x0
kdxledsz 0
kdxlebksz 8032
row#0[8021] flag: K-----, lock: 2, len=11
col 0; len 1; (1): 31
tl: 7 fb: --H-FL-- lb: 0x0 cc: 2
col 0: [ 1] 61
col 1: [ 1] 61
row#1[8009] flag: K-----, lock: 2, len=12
col 0; len 2; (2): 32 32
tl: 7 fb: --H-FL-- lb: 0x0 cc: 2
col 0: [ 1] 62
col 1: [ 1] 61
row#2[7996] flag: K-----, lock: 2, len=13
col 0; len 3; (3): 33 33 33
tl: 7 fb: --H-FL-- lb: 0x0 cc: 2
col 0: [ 1] 63
col 1: [ 1] 61
row#3[7982] flag: K-----, lock: 2, len=14
col 0; len 4; (4): 34 34 34 34
tl: 7 fb: --H-FL-- lb: 0x0 cc: 2
col 0: [ 1] 64
col 1: [ 1] 61
row#4[7967] flag: K-----, lock: 2, len=15
col 0; len 5; (5): 35 35 35 35 35
tl: 7 fb: --H-FL-- lb: 0x0 cc: 2
col 0: [ 1] 65
col 1: [ 1] 61
row#5[7951] flag: K-----, lock: 2, len=16
col 0; len 6; (6): 36 36 36 36 36 36
tl: 7 fb: --H-FL-- lb: 0x0 cc: 2
col 0: [ 1] 66
col 1: [ 1] 61
row#6[7934] flag: K-----, lock: 2, len=17
col 0; len 7; (7): 37 37 37 37 37 37 37
tl: 7 fb: --H-FL-- lb: 0x0 cc: 2
col 0: [ 1] 67
col 1: [ 1] 61
row#7[7916] flag: K-----, lock: 2, len=18
col 0; len 8; (8): 38 38 38 38 38 38 38 38
tl: 7 fb: --H-FL-- lb: 0x0 cc: 2
col 0: [ 1] 68
col 1: [ 1] 61
row#8[7897] flag: K-----, lock: 2, len=19
col 0; len 9; (9): 39 39 39 39 39 39 39 39 39
tl: 7 fb: --H-FL-- lb: 0x0 cc: 2
col 0: [ 1] 69
col 1: [ 1] 61
----- end of leaf block dump -----
End dump data blocks tsn: 4 file#: 4 minblk 955 maxblk 955
--可以發現沒有記錄rowid資訊,
tl: 7 fb: --H-FL-- lb: 0x0 cc: 2
col 0: [ 1] 69
col 1: [ 1] 61
--記錄了主鍵外的資訊。
3.轉儲第2索引的資訊:
Block header dump: 0x010003c3
Object id on Block? Y
seg/obj: 0x145fe csc: 0x00.63a9bd itc: 2 flg: E typ: 2 - INDEX
brn: 0 bdba: 0x10003c0 ver: 0x01 opc: 0
inc: 0 exflg: 0
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
0x02 0x0002.020.00000c9f 0x00c00b1b.066e.03 --U- 9 fsc 0x0000.0063a9ce
Leaf block dump
===============
header address 182924431972=0x2a97255264
kdxcolev 0
KDXCOLEV Flags = - - -
kdxcolok 0
kdxcoopc 0x90: pcode=0: iot flags=I-- is converted=Y
kdxconco 2
kdxcosdc 0
kdxconro 9
kdxcofbo 54=0x36
kdxcofeo 7870=0x1ebe
kdxcoavs 7816
kdxlespl 0
kdxlende 0
kdxlenxt 0=0x0
kdxleprv 0=0x0
kdxledsz 0
kdxlebksz 8032
row#0[8018] flag: K-----, lock: 2, len=14
col 0; len 1; (1): 61
col 1; len 1; (1): 31
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bb
row#1[8003] flag: K-----, lock: 2, len=15
col 0; len 1; (1): 62
col 1; len 2; (2): 32 32
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bb
row#2[7987] flag: K-----, lock: 2, len=16
col 0; len 1; (1): 63
col 1; len 3; (3): 33 33 33
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bb
row#3[7970] flag: K-----, lock: 2, len=17
col 0; len 1; (1): 64
col 1; len 4; (4): 34 34 34 34
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bb
row#4[7952] flag: K-----, lock: 2, len=18
col 0; len 1; (1): 65
col 1; len 5; (5): 35 35 35 35 35
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bb
row#5[7933] flag: K-----, lock: 2, len=19
col 0; len 1; (1): 66
col 1; len 6; (6): 36 36 36 36 36 36
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bb
row#6[7913] flag: K-----, lock: 2, len=20
col 0; len 1; (1): 67
col 1; len 7; (7): 37 37 37 37 37 37 37
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bb
row#7[7892] flag: K-----, lock: 2, len=21
col 0; len 1; (1): 68
col 1; len 8; (8): 38 38 38 38 38 38 38 38
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bb
row#8[7870] flag: K-----, lock: 2, len=22
col 0; len 1; (1): 69
col 1; len 9; (9): 39 39 39 39 39 39 39 39 39
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bb
----- end of leaf block dump -----
End dump data blocks tsn: 4 file#: 4 minblk 963 maxblk 963
-- 可以發現第2索引的記錄資訊如下:
col0 =》對應的是欄位b
col1 =》對應的是欄位a,也就是主鍵。
而後面還存在如下資訊:
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bb
-- 可以發現記錄的資訊都是一樣的,col0: [ 4] 01 00 03 bb,應該跟上面的轉儲對上:
SQL> ALTER SESSION SET EVENTS 'immediate trace name treedump level 83453';
----- begin tree dump
leaf: 0x10003bb 16778171 (0: nrow: 9 rrow: 9)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
----- end tree dump
也就是T_IOT_PK的根節點。
可以得到一些推測:
1.如果透過第2索引查詢主鍵,是不需要查詢IOT表的,因為第2索引裡面已經存在。
2.如果透過第2索引查詢資料資訊,IOT先透過索引節點中記錄的資料塊資訊查詢(這個就應該就是物理猜),如果不行可以透過主鍵也就是對應例子的col1鍵值,來探查IOT索引組織表。
4.做一些測試:
--可以發現並沒有查詢IOT表,而是直接訪問索引。
--可以發現先查詢i_t_iot_b索引,然後在查詢T_IOT索引組織表。
5.再來了解一下邏輯rowid。
--可以發現一些特點,前面都是一樣的都是*BAEAA7s,而且主鍵鍵值的長度越長與rowid的長度也越長。再dump(rowid)
--結合dump(rowid),dump(rowid,16)的轉出資訊.很容易推匯出rowid的資訊。以下的例子來說明:
Typ=208 Len=17: 2,4,1,0,3,bb,9,39,39,39,39,39,39,39,39,39,fe *BAEAA7sJOTk5OTk5OTk5/g 999999999 i
1.開頭的2,4,以及結尾fe實在不好猜測,不過好像是固定不變的。
2.中間的1,0,3,bb正好對應的就是IOT的根節點,也就是對應資料IOT的資料塊。
3.9,39,39,39,39,39,39,39,39,39中9表示主鍵長度,39,39,39,39,39,39,39,39,39就是主鍵的資訊。
6.關於物理猜:
--vc長度加大到1000,原來的IOT已經無法存在這些資訊,可以發現IOT表發生了1次索引分裂。
--可以發現邏輯rowid記錄的塊資訊發現了變化。從1,0,3,bb變成了1,0,3,bd和1,0,3,be.
--再次轉儲第2索引的資訊。
SQL> alter system dump datafile 4 block 963 ;
Block header dump: 0x010003c3
Object id on Block? Y
seg/obj: 0x145fe csc: 0x00.63a9bd itc: 2 flg: E typ: 2 - INDEX
brn: 0 bdba: 0x10003c0 ver: 0x01 opc: 0
inc: 0 exflg: 0
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
0x02 0x0002.020.00000c9f 0x00c00b1b.066e.03 --U- 9 fsc 0x0000.0063a9ce
Leaf block dump
===============
header address 182925401700=0x2a97341e64
kdxcolev 0
KDXCOLEV Flags = - - -
kdxcolok 0
kdxcoopc 0x90: pcode=0: iot flags=I-- is converted=Y
kdxconco 2
kdxcosdc 0
kdxconro 9
kdxcofbo 54=0x36
kdxcofeo 7870=0x1ebe
kdxcoavs 7816
kdxlespl 0
kdxlende 0
kdxlenxt 0=0x0
kdxleprv 0=0x0
kdxledsz 0
kdxlebksz 8032
row#0[8018] flag: K-----, lock: 2, len=14
col 0; len 1; (1): 61
col 1; len 1; (1): 31
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bb
row#1[8003] flag: K-----, lock: 2, len=15
col 0; len 1; (1): 62
col 1; len 2; (2): 32 32
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bb
row#2[7987] flag: K-----, lock: 2, len=16
col 0; len 1; (1): 63
col 1; len 3; (3): 33 33 33
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bb
row#3[7970] flag: K-----, lock: 2, len=17
col 0; len 1; (1): 64
col 1; len 4; (4): 34 34 34 34
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bb
row#4[7952] flag: K-----, lock: 2, len=18
col 0; len 1; (1): 65
col 1; len 5; (5): 35 35 35 35 35
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bb
row#5[7933] flag: K-----, lock: 2, len=19
col 0; len 1; (1): 66
col 1; len 6; (6): 36 36 36 36 36 36
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bb
row#6[7913] flag: K-----, lock: 2, len=20
col 0; len 1; (1): 67
col 1; len 7; (7): 37 37 37 37 37 37 37
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bb
row#7[7892] flag: K-----, lock: 2, len=21
col 0; len 1; (1): 68
col 1; len 8; (8): 38 38 38 38 38 38 38 38
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bb
row#8[7870] flag: K-----, lock: 2, len=22
col 0; len 1; (1): 69
col 1; len 9; (9): 39 39 39 39 39 39 39 39 39
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bb
----- end of leaf block dump -----
End dump data blocks tsn: 4 file#: 4 minblk 963 maxblk 963
--可以發現如下資訊沒有發生變化,依舊是col 0: [ 4] 01 00 03 bb.
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bb
這樣如果我們執行select substr(vc,1,20) from t_iot from where b='a';透過第2索引記錄的資料塊查詢應該找不到vc的值(可以理解物理猜失敗),
必須在透過主鍵來查詢,這樣邏輯讀就會比原來加1.
7.現在我們重建第2索引看看。
I_T_IOT_B僅僅佔用1個塊。HEADER_BLOCK=970,根節點=971.
SQL> alter system dump datafile 4 block 971 ;
Block header dump: 0x010003cb
Object id on Block? Y
seg/obj: 0x145ff csc: 0x00.63b560 itc: 2 flg: E typ: 2 - INDEX
brn: 0 bdba: 0x10003c8 ver: 0x01 opc: 0
inc: 0 exflg: 0
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
0x02 0xffff.000.00000000 0x00000000.0000.00 C--- 0 scn 0x0000.0063b560
Leaf block dump
===============
header address 182925401700=0x2a97341e64
kdxcolev 0
KDXCOLEV Flags = - - -
kdxcolok 0
kdxcoopc 0x90: pcode=0: iot flags=I-- is converted=Y
kdxconco 2
kdxcosdc 0
kdxconro 9
kdxcofbo 54=0x36
kdxcofeo 7870=0x1ebe
kdxcoavs 7816
kdxlespl 0
kdxlende 0
kdxlenxt 0=0x0
kdxleprv 0=0x0
kdxledsz 0
kdxlebksz 8032
row#0[8018] flag: K-----, lock: 0, len=14
col 0; len 1; (1): 61
col 1; len 1; (1): 31
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bd
row#1[8003] flag: K-----, lock: 0, len=15
col 0; len 1; (1): 62
col 1; len 2; (2): 32 32
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bd
row#2[7987] flag: K-----, lock: 0, len=16
col 0; len 1; (1): 63
col 1; len 3; (3): 33 33 33
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bd
row#3[7970] flag: K-----, lock: 0, len=17
col 0; len 1; (1): 64
col 1; len 4; (4): 34 34 34 34
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bd
row#4[7952] flag: K-----, lock: 0, len=18
col 0; len 1; (1): 65
col 1; len 5; (5): 35 35 35 35 35
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bd
row#5[7933] flag: K-----, lock: 0, len=19
col 0; len 1; (1): 66
col 1; len 6; (6): 36 36 36 36 36 36
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bd
row#6[7913] flag: K-----, lock: 0, len=20
col 0; len 1; (1): 67
col 1; len 7; (7): 37 37 37 37 37 37 37
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 be
row#7[7892] flag: K-----, lock: 0, len=21
col 0; len 1; (1): 68
col 1; len 8; (8): 38 38 38 38 38 38 38 38
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 be
row#8[7870] flag: K-----, lock: 0, len=22
col 0; len 1; (1): 69
col 1; len 9; (9): 39 39 39 39 39 39 39 39 39
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 be
----- end of leaf block dump -----
End dump data blocks tsn: 4 file#: 4 minblk 971 maxblk 971
--可以發現索引中的資料塊資訊指向了正確的位置。
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 be
--可以發現邏輯讀又變為3個.物理猜測是正確的。
8.總結:
1.IOT的第2索引包含主鍵資訊以及對應資訊的塊資訊。
2.當IOT索引分裂時,第2索引中記錄的塊資訊不會發生變化。這樣在使用第2索引探查IOT表時,物理猜就會失敗。
3.如果物理猜失敗很多,會導致邏輯讀增加,可以透過重建第2索引來解決這個問題。
IOT 是一種特殊的索引結構,使用它能夠解決特定場合的應用問題,但是在許多應用中很少使用,更多的是使用堆表。
我僅僅在生產系統中對3個表使用,我偏向使用靜態以及"只讀"的小表。
如果IOT表存在除主鍵外的第2索引,如果使用它存在物理猜"physical guess",我以前的理解一直是第2索引記錄了主鍵資訊,
透過這個資訊就可以定位IOT表中對應的資料,一直沒有很好的測試與理解。我最近也看了兩個連結,介紹了IOT的內容:
今天測試看看,看了以前的理解存在很大的偏差!
1.測試環境:
SQL> select * from v$version ;
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
PL/SQL Release 11.2.0.1.0 - Production
CORE 11.2.0.1.0 Production
TNS for Linux: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production
SQL> create table t_iot ( a varchar2(10),b varchar2(10),vc varchar2(1200), constraint t_iot_pk PRIMARY KEY(a)) ORGANIZATION INDEX;
SQL> create index i_t_iot_b on t_iot(b);
insert into t_iot values ('1' ,'a','a');
insert into t_iot values ('22' ,'b','a');
insert into t_iot values ('333' ,'c','a');
insert into t_iot values ('4444' ,'d','a');
insert into t_iot values ('55555' ,'e','a');
insert into t_iot values ('666666' ,'f','a');
insert into t_iot values ('7777777' ,'g','a');
insert into t_iot values ('88888888' ,'h','a');
insert into t_iot values ('999999999','i','a');
commit ;
SQL> exec dbms_stats.gather_table_stats(ownname=>USER, tabname=>'T_iot');
2.轉儲IOT塊的資訊:
SQL> SELECT index_name, table_name, blevel, leaf_blocks FROM dba_indexes WHERE table_name = 'T_IOT';
INDEX_NAME TABLE_NAME BLEVEL LEAF_BLOCKS
------------------------------ ------------------------------ ---------- -----------
T_IOT_PK T_IOT 0 1
I_T_IOT_B T_IOT 0 1
--可以發現索引很小,blevel=0,leaf_blocks=1.
SQL> select header_file,header_block from dba_segments where segment_name='T_IOT_PK';
HEADER_FILE HEADER_BLOCK
----------- ------------
4 954
SQL> select object_id,data_object_id from dba_objects where object_name='T_IOT_PK';
OBJECT_ID DATA_OBJECT_ID
---------- --------------
83453 83453
SQL> ALTER SESSION SET EVENTS 'immediate trace name treedump level 83453';
----- begin tree dump
leaf: 0x10003bb 16778171 (0: nrow: 9 rrow: 9)
----- end tree dump
僅僅佔用1個塊。HEADER_BLOCK=954,根節點=955.
SQL> alter system dump datafile 4 block 955 ;
Block header dump: 0x010003bb
Object id on Block? Y
seg/obj: 0x145fd csc: 0x00.63a965 itc: 2 flg: E typ: 2 - INDEX
brn: 0 bdba: 0x10003b8 ver: 0x01 opc: 0
inc: 0 exflg: 0
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
0x02 0x0002.020.00000c9f 0x00c00b1b.066e.02 --U- 9 fsc 0x0000.0063a9ce
Leaf block dump
===============
header address 182924431972=0x2a97255264
kdxcolev 0
KDXCOLEV Flags = - - -
kdxcolok 0
kdxcoopc 0x90: pcode=0: iot flags=I-- is converted=Y
kdxconco 1
kdxcosdc 0
kdxconro 9
kdxcofbo 54=0x36
kdxcofeo 7897=0x1ed9
kdxcoavs 7843
kdxlespl 0
kdxlende 0
kdxlenxt 0=0x0
kdxleprv 0=0x0
kdxledsz 0
kdxlebksz 8032
row#0[8021] flag: K-----, lock: 2, len=11
col 0; len 1; (1): 31
tl: 7 fb: --H-FL-- lb: 0x0 cc: 2
col 0: [ 1] 61
col 1: [ 1] 61
row#1[8009] flag: K-----, lock: 2, len=12
col 0; len 2; (2): 32 32
tl: 7 fb: --H-FL-- lb: 0x0 cc: 2
col 0: [ 1] 62
col 1: [ 1] 61
row#2[7996] flag: K-----, lock: 2, len=13
col 0; len 3; (3): 33 33 33
tl: 7 fb: --H-FL-- lb: 0x0 cc: 2
col 0: [ 1] 63
col 1: [ 1] 61
row#3[7982] flag: K-----, lock: 2, len=14
col 0; len 4; (4): 34 34 34 34
tl: 7 fb: --H-FL-- lb: 0x0 cc: 2
col 0: [ 1] 64
col 1: [ 1] 61
row#4[7967] flag: K-----, lock: 2, len=15
col 0; len 5; (5): 35 35 35 35 35
tl: 7 fb: --H-FL-- lb: 0x0 cc: 2
col 0: [ 1] 65
col 1: [ 1] 61
row#5[7951] flag: K-----, lock: 2, len=16
col 0; len 6; (6): 36 36 36 36 36 36
tl: 7 fb: --H-FL-- lb: 0x0 cc: 2
col 0: [ 1] 66
col 1: [ 1] 61
row#6[7934] flag: K-----, lock: 2, len=17
col 0; len 7; (7): 37 37 37 37 37 37 37
tl: 7 fb: --H-FL-- lb: 0x0 cc: 2
col 0: [ 1] 67
col 1: [ 1] 61
row#7[7916] flag: K-----, lock: 2, len=18
col 0; len 8; (8): 38 38 38 38 38 38 38 38
tl: 7 fb: --H-FL-- lb: 0x0 cc: 2
col 0: [ 1] 68
col 1: [ 1] 61
row#8[7897] flag: K-----, lock: 2, len=19
col 0; len 9; (9): 39 39 39 39 39 39 39 39 39
tl: 7 fb: --H-FL-- lb: 0x0 cc: 2
col 0: [ 1] 69
col 1: [ 1] 61
----- end of leaf block dump -----
End dump data blocks tsn: 4 file#: 4 minblk 955 maxblk 955
--可以發現沒有記錄rowid資訊,
tl: 7 fb: --H-FL-- lb: 0x0 cc: 2
col 0: [ 1] 69
col 1: [ 1] 61
--記錄了主鍵外的資訊。
3.轉儲第2索引的資訊:
SQL> select header_file,header_block from dba_segments where segment_name='I_T_IOT_B';
HEADER_FILE HEADER_BLOCK
----------- ------------
4 962
SQL> select object_id,data_object_id from dba_objects where object_name='I_T_IOT_B';
OBJECT_ID DATA_OBJECT_ID
---------- --------------
83454 83454
SQL> ALTER SESSION SET EVENTS 'immediate trace name treedump level 83454';
----- begin tree dump
leaf: 0x10003c3 16778179 (0: nrow: 9 rrow: 9)
----- end tree dump
僅僅佔用1個塊。HEADER_BLOCK=962,根節點=963.
SQL> alter system dump datafile 4 block 963 ;
Block header dump: 0x010003c3
Object id on Block? Y
seg/obj: 0x145fe csc: 0x00.63a9bd itc: 2 flg: E typ: 2 - INDEX
brn: 0 bdba: 0x10003c0 ver: 0x01 opc: 0
inc: 0 exflg: 0
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
0x02 0x0002.020.00000c9f 0x00c00b1b.066e.03 --U- 9 fsc 0x0000.0063a9ce
Leaf block dump
===============
header address 182924431972=0x2a97255264
kdxcolev 0
KDXCOLEV Flags = - - -
kdxcolok 0
kdxcoopc 0x90: pcode=0: iot flags=I-- is converted=Y
kdxconco 2
kdxcosdc 0
kdxconro 9
kdxcofbo 54=0x36
kdxcofeo 7870=0x1ebe
kdxcoavs 7816
kdxlespl 0
kdxlende 0
kdxlenxt 0=0x0
kdxleprv 0=0x0
kdxledsz 0
kdxlebksz 8032
row#0[8018] flag: K-----, lock: 2, len=14
col 0; len 1; (1): 61
col 1; len 1; (1): 31
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bb
row#1[8003] flag: K-----, lock: 2, len=15
col 0; len 1; (1): 62
col 1; len 2; (2): 32 32
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bb
row#2[7987] flag: K-----, lock: 2, len=16
col 0; len 1; (1): 63
col 1; len 3; (3): 33 33 33
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bb
row#3[7970] flag: K-----, lock: 2, len=17
col 0; len 1; (1): 64
col 1; len 4; (4): 34 34 34 34
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bb
row#4[7952] flag: K-----, lock: 2, len=18
col 0; len 1; (1): 65
col 1; len 5; (5): 35 35 35 35 35
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bb
row#5[7933] flag: K-----, lock: 2, len=19
col 0; len 1; (1): 66
col 1; len 6; (6): 36 36 36 36 36 36
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bb
row#6[7913] flag: K-----, lock: 2, len=20
col 0; len 1; (1): 67
col 1; len 7; (7): 37 37 37 37 37 37 37
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bb
row#7[7892] flag: K-----, lock: 2, len=21
col 0; len 1; (1): 68
col 1; len 8; (8): 38 38 38 38 38 38 38 38
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bb
row#8[7870] flag: K-----, lock: 2, len=22
col 0; len 1; (1): 69
col 1; len 9; (9): 39 39 39 39 39 39 39 39 39
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bb
----- end of leaf block dump -----
End dump data blocks tsn: 4 file#: 4 minblk 963 maxblk 963
-- 可以發現第2索引的記錄資訊如下:
col0 =》對應的是欄位b
col1 =》對應的是欄位a,也就是主鍵。
而後面還存在如下資訊:
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bb
-- 可以發現記錄的資訊都是一樣的,col0: [ 4] 01 00 03 bb,應該跟上面的轉儲對上:
SQL> ALTER SESSION SET EVENTS 'immediate trace name treedump level 83453';
----- begin tree dump
leaf: 0x10003bb 16778171 (0: nrow: 9 rrow: 9)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
----- end tree dump
也就是T_IOT_PK的根節點。
可以得到一些推測:
1.如果透過第2索引查詢主鍵,是不需要查詢IOT表的,因為第2索引裡面已經存在。
2.如果透過第2索引查詢資料資訊,IOT先透過索引節點中記錄的資料塊資訊查詢(這個就應該就是物理猜),如果不行可以透過主鍵也就是對應例子的col1鍵值,來探查IOT索引組織表。
4.做一些測試:
SQL> set autotrace traceonly ;
SQL> select a from t_iot where b='a';
Execution Plan
----------------------------------------------------------
Plan hash value: 3946844304
------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 8 | 1 (0)| 00:00:01 |
|* 1 | INDEX RANGE SCAN| I_T_IOT_B | 1 | 8 | 1 (0)| 00:00:01 |
------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - access("B"='a')
--可以發現並沒有查詢IOT表,而是直接訪問索引。
SQL> select vc from t_iot where b='a';
Execution Plan
----------------------------------------------------------
Plan hash value: 1095339046
-------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 4 | 1 (0)| 00:00:01 |
|* 1 | INDEX UNIQUE SCAN| T_IOT_PK | 1 | 4 | 1 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN| I_T_IOT_B | 1 | | 1 (0)| 00:00:01 |
-------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - access("B"='a')
2 - access("B"='a')
Statistics
----------------------------------------------------------
1 recursive calls
0 db block gets
3 consistent gets
0 physical reads
0 redo size
519 bytes sent via SQL*Net to client
519 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
--可以發現先查詢i_t_iot_b索引,然後在查詢T_IOT索引組織表。
5.再來了解一下邏輯rowid。
SQL> column vc format a30
SQL> select rowid,a.* from t_iot a;
ROWID A B VC
------------------------- ---------- ---------- ------------------------------
*BAEAA7sBMf4 1 a a
*BAEAA7sCMjL+ 22 b a
*BAEAA7sDMzMz/g 333 c a
*BAEAA7sENDQ0NP4 4444 d a
*BAEAA7sFNTU1NTX+ 55555 e a
*BAEAA7sGNjY2NjY2/g 666666 f a
*BAEAA7sHNzc3Nzc3N/4 7777777 g a
*BAEAA7sIODg4ODg4ODj+ 88888888 h a
*BAEAA7sJOTk5OTk5OTk5/g 999999999 i a
9 rows selected.
--可以發現一些特點,前面都是一樣的都是*BAEAA7s,而且主鍵鍵值的長度越長與rowid的長度也越長。再dump(rowid)
SQL> column x format a70
SQL> select dump(rowid) x,rowid,a,b from t_iot ;
X ROWID A B
---------------------------------------------------------------------- ------------------------- ---------- ----------
Typ=208 Len=9: 2,4,1,0,3,187,1,49,254 *BAEAA7sBMf4 1 a
Typ=208 Len=10: 2,4,1,0,3,187,2,50,50,254 *BAEAA7sCMjL+ 22 b
Typ=208 Len=11: 2,4,1,0,3,187,3,51,51,51,254 *BAEAA7sDMzMz/g 333 c
Typ=208 Len=12: 2,4,1,0,3,187,4,52,52,52,52,254 *BAEAA7sENDQ0NP4 4444 d
Typ=208 Len=13: 2,4,1,0,3,187,5,53,53,53,53,53,254 *BAEAA7sFNTU1NTX+ 55555 e
Typ=208 Len=14: 2,4,1,0,3,187,6,54,54,54,54,54,54,254 *BAEAA7sGNjY2NjY2/g 666666 f
Typ=208 Len=15: 2,4,1,0,3,187,7,55,55,55,55,55,55,55,254 *BAEAA7sHNzc3Nzc3N/4 7777777 g
Typ=208 Len=16: 2,4,1,0,3,187,8,56,56,56,56,56,56,56,56,254 *BAEAA7sIODg4ODg4ODj+ 88888888 h
Typ=208 Len=17: 2,4,1,0,3,187,9,57,57,57,57,57,57,57,57,57,254 *BAEAA7sJOTk5OTk5OTk5/g 999999999 i
9 rows selected.
SQL> select dump(rowid,16) x,rowid,a,b from t_iot ;
X ROWID A B
---------------------------------------------------------------------- ------------------------- ---------- ----------
Typ=208 Len=9: 2,4,1,0,3,bb,1,31,fe *BAEAA7sBMf4 1 a
Typ=208 Len=10: 2,4,1,0,3,bb,2,32,32,fe *BAEAA7sCMjL+ 22 b
Typ=208 Len=11: 2,4,1,0,3,bb,3,33,33,33,fe *BAEAA7sDMzMz/g 333 c
Typ=208 Len=12: 2,4,1,0,3,bb,4,34,34,34,34,fe *BAEAA7sENDQ0NP4 4444 d
Typ=208 Len=13: 2,4,1,0,3,bb,5,35,35,35,35,35,fe *BAEAA7sFNTU1NTX+ 55555 e
Typ=208 Len=14: 2,4,1,0,3,bb,6,36,36,36,36,36,36,fe *BAEAA7sGNjY2NjY2/g 666666 f
Typ=208 Len=15: 2,4,1,0,3,bb,7,37,37,37,37,37,37,37,fe *BAEAA7sHNzc3Nzc3N/4 7777777 g
Typ=208 Len=16: 2,4,1,0,3,bb,8,38,38,38,38,38,38,38,38,fe *BAEAA7sIODg4ODg4ODj+ 88888888 h
Typ=208 Len=17: 2,4,1,0,3,bb,9,39,39,39,39,39,39,39,39,39,fe *BAEAA7sJOTk5OTk5OTk5/g 999999999 i
9 rows selected.
--結合dump(rowid),dump(rowid,16)的轉出資訊.很容易推匯出rowid的資訊。以下的例子來說明:
Typ=208 Len=17: 2,4,1,0,3,bb,9,39,39,39,39,39,39,39,39,39,fe *BAEAA7sJOTk5OTk5OTk5/g 999999999 i
1.開頭的2,4,以及結尾fe實在不好猜測,不過好像是固定不變的。
2.中間的1,0,3,bb正好對應的就是IOT的根節點,也就是對應資料IOT的資料塊。
3.9,39,39,39,39,39,39,39,39,39中9表示主鍵長度,39,39,39,39,39,39,39,39,39就是主鍵的資訊。
6.關於物理猜:
SQL> column name format a30
SQL> column value format 999999999
SQL> SELECT n.name, s.value FROM v$mystat s, v$statname n WHERE s.statistic# = n.statistic# AND lower(n.name) like '%leaf%';
NAME VALUE
------------------------------ ----------
leaf node splits 0
leaf node 90-10 splits 0
SQL> update t_iot set vc=lpad('a',1000,'a') ;
9 rows updated.
SQL> SELECT n.name, s.value FROM v$mystat s, v$statname n WHERE s.statistic# = n.statistic# AND lower(n.name) like '%leaf%';
NAME VALUE
------------------------------ ----------
leaf node splits 1
leaf node 90-10 splits 0
SQL> commit;
--vc長度加大到1000,原來的IOT已經無法存在這些資訊,可以發現IOT表發生了1次索引分裂。
SQL> select dump(rowid,16) x,rowid,a,b from t_iot ;
X ROWID A B
---------------------------------------------------------------------- ------------------------- ---------- ----------
Typ=208 Len=9: 2,4,1,0,3,bd,1,31,fe *BAEAA70BMf4 1 a
Typ=208 Len=10: 2,4,1,0,3,bd,2,32,32,fe *BAEAA70CMjL+ 22 b
Typ=208 Len=11: 2,4,1,0,3,bd,3,33,33,33,fe *BAEAA70DMzMz/g 333 c
Typ=208 Len=12: 2,4,1,0,3,bd,4,34,34,34,34,fe *BAEAA70ENDQ0NP4 4444 d
Typ=208 Len=13: 2,4,1,0,3,bd,5,35,35,35,35,35,fe *BAEAA70FNTU1NTX+ 55555 e
Typ=208 Len=14: 2,4,1,0,3,bd,6,36,36,36,36,36,36,fe *BAEAA70GNjY2NjY2/g 666666 f
Typ=208 Len=15: 2,4,1,0,3,be,7,37,37,37,37,37,37,37,fe *BAEAA74HNzc3Nzc3N/4 7777777 g
Typ=208 Len=16: 2,4,1,0,3,be,8,38,38,38,38,38,38,38,38,fe *BAEAA74IODg4ODg4ODj+ 88888888 h
Typ=208 Len=17: 2,4,1,0,3,be,9,39,39,39,39,39,39,39,39,39,fe *BAEAA74JOTk5OTk5OTk5/g 999999999 i
9 rows selected.
--可以發現邏輯rowid記錄的塊資訊發現了變化。從1,0,3,bb變成了1,0,3,bd和1,0,3,be.
--再次轉儲第2索引的資訊。
SQL> alter system dump datafile 4 block 963 ;
Block header dump: 0x010003c3
Object id on Block? Y
seg/obj: 0x145fe csc: 0x00.63a9bd itc: 2 flg: E typ: 2 - INDEX
brn: 0 bdba: 0x10003c0 ver: 0x01 opc: 0
inc: 0 exflg: 0
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
0x02 0x0002.020.00000c9f 0x00c00b1b.066e.03 --U- 9 fsc 0x0000.0063a9ce
Leaf block dump
===============
header address 182925401700=0x2a97341e64
kdxcolev 0
KDXCOLEV Flags = - - -
kdxcolok 0
kdxcoopc 0x90: pcode=0: iot flags=I-- is converted=Y
kdxconco 2
kdxcosdc 0
kdxconro 9
kdxcofbo 54=0x36
kdxcofeo 7870=0x1ebe
kdxcoavs 7816
kdxlespl 0
kdxlende 0
kdxlenxt 0=0x0
kdxleprv 0=0x0
kdxledsz 0
kdxlebksz 8032
row#0[8018] flag: K-----, lock: 2, len=14
col 0; len 1; (1): 61
col 1; len 1; (1): 31
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bb
row#1[8003] flag: K-----, lock: 2, len=15
col 0; len 1; (1): 62
col 1; len 2; (2): 32 32
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bb
row#2[7987] flag: K-----, lock: 2, len=16
col 0; len 1; (1): 63
col 1; len 3; (3): 33 33 33
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bb
row#3[7970] flag: K-----, lock: 2, len=17
col 0; len 1; (1): 64
col 1; len 4; (4): 34 34 34 34
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bb
row#4[7952] flag: K-----, lock: 2, len=18
col 0; len 1; (1): 65
col 1; len 5; (5): 35 35 35 35 35
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bb
row#5[7933] flag: K-----, lock: 2, len=19
col 0; len 1; (1): 66
col 1; len 6; (6): 36 36 36 36 36 36
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bb
row#6[7913] flag: K-----, lock: 2, len=20
col 0; len 1; (1): 67
col 1; len 7; (7): 37 37 37 37 37 37 37
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bb
row#7[7892] flag: K-----, lock: 2, len=21
col 0; len 1; (1): 68
col 1; len 8; (8): 38 38 38 38 38 38 38 38
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bb
row#8[7870] flag: K-----, lock: 2, len=22
col 0; len 1; (1): 69
col 1; len 9; (9): 39 39 39 39 39 39 39 39 39
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bb
----- end of leaf block dump -----
End dump data blocks tsn: 4 file#: 4 minblk 963 maxblk 963
--可以發現如下資訊沒有發生變化,依舊是col 0: [ 4] 01 00 03 bb.
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bb
這樣如果我們執行select substr(vc,1,20) from t_iot from where b='a';透過第2索引記錄的資料塊查詢應該找不到vc的值(可以理解物理猜失敗),
必須在透過主鍵來查詢,這樣邏輯讀就會比原來加1.
SQL> set autotrace traceonly
SQL> select substr(vc,1,20) from t_iot where b='a';
Execution Plan
----------------------------------------------------------
Plan hash value: 1095339046
-------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 4 | 1 (0)| 00:00:01 |
|* 1 | INDEX UNIQUE SCAN| T_IOT_PK | 1 | 4 | 1 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN| I_T_IOT_B | 1 | | 1 (0)| 00:00:01 |
-------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - access("B"='a')
2 - access("B"='a')
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
4 consistent gets
0 physical reads
0 redo size
551 bytes sent via SQL*Net to client
519 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
7.現在我們重建第2索引看看。
SQL> alter index i_t_iot_b rebuild ;
Index altered.
SQL> select header_file,header_block from dba_segments where segment_name='I_T_IOT_B';
HEADER_FILE HEADER_BLOCK
----------- ------------
4 970
SQL> select object_id,data_object_id from dba_objects where object_name='I_T_IOT_B';
OBJECT_ID DATA_OBJECT_ID
---------- --------------
83454 83455
SQL> exec dbms_stats.gather_table_stats(ownname=>USER, tabname=>'T_iot');
PL/SQL procedure successfully completed.
SQL> SELECT index_name, table_name, blevel, leaf_blocks FROM dba_indexes WHERE table_name = 'T_IOT';
INDEX_NAME TABLE_NAME BLEVEL LEAF_BLOCKS
------------------------------ ------------------------------ ---------- -----------
T_IOT_PK T_IOT 1 2
I_T_IOT_B T_IOT 0 1
SQL> ALTER SESSION SET EVENTS 'immediate trace name treedump level 83454';
Session altered.
----- begin tree dump
leaf: 0x10003cb 16778187 (0: nrow: 9 rrow: 9)
----- end tree dump
I_T_IOT_B僅僅佔用1個塊。HEADER_BLOCK=970,根節點=971.
SQL> alter system dump datafile 4 block 971 ;
Block header dump: 0x010003cb
Object id on Block? Y
seg/obj: 0x145ff csc: 0x00.63b560 itc: 2 flg: E typ: 2 - INDEX
brn: 0 bdba: 0x10003c8 ver: 0x01 opc: 0
inc: 0 exflg: 0
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
0x02 0xffff.000.00000000 0x00000000.0000.00 C--- 0 scn 0x0000.0063b560
Leaf block dump
===============
header address 182925401700=0x2a97341e64
kdxcolev 0
KDXCOLEV Flags = - - -
kdxcolok 0
kdxcoopc 0x90: pcode=0: iot flags=I-- is converted=Y
kdxconco 2
kdxcosdc 0
kdxconro 9
kdxcofbo 54=0x36
kdxcofeo 7870=0x1ebe
kdxcoavs 7816
kdxlespl 0
kdxlende 0
kdxlenxt 0=0x0
kdxleprv 0=0x0
kdxledsz 0
kdxlebksz 8032
row#0[8018] flag: K-----, lock: 0, len=14
col 0; len 1; (1): 61
col 1; len 1; (1): 31
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bd
row#1[8003] flag: K-----, lock: 0, len=15
col 0; len 1; (1): 62
col 1; len 2; (2): 32 32
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bd
row#2[7987] flag: K-----, lock: 0, len=16
col 0; len 1; (1): 63
col 1; len 3; (3): 33 33 33
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bd
row#3[7970] flag: K-----, lock: 0, len=17
col 0; len 1; (1): 64
col 1; len 4; (4): 34 34 34 34
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bd
row#4[7952] flag: K-----, lock: 0, len=18
col 0; len 1; (1): 65
col 1; len 5; (5): 35 35 35 35 35
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bd
row#5[7933] flag: K-----, lock: 0, len=19
col 0; len 1; (1): 66
col 1; len 6; (6): 36 36 36 36 36 36
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 bd
row#6[7913] flag: K-----, lock: 0, len=20
col 0; len 1; (1): 67
col 1; len 7; (7): 37 37 37 37 37 37 37
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 be
row#7[7892] flag: K-----, lock: 0, len=21
col 0; len 1; (1): 68
col 1; len 8; (8): 38 38 38 38 38 38 38 38
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 be
row#8[7870] flag: K-----, lock: 0, len=22
col 0; len 1; (1): 69
col 1; len 9; (9): 39 39 39 39 39 39 39 39 39
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 be
----- end of leaf block dump -----
End dump data blocks tsn: 4 file#: 4 minblk 971 maxblk 971
--可以發現索引中的資料塊資訊指向了正確的位置。
tl: 8 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 01 00 03 be
SQL> set autotrace traceonly
SQL> select substr(vc,1,20) from t_iot where b='a';
Execution Plan
----------------------------------------------------------
Plan hash value: 1095339046
-------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 1003 | 1 (0)| 00:00:01 |
|* 1 | INDEX UNIQUE SCAN| T_IOT_PK | 1 | 1003 | 1 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN| I_T_IOT_B | 1 | | 1 (0)| 00:00:01 |
-------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - access("B"='a')
2 - access("B"='a')
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
3 consistent gets
0 physical reads
0 redo size
551 bytes sent via SQL*Net to client
519 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
--可以發現邏輯讀又變為3個.物理猜測是正確的。
8.總結:
1.IOT的第2索引包含主鍵資訊以及對應資訊的塊資訊。
2.當IOT索引分裂時,第2索引中記錄的塊資訊不會發生變化。這樣在使用第2索引探查IOT表時,物理猜就會失敗。
3.如果物理猜失敗很多,會導致邏輯讀增加,可以透過重建第2索引來解決這個問題。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/267265/viewspace-717272/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- [20120324]IOT索引組織表相關資訊的學習(二).txt索引
- [20120509]IOT索引組織表相關資訊的學習(三).txt索引
- [20120509]IOT索引組織表相關資訊的學習(四).txt索引
- Oracle 索引組織表(IOT)Oracle索引
- oracle iot索引組織表(一)Oracle索引
- oracle iot索引組織表(二)Oracle索引
- 索引組織表(index organized table ,IOT)索引IndexZed
- 在OLTP系統使用索引組織表IOT索引
- 學習型組織的資訊化支撐
- Oracle堆組織表的索引和索引組織表Oracle索引
- oracle 索引組織表Oracle索引
- [20151008]索引組織表上建立BITMAP索引.txt索引
- 索引組織表上建立BITMAP索引(三)索引
- 索引組織表上建立BITMAP索引(二)索引
- 索引組織表上建立BITMAP索引(一)索引
- 澳洲中學組織加密貨幣資訊之夜加密
- SQL Server 重新組織生成索引SQLServer索引
- 索引組織表(Index Organizied Table)索引Index
- ORACLE索引組織表討論Oracle索引
- 風雲突變的NB-IoT、LoRa產業組織格局產業
- 一個關於組織學員學習技術的筆試題--求討論筆試
- MySQL學習筆記:組合索引-索引下推MySql筆記索引
- 關於不可見索引的學習索引
- 組織能力成熟度模型學習模型
- 資料庫表,索引(索引組織表,聚簇表,聚簇索引,)資料庫索引
- [20121028]IOT的第2索引-NULL的問題.txt索引Null
- 埋點表相關
- 網秦組織學習黨的十九大報告精神
- oracle IOT表學習Oracle
- 資料表相關操作
- 組織計量學--指標學指標
- MySQL學習筆記:組合索引-最左原則MySql筆記索引
- 自組織的鐵三角關係
- Accelerated C++學習筆記--組織程式和資料C++筆記
- oracle報表相關指令碼Oracle指令碼
- FB被曝收集兒童資訊 多個保護組織呼籲關閉相關應用
- 張雅秋:移動網頁設計的資訊組織網頁
- 公司程式碼與採購組織的關係