[20140402]关于位图索引的统计信息

[20140402]关于位图索引的统计信息.txt

前几天,帮别人解决一些数据库问题,看awr报表很容易确定有1个表的索引使用了位图,导致在业务高峰出现阻塞情况, 当然不能简单的把
原来的位图索引删除,建立常规索引,因为查询条件存在is null的情况,我根据情况加入一个非空字段,建立复合索引,因为查询有时候涉及
这个条件,我遇到的问题是查询位图索引统计信息时遇到一些奇怪的情况,自己写一些测试来说明情况.

SCOTT@test01p> @ver

BANNER                                                                               CON_ID
-------------------------------------------------------------------------------- ----------
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production              0

SCOTT@test01p> create table t as select rownum id ,'Y' flag,'test' name from dual connect by levelTable created.

SCOTT@test01p> insert into t select rownum+1e4,'N' flag ,'TEST' name from dual connect by level10000 rows created.

SCOTT@test01p> select count(*),flag from t group by flag ;
  COUNT(*) F
---------- -
     10000 Y
     10000 N

SCOTT@test01p> create bitmap index ib_t_flag on t(flag);
Index created.

SCOTT@test01p> exec dbms_stats.gather_table_stats(null,'T',estimate_percent=>100,no_invalidate=>false,cascade=>true,method_OPT=>'FOR ALL COLUMNS SIZE 1') ;
PL/SQL procedure successfully completed.

SCOTT@test01p> validate index ib_t_flag ;
Index analyzed.

SCOTT@test01p> @i
    HEIGHT     BLOCKS NAME          LF_ROWS    LF_BLKS LF_ROWS_LEN LF_BLK_LEN    BR_ROWS    BR_BLKS BR_ROWS_LEN BR_BLK_LEN DEL_LF_ROWS DEL_LF_ROWS_LEN DISTINCT_KEYS
---------- ---------- ---------- ---------- ---------- ----------- ---------- ---------- ---------- ----------- ---------- ----------- --------------- -------------
         1          8 IB_T_FLAG           2          1        2960       8000          0          0           0          0           0               0             2

MOST_REPEATED_KEY BTREE_SPACE USED_SPACE   PCT_USED ROWS_PER_KEY BLKS_GETS_PER_ACCESS   PRE_ROWS PRE_ROWS_LEN OPT_CMPR_COUNT OPT_CMPR_PCTSAVE
----------------- ----------- ---------- ---------- ------------ -------------------- ---------- ------------ -------------- ----------------
                1        8000       2960         37            1                    2          0            0              0                0

SCOTT@test01p> select distinct_keys, num_rows, clustering_factor,sample_size from dba_indexes where table_name = 'T' and owner=user;
DISTINCT_KEYS   NUM_ROWS CLUSTERING_FACTOR SAMPLE_SIZE
------------- ---------- ----------------- -----------
            2          2                 2           2

--如果看索引统计信息,可以发现可以发现NUM_Rows=2,CLUSTERING_FACTOR=2,sample_size=2.而实际的记录数是2e4.
--如果了解位图索引的结构就很容易理解,做一个转储看看.

SCOTT@test01p> select header_file,header_block,bytes,blocks,extents  from dba_segments where owner=user and segment_name='IB_T_FLAG';
HEADER_FILE HEADER_BLOCK      BYTES     BLOCKS    EXTENTS
----------- ------------ ---------- ---------- ----------
          9          258      65536          8          1

--下一块是索引的root.从上面分析也可以看出仅仅占用1块.
SCOTT@test01p> alter system dump datafile 9 block 259;
System altered.

Block header dump:  0x02400103
Object id on Block? Y
seg/obj: 0x17443  csc: 0x00.58dfc9  itc: 2  flg: E  typ: 2 - INDEX
     brn: 0  bdba: 0x2400100 ver: 0x01 opc: 0
     inc: 0  exflg: 0
 
Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000
0x02   0xffff.000.00000000  0x00000000.0000.00  C---    0  scn 0x0000.0058dfc9
Leaf block dump
===============
header address 376701028=0x16740064
kdxcolev 0
KDXCOLEV Flags = - - -
kdxcolok 0
kdxcoopc 0x80: opcode=0: iot flags=--- is converted=Y
kdxconco 4
kdxcosdc 0
kdxconro 2
kdxcofbo 40=0x28
kdxcofeo 5080=0x13d8
kdxcoavs 5040
kdxlespl 0
kdxlende 0
kdxlenxt 0=0x0
kdxleprv 0=0x0
kdxledsz 0
kdxlebksz 8036
row#0[6562] flag: -------, lock: 0, len=1474
col 0; len 1; (1):  4e
col 1; len 6; (6):  02 40 00 db 00 00
col 2; len 6; (6):  02 40 00 ff 01 af
col 3; len 1454; (1454):
cf ff ff ff ff ff ff ff ff cf ff ff ff ff ff ff ff ff cf ff ff ff ff ff ff
.... 太长截断
ff ff ff 07
row#1[5080] flag: -------, lock: 0, len=1482
col 0; len 1; (1):  59
col 1; len 6; (6):  02 40 00 bb 00 00
col 2; len 6; (6):  02 40 00 da 00 37
col 3; len 1462; (1462):
cf ff ff ff ff ff ff ff ff cf ff ff ff ff ff ff ff ff cf ff ff ff ff ff ff
.... 太长截断
ff c8 0f fe 1e ff ff ff ff ff ff 03
----- end of leaf block Logical dump -----
----- end of leaf block dump -----
End dump data blocks tsn: 3 file#: 9 minblk 259 maxblk 259

