不可见索引(invisible index)在表DML操作过程中依然被维护

 在文章《【 INDEX 】 11g 中利用 不可见索引 降低索引 维护 时对系统的冲击》（http://space.itpub.net/519536/viewspace-662238）中介绍了关于11g的新特性“不可见索引”，这项新 技术 给出了在不删除索引的情况下来判断有无索引对 SQL 语句执行计划的影响，以便辅助判断索引是否可以被真正的删除。在使用这项技术的过程中，需要 注意 一点：虽然索引被标识为“不可见”，这仅仅指的是索引本身在生成SQL执行计划时不会考虑使用相应索引，但是，索引本身还是会随表的变化而进行进行维护，这里给出 实验 来说明。

1.演示不可见索引使用方法
1）当使用普通索引时的SQL执行计划
sys@ora11g> conn sec/sec
Connected.
sec@ora11g> create table t as select * from all_objects;

Table created.

sec@ora11g> create index i_t on t(object_id);

Index created.

sec@ora11g> set autot traceonly exp
sec@ora11g> select * from t where OBJECT_ID = 666;

Execution Plan
----------------------------------------------------------
Plan hash value: 2928007915

------------------------------------------------------------------------------------
| Id  | Operation                   | Name | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |      |     1 |   158 |     2   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| T    |     1 |   158 |     2   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | I_T  |     1 |       |     1   (0)| 00:00:01 |
------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("OBJECT_ID"=666)

Note
-----
   - dynamic sampling used for this statement (level=2)

可见，此时SQL语句使用的是I_T这个索引构造的SQL执行计划。

2）将索引调整为不可见索引后查看SQL语句执行计划
sec@ora11g> alter index i_t invisible;

Index altered.

sec@ora11g> select * from t where OBJECT_ID = 666;

Execution Plan
----------------------------------------------------------
Plan hash value: 1601196873

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |    11 |  1738 |   285   (1)| 00:00:04 |
|*  1 |  TABLE ACCESS FULL| T    |    11 |  1738 |   285   (1)| 00:00:04 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("OBJECT_ID"=666)

Note
-----
   - dynamic sampling used for this statement (level=2)

此时，虽然索引依然存在，但是构造SQL语句的执行计划的时候不再考虑索引，这里使用的是T表全表扫描方式获取数据。

2.查看索引的使用情况
sec@ora11g> analyze index I_T validate structure;

Index analyzed.

sec@ora11g> set autot off
sec@ora11g> select height, lf_blks, br_blks, btree_space from index_stats;

    HEIGHT    LF_BLKS    BR_BLKS BTREE_SPACE
---------- ---------- ---------- -----------
         2        158          1     1271396

此时索引使用了158个叶子块。

3.向T表插入数据
sec@ora11g> insert into t select * from all_objects;

71463 rows created.

这里先不提交事务。

4.重新获取索引的使用情况
sec@ora11g> analyze index I_T validate structure;

Index analyzed.

sec@ora11g> select height, lf_blks, br_blks, btree_space from index_stats;

    HEIGHT    LF_BLKS    BR_BLKS BTREE_SPACE
---------- ---------- ---------- -----------
         2        321          1     2574744

可见，此时索引占用了321个叶子块，几乎是原先的的2倍。

5.回滚事务后再次查询索引使用情况
sec@ora11g> rollback;

Rollback complete.

sec@ora11g> analyze index I_T validate structure;

Index analyzed.

sec@ora11g> select height, lf_blks, br_blks, btree_space from index_stats;

    HEIGHT    LF_BLKS    BR_BLKS BTREE_SPACE
---------- ---------- ---------- -----------
         2        321          1     2574744

显然，曾经被分配的索引块和空间没有被释放（这与索引特点相关）。

6.小结
  本文通过实验给出了在表内容发生变化的过程中，不可见索引是随着表的内容变化而变化的。这一点在使用不可见索引的过程中一定要多加注意。当使用不可见索引技术判断一个索引的确不再需要的时候，请尽快找到合适的维护窗口将其删除掉，否则会因多余的索引导致DML操作性能低下。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23071790/viewspace-734457/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/23071790/viewspace-734457/