ORACLE不可见索引(Invisible Indexes)

 

不可见索引概念

 

不可见索引(Invisible Index)是ORACLE 11g引入的新特性。不可见索引是会被优化器忽略的不可见索引,除非在会话或系统级别上将OPTIMIZER_USE_INVISIBLE_INDEXES初始化参数显式设置为TRUE。此参数的默认值是FALSE。如果是虚拟索引是为了合理、科学新增索引而设计的,那么不可见索引就是为了合理、科学的删除索引而设计的。为什么这样说呢? 因为DBA在维护索引时,我们经常会找出无用或低效的索引,并删除这些索引,在生产环境下,删除索引还是有一定风险的,即使ORACLE提供了监控索引使用情况的技术。例如,某些索引可能只是在一些周期的作业中被使用到,而如果监控周期没有覆盖到这些作业的触发点,就会认为索引是无用的而被删除。当作业启动后,可能就会对系统性能造成冲击。这时,可能就会手忙脚乱的去找回索引定义语句、重建索引。11G之前,我们可以先不删除索引,而将其修改为unusable。这样的话,索引的定义并未删除,只是索引不能再被使用也不会随着表数据的更新而更新。当需要重新使用该索引时,需要用rebuild语句重建、然后更新统计信息。对于一些大表来说,这个时间可能就非常长。在ORACLE 11g里提供了一个新的特性来降低直接删除索引或者禁用索引的风险,那就是索引不可见(Index Invisible)。我们可以将无用或低效的索引设置为不可见索引,当观察一段时间后,发现其对系统性能并无任何影响,那么就可以彻底删除索引了。

                                                                                                

 

Beginning with Release 11g, you can create invisible indexes. An invisible index is an index that is ignored by the optimizer and the user unless you explicitly set the OPTIMIZER_USE_INVISIBLE_INDEXES initialization parameter to TRUE at the session or system level.The default value for this parameter is FALSE.

 

Using invisible indexes, you can do the following:

 

1.Test the removal of an index before dropping it.

 

2.Use temporary index structures for certain operations or modules of an application without affecting the overall application.

 

Unlike unusable indexes, an invisible index is maintained during DML statements.

 

 

不可见索引测试

 

 

创建测试表TEST,在表上新建不可见索引IDX_TEST_ID,不可见索引可以从字段VISIBILITY这个字段来区别,如下所示:

 

 

SQL> create table test
  2  as
  3  select * from dba_objects;
 
Table created.
 
SQL> create index idx_test_id on test(object_id) invisible;
 
Index created.
 
SQL> select index_name, status,visibility from dba_indexes where index_name=upper('idx_test_id');
 
INDEX_NAME                     STATUS   VISIBILIT
------------------------------ -------- ---------
IDX_TEST_ID                    VALID    INVISIBLE
 
 
 
SQL> show parameter optimizer_use_invisible_indexes;
 
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
optimizer_use_invisible_indexes      boolean     FALSE
SQL>                                                                                    
SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS(OWNNAME =>USER,TABNAME=>'TEST',CASCADE => TRUE);
 
PL/SQL procedure successfully completed.

 

 

如下所示,优化器是“看不见”这个索引的,即使使用提示hint强制其走这个索引。优化器还是不会走索引扫描

 

 

SQL> set autotrace traceonly;
SQL> select * from test where object_id=12;
 
 
Execution Plan
----------------------------------------------------------
Plan hash value: 1357081020
 
--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |     1 |    97 |   282   (1)| 00:00:04 |
|*  1 |  TABLE ACCESS FULL| TEST |     1 |    97 |   282   (1)| 00:00:04 |
--------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter("OBJECT_ID"=12)
 
 
Statistics
----------------------------------------------------------
        424  recursive calls
          0  db block gets
       1094  consistent gets
          0  physical reads
          0  redo size
       1604  bytes sent via SQL*Net to client
        523  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          4  sorts (memory)
          0  sorts (disk)
          1  rows processed
 
 
 
