Compute Statistics when create&rebuild index

May 15th, 2007 | Categories: Boring | Tags:

当创建和重建索引,可以增加compute statistics计算索引的统计信息;但我在9205中测试,有时候compute statistics不但更新了索引的统计信息,还会更新表的统计信息。

我在9205的测试如下,

SQL> create table TC as select * from dba_objects;
Table created.

SQL> create index TC_IDX1 on TC(object_id);
Index created.
表信息:
OWNER U TYPE Index Name Column Name
--------------- - ------ ------------------------------- ------------------------- ---
ORACLE N TC_IDX1 OBJECT_ID 1
OWNER TABLE_NAME TS_NAME PAR NUM_ROWS BLOCKS SAMPLE LAST_ANALYZED
--------------- -------------------- --------------- --- --------------- --------------- --------------- -------------------
ORACLE TC USERS01 NO
OWNER INDEX_NAME PAR LEAF_BLOCKS BLEVEL DISTINCT_KEYS NUM_ROWS CLUSTERING_FACTOR SAMPLE
--------------- ------------------------------ --- --------------- --------------- --------------- --------------- ----------------- ---------------
LAST_ANALYZED
-------------------
ORACLE TC_IDX1 NO

刚开始表没有统计信息

SQL> Create index TC_IDX2 on TC(object_name) compute statistics online;

Index created.

表信息:
OWNER U TYPE Index Name Column Name
--------------- - ------ ------------------------------- ------------------------- ---
ORACLE N TC_IDX1 OBJECT_ID 1
ORACLE N TC_IDX2 OBJECT_NAME 1

OWNER TABLE_NAME TS_NAME PAR NUM_ROWS BLOCKS SAMPLE LAST_ANALYZED
--------------- -------------------- --------------- --- --------------- --------------- --------------- -------------------
ORACLE TC USERS01 NO 18497 227 0 2007/05/15 01:38:44

OWNER INDEX_NAME PAR LEAF_BLOCKS BLEVEL DISTINCT_KEYS NUM_ROWS CLUSTERING_FACTOR SAMPLE
————— —————————— — ————— ————— ————— ————— —————– —————
LAST_ANALYZED
——————-
ORACLE TC_IDX1 NO

ORACLE TC_IDX2 NO 64 1 11394 18497 10654 99
2007/05/15 01:38:44

Online创建索引的时候设置了Compute Statistics,不但索引被分析了,而且表也被分析了

SQL> delete from tC where rownum<1000;

999 rows deleted.

SQL> commit;

Commit complete. 作一些数据的修改

然后Online重建索引,并且进行分析

SQL> alter index tc_idx2 rebuild online compute statistics;

Index altered.

SQL> !ora idxdesc TC

OWNER U TYPE Index Name Column Name
————— - —— ——————————- ————————- —
ORACLE N TC_IDX1 OBJECT_ID 1
ORACLE N TC_IDX2 OBJECT_NAME 1

OWNER TABLE_NAME TS_NAME PAR NUM_ROWS BLOCKS SAMPLE LAST_ANALYZED
————— ——————– ————— — ————— ————— ————— ——————-
ORACLE TC USERS01 NO 17498 227 0 2007/05/15 01:39:40

OWNER INDEX_NAME PAR LEAF_BLOCKS BLEVEL DISTINCT_KEYS NUM_ROWS CLUSTERING_FACTOR SAMPLE
————— —————————— — ————— ————— ————— ————— —————– —————
LAST_ANALYZED
——————-
ORACLE TC_IDX1 NO

ORACLE TC_IDX2 NO 60 1 11129 17498 9490 99
2007/05/15 01:39:40

发现表的LAST_ANALYZED也被修改了。

SQL> show parameters optim

NAME TYPE VALUE
———————————— ——————————– ——————————
object_cache_optimal_size integer 102400
optimizer_dynamic_sampling integer 1
optimizer_features_enable string 9.2.0
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 100
optimizer_max_permutations integer 2000
optimizer_mode string CHOOSE

9205中,create/alter index ..compute statistics可能会更新表的统计信息,在表有多个索引的时候,可能会中招,导致表,索引之间的统计信息不一致,CBO选择错误的执行计划。

通常的规则是,创建新索引后,也对整个表进行分析。尽量保证索引和表是一个整体,保证这个整体内的每个对象都有一致的统计信息,又或者都没有统计信息。

10g中修改了这个bug,但我没有从metalink查到具体的bug number.




Del.icio.us Google书签 Digg Live Bookmark Technorati Furl Yahoo书签 Facebook 百度搜藏 新浪 ViVi 365Key 网摘 天极网摘 和讯网摘 博拉网 POCO 网摘 饭否 QQ 书签 Digbuzz 我挖网 Mister Wong
  1. 棉花糖ONE
    April 27th, 2008 at 11:05
    Quote | #1

    这个不能算bug,你可以看9i的performance tuning文档,你的现象就是oracle的文档中描述的,不过10g里没看到相关说明

  2. 棉花糖ONE
    April 27th, 2008 at 11:11
    Quote | #2

    你可以试试分区表,就不会有你说那现象

  3. ora110
    August 5th, 2008 at 17:16
    Quote | #3

    很好,我一般同时分析表和索引。