|
|
有时候，METALINK的水平真不敢恭维。
至少碰到过两三个case , 是我在引导他们的工程师走到解决问题的正路上。
最初由 biti_rainy 发布
[B]
其实我说这么多并不是针对你发言，只是说，能想到很多情况并且包含真实原因，并不代表能快速真的找到原因。
我对oracle 的等待 或者 错误信息提示，一向是 99.99%相信的！经常有很多人看到一些似乎粗浅的提示会忽略过去，不相信系统是有浅显的错误 或者 认为这个错误的原因 不可能存在。 但事实情况下很可能有一些超出常规的设置、操作等导致系统触发浅显的错误。 顺着这个浅显错误提示往往能最快找到问题所在。 但太多的人太自信了……常说的一句话就是： 那不可能，没有任何人做过任何动作。
这种保证的话我听的太多了。 越来越多的案例让我更坚决地相信oracle的提示信息是一条走向正确道路的方向。
回到这个问题，出现 session allocation ，往常真没见过，在系统大量并发症状的情况下，很多人会认为这是 伴随发生的。但我相信oracle的提示，那真的是在session 级别有创建和消亡。 session的创建和消亡 如果频率过高会导致系统出现严重问题。 在确认应用连接自身没什么问题之后我就一定要明确 并行问题。 不把这方面的原因彻底排除，我是不会转去研究其他问题的。 所以在这个情况下，我根本不去研究 执行计划、sql 以及其他表现。 如果自己在现场，基本上5分钟以内就能明确问题，很快就能解决问题。
在高压力情况下，有些时候，DBA需要有自己的直觉。这是建立在基础、经验之上长期培养的。
3年半前 我们在linxu rac 上遭遇过一个问题，2星期左右oracle就crash 一次，根据oracle的trace 来看，隐约是跟内存有关，但不明确。其实以前一直很正常的，那时候 这种情况连续出了3次，但oracle metalink的人换了一茬又一茬也没有进展。我也刚到公司才一两个月，这个时候跟rudolf就问题的原因争执起来了。 我怀疑跟 aio 有关系，因为aio 会需要一部分内存，怀疑在高压力的时候aio 积累太多内存消耗比较大，oracle 跟os之间配合出现问题而down。 所以我要求 去掉aio。 但 rodulf 认为 aio是个好东西，我问题没搞清楚就决定这么做没必要。
由于系统出现3次故障 影响非常大，我们的技术总监那时候也决定不了，后来我们争论到了CTO办公室（吴炯），在办公室我强烈要求去掉 AIO。 由于除了我这个建议其他也没什么办法，吴炯就说那去掉看看吧。 于是在一个周末早上6:30，我去掉了AIO，从此系统运行稳定再没出问题。 大约3个月后，oracle的人终于说可能跟AIO有关系。
其实出这个问题的时候，oracle 的提示是和内存有关，但没有证据表明系统内存不足。 所以我坚持是在某个环节的内存分配有关系，而自然联想到AIO要消耗内存 可能是正好高峰时期down的原因……
你说这是经验还是基本功？ 都不好说，有的时候就是直觉。
当然我这么说并不是说不需要严谨的分析了，直觉是为了最快的解决问题，但时候一定要严谨的分析到问题的根源。 我们好几次一个问题追踪了几个月才有结论。 [/B] |
|
楼主: biti_rainy
IP卡
狗仔卡
发表于 2007-10-8 11:46
显身卡
发表于 2007-10-8 12:12
