« Oracle诊断案例-Sql_trace之一 | Blog首页 | 安装10g以后Oracle9i的DBCA无法启动问题之解决 »
OPTIMIZER_INDEX_COST_ADJ与成本计算
链接:https://www.eygle.com/archives/2004/06/optimizer_index_cost_adj.html
OPTIMIZER_INDEX_COST_ADJ
这个初始化参数代表一个百分比,取值范围在1到10000之间.
该参数表示索引扫描和全表扫描成本的比较。缺省值100表示索引扫描成本等价转换与全表扫描成本。
这些参数对于CBO的执行具有重大影响,其缺省值对于数据库来说通常需要调整。
一般来说对于OPTIMIZER_INDEX_CACHING可以设置为90左右
对于大多数OLTP系统,OPTIMIZER_INDEX_COST_ADJ可以设置在10到50之间。对于数据仓库和DSS系统,
可能不能简单的把OPTIMIZER_INDEX_COST_ADJ设置为50,通常我们需要反复调整取得一个合理值.
更为具体的可以根据统计信息,db file scattered reads/db file sequential reads来计算.
本文通过实验对该参数的使用作出探讨和说明.
我们看到optimizer_index_cost_adj的缺省值为100.
[oracle@jumper udump]$ sqlplus eygle/eygle SQL*Plus: Release 9.2.0.3.0 - Production on Mon Jun 28 17:11:15 2004 Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved. Connected to: SQL> show parameter optimizer_index_cost_adj NAME TYPE VALUE |
创建测试表:
SQL> create table t as select * from dba_objects; Table created. SQL> create index ind_owner on t(owner); Index created. SQL> analyze table t compute statistics; Table analyzed.
|
我们分别观察一下全表扫描和索引访问的成本:
SQL> set autotrace traceonly
|
Oracle在选择不同的访问路径时,会对全表扫描和索引扫描进行比较评估.
在比较的时候,Oracle会把索引扫描的成本转换为全表扫描的成本,和全表扫描的COST进行比较.这个转换需要一个转换因子.
就是optimizer_index_cost_adj:
optimizer_index_cost_adj * (Index Scan Cost) = 等价的 Full Scan Cost
这个 等价的 Full Scan Cost 就是来和全表扫描成本进行比较的.
而这个转换因子的临界值实际上就是Full Scan Cost 和 Index Scan Cost的比值.
即:
optimizer_index_cost_adj = Full Scan Cost / Index Scan Cost
SQL> set autotrace off (14/16)*100 1 row selected. |
我们通过调整optimizer_index_cost_adj来看一下执行计划的变化:
SQL> set autotrace traceonly SQL> alter session set optimizer_index_cost_adj = 87; Session altered. SQL> select * from t where owner='EYGLE'; Execution Plan 此时使用索引成本较低.等价全表扫描成本为: 87% * (Index Scan Cost) < Full Scan Cost 此时Oracle选择了索引. SQL> alter session set optimizer_index_cost_adj = 88; Session altered. SQL> select * from t where owner='EYGLE'; Execution Plan 此时使用索引成本较高.等价全表扫描成本为: 88% * (Index Scan Cost) > Full Scan Cost 所以Oracle选择了全表扫描. |
参考文档:
http://www.evdbt.com/SearchIntelligenceCBO.doc
历史上的今天...
>> 2016-06-28文章:
>> 2010-06-28文章:
>> 2007-06-28文章:
>> 2006-06-28文章:
>> 2005-06-28文章:
By eygle on 2004-06-28 21:01 | Comments (0) | SQL.PLSQL | 34 |