小案例分享，11G新特性引发的严重性能问题【附AWR截图】

sohay

非常不错，感谢分享！

leros123

救命的东西.我昨天重装了生产库用了11gr2  今天一天都是direct path read.电话都爆掉了

qq262420958

棉花糖ONE 发表于 2012-1-16 12:17
alter system set event= '10949 trace name context forever, level 1' scope=spfile;
alter system set  ...

ご認識のとうりですね

当タスクの処理でパフォーマンスが落ちる可能性があるため使用しない。
※Standard Edition Oneでは使用できない。

qq262420958

棉花糖ONE 发表于 2012-1-16 12:17
alter system set event= '10949 trace name context forever, level 1' scope=spfile;
alter system set  ...

ご認識のとうりですね

当タスクの処理でパフォーマンスが落ちる可能性があるため使用しない。
※Standard Edition Oneでは使用できない。

xiaoli

学习过。

szy00416

不错，学习了

cugshomi

我的数据库最近也出现了这个问题，但是我对这个问题为什么出现一直持有怀疑态度，在11g R2的数据库中，数据库通过隐含参数控制什么时候使用direct path read，理论上是超过一定的块大小之后就会触发直接路径读。但是事实上，我数据库中的某张表上建有分区，而且是历史数据，没有过任何的刷新，统计信息也没有刷新，数据库之前访问这张表的历史分区时，使用索引都是partition index range scan，但是突然在某天访问同样的分区，就变成了partition index fast full scan，而且当时出现问题时，存储达到IO极限，为了确定是否是执行计划的问题，立马把sql执行一遍看计划，但是奇怪的是，前端应用服务器抛过来一样的sql ，采用的是index fast full scan ，我自己从sqlplus上抛进去相同的sql ，执行计划是index range scan。所以我基本可以断定，这是一个数据库的bug，不可能在同一时间同一sql，来源不同就采用不同的执行计划，而且在数据量以及统计信息没有发生任何变化的情况下就发生。

cugshomi

从直接路径读带来的效果看，我觉得ORACLE的设计工程师并没有考虑OLTP系统上大并发导致的存储级别的IO问题，可能当初设计DIRECT PATH READ时，是基于OLAP这种小并发模式或者EXADATA这种分布式架构的数据库进行设计的，只不过数据库本身并不知道用户是在哪种模式下使用数据库，所以莫名其妙触发了直接路径读从而造成显著的IO性能瓶颈。另外，我基本上可以肯定，数据库判断什么时候使用直接路径读时，绝对不是网友所说的两个隐含参数的值来控制，肯定还有其他我们不知道的参数发挥着作用。不然数据库还不至于傻成一条sql两条执行计划，在一条明显优于另一条时，还采用效果差的那条计划。