OPTIMIZER_FEATURES_ENABLE

最新推荐文章于 2021-04-28 13:35:14 发布
最新推荐文章于 2021-04-28 13:35:14 发布
阅读量4.3k 收藏 2
点赞数
分类专栏： Oracle Optimization 文章标签： features nested loops integer statistics object
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/wyzxg/article/details/5409682
版权

author：skate

time：2010-03-23

 

OPTIMIZER_FEATURES_ENABLE

PropertyDescription
Parameter typeString
SyntaxOPTIMIZER_FEATURES_ENABLE = { 8.0.0 | 8.0.3 | 8.0.4 | 8.0.5 | 8.0.6 | 8.0.7 | 8.1.0 | 8.1.3 | 8.1.4 | 8.1.5 | 8.1.6 | 8.1.7 | 9.0.0 | 9.0.1 | 9.2.0 | 10.0.0 }
Default value10.0.0
ModifiableALTER SESSION, ALTER SYSTEM

OPTIMIZER_FEATURES_ENABLE acts as an umbrella parameter for enabling a series of optimizer features based on an Oracle release number.

For example, if you upgrade your database from release 8.0.6 to release 9.2, but you want to keep the release 8.0.6 optimizer behavior, you can do so by setting this parameter to 8.0.6. At a later time, you can try the enhancements introduced in releases up to and including release 9.2 by setting the parameter to 9.2.0.

Table 1-2 describes some of the optimizer features that are enabled when you set the OPTIMIZER_FEATURES_ENABLE parameter to an 8.0 release or an 8.1 release. Table 1-3 describes some of the optimizer features that are enabled when you set the OPTIMIZER_FEATURES_ENABLE parameter to a 9.0 release or a 9.2 release.


See Also:

Oracle Database Performance Tuning Guide for more information about the optimizer and for information about the features listed in the following tables

Table 1-2 Release 8.0 and Release 8.1 Optimizer Features

FeaturesRelease
8.0.08.0.38.0.48.0.58.0.68.0.78.1.08.1.38.1.48.1.58.1.68.1.7
Index fast full scan  XXXXXXXXXX
Consideration of bitmap access paths for tables with only B-tree indexes  XXXX      
Complex view merging  XXXX      
Push-join predicate  XXXX      
Ordered nested loop costing  XXXX      
Improved outer join cardinality calculation    XXXXXXXX
Improved verification of NULLs inclusion in B-tree indexes         XXX
Random distribution method for left of nested loops          XX
Type-dependent selectivity estimates          XX
Setting of optimizer mode for user recursive SQL          XX
Improved average row length calculation          XX
Partition pruning based on subquery predicates          XX
Common subexpression elimination           X
Use statistics of a column imbedded in some selected functions such as TO_CHAR to compute selectivity           X
Improved partition statistics aggregation           X

Table 1-3 Release 9.0 and Release 9.2 Optimizer Features

FeaturesRelease
9.0.09.0.19.2.0
Index fast full scanXXX
Consideration of bitmap access paths for tables with only B-tree indexesXXX
Complex view mergingXXX
Push-join predicateXXX
Ordered nested loop costingXXX
Improved outer join cardinality calculationXXX
Improved verification of NULLs inclusion in B-tree indexesXXX
Random distribution method for left of nested loopsXXX
Type-dependent selectivity estimatesXXX
Setting of optimizer mode for user recursive SQLXXX
Improved average row length calculationXXX
Partition pruning based on subquery predicatesXXX
Common subexpression eliminationXXX
Use statistics of a column imbedded in some selected functions such as TO_CHAR to compute selectivityXXX
Improved partition statistics aggregationXXX
Peeking at user-defined bind variablesXXX
Index joinsXXX
Subquery unnestingXXX

