PLSQL_性能优化系列12_Oracle Index Anaylsis索引分析

简介: 2014-10-04 Created By BaoXinjian 一、摘要 1. 索引质量 索引质量的高低对数据库整体性能有着直接的影响。 良好高质量的索引使得数据库性能得以数量级别的提升,而低效冗余的索引则使得数据库性能缓慢如牛,即便是使用高档的硬件配置。

2014-10-04 Created By BaoXinjian

一、摘要


1. 索引质量

索引质量的高低对数据库整体性能有着直接的影响。

良好高质量的索引使得数据库性能得以数量级别的提升,而低效冗余的索引则使得数据库性能缓慢如牛,即便是使用高档的硬件配置。

因此对于索引在设计之初需要经过反复的测试与考量。

那对于已经置于生产环境中的数据库,我们也可以通过查询相关数据字典得到索引的质量的高低,通过这个分析来指导如何改善索引的性能。

 

2. 索引创建的基本指导原则

索引的创建应遵循精而少的原则

收集表上所有查询的各种不同组合,找出具有最佳离散度的列(或主键列等)创建单索引

对于频繁读取而缺乏比较理想离散值的列为其创建组合索引

对于组合索引应考虑下列因素来制定合理的索引列顺序,以下优先级别由高到低来作为索引的前导列,第二列等等

  • 列被使用的频率
  • 该列是否经常使用“ = ”作为常用查询条件
  • 列上的离散度
  • 组合列经常按何种顺序排序
  • 哪些列会作为附件性列被添加 

 

二、索引的聚簇因子


聚簇因子是 Oracle 统计信息中在CBO优化器模式下用于计算cost的参数之一,决定了当前的SQL语句是否走索引,还是全表扫描以及是否作为嵌套连接外部表等。

1. 堆表的存储方式

Oralce 数据库系统中最普通,最为常用的即为堆表。

堆表的数据存储方式为无序存储,也就是任意的DML操作都可能使得当前数据块存在可用的空闲空间。

处于节省空间的考虑,块上的可用空闲空间会被新插入的行填充,而不是按顺序填充到最后被使用的块上。

上述的操作方式导致了数据的无序性的产生。

当创建索引时,会根据指定的列按顺序来填充到索引块,缺省的情况下为升序。

新建或重建索引时,索引列上的顺序是有序的,而表上的顺序是无序的,也就是存在了差异,即表现为聚簇因子。

2. 什么是聚簇因子(Clustering Factor/CF)

聚簇因子是基于表上索引列上的一个值,每一个索引都有一个聚簇因子。

用于描述索引块上与表块上存储数据在顺序上的相似程度,也就说表上的数据行的存储顺序与索引列上顺序是否一致。

在全索引扫描中,CF的值基本上等同于物理I/O或块访问数,如果相同的块被连续读,则Oracle认为只需要1次物理I/O。

好的CF值接近于表上的块数,而差的CF值则接近于表上的行数。

聚簇因子在索引创建时就会通过表上存存在的行以及索引块计算获得。

3. 聚簇因子结构图

(1). 良好的索引与聚簇因子的情形

(2). 良好的索引、差的聚簇因子的情形

(3). 差的索引、差的聚簇因子的情形

 

三、案例 - 表上索引和索引质量


1. 查询单表上索引列的相关信息

SQL> @/home/oracle/sql/idx_info.sql
Enter value for owner: SH
Enter value for table_name: SALES

Table                     Index                     CL_NAM               CL_POS STATUS   IDX_TYP         DSCD
------------------------- ------------------------- -------------------- ------ -------- --------------- ----
SALES                     SALES_CHANNEL_BIX         CHANNEL_ID                1 N/A      BITMAP          ASC
                          SALES_CUST_BIX            CUST_ID                   1 N/A      BITMAP          ASC
                          SALES_PROD_BIX            PROD_ID                   1 N/A      BITMAP          ASC
                          SALES_PROMO_BIX           PROMO_ID                  1 N/A      BITMAP          ASC
                          SALES_TIME_BIX            TIME_ID                   1 N/A      BITMAP          ASC

5 rows selected.

(1). 从上面的查询结果可知,当前表TRADE_CLIENT_TBL上含有4个索引,应该来说该表索引存在一定冗余。  
(2). 大多数情况下,单表上6-7个索引是比较理想的。过多的索引导致过大的资源开销,以及降低DML性能。

