在文章《【
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操作性能低下。
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/