[20120509]IOT索引组织表相关信息的学习(四).txt

[20120509]IOT索引组织表相关信息的学习(四).txt

今天看了一个有关IOT的介绍:
http://richardfoote.wordpress.com/2012/04/11/iot-secondary-indexes-primary-key-considerations-beauty-and-the-beast/

    If we create a secondary index on a column that forms part of the PK, Oracle can be a lit bit cleverer. Following, we create an
index on the COUNTRY_ID column, which is the second column of our PK (album_id, country_id):

SQL> create index album_sales_iot_country_id_i on album_sales_iot(country_id);
Index created.

    We notice that for this new index, Oracle has eliminated "redundant" PK columns from the secondary index, as there's no need to
store the entire PK again as the indexed column itself already forms part of the PK:

SQL> select index_name, iot_redundant_pkey_elim from dba_indexes where table_name = 'ALBUM_SALES_IOT';

INDEX_NAME                     IOT_REDUNDANT_PKEY_ELIM
------------------------------ ------------------------
ALBUM_SALES_IOT_PK             NO
ALBUM_SALES_IOT_TOTAL_SALES_I  NO
ALBUM_SALES_IOT_COUNTRY_ID_I   YES

    上面提到如果建立的第2索引中包含主键的一部分,不会在第2索引的进行冗余保存。自己做一个测试看看。

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),c varchar2(10),vc varchar2(1200), constraint t_iot_pk PRIMARY KEY(a,b)) ORGANIZATION INDEX;
SQL> create index i_t_iot_b_c on t_iot(b,c);
SQL> create index i_t_iot_c_b on t_iot(c,b);
insert into t_iot values ('1'        ,'a','s1','a');
insert into t_iot values ('22'       ,'b','s2','a');
insert into t_iot values ('333'      ,'c','s3','a');
insert into t_iot values ('4444'     ,'d','s4','a');
insert into t_iot values ('55555'    ,'e','s5','a');
insert into t_iot values ('666666'   ,'f','s6','a');
insert into t_iot values ('7777777'  ,'g','s7','a');
insert into t_iot values ('88888888' ,'h','s8','a');
insert into t_iot values ('999999999','i','s9','a');
commit ;
SQL> exec dbms_stats.gather_table_stats(ownname=>USER, tabname=>'T_iot');

2.检查建立索引:

SQL> select index_name, iot_redundant_pkey_elim from dba_indexes where table_name = 'T_IOT';
INDEX_NAME                     IOT
------------------------------ ---
T_IOT_PK                       NO
I_T_IOT_B_C                    YES
I_T_IOT_C_B                    YES
--发现确实如此!
SQL> select column_id, segment_column_id, column_name from dba_tab_cols where table_name = 'T_IOT' order by column_id;
 COLUMN_ID SEGMENT_COLUMN_ID COLUMN_NAME
---------- ----------------- ------------------------------
         1                 1 A
         2                 2 B
         3                 3 C
         4                 4 VC

3.转储第2索引的信息:

SQL> SELECT index_name, table_name, blevel, leaf_blocks,iot_redundant_pkey_elim FROM dba_indexes  WHERE table_name = 'T_IOT';
INDEX_NAME                     TABLE_NAME                         BLEVEL LEAF_BLOCKS IOT
------------------------------ ------------------------------ ---------- ----------- ---
T_IOT_PK                       T_IOT                                   0           1 NO
I_T_IOT_B_C                    T_IOT                                   0           1 YES
I_T_IOT_C_B                    T_IOT                                   0           1 YES
--可以发现索引很小,blevel=0,leaf_blocks=1.
SQL> select header_file,header_block from dba_segments where segment_name='I_T_IOT_B_C';
HEADER_FILE HEADER_BLOCK
----------- ------------
          4         2570

SQL> select object_id,data_object_id from dba_objects where object_name='I_T_IOT_B_C';
 OBJECT_ID DATA_OBJECT_ID
---------- --------------
     91490          91490

SQL> ALTER SESSION SET EVENTS 'immediate trace name treedump level 91490';
----- begin tree dump
leaf: 0x1000a0b 16779787 (0: nrow: 9 rrow: 9)
----- end tree dump
仅仅占用1个块。HEADER_BLOCK=2570,根节点=2571.
SQL> alter system dump datafile 4 block 2571 ;
Block header dump:  0x01000a0b
 Object id on Block? Y
 seg/obj: 0x16562  csc: 0x00.9dc409  itc: 2  flg: E  typ: 2 - INDEX
     brn: 0  bdba: 0x1000a08 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   0x0009.010.0000137f  0x00c0110b.09dd.43  --U-    9  fsc 0x0000.009dc423