2. 获取指定schema或表上的索引质量信息报告

SQL> @/home/oracle/sql/idx_quality.sql
Enter value for input_owner: SH
Enter value for input_tbname: SALES

                                 Table      Table                             Index Data Blks Leaf Blks        Clust Index
Table                             Rows     Blocks Index                     Size MB   per Key   per Key       Factor Quality
------------------------- ------------ ---------- ------------------------- ------- --------- --------- ------------ -------------
SALES                          918,843       1769 SALES_PROD_BIX                  0        14         1        1,074 5-Excellent
                                                  SALES_CUST_BIX                  0         5         1       35,808 5-Excellent
                                                  SALES_TIME_BIX                  0         1         1        1,460 5-Excellent
                                                  SALES_CHANNEL_BIX               0        23        11           92 5-Excellent
                                                  SALES_PROMO_BIX                 0        13         7           54 5-Excellent
     5 rows selected.

(1). 从上面的单表输出的索引质量可知,出现了4个处于Poor级别的索引,也就是说这些个索引具有较大的聚簇因子,几乎接近于表上的行了  
(2). 对于这几个索引的质量还应结合该索引的使用频率来考量该索引存在的必要性  
(3). 对于聚簇因子,只能通过重新组织表上的数据来,以及调整相应索引列的顺序得以改善
 

四、案例 - 索引的使用频率报告


Oracle提供了索引监控特性来判断索引是否被使用。在Oracle 10g中,收集统计信息会使得索引被监控,在Oracle 11g中该现象不复存在。

尽管如此,该方式仅提供的是索引是否被使用。索引被使用的频率未能得以体现。

下面的脚本将得到索引的使用率,可以很好的度量索引的使用情况以及根据这个值来判断当前的这些索引是否可以被移除或改进。\

参考了沙弥大神

 

1. 判断索引是否被使用

SQL> @/home/oracle/sql/idx_usage_detail.sql SH 1

                                                                                    Index
Table name                     Index name                     Index type          Size MB Index operation       Executions
------------------------------ ------------------------------ --------------- ----------- --------------------- ----------
COSTS                          COSTS_PROD_BIX                 BITMAP                 1.75        -                       0
                               COSTS_TIME_BIX                 BITMAP                 1.75        -                       0
****************************** ****************************** *************** -----------                       ----------
sum                                                                                  3.50                                0


SALES                          SALES_CHANNEL_BIX              BITMAP                 1.75        -                       0
                               SALES_CUST_BIX                 BITMAP                 5.69 SINGLE VALUE                   2
                                                                                          FAST FULL SCAN                 1
                               SALES_PROD_BIX                 BITMAP                 1.75 SINGLE VALUE                   3
                                                                                          FAST FULL SCAN                 1
                               SALES_PROMO_BIX                BITMAP                 1.75 FULL SCAN                      1
                               SALES_TIME_BIX                 BITMAP                 1.94        -                       0
****************************** ****************************** *************** -----------                       ----------
sum                                                                                 20.31                                8



9 rows selected. 

(1). 上面的结果列出了当前数据库中schema为SH且索引大小大于1MB的索引的使用频率。

(2). 由于当前的数据库为标准版,没有分区表功能,所以可以看到很多arc结尾的表,且索引很大,如ACC_POS_STOCK_TBL_ARC上索引达到19G。

(3). 表SALES的主键SALES_PROD_BIX上范围扫描最多,总计被使用次数为3次。

(4). 对于上述列出的被使用的次数为0的那些索引,应考虑索引的设置是否合理。

(5). 过大的索引应考虑能否使用索引压缩。

(6). 最后列出的是报告的schema名称以及索引大小的过滤条件、索引被收集的日期。注,索引列的大小sum求和有些不准确。

2. 总结

本使用了2个替代变量,一个是schema,一个是索引的大小。

缺省情况下,对于那些较小 的索引以及仅仅运行一至两次的sql语句的历史执行计划不会被收集到DBA_HIST_SQL_PLAN。

因此执行脚本时索引大小输入的建议值是100。

如果需要收集所有的历史sql执行计划来判断索引是否被使用,需要修改statistics_level为all或者修改snapshot的收集策略。

收集策略对系统性能有一定的影响,以及耗用大量磁盘空间,因此Prod环境应慎用(UAT和DEV则无妨)。

 