SQL> select /*+ index(text, idx_test_id) */ * from test where object_id=12;
 
 
Execution Plan
----------------------------------------------------------
Plan hash value: 1357081020
 
--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |     1 |    97 |   282   (1)| 00:00:04 |
|*  1 |  TABLE ACCESS FULL| TEST |     1 |    97 |   282   (1)| 00:00:04 |
--------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter("OBJECT_ID"=12)
 
 
Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
       1036  consistent gets
          0  physical reads
          0  redo size
       1604  bytes sent via SQL*Net to client
        523  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

 

设置参数optimizer_use_invisible_indexes为true后,此时优化器就会走索引范围扫描了。

 

SQL> alter session set optimizer_use_invisible_indexes=true;
 
Session altered.
 
SQL> select * from test where object_id=12;
 
 
Execution Plan
----------------------------------------------------------
Plan hash value: 1345973065
 
-------------------------------------------------------------------------------------------
| Id  | Operation                   | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |             |     1 |    97 |     2   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| TEST        |     1 |    97 |     2   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | IDX_TEST_ID |     1 |       |     1   (0)| 00:00:01 |
-------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("OBJECT_ID"=12)
 
 
Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          4  consistent gets
          0  physical reads
          0  redo size
       1607  bytes sent via SQL*Net to client
        523  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

 

 

 

早期版本中,不可见索引有一些Bug,下面整理了一些这方面的Bug,应用相关的补丁或最新的版本都可避免碰到这些Bug。

 

1:使用DBMS_METADATA.GET_DDL获取不可见索引的定义不正确,少了关键字invisible

 

详情参考:DBMS_METADATA.GET_DDL Returns Incorrect DDL For Invisible Index (文档 ID 1965563.1)

 

 

2:Bug 9336476 - Optimizer 10053 trace shows wrong status for INVISIBLE index(文档 ID 9336476.8)

 

3:Bug 16544878 - Drop invisible index affects SQL execution plan (文档 ID 16544878.8)

 

4:Wrong Result With Invisible Index (文档 ID 1266380.1)


 

 

UPDATE statement fails with below error when all indexes are marked invisible.

ORA-14406: updated partition key is beyond highest legal partition key

The execution plan of the UPDATE is parallel plan.

 

5: Bug 9347681 - OERI [12863] with invisible indexing(文档 ID 9347681.8)

 

 

参考资料

 

http://blog.itpub.net/26736162/viewspace-2124044

时间: 2024-10-25 15:41:32

ORACLE不可见索引(Invisible Indexes)的相关文章

[20120514]Invisible Indexes and FK问题.txt

[20120514]Invisible Indexes and FK问题.txt SQL> select * from v$version ; BANNER------------------------------------------------------------------------------Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit ProductionPL/SQL Release 11.

为什么有时 Oracle 数据库不用索引来查找数据

oracle|数据|数据库|索引 当你运用 SQL 语言,向数据库发布一条查询语句时, ORACLE 将伴随产生一个"执行计划",也就是该语句将通过何种数据搜索方案执行,是通过全表扫描.还是通过索引搜寻等其它方式.搜索方案的选用与 ORACLE 的优化器息息相关. SQL 语句的执行步骤. 1 语法分析 分析语句的语法是否符合规范,衡量语句中各表达式的意义. 2 语义分析 检查语句中涉及的所有数据库对象是否存在,且用户有相应的权限. 3 视图转换 将涉及视图的查询语句转换为相应的对基表

AliSQL · 特性介绍 · 支持 Invisible Indexes

前言 MySQL 8.0 引入了 Invisible Indexes 这一个特性,对于 DBA 同学来说是一大福音,索引生命周期管理除了有和无外,又多了一种形态–可见和不可见,进而对业务SQL的调优又多了一种手段. 关于 Invisible Indexes,不管是官方还是第三方,都有非常多的介绍文档,这里推荐大家可以先看下: 官方文档: Invisible Indexes 官方 server 层团队博客: MySQL 8.0: Invisible Indexes 官方 worklog: WL#8