Leaf block dump
===============
header address 182924563044=0x2a97275264
kdxcolev 0
KDXCOLEV Flags = - - -
kdxcolok 0
kdxcoopc 0x90: pcode=0: iot flags=I-- is converted=Y
kdxconco 3
kdxcosdc 0
kdxconro 9
kdxcofbo 54=0x36
kdxcofeo 7843=0x1ea3
kdxcoavs 7789
kdxlespl 0
kdxlende 0
kdxlenxt 0=0x0
kdxleprv 0=0x0
kdxledsz 0
kdxlebksz 8032
row#0[8015] flag: K-----, lock: 2, len=17
col 0; len 1; (1):  61
col 1; len 2; (2):  73 31
col 2; len 1; (1):  31
tl: 8 fb: --H-FL-- lb: 0x0  cc: 1
col  0: [ 4]  01 00 0a 03
row#1[7997] flag: K-----, lock: 2, len=18
col 0; len 1; (1):  62
col 1; len 2; (2):  73 32
col 2; len 2; (2):  32 32
tl: 8 fb: --H-FL-- lb: 0x0  cc: 1
col  0: [ 4]  01 00 0a 03
row#2[7978] flag: K-----, lock: 2, len=19
col 0; len 1; (1):  63
col 1; len 2; (2):  73 33
col 2; len 3; (3):  33 33 33
tl: 8 fb: --H-FL-- lb: 0x0  cc: 1
col  0: [ 4]  01 00 0a 03
row#3[7958] flag: K-----, lock: 2, len=20
col 0; len 1; (1):  64
col 1; len 2; (2):  73 34
col 2; len 4; (4):  34 34 34 34
tl: 8 fb: --H-FL-- lb: 0x0  cc: 1
col  0: [ 4]  01 00 0a 03
row#4[7937] flag: K-----, lock: 2, len=21
col 0; len 1; (1):  65
col 1; len 2; (2):  73 35
col 2; len 5; (5):  35 35 35 35 35
tl: 8 fb: --H-FL-- lb: 0x0  cc: 1
col  0: [ 4]  01 00 0a 03
row#5[7915] flag: K-----, lock: 2, len=22
col 0; len 1; (1):  66
col 1; len 2; (2):  73 36
col 2; len 6; (6):  36 36 36 36 36 36
tl: 8 fb: --H-FL-- lb: 0x0  cc: 1
col  0: [ 4]  01 00 0a 03
row#6[7892] flag: K-----, lock: 2, len=23
col 0; len 1; (1):  67
col 1; len 2; (2):  73 37
col 2; len 7; (7):  37 37 37 37 37 37 37
tl: 8 fb: --H-FL-- lb: 0x0  cc: 1
col  0: [ 4]  01 00 0a 03
row#7[7868] flag: K-----, lock: 2, len=24
col 0; len 1; (1):  68
col 1; len 2; (2):  73 38
col 2; 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 0a 03
row#8[7843] flag: K-----, lock: 2, len=25
col 0; len 1; (1):  69
col 1; len 2; (2):  73 39
col 2; 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 0a 03
----- end of leaf block dump -----
End dump data blocks tsn: 4 file#: 4 minblk 2571 maxblk 2571

-- 可以看出col1对应字段b的值,col2对应字段c的值,col2对应字段a的值。
--确实b字段没有重复保存。

时间: 2024-08-03 08:54:03

[20120509]IOT索引组织表相关信息的学习(四).txt的相关文章

[20120509]IOT索引组织表相关信息的学习(三).txt

[20120509]IOT索引组织表相关信息的学习(三).txt 上次链接:http://space.itpub.net/267265/viewspace-719517http://space.itpub.net/267265/viewspace-717272 IOT 是一种特殊的索引结构,使用它能够解决特定场合的应用问题,但是在许多应用中很少使用,更多的是使用堆表.我仅仅在生产系统中对3个表使用,我偏向使用静态以及"只读"的小表. 如果IOT表存在除主键外的第2索引,如果使用它存在物

[20120324]IOT索引组织表相关信息的学习(二).txt

