下面我们讨论一下由于数据存储为索引而带来的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。但是，在选型的时候，一定要明确两种表结构的优缺点和适用范围。
