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

mustapha

我持不同观点，10G和之前的版本，全表扫描的性能是非常的差，因为做一个10046跟踪就可以知道，当遇到有块在cache中时，扫描就会被打断，从cache中读出数据，然后再继续扫描表，当存储性能非常好的时候，没有索引的情况下，出现了全表扫描，也无法充分发挥存储的性能，sql就在那里慢慢的一点一点的读了断，读了断，一点一点的，可以说全表扫描的性能实在是非常差，根本无法接受，尤其是在数据仓库中，是无法避免全表扫描的，这时候11g的新特性就非常好的解决了这个问题，这个问题也是oracle的开发人员一直想要解决的。

在oltp的数据库中，是要避免全表扫描的，这样只要在上线前审核sql时，把频繁执行的关键sql全部使用索引就可以了，不频繁的sql，偶尔一天之中用以此全表扫描，因为direct path read的功能，反而提高速度。
如果是olap的仓库系统，尽量将频繁扫描的表移到memdisk或者fusionio的闪存存储上，处理性能是非常之高的，大家可以尝试一下，我始终认为是个非常好的特性。

棉花糖ONE

mustapha 发表于 2012-1-17 09:49
我持不同观点，10G和之前的版本，全表扫描的性能是非常的差，因为做一个10046跟踪就可以知道，当遇到有块在 ...

任何特性没有绝对好和绝对坏的,oracle应该提供一个功能,能在对象级别设置这种特性,这个可以做为表的属性来做啊

likgui

这种问题有什么好的解决方案？

lbs1988

恩 遇到过这个 问题， 还遇到过 一个问题  resmgr: cpu quantum 等待， 在 EXADATA 和 普通的11g都遇到过 关闭 resource manager 就行了

dla001

棉花糖ONE 发表于 2012-1-17 10:02
任何特性没有绝对好和绝对坏的,oracle应该提供一个功能,能在对象级别设置这种特性,这个可以做为表的属性来 ...

向老大学习

mustapha

棉花糖ONE 发表于 2012-1-17 10:02
任何特性没有绝对好和绝对坏的,oracle应该提供一个功能,能在对象级别设置这种特性,这个可以做为表的属性来 ...

好像tom大叔说过，参数没有一个确定值是合适的，所以才没有固化参数，但是direct path read被默认使用在了数据库级别，oracle公司的开发人员是认为是好的，所以进行固化，但是可以理解大家的情况，有些数据库优化的不太好，10g的情况下，及时全表扫描也不会占很大的io，因此没有问题，但是放在11g，io就出现问题了，这是个好事也是不好的事情，好事是说可以发现问题，对索引好好维护一下，做好优化， 不好么，就是本来不需要优化凑合用的系统，在11g这种的情况下必须进行处理。

ccd_19801003

学习了，多谢分享。

ccd_19801003

lbs1988 发表于 2012-1-17 11:14
恩 遇到过这个 问题， 还遇到过 一个问题  resmgr: cpu quantum 等待， 在 EXADATA 和 普通的11g都遇到过 关 ...

落落童鞋，你说的那个事什么情况？

taelons

一开头思路就不对,始终要避免没有where的全表扫描!
别期望oracle能帮你解决任何问题.

hctech

请教一下，direct path read这种方式是不是在10G的后续版本中就已经有了的？