上次链接:http://space.itpub.net/?uid-267265-action-viewspace-itemid-717272 IOT 是一种特殊的索引结构,使用它能够解决特定场合的应用问题,但是在许多应用中很少使用,更多的是使用堆表.我仅仅在生产系统中对3个表使用,我偏向使用静态以及"只读"的小表. 如果IOT表存在除主键外的第2索引,如果使用它存在物理猜"physical guess",我以前的理解一直是第2索引记录了主键信息,通过这个信息就可以定

[20120228]IOT索引组织表相关信息的学习.txt

[20120228]IOT索引组织表相关信息的学习.txt IOT 是一种特殊的索引结构,使用它能够解决特定场合的应用问题,但是在许多应用中很少使用,更多的是使用堆表.我仅仅在生产系统中对3个表使用,我偏向使用静态以及"只读"的小表. 如果IOT表存在除主键外的第2索引,如果使用它存在物理猜"physical guess",我以前的理解一直是第2索引记录了主键信息,通过这个信息就可以定位IOT表中对应的数据,一直没有很好的测试与理解.我最近也看了两个链接,介绍了IO

oracle点知识8——索引组织表

关于索引的入门参照博客:http://blog.csdn.net/changyanmanman/article/details/7097318 索引组织表(index organized table, IOT)就是存储在一个索引结构中的表.存储在堆中的表是无组织的(也就是说,只要有可用的空间,数据可以放在任何地方),IOT中的数据则按主键存储和排序.对你的应用来说,IOT表和一个"常规"表并无二致. IOT有什么意义呢?使用堆组织表时,我们必须为表和表主键上的索引分别留出空间.而IOT

索引组织表(index organized table ,IOT)

索引组织表(index organized table ,IOT) 默认情况下所有的表都是堆组织表,对表中的记录不进行排序.堆组织表通过rowid 来访问(定位)表中的记录.IOT 使用b-tree index 的结构存储记录.逻辑上按照主键排序,和正常的主键索引不同的是,主键索引仅仅是存储定义列的值.IOT index 存储所有IOT表中所有的列,并按照主键排序.索引和表合二为一,存储在同一个数据库对象中.表中记录的访问也不是通过传统的rowid来现实,而是通过主键来访问. 创建IOT IOT

[20151008]索引组织表上创建BITMAP索引.txt

[20151008]索引组织表上创建BITMAP索引.txt --IOT 是一种特殊的索引结构,使用它能够解决特定场合的应用问题,但是在许多应用中很少使用,更多的是使用堆表. --我偏向使用静态以及"只读"的小表. --以前写过一个系列,一直没有很好理解在IOT表上建立位图索引,最近再研究看看; --我当时不理解为什么mapping table与iot表对应的块为什么不一致? 1.建立测试环境: SCOTT@test> @ver1 PORT_STRING             

ORACLE索引组织表讨论

本文只代表作者观点,如有错误请指正 关于索引组织表本文主要讨论以下几个方面 1.什么是索引组织表 2.索引组织表的关键特性 3.如果建立一个合适的索引组织表 4.什么事逻辑ROWID以及物理猜(Physical Guesses) 5.从内部结构进行分析和证明这些观点 一般的情况下索引是和表分离的SEGMENT,索引的行记录的是索引键值和ROWID,而在索引组织表中就整个表就是一个索引,索引的页节点记录的并非 键值和ROWID而记录是整个数据行,这里和MYSQL INNODB的表非常相像,MYSQ

Oracle中如何管理索引组织表

索引组织表(IOT)有一种类B树的存储组织方法.普通的堆组织表是以一种无序的集合存储.而IOT中的数据是按主键有序的存储在B树索引结构中.与一般B树索引不同的的是,在IOT中每个叶结点即有每行的主键列值,又有那些非主键列值. 在IOT所对应的B树结构中,每个索引项包括<主键列值,非主键列值>而不是ROWID,对于普通堆组织表,oracle会有对应的索引与之对应,且分开存储.换句话说,IOT即是索引,又是实际的数据. 索引组织表(IOT)不仅可以存储数据,还可以存储为表建立的索引.索引组织表的数

oracle 索引组织表的深入详解_oracle

索引组织表(IOT)不仅可以存储数据,还可以存储为表建立的索引.索引组织表的数据是根据主键排序后的顺序进行排列的,这样就提高了访问的速度.但是这是由牺牲插入和更新性能为代价的(每次写入和更新后都要重新进行重新排序).索引组织表的创建格式如下: 复制代码 代码如下: create table indexTable(   ID   varchar2 (10),   NAME varchar2 (20),   constraint pk_id primary key (ID)   )   organi