脚本下载 (由了沙弥大神整理,借用下)

1. idx_info.sql               http://files.cnblogs.com/eastsea/idx_info.zip

2. idx_quality.sql           http://files.cnblogs.com/eastsea/idx_quality.zip

3. idx_usage_detail.sql   http://files.cnblogs.com/eastsea/idx_usage_detail.zip


Thanks and Regards

参考:了沙弥大神 http://blog.csdn.net/leshami/article/details/23687137

ERP技术讨论群: 288307890
技术交流,技术讨论,欢迎加入
Technology Blog Created By Oracle ERP - 鲍新建
相关文章
|
5月前
|
存储 Java 数据库
JAVAEE框架数据库技术之13_oracle 之PLSQL技术及存储过程和函数(二)
JAVAEE框架数据库技术之13_oracle 之PLSQL技术及存储过程和函数
73 0
|
5月前
|
存储 Oracle 关系型数据库
Oracle索引知识看这一篇就足够
Oracle索引知识看这一篇就足够
|
5月前
|
SQL 监控 Oracle
Oracle 性能优化之AWR、ASH和ADDM(含报告生成和参数解读)
Oracle 性能优化之AWR、ASH和ADDM(含报告生成和参数解读)
|
5月前
|
Oracle 网络协议 关系型数据库
异地使用PLSQL远程连接访问Oracle数据库【内网穿透】
异地使用PLSQL远程连接访问Oracle数据库【内网穿透】
|
5月前
|
存储 Oracle 关系型数据库
Oracle 12c的多重索引:数据的“多维导航仪”
【4月更文挑战第19天】Oracle 12c的多重索引提升数据查询效率,如同多维导航仪。在同一表上创建针对不同列的多个索引,加速检索过程。虽然过多索引会增加存储和维护成本,但合理选择和使用索引策略,结合位图、函数索引等高级特性,能优化查询,应对复杂场景。数据管理员应善用这些工具,根据需求进行索引管理,支持企业数据分析。
|
5月前
|
Oracle 关系型数据库 Java
plsql链接远程Oracle数据库步骤
实际工作中,我们往往需要使用 PLSQL Develope 工具连接远程服务器上的 ORACLE 数据库进行管理,但是由于 ORACLE 安装在本地电脑步骤繁琐,并且会耗费电脑的很大一部分资源,因此,我们寻求一种不需要在本地安装 ORACLE 数据库而能直接使用 PLSQL Develope 工具连接到远程服务器 ORACLE 的方法。
96 2
|
5月前
|
SQL Oracle 关系型数据库
[Oracle]索引
[Oracle]索引
103 0
[Oracle]索引
|
2月前
|
存储 自然语言处理 Oracle
Oracle数据库字符集概述及修改方式
【8月更文挑战第15天】Oracle 数据库字符集定义了数据的编码方案,决定可存储的字符类型及其表示方式。主要作用包括数据存储、检索及跨系统传输时的正确表示。常见字符集如 AL32UTF8 支持多语言,而 WE8MSWIN1252 主用于西欧语言。修改字符集风险高,可能导致数据问题,需事先备份并评估兼容性。可通过 ALTER DATABASE 语句直接修改或采用导出-导入数据的方式进行。完成后应验证数据完整性。此操作复杂,须谨慎处理。
|
2月前
|
数据采集 Oracle 关系型数据库
实时计算 Flink版产品使用问题之怎么实现从Oracle数据库读取多个表并将数据写入到Iceberg表
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
|
24天前
|
Oracle 关系型数据库 数据库
数据库数据恢复—Oracle数据库文件出现坏块的数据恢复案例
打开oracle数据库报错“system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。 数据库没有备份,无法通过备份去恢复数据库。用户方联系北亚企安数据恢复中心并提供Oracle_Home目录中的所有文件,急需恢复zxfg用户下的数据。 出现“system01.dbf需要更多的恢复来保持一致性”这个报错的原因可能是控制文件损坏、数据文件损坏,数据文件与控制文件的SCN不一致等。数据库恢复工程师对数据库文件进一步检测、分析后,发现sysaux01.dbf文件损坏,有坏块。 修复并启动数据库后仍然有许多查询报错,export和data pump工具使用报错。从数据库层面无法修复数据库。
数据库数据恢复—Oracle数据库文件出现坏块的数据恢复案例

推荐镜像

更多