session allocation latch问题

WESTLIFE_XU

没有完全理解，明天去公司测试一下

battleman

直接定位到并行问题，很有难度

paulyibinyi

好帖，顶一下

warehouse

最初由 biti_rainy 发布
[B]

呵呵，事实情况一般是当故障发生的时候，表现有很多形式，这只是其中一种，人能想到的可能性也非常的多。 没有人敢 100% 的确定是怎么回事情。 所以处理的人必须快速的清晰的确定方向并迅速做出 证实  或者证伪 的操作。 若这个过程太长……则可能受到其他因素的干扰而导致自己摇摆。 最后陷入困局，因缘差错而失去明确问题的机会。

当然，说这个我也并不只针对这件事情，这次我不是现场接受压力的人。很多时候事实是这样的，在高压力情形下的人，很容易对自己的判断摇摆……很难冷静…… 所以真实故障处理的时候对我们有更高的要求。 [/B]

我少敲了几个字，大师多虑了
我是想说在这么紧急的情况下，确实没有多少人能如此迅速准确的定位这么不常见的问题，而且还不在现场！这需要的到底是经验还是扎实的功底
记得自己有一次在现场遇到12540错误时，连接数据库时几乎所有的连接都死在哪儿，偶尔能连上1，2个，当然系统更是慢的几乎什么也干不了！通过vmstat发现操作系统page in ，out 严重，最后几经摇摆发现os memory 2g ，sga分配了1。8g，导致os memory严重短缺造成的！将sga下调问题得以解决！

扯远了，还是说说大师是如何定位到parallel的吧

rollingpig

又看了一下
还有其他几条路可走
1。 v$session_wait / v$system_event => v$session.sql_address => v$sql / v$sql_plan ==> auto trace/explain plan ==> parallel ==> degree

2。statspack top SQL => auto trace/explain plan ==> parallel ==> degree
....

anlinew

最初由 rollingpig 发布
[B]又看了一下
还有其他几条路可走
1。 v$session_wait / v$system_event => v$session.sql_address => v$sql / v$sql_plan ==> auto trace/explain plan ==> parallel ==> degree

2。statspack top SQL => auto trace/explain plan ==> parallel ==> degree
.... [/B]

如果在现场，路1很直接

老少皆益

biti_rainy

最初由 warehouse 发布
[B]

我少敲了几个字，大师多虑了
我是想说在这么紧急的情况下，确实没有多少人能如此迅速准确的定位这么不常见的问题，而且还不在现场！这需要的到底是经验还是扎实的功底
记得自己有一次在现场遇到12540错误时，连接数据库时几乎所有的连接都死在哪儿，偶尔能连上1，2个，当然系统更是慢的几乎什么也干不了！通过vmstat发现操作系统page in ，out 严重，最后几经摇摆发现os memory 2g ，sga分配了1。8g，导致os memory严重短缺造成的！将sga下调问题得以解决！

扯远了，还是说说大师是如何定位到parallel的吧 [/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的原因……

你说这是经验还是基本功？  都不好说，有的时候就是直觉。
当然我这么说并不是说不需要严谨的分析了，直觉是为了最快的解决问题，但时候一定要严谨的分析到问题的根源。 我们好几次一个问题追踪了几个月才有结论。

anlinew

杀猪杀屁股，呵呵

有时候挺悲观的，哎
这世界缺了谁也一样转，就算没有你，这问题没准儿也一样被糊弄过去，就算没有解决根本问题，也一样过去。。。

howard_zhang

最初由 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]

学习了

chj733

能感觉SESSION出问题,但没想到并行