Oracle索引质量介绍和分析脚本分享

索引质量的高低对数据库整体性能有着直接的影响。良好高质量的索引使得数据库性能得以数量级别的提升,而低效冗余的索引则使得数据库性能缓慢如牛,即便是使用高档的硬件配置。因此对于索引在设计之初需要经过反复的测试与考量。那对于已经置于生产环境中的数据库,我们也可以通过查询相关数据字典得到索引的质量的高低,通过这个分析来指导如何改善索引的性能。下面给出了演示以及索引创建的基本指导原则,最后给出了索引质量分析脚本。

1、查看索引质量

--获取指定schema或表上的索引质量信息报告
gx_adm@CABO3> @idx_quality
Enter value for input_owner: GX_ADM
Enter value for input_tbname: CLIENT_TRADE_TBL -->如果我们省略具体的表名则会输出整个schema的索引质量报告

                 Table   Table               Index Data Blks Leaf Blks    Clust Index
Table               Rows   Blocks Index           Size MB  per Key  per Key    Factor Quality
------------------------- ------------ ---------- ------------------------- ------- --------- --------- ------------ -------------
CLIENT_TRADE_TBL       6,318,035   278488 I_TDCL_ARC_STL_DATE_STOCK   62    312    13   171,017 5-Excellent
                         I_TDCL_ARC_STL_DATE_CASH    62    318    13   174,599 5-Excellent
                         I_TDCL_ARC_CANCEL_DATE     83    238     8   288,678 5-Excellent
                         I_TDCL_ARC_INPUT_DATE     144    249    13   310,974 5-Excellent
                         I_TDCL_ARC_TRADE_DATE     144    269    14   337,097 5-Excellent
                         PK_CLIENT_TRADE_TBL      200     1     1   798,216 2-Good
                         I_TDCL_ARC_GRP_REF_ID     144     1     1   811,468 2-Good
                         UNI_TDCL_ARC_REF_ID      136     1     1   765,603 2-Good
                         I_TDCL_ARC_CONTRACT_NUM    72     1     1   834,491 2-Good
                         I_TDCL_ARC_SETTLED_DATE    61    299     5   380,699 1-Poor
                         I_TDCL_ARC_ACC_NUM      184    624     3  3,899,446 1-Poor
                         I_TDCL_ARC_PL_STK       176    218     1  4,348,804 1-Poor
                         I_TDCL_ARC_INSTRU_ID     120   2,667     8  4,273,038 1-Poor

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

--查询单表上索引列的相关信息
gx_adm@CABO3> @idx_info
Enter value for owner: GX_ADM
Enter value for table_name: CLIENT_TRADE_TBL

TABLE_NAME        INDEX_NAME           CL_NAM        CL_POS STATUS  IDX_TYP     DSCD
------------------------- ------------------------------ -------------------- ------ -------- --------------- ----
CLIENT_TRADE_TBL     I_TDCL_ARC_ACC_NUM      ACC_NUM          1 VALID  NORMAL     ASC
             I_TDCL_ARC_CANCEL_DATE    CANCEL_DATE        1 VALID  NORMAL     ASC
             I_TDCL_ARC_CONTRACT_NUM   CONTRACT_NUM       1 VALID  NORMAL     ASC
             I_TDCL_ARC_GRP_REF_ID    GRP_REF_ID        1 VALID  NORMAL     ASC
             I_TDCL_ARC_INPUT_DATE    INPUT_DATE        1 VALID  NORMAL     ASC
             I_TDCL_ARC_INSTRU_ID     INSTRU_ID         1 VALID  NORMAL     ASC
             I_TDCL_ARC_PL_STK      STOCK_CD         1 VALID  NORMAL     ASC
             I_TDCL_ARC_PL_STK      PL_CD           2 VALID  NORMAL     ASC
             I_TDCL_ARC_SETTLED_DATE   SETTLED_DATE       1 VALID  NORMAL     ASC
             I_TDCL_ARC_STL_DATE_CASH   STL_DATE_CASH       1 VALID  NORMAL     ASC
             I_TDCL_ARC_STL_DATE_STOCK  STL_DATE_STOCK      1 VALID  NORMAL     ASC
             I_TDCL_ARC_TRADE_DATE    TRADE_DATE        1 VALID  NORMAL     ASC
             PK_CLIENT_TRADE_TBL     BUSINESS_DATE       1 VALID  NORMAL     ASC
             PK_CLIENT_TRADE_TBL     REF_ID          2 VALID  NORMAL     ASC
             UNI_TDCL_ARC_REF_ID     REF_ID          1 VALID  NORMAL     ASC

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

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