AliSQL 20170716版本发布 Invisible Indexes 功能和 SELECT FROM UPDATE 语法

Abstract 在传统的关系数据库中,想要在堆表或者索引组织表中快速的检索到目标数据,添加索引是一个常用的手段,但过多的索引不但增加空间的开销,还会带来写入性能的衰减,如何降低在线删除索引的风险,Invisible Indexes 提供了一个风险可控的方法. 在面临一个常见的业务场景,比如更新某行记录,然后查询变更后的记录内容的时候,通常都是UPDATE + SELECT 两条语句来完成,AliSQL 扩展了语法,提供SELECT...FROM UPDATE语句,在完成update变更的同时,

Oracle之函数索引

Oracle之函数索引 在Oracle中,有一类特殊的索引,称为函数索引(Function-Based Indexes,FBI),它基于对表中列进行计算后的结果创建索引.函数索引在不修改应用程序的逻辑基础上提高了查询性能.如果没有函数索引,那么任何在列上执行了函数的查询都不能使用这个列的索引.当在查询中包含该函数时,数据库才会使用该函数索引.函数索引可以是一个B-Tree索引或位图索引. 用于生成索引的函数可以是算术表达式,也可以是一个包含SQL函数.用户定义PL/SQL函数.包函数,或C调用的

Oracle技术:索引与Null值对于Hints及执行计划的影响

由于B*Tree索引不存储Null值,所以在索引字段允许为空的情况下,某些Oracle查询不会使用索引. 很多时候,我们看似可以使用全索引扫描(Full Index Scan)的情况,可能Oracle就会因为Null值的存在而放弃索引. 在此情况下即使使用Hints,Oracle也不会使用索引,其根本原因就是因为Null值的存在. 我们看以下测试. 在username字段为Not Null时,Index Hints可以生效. 更多精彩内容:http://www.bianceng.cnhttp:/

oracle中,索引数据定位和索引扫描有什么区别?

问题描述 oracle中,索引数据定位和索引扫描有什么区别? oracle中,索引数据定位和索引扫描有什么区别? 是不是就是简单的扫描就是要扫完,定位只要查到就可以了? 解决方案 oracle索引扫描索引扫描高手闲谈Oracle索引扫描 解决方案二: http://blog.sina.com.cn/s/blog_54eeb5d90100q9zu.html 解决方案三: 索引数据定位和索引扫描 你说的应该是索引数据定位和全表扫描吧?如果用到索引的话,没必要进行扫描,可以通过二分法快速定位

ORACLE Index Lookup索引访问路径总结

  在ORACLE中,索引访问/查找(Index Lookup)路径有五种方式,分别为INDEX UNIQUE SCAN.INDEX RANGE SCAN.INDEX FULL SCAN.INDEX FAST FULL SCAN .INDEX SKIP SCAN.下面通过一些案例介绍.总结一下这五种索引访问路径.本文是总结这方面的知识点,所以文中一些地方参考.引用了参考资料中的部分内容.详细.具体资料可以参考官方资料Index Scans         索引唯一扫描(INDEX UNIQUE

Oracle关于重建索引争论的总结_oracle

索引重建是一个争论不休被不断热烈讨论的议题.当然Oracle官方也有自己的观点,我们很多DBA也是遵循这一准则来重建索引,那就是Oracle建议对于索引深度超过4级以及已删除的索引条目至少占有现有索引条目总数的20% 这2种情形下需要重建索引.近来Oracle也提出了一些与之相反的观点,就是强烈建议不要定期重建索引.本文是参考了1525787.1并进行相应描述. 1.重建索引的理由     a.Oracle的B树索引随着时间的推移变得不平衡(误解)     b.索引碎片在不断增加     c.索