session allocation latch问题

棉花糖ONE · 发表于 2007-10-9 17:48

最初由 biti_rainy 发布
[B]

我没鼓吹不找证据啊，大家不要误会
在经验、基本功的知识上，有时候需要直觉。

当然这个例子，在完善的诊断script 和 monitor 之前，自然是可以抓到踪迹发现问题并解决问题的。对于我们的正式环境，都会部署一系列的标准script 供dba使用，监控自然也是比较完备的。

我这里只强调在遇到不曾遇到的问题、脚本有可能无法诊断的问题，甚至短时间内无法识别的问题，有时候需要靠直觉快速解决问题。但最先这个例子不属于这个情况，我举的第二个例子属于这个情况。问题最终是一定要分析清楚的。

说到直觉，不妨说说上次你那个 redo log里面解析sql出来如何识别事务的问题，我相信你也是仔细思考并尝试过的。其实我最近3年几乎没有研究过block结构以及事务信息了，但你一问到这个问题，我的直觉告诉我应该怎么去找，所以几乎很快就找到了如何在redo 里面识别事务。直觉不是告诉我结果，是引导我朝着正确的方向去以最短的时间证实一些事情。同样一堆诊断script放着，直觉可以告诉你先运行什么script先分析什么数据，如此而已。

再次说一下，直觉是方向性的引导，不代表结果。直觉是在大量经验和对概念知识的深刻理解的基础上的，而不是拍脑袋的。 [/B]

biti老大，太厉害了

biti_rainy · 发表于 2007-10-9 17:48

每个人在自己的工作中，会总结一系列的方法、脚本，在遇到问题的时候会遵循一定的规则去排除、查找问题，这是基本的要求。不要妄图跳过这一步。所以dba也要讲通用的方法，而一个团队，通常诊断的过程和方法也大同小异。ebay如此， alibaba的team依然如此。我们追究问题绝不轻言放弃，即使花上一两个月甚至阅读部分linux kernel的经历也是有的，这就是为了明确问题，而不是糊弄过去。

flying.hg · 发表于 2007-10-9 20:09

學習了！

nokilled · 发表于 2007-10-9 21:39

最初由 biti_rainy 发布
[B]每个人在自己的工作中，会总结一系列的方法、脚本，在遇到问题的时候会遵循一定的规则去排除、查找问题，这是基本的要求。不要妄图跳过这一步。所以dba也要讲通用的方法，而一个团队，通常诊断的过程和方法也大同小异。ebay如此， alibaba的team依然如此。我们追究问题绝不轻言放弃，即使花上一两个月甚至阅读部分linux kernel的经历也是有的，这就是为了明确问题，而不是糊弄过去。 [/B]

钦佩！

pooplpos · 发表于 2007-10-9 22:13

最初由 biti_rainy 发布
[B]即使花上一两个月甚至阅读部分linux kernel的经历也是有的，这就是为了明确问题，而不是糊弄过去。 [/B]

厉害，读LINUX KERNEL的代码，什么时候我能达到这个水平呢？

wdpj2ee · 发表于 2007-10-9 22:39

谢谢分享案例

liu_xp2003 · 发表于 2007-10-9 23:10

嘿嘿,前不久在分析性能的时候也遇到过.
一下是我的个人分析:

session allocation可以定位DB当时的session在产生这个latch的时候已经有相当大的数量,同时还无法满足应用需求在产生新的session.
一般应用服务的JDBC ODBC都会有一条简单的SQL来做health check(such as: select instance_name from v$instance).
此时通过相关工具可以查到session allocation的等待事件都是有该条health check语句产生的,一般同时会伴随CPU等待.
通过stackpack和类似工具可以查到,health check语句的执行次数远比正常时候大.

可能原因: 应用中查询数据库时SQL被嵌套在循环中并在循环中产生新的DB connection请求.