X

Author Profile

Feng Gao

Recent Posts by Feng Gao

只对某个特定的SQL语句开启10046 trace

最近碰到了这样一个有趣的问题: 有一条SQL语句,大部分时间它的执行时间是几十个毫秒; 但是偶尔某次的执行时间会长于2秒钟。因为应用对这个语句的执行时间非常的敏感,我们必须诊断是因为什么原因导致它偶尔执行时间长于2秒。 这个问题为什么会有挑战性呢?因为我们很难收集慢的时候的10046 trace:首先我们不知道这个问题什么时候会发生,也不知道会在哪个session里发生。如果对所有的session全天开启10046 trace, 会产生很多比较大的trace并影响数据库整体的性能。 好在这个数据库是11g的,在11g中event++的特性允许我们只对某个特定的SQL收集10046 trace. 即在运行这条SQL时开启10046 trace,在这条SQL运行完之后关闭10046 trace.这样可以显著的降低生成的trace的大小。但是因为我们无法确定哪个session会产生问题,所以只要运行过这个SQL的session都会产生一个trace文件。 开启的步骤是(要把下面的awsh60c8mpfu1替换成那条SQL的SQL_ID): alter system...

如何分析发生在过去的数据库性能问题

在数据库运行的过程中,我们有时会碰到数据库hung住的问题,在这个时候很多人会选择尽快让它恢复正常而不是找出问题的root cause. 只有在问题被解决后,才意识到需要找到root cause来避免再次碰到相同的问题; 下面就讲讲如何分析发生在过去的数据库性能问题 (这是一篇讲方法论的blog,并没有涉及到具体的案例, 稍后会有更多具体案例的Blog) 1.       首先要申明的是, 对于这样的问题,我们需要有一个正确的期望: 不一定能够找到root cause, 这取决于发生问题时是否收集到了足够的信息. 2.       梳理我们可以收集到的信息, 一般的可以先检查下面的日志 a)       操作系统日志, 参照文档 note 1349613.1 - How To Gather The OS Logs For Each Specific OS Platform b)       数据库alert log c)       操作系统resource(CPU, memory, IO, swapping)使用的状况, 推荐使用OSWbb...