SCOTT@test01p> select dump('Y',16) , dump('N',16) from dual ;
DUMP('Y',16)     DUMP('N',16)
---------------- ----------------
Typ=96 Len=1: 59 Typ=96 Len=1: 4e

col 0; len 1; (1):  59
col 1; len 6; (6):  02 40 00 bb 00 00
col 2; len 6; (6):  02 40 00 da 00 37
col 3; len 1462; (1462):

--可以看出位图索引col0是键值,col1,col2 表示start rowid,end rowid.col3以位图形式表示对应的键值.
--这样可以看出行是2个,CLUSTERING_FACTOR=2.也就是位图索引的统计信息计算方式NUM_Rows,CLUSTERING_FACTOR,sample_size与普通索引不同。
--换一个方式再看看.

SCOTT@test01p> drop table t purge ;
Table dropped.

SCOTT@test01p> create table t as select rownum id ,decode(mod(rownum,3),0,'Y',1,'N',2,'A') flag,'test' name from dual connect by levelTable created.

SCOTT@test01p> create bitmap index ib_t_flag on t(flag);
Index created.

SCOTT@test01p> exec dbms_stats.gather_table_stats(null,'T',estimate_percent=>100,no_invalidate=>false,cascade=>true,method_OPT=>'FOR ALL COLUMNS SIZE 1') ;
PL/SQL procedure successfully completed.

SCOTT@test01p> validate index ib_t_flag ;
Index analyzed.

SCOTT@test01p> @i
    HEIGHT     BLOCKS NAME          LF_ROWS    LF_BLKS LF_ROWS_LEN LF_BLK_LEN    BR_ROWS    BR_BLKS BR_ROWS_LEN BR_BLK_LEN DEL_LF_ROWS DEL_LF_ROWS_LEN DISTINCT_KEYS
---------- ---------- ---------- ---------- ---------- ----------- ---------- ---------- ---------- ----------- ---------- ----------- --------------- -------------
         2          8 IB_T_FLAG           0          0                      0          1          1           9       8032           0               0             0

MOST_REPEATED_KEY BTREE_SPACE USED_SPACE   PCT_USED ROWS_PER_KEY BLKS_GETS_PER_ACCESS   PRE_ROWS PRE_ROWS_LEN OPT_CMPR_COUNT OPT_CMPR_PCTSAVE
----------------- ----------- ---------- ---------- ------------ -------------------- ---------- ------------ -------------- ----------------
                0        8032                                  0                    2          0            0              0                0

SCOTT@test01p> select distinct_keys, num_rows, clustering_factor,sample_size from dba_indexes where table_name = 'T' and owner=user;
DISTINCT_KEYS   NUM_ROWS CLUSTERING_FACTOR SAMPLE_SIZE
------------- ---------- ----------------- -----------
            3          3                 3           3

SCOTT@test01p> select header_file,header_block,bytes,blocks,extents  from dba_segments where owner=user and segment_name='IB_T_FLAG';
HEADER_FILE HEADER_BLOCK      BYTES     BLOCKS    EXTENTS
----------- ------------ ---------- ---------- ----------
          9          258      65536          8          1

时间: 2024-07-30 13:28:15

[20140402]关于位图索引的统计信息的相关文章

[MySQL 5.6] Innodb 后台线程之 dict stats 线程 及如何计算索引统计信息

前言   在5.6中,引入的一个新参数innodb_stats_auto_recalc用于控制是否进行自动统计信息计算.当表上的记录修改超过10%时,就会对统计信息重新计算;这只对在建表时打开了innodb_stats_persistent或者指定了建表选项STATS_PERSISTEND=1生效,采样page的个数通过参数innodb_stats_persistent_sample_pages来控制(实际读取的page数会大于该值). 在函数dict_stats_is_persistent_e

