简述Oracle IOT（Index Organized Table）（下）

 

下面我们讨论一下由于数据存储为索引而带来的Rowid、Secondary Index问题。

 

6、Logical Rowid & Secondary Index

 

在IOT的环境下，我们是不能保证一个固定的物理Rowid的。

 

堆表（Heap Table）中，一行数据被保存在一个物理位置（file no. + block no.）之后，在正常保存行为中，即使发生行迁移现象，它的rowid是不会发生变化的。只有在进行数据表存储重构，如move和shrink space的时候才会发生新的rowid赋予。

 

堆表rowid的固定给我们带来一个好处，就是连带的数据表索引叶子节点上面的的rowid永远有效的，除非发生move或者和shrink space操作（此时索引失效）。

 

但是，IOT存在一些问题。索引叶子节点的分裂操作是相当频繁的，我们很难保证一个数据行维持在一个rowid不会发生大的变化。当然，如果我们保证每次访问数据表都是通过主键primary key方式，变化的rowid不会有任何影响。问题出在非主键的索引，IOT中称之为“二级索引”Secondary Index上。

 

对于一般的二级索引，如果叶子节点上保留数据行的rowid，那么失效的rowid意味着所有对应的二级索引非常容易变为invalid状态。

 

在很多数据库版本，包括早期的Oracle版本中，对于Secondary Index是不支持的。最近的oracle中，引入了Logical Rowid和Physical Guess的方法，才最终解决了Secondary Index问题。

 

 

SQL> select rowid, object_id from t_iot where rownum<5;

 

ROWID                             OBJECT_ID

------------------------------- -----------

*BABBVmoCwQP+                             2

*BABBVmoCwQT+                             3

*BABBVmoCwQX+                             4

*BABBVmoCwQb+                             5

 

 

对IOT而言，rowid基本上是不合乎我们常见的heap table rowid格式的。我们可以对t_iot添加secondary index。

 

 

SQL> create index idx_t_iot_name on t_iot(object_name);

Index created

 

SQL> exec dbms_stats.gather_table_stats(user,'T_IOT',cascade => true);

PL/SQL procedure successfully completed

 

 

从数据字典中看，索引idx_t_iot_name没有什么额外的差异，只是对于一般索引来说，clustering factor取值略高。

 

 

SQL> select index_Name, index_type, clustering_factor  from dba_indexes where wner='SYS' and index_name='IDX_T_IOT_NAME';

 

INDEX_NAME                     INDEX_TYPE                  CLUSTERING_FACTOR

------------------------------ --------------------------- -----------------

IDX_T_IOT_NAME                 NORMAL                                  55006

 

SQL> select count(*) from t_iot;

 

  COUNT(*)

----------

     72604

 

 

SQL> select sum(bytes)/1024/1024, count(*) from dba_extents where wner='SYS' and segment_name='IDX_T_IOT_NAME';

 

SUM(BYTES)/1024/1024   COUNT(*)

-------------------- ----------

                   4         19

 

 

对于一个7万余条记录的数据表索引，占到了19个分区，总看空间4M。那么，如果是一般的heap table index呢？空间如何？

 

 

SQL> desc t_heap;

Name        Type          Nullable Default Comments

----------- ------------- -------- ------- --------

OBJECT_ID   NUMBER(10)                             

OBJECT_NAME VARCHAR2(100) Y                         

 

SQL> create index idx_t_heap_name on t_heap(object_name);

 

Index created

 

SQL> select count(*) from t_heap;

 

  COUNT(*)

----------

     72605

 

SQL> select sum(bytes)/1024/1024, count(*) from dba_extents where wner='SYS' and segment_name='IDX_T_HEAP_NAME';

 

SUM(BYTES)/1024/1024   COUNT(*)

-------------------- ----------

                   3         18

 

 

相同取值，正常index只有3M空间，约占到18个分区。说明：Secondary Index对比一些其他索引，有很多特殊的信息在其中。

 

 

SQL> col object_name for a20;

SQL> select object_id, object_name from dba_objects where object_name in ('IDX_T_HEAP_NAME','IDX_T_IOT_NAME');

 

 OBJECT_ID OBJECT_NAME

---------- --------------------

     75146 IDX_T_HEAP_NAME

     75143 IDX_T_IOT_NAME

 

 

