熊猫大侠一次性能诊断优化十一问

最新推荐文章于 2024-07-24 16:19:12 发布

转载最新推荐文章于 2024-07-24 16:19:12 发布 · 91 阅读

                     熊猫大侠一次性能诊断优化十一问

刚才看到  ORA-600 & ORA-7445 by Maclean.Liu帖子：
http://www.itpub.net/thread-1558212-1-1.html
大家蜂拥而至呐喊受精！

我学习了一下，的确本身碰到这么多的问题，本身不容易
并且能一一记录在案就更不容易了

但是有些我是这样看的
碰到这么多
不过看了几篇没什么特别的
不过是 metlink/sr 和bug 说

不过还是有不少学习的地方

授精个人觉得有待商榷

是不是 bug 原因有可能是更深层次的？
是不是问题“想当然”的就这样？

很多归于bug 有时候是不严谨和科学的
很多想当然的得出结论是轻率的和不科学的

凡事都需要多问个为什么的
由看熊猫大侠想开去：
比如我昨晚看到的熊军的一文：
修改隐含参数_library_cache_advice解决性能问题一例
http://www.laoxiong.net/resolve- ... meter.html#more-857
要是我们说不好问题就定位为shared pool latch结案，还欣欣然的离开
可人家最终会思考到shared pool simulator latch的竞争

个人表示很敬佩人家的这种精神和境界！！

看看此文中熊军疑惑的“为什么呢？”————————
从Load profile数据对比来看，应用调整后系统负载有一定的提高，同时每事务逻辑读也有一定的增加（不足10%）。这会是个问题吗？

最直观的，最容易想到的就是，性能问题的出现是否与应用调整有关，如果是，为什么另一套库没有出现问题？
会不会是另一套库的负载在2个节点都有相对均衡的负担，而出问题的库，负载全部集中在1个节点上引起？
客户是在应用调整几天后才报告性能问题，这个问题会不会是一个逐渐出现的问题？
如果一开始就有严重的性能问题，那么应该会很快报告。不过中间跨了一个周末，所以对于”逐渐出现问题“的判断又加了一些难度。
这么多的性能问题相关的现象中，哪个更贴近问题的原因？
实际上在主机的CPU长期保持在100%左右时，会放大平时的一些轻微的问题，或者引起另一些问题。从等待来看，latch: cache buffers chains和cursor: pin S都会引起CPU的急剧增加，而其他的latch竞争同样也会引起CPU的上升，虽然上升没有前者大。到底是SQL执行效率不高引起CPU急剧增加然后引起了shared pool latch等与解析相关的资源争用还是因为解析相关的问题导致CPU急剧增加引起了cache buffers chains等与SQL执行相关的latch争用？
或者是2者的共同作用？

虽然性能问题已经解决，但是留下来需要更深入的问题还有：
cursor: pin S这个等待，在shared pool simulator latch争用时，是如何产生的？
share pool simulator latch的争用是如何产生的，为什么之前没有，是什么引起的？
是BUG吗？
如果是BUG又是怎么触发的？
实际上后面尝试将”_library_cache_advice”参数改回为TRUE，但是该性能问题并没有再次出现。
……