索引的创建应遵循精而少的原则
     收集表上所有查询的各种不同组合,找出具有最佳离散度的列(或主键列等)创建单索引
     对于频繁读取而缺乏比较理想离散值的列为其创建组合索引
     对于组合索引应考虑下列因素来制定合理的索引列顺序,以下优先级别由高到低来作为索引的前导列,第二列等等
           列被使用的频率
           该列是否经常使用“ = ”作为常用查询条件
           列上的离散度
           组合列经常按何种顺序排序
           哪些列会作为附件性列被添加

3、索引质量分析脚本

--script name: idx_quality.sql   --Author : Leshami --Blog: http://blog.csdn.net/leshami
--index quality retrieval
SET LINESIZE 145
SET PAGESIZE 1000
SET VERIFY OFF

CLEAR COMPUTES
CLEAR BREAKS

BREAK ON table_name ON num_rows ON blocks

COLUMN owner FORMAT a14 HEADING 'Index owner'
COLUMN table_name FORMAT a25 HEADING 'Table'
COLUMN index_name FORMAT a25 HEADING 'Index'
COLUMN num_rows FORMAT 999G999G990 HEADING 'Table|Rows'
COLUMN MB FORMAT 9G990 HEADING 'Index|Size MB'
COLUMN blocks HEADING 'Table|Blocks'
COLUMN num_blocks FORMAT 9G990 HEADING 'Data|Blocks'
COLUMN avg_data_blocks_per_key FORMAT 999G990 HEADING 'Data Blks|per Key'
COLUMN avg_leaf_blocks_per_key FORMAT 999G990 HEADING 'Leaf Blks|per Key'
COLUMN clustering_factor FORMAT 999G999G990 HEADING 'Clust|Factor'
COLUMN Index_Quality FORMAT A13 HEADING 'Index|Quality'

--SPOOL index_quality

 SELECT i.table_name,
     t.num_rows,
     t.blocks,
     i.index_name,
     o.bytes / 1048576 mb,
     i.avg_data_blocks_per_key,
     i.avg_leaf_blocks_per_key,
     i.clustering_factor,
     CASE
      WHEN NVL (i.clustering_factor, 0) = 0 THEN '0-No Stats'
      WHEN NVL (t.num_rows, 0) = 0 THEN '0-No Stats'
      WHEN (ROUND (i.clustering_factor / t.num_rows * 100)) < 6 THEN '5-Excellent'
      WHEN (ROUND (i.clustering_factor / t.num_rows * 100)) BETWEEN 7 AND 11 THEN '4-Very Good'
      WHEN (ROUND (i.clustering_factor / t.num_rows * 100)) BETWEEN 12 AND 15 THEN '2-Good'
      WHEN (ROUND (i.clustering_factor / t.num_rows * 100)) BETWEEN 16 AND 25 THEN '2-Fair'
      ELSE '1-Poor'
     END
      index_quality
  FROM dba_indexes i, dba_segments o, dba_tables t
  WHERE
   --  i.index_name LIKE UPPER ('%&&1%') AND
     i.owner = t.owner
     AND i.table_name = t.table_name
     AND i.owner = o.owner
     AND i.index_name = o.segment_name
     AND t.owner = UPPER('&input_owner')
     AND t.table_name LIKE UPPER('%&input_tbname%')
ORDER BY table_name,
     num_rows,
     blocks,
     index_quality DESC;

--SPOOL OFF;

===========================================================================================
--script name: idx_info.sql
--get the index column information by specified table
set linesize 180
col cl_nam format a20
col table_name format a25
col cl_pos format 9
col idx_typ format a15
SELECT b.table_name,
      a.index_name,
      a.column_name   cl_nam,
      a.column_position cl_pos,
      b.status,
      b.index_type   idx_typ,
      a.descend     dscd
FROM  dba_ind_columns a, dba_indexes b
WHERE a.index_name = b.index_name
      AND owner = upper('&owner')
      AND a.table_name LIKE upper('%&table_name%')
ORDER BY 2, 4;
(0)