我们尝试将两个索引树dump出来，探索其结构差异。

 

 

SQL> select value from v$diag_info where name='Default Trace File';

 

VALUE

--------------------------------------------------------------------------------

/u01/diag/rdbms/wilson/wilson/trace/wilson_ora_9101.trc

 

--堆表索引结构

SQL> alter system set events 'immediate trace name treedump level  75146';

System altered

 

--IOT表索引结构

SQL> alter system set events 'immediate trace name treedump level  75143';

System altered

 

 

 

首先，我们分析一下一般堆表的索引情况。由于篇幅原因，只截取部分内容。

 

 

*** ACTION NAME:(Command Window - New) 2012-10-05 02:43:39.561

 

----- begin tree dump

branch: 0x415c01 4283393 (0: nrow: 2, level: 2)

   branch: 0x415d3b 4283707 (-1: nrow: 312, level: 1)

      leaf: 0x415c02 4283394 (-1: nrow: 184 rrow: 184)

      leaf: 0x415c03 4283395 (0: nrow: 184 rrow: 184)

      leaf: 0x415c04 4283396 (1: nrow: 188 rrow: 188)

      leaf: 0x415c05 4283397 (2: nrow: 190 rrow: 190)

      leaf: 0x415c06 4283398 (3: nrow: 184 rrow: 184)

      leaf: 0x415c07 4283399 (4: nrow: 186 rrow: 186)

      leaf: 0x415c08 4283400 (5: nrow: 185 rrow: 185)

 

 

从Dump结果上，我们可以清晰看到IDX_T_HEAP_NAME是一个两层索引结构。根节点地址为0x415c01（file=1, block=89089）。

 

 

SQL> select to_number('415c01','xxxxxx') from dual;

 

TO_NUMBER('415C01','XXXXXX')

----------------------------

                     4283393

 

 

其中的一个数据块0x415c06进行试验，转化为十进制地址为4283398，二进制地址为：10000010101110000000110。根据rfile解析规则，最终地址为：file_no=1，block_no=89094。

 

 

SQL> alter system dump datafile 1 block 89094;

System altered

 

Dump文件中叶子节点的内容为：

 

row#0[8000] flag: ------, lock: 0, len=32

col 0; len 22; (22):

 2f 31 34 64 63 62 36 32 32 5f 53 79 6e 74 68 4c 61 62 65 6c 55 49

col 1; len 6; (6):  00 41 55 91 00 4b

row#1[7968] flag: ------, lock: 0, len=32

col 0; len 22; (22):

 2f 31 34 64 63 62 36 32 32 5f 53 79 6e 74 68 4c 61 62 65 6c 55 49

col 1; len 6; (6):  00 41 55 91 00 4c

row#2[7928] flag: ------, lock: 0, len=40

col 0; len 30; (30):

 2f 31 34 65 33 63 31 31 32 5f 50 4e 47 45 6e 63 6f 64 65 50 61 72 61 6d 50

 61 6c 65 74 74

col 1; len 6; (6):  00 41 5b 9a 00 9d

 

 

 

从结构上猜测，col0和col1分别表示索引列取值和对应rowid信息。而IOT的secondary index如何呢？

 

 

*** 2012-10-05 02:43:55.944

----- begin tree dump

branch: 0x4154b9 4281529 (0: nrow: 2, level: 2)

   branch: 0x415acd 4283085 (-1: nrow: 330, level: 1)

      leaf: 0x4154ba 4281530 (-1: nrow: 160 rrow: 160)

      leaf: 0x4154bb 4281531 (0: nrow: 158 rrow: 158)

      leaf: 0x4154bc 4281532 (1: nrow: 163 rrow: 163)

      leaf: 0x4154bd 4281533 (2: nrow: 162 rrow: 162)

      leaf: 0x4154be 4281534 (3: nrow: 163 rrow: 163)

      leaf: 0x4154bf 4281535 (4: nrow: 160 rrow: 160)

      leaf: 0x4154c0 4281536 (5: nrow: 159 rrow: 159)

      leaf: 0x4154c1 4281537 (6: nrow: 161 rrow: 161)

      leaf: 0x4154c2 4281538 (7: nrow: 160 rrow: 160)

 

 

叶子节点0x4154bc，对应具体的二进制为：10000010101010010111100。分析获得的位置为：file_no=1，block_no=87228。

 