10g和optimizer有关的参数：
SQL> show parameter optimizer
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
optimizer_dynamic_sampling           integer     2
optimizer_features_enable            string      10.2.0.1
optimizer_index_caching              integer     0
optimizer_index_cost_adj             integer     100
optimizer_mode                       string      ALL_ROWS
optimizer_secure_view_merging        boolean     TRUE
9i和optimizer有关的参数：
SQL> show parameter optimi
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
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
SQL>
今天在和群里讨论的时候，有个网友说一个sql在两个配置相同的数据库上执行速度差很多，下面是这两个sql的执行计划
快的sql：
已用时间:  00: 00: 00.55
执行计划
----------------------------------------------------------
Plan hash value: 1189072556
------------------------------------------------------------------------------------------------------------
| Id  | Operation                           | Name                 | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                    |                      |     1 |   123 |    33   (4)| 00:00:01 |
|   1 |  SORT AGGREGATE                     |                      |     1 |   123 |            |          |
|*  2 |   HASH JOIN                         |                      |  2433 |   292K|    33   (4)| 00:00:01 |
|   3 |    NESTED LOOPS OUTER               |                      |   385 | 46585 |    13   (0)| 00:00:01 |
|   4 |     NESTED LOOPS OUTER              |                      |   346 | 38752 |    13   (0)| 00:00:01 |
|   5 |      NESTED LOOPS OUTER             |                      |   346 | 35638 |    13   (0)| 00:00:01 |
|   6 |       NESTED LOOPS                  |                      |   346 | 33216 |    13   (0)| 00:00:01 |
|   7 |        NESTED LOOPS                 |                      |   462 | 36498 |    13   (0)| 00:00:01 |
|*  8 |         INDEX UNIQUE SCAN           | PK_DEVICETYPE        |     1 |     9 |     0   (0)| 00:00:01 |
|*  9 |         TABLE ACCESS FULL           | DEVICE               |   462 | 32340 |    13   (0)| 00:00:01 |
|* 10 |        INDEX UNIQUE SCAN            | PK_DEVICEMODEL       |     1 |    17 |     0   (0)| 00:00:01 |
|* 11 |       INDEX UNIQUE SCAN             | PK_DEVICEPROP        |     1 |     7 |     0   (0)| 00:00:01 |
|* 12 |      INDEX UNIQUE SCAN              | PK_RESCOLTIMEPLAN    |     1 |     9 |     0   (0)| 00:00:01 |
|* 13 |     INDEX UNIQUE SCAN               | PK_RESCOLITEMPROFILE |     1 |     9 |     0   (0)| 00:00:01 |
|  14 |    COLLECTION ITERATOR PICKLER FETCH| USERRESOURCEAUTH     |       |       |            |          |
------------------------------------------------------------------------------------------------------------
慢点sql：
Elapsed: 00:01:44.94
Execution Plan
----------------------------------------------------------
Plan hash value: 1816705116
------------------------------------------------------------------------------------------------------------
| Id  | Operation                           | Name                 | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                    |                      |     1 |   109 |   113   (4)| 00:00:02 |
|   1 |  SORT AGGREGATE                     |                      |     1 |   109 |            |          |
|*  2 |   HASH JOIN                         |                      |   795 | 86655 |   113   (4)| 00:00:02 |
|   3 |    NESTED LOOPS OUTER               |                      |   656 | 70192 |    88   (4)| 00:00:02 |
|   4 |     NESTED LOOPS OUTER              |                      |   656 | 64944 |    88   (4)| 00:00:02 |
|   5 |      NESTED LOOPS OUTER             |                      |   656 | 61008 |    88   (4)| 00:00:02 |
|   6 |       NESTED LOOPS                  |                      |   656 | 55760 |    88   (4)| 00:00:02 |
|   7 |        NESTED LOOPS                 |                      |   674 | 46506 |    87   (3)| 00:00:02 |
|*  8 |         INDEX UNIQUE SCAN           | PK_DEVICETYPE        |     1 |     9 |     0   (0)| 00:00:01 |
|*  9 |         TABLE ACCESS FULL           | DEVICE               |   674 | 40440 |    87   (3)| 00:00:02 |
|* 10 |        INDEX UNIQUE SCAN            | PK_DEVICEMODEL       |     1 |    16 |     0   (0)| 00:00:01 |
|* 11 |       INDEX UNIQUE SCAN             | PK_RESCOLITEMPROFILE |     1 |     8 |     0   (0)| 00:00:01 |
|* 12 |      INDEX UNIQUE SCAN              | PK_DEVICEPROP        |     1 |     6 |     0   (0)| 00:00:01 |
|* 13 |     INDEX UNIQUE SCAN               | PK_RESCOLTIMEPLAN    |     1 |     8 |     0   (0)| 00:00:01 |
|  14 |    COLLECTION ITERATOR PICKLER FETCH| USERRESOURCEAUTH     |       |       |            |          |
------------------------------------------------------------------------------------------------------------
从执行计划看消耗cpu较高，返回行数差不多，也没发现什么具体的异样，于是让朋友做了个10046
快的sql：
select count(*)
  from slview.Device a,
       slview.Node b,
       slview.DeviceType c,
       slview.DeviceModel e,
       slview.DeviceProp f,
       slview.ResColItemProfile Profile,
       slview.ResColTimePlan ColPlan,
       table(cast(userresourceauth('admin', 'DEV', 'NOD999', 'CFG') as
                  resauthresult)) z
 where a.NodeCode = b.NodeCode
   and a.DeviceTypeCode = c.DeviceTypeCode
   and a.DeviceModelCode = e.DeviceModelCode
   and a.ChangeType = '0'
   and a.DevicePropCode = f.DevicePropCode(+)
   and a.ColItemProfile = Profile.ColItemProfile(+)
   and a.ColTimePlanId = ColPlan.ColTimePlanId(+)
   and a.deviceid = z.resid
   AND a.DEVICETYPECODE = 'DEV_IP_R'
