今天执行一个语句
SELECT |
其中表DF_ParticipantBankNo 中大概有2万多条数据。在生产环境执行很慢很慢,以至于最后将临时表空间占满,测试环境中却没有问题,观察两个数据库中该表的属性,生产环境的GLOBAL_STATS 为true。而测试环境的为false;
1.global_stats
For partitioned tables, indicates whether statistics were collected for the table as a whole (YES) or were estimated from statistics on underlying partitions and subpartitions (NO)
我们可以根据这一列来判断上一次分析是采用的analyze还是dbms_stats,不仅仅对分区表,非分区表也可以使用
如果表有统计信息,global_stats=NO表明是用analyze分析的,global_stats=YES表明是dbms_stats分析的
2.
ORACLE数据库的PL/SQL语句执行的优化器,有基于代价的优化器(CBO)和基于规则的优化器(RBO)。 RBO的优化方式,依赖于一套严格的语法规则,只要按照规则写出的语句,不管数据表和索引的内容是否发生变化,不会影响PL/SQL语句的"执行计划"。CBO自ORACLE7版被引入,ORACLE自7版以来采用的许多新技术都是只基于CBO的,如星型连接排列查询,哈希连接查询,反向索引,索引表,分区表和并行查询等。CBO计算各种可能"执行计划"的"代价",即cost,从中选用cost最低的方案,作为实际运行方案。各"执行计划"的cost的计算根据,依赖于数据表中数据的统计分布,ORACLE数据库本身对该统计分布是不清楚的,须要分析表和相关的索引,才能搜集到CBO所需的数据。CBO是ORACLE推荐使用的优化方式,要想使用好CBO,使SQL语句发挥最大效能,必须保证统计数据的及时性。
生产环境的该语句的执行计划,没有使用DF_ParticipantBankNo对应的index,而是遍历了全表。
3.
http://space.itpub.net/10356975/viewspace-680353
http://www.cnblogs.com/helpdesk/archive/2008/06/18/1224973.html
4.DBMS_STATS.GATHER_TABLE_STATS详解
http://hi.baidu.com/cuigq_hr/blog/item/ab505a1623eaac05c83d6ddc.html
PS:
imp defc2/defc2@orcl file=M:/201105301700.dmp tables=(DF_ParticipantBankNo);
shutdown immediate
STARTUP
execute dbms_stats.gather_table_stats('defc2','DF_ParticipantBankNo',cascade=>true);
analyze table DF_ParticipantBankNo compute statistics;
select * from Dba_Scheduler_Jobs where JOB_NAME ='GATHER_STATS_JOB';