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

kelsoncong

很好的实践，mark下，回去也试下。
这个性能对数据仓库还是帮助蛮大的，高并发的OLTP系统还是要尽量避免这种全表扫的

yyp2009

棉花糖ONE 发表于 2012-1-16 18:46
1.10g以后排序的等待事件是direct path read temp,或者综合变得指标都能看出来(sort disks,或者根据ash ...

11g不知道
direct path read并不一定触发object checkpoint-----玉面飞龙的曾经文章
http://yumianfeilong.com/html/2009/02/25/327.html

yyp2009

同时不妨参考一下阿里这位的文章
http://space.itpub.net/22034023/viewspace-688817

yyp2009

http://space.itpub.net/24582392/viewspace-705133

http://blog.itpub.net/post/37461/496571

yyp2009

不过说实话 Kevin__Zhang 嗅觉很敏锐啊 ！

yangb71881

AndyChan 发表于 2012-1-16 20:01
路过。非常关注sql tuning advisor 与direct path 的影响。

物理IO的大小不再取决于buffer_cache中所存在的块；试想某个8个块的extent中1,3,5,7号块在高速缓存中，而2,4,6,8块没有被缓存，传统的方式在读取该extent时将会是对2,4,6,8块进行4次db file sequential read....
这有点不明白...能详细解析下吗？ 主要是为何要进行4次？

hp.smiling

yangb71881 发表于 2012-6-11 15:57
物理IO的大小不再取决于buffer_cache中所存在的块；试想某个8个块的extent中1,3,5,7号块在高速缓存中，而 ...

你可以查下这个事件的机制：db file sequential read，就会懂得为什么要读取4次了。

yangb71881

yangb71881 发表于 2012-6-11 15:57
物理IO的大小不再取决于buffer_cache中所存在的块；试想某个8个块的extent中1,3,5,7号块在高速缓存中，而 ...

呵呵，理解错误，以为是一个块要读取4次

george16

悲剧了，偶的新公司也上11g r2，看来要尽量避免全表扫描啊。

在oltp系统还是尽量不要写这种全表加载大表的sql为好。