索引跳跃式扫描（INDEX SKIP SCAN），需要在CBO模式下才能起作用，当查询谓词中不带有前导列，且前导列唯一值较少时，才有可能用上该索引扫描方式。下面来看看INDEX SKIP SCAN 是如何扫描的：

昨天写了个索引与NULL值，回头查看了资料，发现理解得太单一了，没把组合索引考虑上，而且组合索引中，NULL不是不记录，应该理解为不完全记录：

常见的B-Tree单列索引中，并不会记录null值的索引条目，因而is null等条件的查询走不了索引，走的是全表扫，而Bitmap索引则不同，它会记录NULL值的索引条目：

一、前一篇文章的案例中提到,索引损坏了，重建索引时，直接rebuild报错，而rebuild online则可以，这主要是两者重建索引时的扫描方式不同，rebuild用的是“INDEX FAST FULL SCAN”，rebuild online用的是“TABLE ACCESS FULL”：

上周公司组织了一次拓展，大老远地从杭州跑到金华去，说是那风景好，汗。第一次参加拓展活动，感觉还不错。过缅甸桥、爬天梯、攀岩、哑人搭塔、沙漠掘金，都挺有意思的。印象比较深刻的还有早上起来活动的“早上操”，本想找几张图出来给大家看看的，可惜没搜到。还有练反应的“一只枪打四只鸟”，刚开始一点反应不过来，练了练，现在就玩得挺溜的了。

执行truncate partition时报错：

SQL> alter table EC_IOM_OCMDRDER_TBL 
truncate partition E_I_O_T_2009_APR update global indexes
            *
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-08102: index key not found, obj# 6958, dba 113254602 (2)

系统出现好几百个enq: TX - row lock contention，MODE为6,检查发现是一个会话在执行select…for update并且不带where条件，阻塞了其它会话，检查用户的权限发现，这个用户只有Select该表的权限。这才发现原来没有update表的权限，也可以执行select…for update，并持有锁。

主要就是观察下，唯一索引与非唯一索引中，Branch block与Leaf block分别记录了些什么，有何不同之处。