call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.10       0.08          0        114          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        1      0.61       0.59          0       1230          0           1
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        3      0.71       0.68          0       1344          0           1
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 61 
Rows     Row Source Operation
-------  ---------------------------------------------------
      1  SORT AGGREGATE (cr=1230 pr=0 pw=0 time=599268 us)
    461   HASH JOIN  (cr=1230 pr=0 pw=0 time=600548 us)
    461    NESTED LOOPS OUTER (cr=77 pr=0 pw=0 time=29314 us)
    461     NESTED LOOPS OUTER (cr=75 pr=0 pw=0 time=23774 us)
    461      NESTED LOOPS OUTER (cr=73 pr=0 pw=0 time=17774 us)
    461       NESTED LOOPS  (cr=71 pr=0 pw=0 time=11310 us)
    461        NESTED LOOPS  (cr=69 pr=0 pw=0 time=4384 us)
      1         INDEX UNIQUE SCAN PK_DEVICETYPE (cr=1 pr=0 pw=0 time=42 us)(object id 52114)
    461         TABLE ACCESS FULL DEVICE (cr=68 pr=0 pw=0 time=3878 us)
    461        INDEX UNIQUE SCAN PK_DEVICEMODEL (cr=2 pr=0 pw=0 time=4169 us)(object id 52110)
    461       INDEX UNIQUE SCAN PK_DEVICEPROP (cr=2 pr=0 pw=0 time=3197 us)(object id 52084)
    461      INDEX UNIQUE SCAN PK_RESCOLTIMEPLAN (cr=2 pr=0 pw=0 time=3016 us)(object id 52243)
    461     INDEX UNIQUE SCAN PK_RESCOLITEMPROFILE (cr=2 pr=0 pw=0 time=3134 us)(object id 52239)
   1233    COLLECTION ITERATOR PICKLER FETCH USERRESOURCEAUTH (cr=1153 pr=0 pw=0 time=561120 us)
慢点sql：
select count(*)
  from Device a,
       Node b,
       DeviceType c,
       DeviceModel e,
       DeviceProp f,
       ResColItemProfile Profile,
       ResColTimePlan ColPlan,
       table(cast(userresourceauth('admin', 'DEV', 'NOD999', 'CFG') as
                  resauthresult)) z
 where a.NodeCode = b.NodeCode
   and a.DeviceTypeCode = c.DeviceTypeCode
   and a.DeviceModelCode = e.DeviceModelCode
   and a.ChangeType = '0'
   and a.DevicePropCode = f.DevicePropCode(+)
   and a.ColItemProfile = Profile.ColItemProfile(+)
   and a.ColTimePlanId = ColPlan.ColTimePlanId(+)
   and a.deviceid = z.resid
   AND a.DEVICETYPECODE = 'DEV_IP_R'