我们将该块dump出。

 

 

SQL> alter system dump datafile 1 block 87228;

System altered

 

 

row#0[7986] flag: K-----, lock: 0, len=46

col 0; len 30; (30):

 2f 31 32 30 66 34 37 30 38 5f 46 75 6c 6c 48 54 4d 4c 44 6f 63 75 6d 65 6e

 74 61 74 69 6f

col 1; len 4; (4):  c3 04 39 24

tl: 8 fb: --H-FL-- lb: 0x0  cc: 1

col  0: [ 4]  00 41 59 3e

row#1[7940] flag: K-----, lock: 0, len=46

col 0; len 30; (30):

 2f 31 32 30 66 64 37 36 64 5f 4f 72 61 63 6c 65 44 61 74 61 62 61 73 65 4d

 65 74 61 44 61

col 1; len 4; (4):  c3 02 50 1a

tl: 8 fb: --H-FL-- lb: 0x0  cc: 1

col  0: [ 4]  00 41 54 a1

row#2[7894] flag: K-----, lock: 0, len=46

col 0; len 30; (30):

 2f 31 32 30 66 64 37 36 64 5f 4f 72 61 63 6c 65 44 61 74 61 62 61 73 65 4d

 65 74 61 44 61

col 1; len 4; (4):  c3 04 4c 1a

tl: 8 fb: --H-FL-- lb: 0x0  cc: 1

col  0: [ 4]  00 41 54 a2

 

 

上面标红的部分是我们看到了和Heap Index的差异，正式由于这部分信息的差异，才让IOT Secondary Index体积略大。

 

从概念上，Secondary Index包括三部分叶子节点内容：索引键值、logical rowid和对应数据行的主键值。在进行检索的时候，Oracle首先用logical rowid进行初步的试探，看看对应的位置是否可以找到对应数据。这个过程我们称为physical guess。

 

如果找到了对应数据行，那么皆大欢喜。如果没有，oracle就只能通过数据行的主键值，进行IOT索引树定位。这个过程，要重复多读一个段结构。

 

具体Secondary Index的分析，留待下次进行更加详细的说明。

 

7、IOT的使用

 

我们已经在一个系列中，详细介绍了IOT的特性，最后我们聊一聊IOT应用的场景。总的来说，笔者认为IOT在一般系统的应用中，是没有很广泛的发挥场景的。在没有明确的分析和POC实验基础上，我们不要轻易进行IOT决策。具体来说，有如下的几点：

 

ü  IOT环境下，有更多的限制

 

我们常使用的堆表，虽然有各种问题，但是是目前我们可以得到的适应性最广，优化策略最多的一种表存储结构。IOT则要受到很多的限制，例如：IOT必须要制定主键，也就是定义出核心访问方式；PCTThreshold参数如果设置了，但是没有指定overflew segment，那么超出阈值的数据行是不会被接受，要抛出异常。IOT表中分区和Lob类型不能同时使用。IOT维护工作要更多。

 

ü  单一读取，读多写少的操作类型

 

我们定义出IOT后，实际上就是规定了数据表的核心访问方式。当我们使用主键条件时，IOT可以方便的帮助我们定位记录。但是其他查询条件应用secondary index的效率就是一个问题。而且secondary index也是不久前才支持的Oracle特性。如果我们的数据表应用是一个多种检索方式并存的操作表，那么IOT不是理想的选择。

 

索引操作本身对增加、修改和删除等DML操作是具有性能影响的。在IOT环境下，这种影响只会让其更加剧烈。所以，如果数据表不是很少修改的数据表，那么使用IOT不是最好的选择。

 

ü  主键列和列数目的约束

 

索引叶子节点中就能将所有数据行列保存在叶子节点上。而索引叶子节点是变化分裂频繁的对象。所以，如果数据行列数很多，或者数据主键列相对很小，那么IOT的效果是不好的。

 

 

8、结论

 

Heap，IOT和Cluster是数据表的三大基本存储类型。我们在实际中，要把握原则是：以堆表为核心，默认都使用Heap Table。如果在架构分析、性能测试和试运行阶段，发现性能问题，可以考虑使用IOT或者Cluster。但是，在选型的时候，一定要明确两种表结构的优缺点和适用范围。