执行计划错误—索引统计信息的不准确

mysql在生成执行计划的时候,需要根据索引的统计信息进行一个估算,计算出成本最低的索引: 但是mysql索引统计信息的采集默认8个page: root@test 08:48:52>show global variables like '%samp%'; +---------+---+ | Variable_name             | Value | +---------+---+ | innodb_stats_sample_pages | 8     | +---------+---

收集统计信息导致索引被监控

      对于索引的调整,我们可以通过Oracle提供的索引监控特性来跟踪索引是否被使用.尽管该特性并未提供索引使用的频度,但仍不失为我们参考的方式之一.然而,最近在Oracle 10.2.0.3中发现收集统计信息时导致索引也被监控,而不是用于sql查询引发的索引监控.如此这般,索引监控岂不是鸡肋?   1.基于Oracle 10g 收集统计信息索引被监控情形 scott@CNMMBO> select * from v$version where rownum<2; BANNER -----

如何提高Oracle位图索引的使用效果

位图索引是Oralce数据库索引中的异类,其在某些比较特殊的场合中有突出的表现.一般来说,位图索引的效果直接跟列的基 数相关.为此在谈到如何提高位图索引的使用效果时,也往往跟这个列的基数相关.为此必须对这个列的基数有一个清晰的认识. 一.什么时候改采用位图索引 基数是指某个列可能拥有的不重复数值的个数.比如说在一个中华人民共和国公民的信息表中,包含着十几亿条的记录.但是在这些记录中 ,有几个比较特殊的列,其指包含几个有限的重复数值.如性别这一字段,其就只有男与女两个可能值;如在民族一列内也只有5

Oracle的统计信息简介

1.什么是统计信息 统计信息主要是描述数据库中表,索引的大小,规模,数据分布状况等的一类信息.比如,表的行数,块数,平均每行的大小,索引的leaf blocks,索引字段的行数,不同值的大小等,都属于统计信息.CBO正是根据这些统计信息数据,计算出不同访问路径下,不同join 方式下,各种计划的成本,最后选择出成本最小的计划. 统计信息是存放在数据字段表中的,如tab$.一般我们从数据字段视图中察看统计信息状况,如DBA_TABLES,DBA_INDEXES,DBA_TAB_COL_STATIS

Oracle统计信息和dbms_stats包

1.统计信息的作用 Oracle基于CBO的优化器在生成执行计划时,很大程度上依赖 于统计信息,你可以把CBO理解为一个复杂的数学模型,而统计信息是它最主要的输入,执行 计划是输出,如果输入都不准确,输出还可能准确吗?所有,统计信息是否及时有效对执行 计划的好坏有着关键的影响. 2.dbms_stats包 Oracle里采用dbms_stats包分 析统计信息(Analyze命令已过时,不建议使用),该包的使用方法,官方文档有详细说明 (http://docs.oracle.com/cd/E11

oracle收集统计信息

什么是统计信息 统计信息主要是描述数据库中表,索引的大小,规模,数据分布状况等的一类信息.比如,表的行数,块数,平均每行的大小,索引的leaf blocks,索引字段的行数,不同值的大小等,都属于统计信息.CBO正是根据这些统计信息数据,计算出不同访问路径下,不同join 方式下,各种计划的成本,最后选择出成本最小的计划. 统计信息是存放在数据字段表中的,如dba_tab_statistics 如何搜集统计信息 统计信息搜集也是有多种方法,推荐大家使用DBMS_STATS 表来进行统计信息搜集及

MS SQL 统计信息浅析上篇

统计信息概念     统计信息是一些对象,这些对象包含在表或索引视图中一列或多列中的数据分布有关的统计信息.数据库查询优化器使用这些统计信息来估计查询结果中的基数或行 数. 通过这些基数估计,查询优化器可以生成高质量的执行计划. 例如,查询优化器可以使用基数估计选择索引查找运算符而不是耗费更多资源的索引扫描运算符,从而提高查询性能.[参考MSDN]     其实如果你以前没有接触过统计信息,你可以将其看做是数据库为了得到最优的执行计划,统计数据库里面表.索引等对象的一些数据,例如表的记录数.所有

MySQL源码学习:索引使用统计功能

今天刚刚知道Oracle有个索引统计的功能,可以统计每个索引的使用次数.作为一个Oracle的门外汉,我还是再次感叹人家做的是真细致.第二个想法就是给MySQL也加上. Percona版本的information_schema.innodb_index_stats 已经有索引的统计信息,我们就在巨人的肩膀上踩一脚了. 先来看下原来的表结构. CREATE TEMPORARY TABLE `INNODB_INDEX_STATS` ( `table_schema` varchar(192) NOT