call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.22       0.20          0        127          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        1    175.75     171.77          0     192609          0           1
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        3    175.97     171.98          0     192736          0           1
Misses in library cache during parse: 1
Optimizer mode: CHOOSE
Parsing user id: 60 
Rows     Row Source Operation
-------  ---------------------------------------------------
      1  SORT AGGREGATE (cr=192609 pr=0 pw=0 time=171775026 us)
    235   HASH JOIN  (cr=192609 pr=0 pw=0 time=171763231 us)
    235    NESTED LOOPS  (cr=314 pr=0 pw=0 time=22534 us)
    235     NESTED LOOPS  (cr=312 pr=0 pw=0 time=18535 us)
    236      NESTED LOOPS OUTER (cr=310 pr=0 pw=0 time=15305 us)
    236       NESTED LOOPS OUTER (cr=308 pr=0 pw=0 time=11522 us)
    236        NESTED LOOPS OUTER (cr=306 pr=0 pw=0 time=7743 us)
    236         NESTED LOOPS  (cr=304 pr=0 pw=0 time=2537 us)
      1          INDEX UNIQUE SCAN PK_DEVICETYPE (cr=1 pr=0 pw=0 time=44 us)(object id 66966)
    236          TABLE ACCESS FULL DEVICE (cr=303 pr=0 pw=0 time=2020 us)
    236         INDEX UNIQUE SCAN PK_RESCOLTIMEPLAN (cr=2 pr=0 pw=0 time=2073 us)(object id 68692)
    187        INDEX UNIQUE SCAN PK_RESCOLITEMPROFILE (cr=2 pr=0 pw=0 time=1500 us)(object id 68688)
    234       INDEX UNIQUE SCAN PK_DEVICEPROP (cr=2 pr=0 pw=0 time=1607 us)(object id 66964)
    235      INDEX UNIQUE SCAN PK_DEVICEMODEL (cr=2 pr=0 pw=0 time=1720 us)(object id 66958)
    235     INDEX UNIQUE SCAN PK_NODE (cr=2 pr=0 pw=0 time=1788 us)(object id 68056)
   2253    COLLECTION ITERATOR PICKLER FETCH USERRESOURCEAUTH (cr=192295 pr=0 pw=0 time=171735676 us)
从上面的两个计划对比，慢点的sql的cr=192295 time=171735676 us，而cr=1153 time=561120 us 群里有的朋友说是sql的函数的作用，这时我也想起，我以前有过就是因为在sql用函数，导致sql很慢的经历
最后这位朋友查看函数，发现里面的sql的执行计划都不一样，这个朋友做了如下的调整，然后sql速度恢复
 
记录下，学到这个参数的用处，估计他这个库升级了，怕影响sql的效率所以才把这个参数保持原来的
 