相关推荐

  • Oracle索引质量介绍和分析脚本分享

    索引质量的高低对数据库整体性能有着直接的影响.良好高质量的索引使得数据库性能得以数量级别的提升,而低效冗余的索引则使得数据库性能缓慢如牛,即便是使用高档的硬件配置.因此对于索引在设计之初需要经过反复的测试与考量.那对于已经置于生产环境中的数据库,我们也可以通过查询相关数据字典得到索引的质量的高低,通过这个分析来指导如何改善索引的性能.下面给出了演示以及索引创建的基本指导原则,最后给出了索引质量分析脚本. 1.查看索引质量 --获取指定schema或表上的索引质量信息报告 gx_adm@CABO3

  • Oracle不同数据库间对比分析脚本

    正在看的ORACLE教程是:Oracle不同数据库间对比分析脚本. Oracle数据库开发应用中经常对数据库管理员有这样的需求,对比两个不同实例间某模式下对象的差异或者对比两个不同实例某模式下表定义的差异性,这在涉及到数据库软件的开发应用中是经常遇到的.一般数据库软件的开发都是首先在开发数据库上进行,开发到一定程度后,系统投入运行,此时软件处于维护阶段.针对在系统运行中遇到的错误.bug等,还有应用系统的升级,经常需要调整后台程序,数据库开发人员经常遇到这样一种尴尬的事情,维护到一定时期,开发库

  • python分析nignx访问日志脚本分享

    #!/usr/bin/env python # coding=utf-8 #------------------------------------------------------ # Name: nginx 日志分析脚本 # Purpose: 此脚本只用来分析nginx的访问日志 # Version: 1.0 # Author: LEO # Created: 2013-05-07 # Modified: 2013-05-07 # Copyright: (c) LEO 2013 #-----

  • python分析apache访问日志脚本分享

    #!/usr/bin/env python # coding=utf-8 #------------------------------------------------------ # Name: Apache 日志分析脚本 # Purpose: 此脚本只用来分析Apache的访问日志 # Version: 2.0 # Author: LEO # Created: 2013-4-26 # Modified: 2013-5-4 # Copyright: (c) LEO 2013 #------

  • 基于MongoDB数据库索引构建情况全面分析

    前面的话 本文将详细介绍MongoDB数据库索引构建情况分析 概述 创建索引可以加快索引相关的查询,但是会增加磁盘空间的消耗,降低写入性能.这时,就需要评判当前索引的构建情况是否合理.有4种方法可以使用 1.mongostat工具 2.profile集合介绍 3.日志 4.explain分析 mongostat mongostat是mongodb自带的状态检测工具,在命令行下使用.它会间隔固定时间获取mongodb的当前运行状态,并输出.如果发现数据库突然变慢或者有其他问题的话,首先就要考虑采用

  • oracle 索引不能使用深入解析

    较典型的问题有:有时,表明明建有索引,但查询过程显然没有用到相关的索引,导致查询过程耗时漫长,占用资源巨大,问题到底出在哪儿呢?按照以下顺序查找,基本上能发现原因所在. 查找原因的步骤 首先,我们要确定数据库运行在何种优化模式下,相应的参数是:optimizer_mode.可在svrmgrl中运行"showparameteroptimizer_mode"来查看.ORACLEV7以来缺省的设置应是"choose",即如果对已分析的表查询的话选择CBO,否则选择RBO.

  • oracle索引的测试实例代码

    前言 在测试oracle索引性能时大意了,没有仔细分析数据特点,将情况特此记录下来. 需求:  对一张100w记录的表的 stuname列进行查询,测试在建立索引与不建立索引的区别. 以下是开始用的创建代码及执行效果. 1. 随机数据生成代码分析 --为测试索引而准备的随机数据生成代码,先分析一下 select rownum as id, 'smith'||trunc(dbms_random.value(0, 100)) as stu_name, dbms_random.string('x',

  • oracle删除超过N天数据脚本的方法

    公司内做的项目是工厂内的,一般工厂内数据要求的是实时性,很久之前的数据可以自行删除处理,我们数据库用的oracle,所以就想着写一个脚本来删除,这样的话,脚本不管放在那里使用都可以达到效果 由于服务器是windows,参照Oracle Shell Scripting中,我们写一下windows下的脚本 首先删除数据的sql语句写一下 DELETE FROM tablename WHERE createdtime<TRUNC(SYSDATE)-59; --删除59天前的数据 commit; --提

  • MySql索引详细介绍及正确使用方法

    MySql索引详细介绍及正确使用方法 1.前言: 索引对查询的速度有着至关重要的影响,理解索引也是进行数据库性能调优的起点. 索引是存储引擎用于快速查找记录的一种数据结构,通过合理的使用数据库索引可以大大提高系统的访问性能,接下来主要介绍在MySql数据库中索引类型,以及如何创建出更加合理且高效的索引技巧. 注:这里主要针对的是InnoDB存储引擎的B+Tree索引数据结构 2.索引的优点 1.大大减轻了服务器需要扫描的数据量,从而提高了数据的检索速度 2.帮助服务器避免排序和临时表 3.可以将

  • 一个强大的网络分析shell脚本分享(实时流量、连接统计)

    介绍一个强大的分析网络的shell脚本,此脚本是从EZHTTP拆分出来的,觉得有必要单独介绍下. 脚本运行效果截图: 此脚本包含的功能有: 1.实时监控任意网卡的流量 2.统计10秒内平均流量 3.统计每个端口在10秒内的平均流量,基于客户端和服务端端口统计.可以看出哪些端口占流量比较大,对于web服务器,一般是80端口.其它端口受到攻击时,也有可能其它端口流量比较大.所以此功能可以帮助我们端口流量是否正常. 4.统计在10s内占用带宽最大的前10个ip.此项功能可以帮助我们来查出是否有恶意占用

随机推荐