-----end------
skate
关注
  • 0
    点赞
  • 踩
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
oracle optimizer_features_enable,【SQL 性能优化】参数设置
weixin_42324002的博客
04-05 789
QL> select * from v$version;BANNER----------------------------------------------------------------Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64biPL/SQL Release 10.2.0.4.0 - Product...
[20131111]参数optimizer_features_enable.txt
11-11 312
[20131111]参数optimizer_features_enable.txt optimizer_features_enable可以使系统升级后保持原来的执行计划。我自己很少做这种升级操作，昨天在给别人做优化时遇到一...
optimizer_features_enable
系统运维
11-14 436
if you upgrade your database from release 10.1 to release 11.1, but you want to keep the release 10.2.0.4 optimizer behavior, you can do so by setting this parameter to 10.2.0.4. At a later time, you ...
查询优化器参数optimizer_features_enable
blockheading的博客
05-22 4662
--查询优化器参数optimizer_features_enable --在每个数据库版本中，Oracle都会在查询优化器中引入或启用新的特性。 --如果在升级到一个新的版本后希望保留查询优化器的行为，可以通过设置这个参数或语句级别使用hint。 --不同版本优化器差异http://docs.oracle.com/cd/E11882_01/server.112/e40402/initparams
mysql optimizer_prune_level_MySQL实例自定义参数设置
weixin_42356811的博客
02-07 259
云数据库SQL Server实例不支持修改参数，MySQL实例支持修改参数，具体参数列表见下文MySQL参数列表。修改参数1.登录控制台->云数据库->管理云数据库实例。2. 找到需要设置参数的目标实例，单击管理3. 在云数据库详情页面最右侧点击参数设置4. 修改参数后，点击预览，预览修改的参数5. 点击保存，保存参数修改导入参数在参数设置页面，更多操作->导入参数2. 在导入参...
一文掌握数据库最核心的功能——优化器
华章IT官方博客
04-16 1068
导读：优化器是数据库最核心的功能，也是最复杂的一部分。它负责将用户提交的SQL语句根据各种判断标准，制定出最优的执行计划，并交由执行器来最终执行。优化器算法的好坏、能力的强弱，直接决定了...
oracle optimizer_features_enable,Oracle Optimizer:迁移到使用基于成本的优化器—–系列2.1-数据库专栏,ORACLE...
weixin_29577613的博客
04-05 161
oracle optimizer:迁移到使用基于成本的优化器—–系列2.1系列之二包含影响优化器选择执行计划的初始化参数和oracle内部隐藏参数，合理设置这些参数对于优化器是相当重要的。6.影响优化器的初始化参数除了生成统计资料之外，下面提及的参数设置在你的系统正常工作中扮演着极重要的角色.这些设置将大多依赖于你想创建何种类型的环境。联机，批处理，数据仓库或多于一个的组合。请注意优化器考虑这些参...
oracle optimizer_features_enable,Oracle OFE (OPTIMIZER_FEATURES_ENABLE)  参数 说明
weixin_40003767的博客
04-05 647
Oracle 数据库版本一直在不断迭代，其中一些重要的特性也在不断的引入，包括数据库SQL引擎也在不断的优化。https://www.cndba.cn/dave/article/4352Oracle的优化器共有两种的优化方式,即基于规则的优化方式(Rule-Based Optimization,简称为RBO)和基于代价的优化方式(Cost-Based Optimization,简称为CBO)，其中...
oracle optimizer_features_enable,[Oracle维护工程师手记系列]一次升级后运行变慢的分析...
weixin_34363071的博客
04-05 351
客户报告，当他从 Oracle 11.1.0.7 ，迁移到云环境，并且升级到12.1.0.2。运行客户的应用程序测试，发现比以前更慢了。从AWR report 的"Top 10 Foreground Events by Total Wait Time"和"Wait Classes by Total Wait Time"等信息，可以看到 CPU 值升高了。初步思考，怀疑由于环境的不同，导致性能不同。...
053试题 233 - OPTIMIZER_FEATURE_ENABLE
文档搬运工
08-27 128
题目： 233.Your system has been upgraded from Oracle Database 10g to Oracle Database 11g. You imported SQL Tuning Sets (STS) from the previous version. After changing the OPTIMIZER_FEATURE_ENABLE parame...
会话级指定和提示级指定OPTIMIZER_FEATURES_ENABLE结果不同
ckawt40802的专栏
09-27 237
帮客户优化时发现，同样是OPTIMIZER_FEATURES_ENABLE参数，在会话级设置和在HINT中指定的效果不同。 客户的数据库从11.1.0.6升级到最新的...
11.2.0的参数OPTIMIZER_FEATURES_ENABLE会话层与语句层上设置区别；
N
05-29 7210
--下午在测试ventor io的发现OPTIMIZER_FEATURES_ENABLE在会话层级别和语句级别的HINT有差异； 先操练下： --加入hint情况，OPT_PARAM('OPTIMIZER_FEATURES_ENABLE','10.2.0.1') SQL> select * from v$version; BANNER ------------------------------
【SQL优化器】初始化参数
cojm55771的博客
09-09 128
一些和优化器相关的初始化参数1、OPTIMIZER_FEATURES_ENABLE每个版本的Oracle优化器特性都不相同，特别是做了版本升级以后一定要修改这个参数才可以使用仅被该版本支持的优化器特性。可以赋予它的...
Oracle参数查看方法小结
热门推荐
宁静致远
09-24 1万+
Oracle提供了大量的系统参数，下面是查询方法小结。 系统当前参数 系统当前参数涉及到这些视图：v$parameter、v$parameter2、v$system_parameter、v$system_parameter2和v$spparameter。 v$parameter 存放session级的参数，如果没有被"alter session"修改，默认和system级的参数值相同，下面
一个android应用开发的感悟
weixin_34138521的博客
03-12 161
　　对于客户端的开发，以我个人现在的水准，很难进行一个系统的讲解，只能分享下遇到的几个问题点好了！ 　　1：对于tabhost的使用，这个东西真的是过时了；第一个版本，我是用的tabhost确实是很难用，不过效果都做出来了，我就想这样凑合好了，无奈客户端更加专业的同学还是坚持让我改成Fragment去做！ 　　2：关于FreshPullList的使用，对于列表的使用，我想大家都不陌生，可是an...
Oracle中的Hint
qq_41967563的博客
04-28 9439
Hint是Oracle数据库里SQL优化的终极手段，通常用于直接指定目标SQL的执行计划，它作为一种非常规的直接影响优化器，指定执行计划的手段。深入理解Hint，能明白Hint是如何影响优化器对于执行计划的选择的，进而用好Hint，能起到事半功倍的效果。 1 什么是Hint Hint实际上是一种特殊的注释，它以一种固定的格式和位置出现在SQL语句的SQL文本中，可以影响优化器对于执行计划的选择，但这种影响不是强制性的，优化器在某些情况下也可能忽略目标SQL中的Hint,即使这个Hint在语法和语义上是有
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值