1.数据库性能问题分析和诊断方法

1.数据库性能问题分析和诊断方法

知识有时候仅仅是知识，在处理实际问题中对问题的理解和处理问题的思路，以及在掌握知识的基础上活用知识可能更为重要。
这篇文章是笔者在技术支持工作中应用多年的Oracle数据库问题分析和诊断方法。
我愿意以此篇，作为本专栏的首篇文章，希望对大家有所帮助。

从宋丹丹的小品开始

如多年前宋丹丹的小品 ：

问：“把一个大象装进冰箱要几个步骤？

答：“分三步，
第一步，打开冰箱。
第二步，把大象塞进冰箱里。
第三步，把冰箱关上。”

同样，分析和解决数据库性能问题也可以概括地分为三步：

• 第一步，形成“共识”。
• 第二步，分析和诊断。
• 第三步，提供解决方案。

第1步：形成共识

所谓形成共识，即与“客户”站在同一立场上，从“客户”的角度出发定位问题，理解“客户”真正想要解决的问题，以及对“客户”的影响范围等；这里的“客户”可以是使用数据库的客户，也可以是请教你问题的朋友同僚。

2个小例子

很多时候，“客户”其实也并不能清楚地描述自己的问题，例如很多客户可能只会问”Oracle数据库选择索引的原理是什么？“，”我的数据库慢了，我该怎么办？“，
通过客户的描述，我们似乎看到了客户的问题，但是我们真正弄清楚客户问题是什么么？在哪里了么？

以上面的2个问题为例，问题是不是还可以更清晰些，更具体一点儿：

”Oracle数据库选择索引的原理是什么？“

    ・客户的问题仅仅是一个咨询性的问题么？
    ・还是客户遇到了什么问题而产生了这种疑问呢？
    ・在回答客户问题的同时，顺便问一下问题背景是不是更好？

”我的数据库慢了，我该怎么办？“

    ・客户遇到现象是什么样的？是整个数据库慢？所有的应用处理都慢？还是某一条特定的SQL慢？
    ・客户所谓“慢”的标准是什么？相对地达到什么目标才算成“快”？
    ・问题还在发生还是过去某个时间段发生的？问题发生的精确时间是什么？
    ・问题的发生是否有规律可循？是否可以任意重现？
    ・问题发生前是否对服务器、数据库或者应用等进行了变更？（如硬件软件变化、打补丁、应用程序修改、表结构变更等）

如中医的望闻问切诊法，为了做出客观的正确判断以便对症下药，除了弄清客户的问题描述以外，同时需要搜集和整理一下已知的线索和相关信息，以便验证问题到底是不是如客户所述。

这一点之所以重要，因为人都是有主观性的，可能会忽略显而易见的东西。比如疑邻盗斧的故事，建立在错误的前提上， 之后的分析再怎么努力，再怎么正确也是徒劳。

第一步的目标

从软件开发的角度来讲，这是需求分析中“获得用户承诺”的重要步骤，它的重要性几乎决定了你整个开发的成本和风险。

通过这一步，我们要与“客户”形成以下的共识：

・明确问题，确立目标
・尽可能地缩小问题范围
・定位环境信息（数据库版本，补丁状况，运行平台）
・弄清楚4W（What：现象、When：时间、Where:范围 、Who：影响）

好的开始便是成功的一半，通过理清这些问题，部分问题原因和答案可能会已经跃然纸上了。

第2步：分析和诊断

分析和诊断性能问题包括一系列的行动计划，数据和信息收集，分析和调查。

这不仅仅是一个搜索资料，对比文档清单进行 校验的过程，而是充满创造力，考察对细节的把握，经验及直觉分析等能力的过程。

新手与专家的区别

新手与专家的区别常常在此。

例如，当遇到相对复杂的问题时，初级工程师有时会大海捞针一般不断地搜索各种资料，然后不断地尝试各种方案，有时甚至会在某个方向(或某个可能原因)上死扣到底，却难以找到症结所在。

而资深工程师在确认和理清问题后，（有时甚至在很短的时间）会提出一个相对靠谱的行动方案或者指明进一步的调查方向。差距到底在哪里呢？

问题的处理能力

个人认为数据库性能问题诊断中对问题的处理能力，可以总结为以下几个方面：

・知识架构的系统性（广度） 
・某一领域知识点的理解程度（深度）
・经验和时间积累的问题敏感度

知识不等同于信息，只有经过思考和处理才能让信息变成你的知识。

对于知识的系统性即广度而言，需要在系统的学习，读书，参加培训过程中，具有开放的绿灯思维，保持各种新事物的好奇心，对接触到的信息内容不断整理和拓展；

对于知识的理解即深度而言，则需要在知识的重复性学习和解决问题过程中，不断自己动手测试验伪，追本溯源回归原理。

对于问题的敏感度，则是一种综合能力，需要在前两点的基础上，通过经验积累和有意识地磨练。

思考方法

作为一般的思考方法，可以通过有效的联想，基于基本原理和特定情景，深入本质，找出已知信息和未知变量之间的联系；

如果不能够找到直接的关系，再进行联想，普遍化或者特殊化相关类似问题，保留一部分已知信息再进行抽象和摸索，找到思路。适当地休息让右脑工作也能起到意想不到的效果。

然后可以通过规范的流程(例如如本文中介绍的内容)对已确定内容的回顾和重新整理思路，缩小问题范围，找到突破点，并找到最终的原因。

数据库性能诊断清单

对于数据库性能问题，我们通常采取自上而下的方法进行诊断，下面是一个自上而下性能问题诊断的清单:

▲自上而下性能问题诊断的清单

1.　
80%以上的问题是由于应用导致的，所以在遇到数据库性能问题时，首先要从应用程序和应用状况入手，看看发生问题时或之前，是否有相关的应用或设置变更等，对于数据库来说比如参数修改，表或索引的变更，大量的修改删除或错误的应用导致的连接风暴等。

2.　
对于一台服务器而言，包括硬件和软件；软件又可以细分为操作系统和操作系统上应用软件，数据库只是操作系统上应用软件的一个应用软件而已。
当操作系统整体较慢时，作为应用软件的数据库自然也会受到影响，成为被害者而性能低下。

所以，当我们遇到服务器的CPU/内存/I/O等资源的使用率较高时，首先要通过OSWatcher或TOP等OS命令弄清楚到底是什么应用在占用大量的CPU/内存/I/O等？这里的“罪魁祸首”可能是Oracle数据库的操作，也可能是操作系统本身进程或者其他应用软件（如杀毒软件，备份软件等）。

3.　
如果操作系统层面没有问题的话，则需要看一看是整个数据库实例慢还是挂起（Hang/Spin）状态。
如果是数据库实例慢，我们可以通过AWR/Statspack/ASH/动态试图等数据库工具来确认数据库整体性能是否真的有问题以及进一步缩小一下问题的范围。
需要注意的是，所谓的是否有问题的标准时相对的，要参考平时的负荷状态以及事先建立的基线等。
如果是挂起（Hang/Spin）状态，最好第一时间取得hanganalyze和systemstate dump信息，以便找到根本原因。

4.　
如果能够找到某些特定的进程或会话占用大量DB时间，我们可以基于进程的信息来分析和诊断，看看是后台进程还是前台进程有问题，
如果是后台进程的话，可能和数据库内部运行程序本身相关，如果前台进程则可能是用户的应用程序有问题。

5.　
如果能够定位某条SQL语句，可以确认问题在于SQL的哪个执行阶段（Parse？Executing？Fetch？），执行计划是否改变？我们可能会去SQL Trace 或者Optimizer Trace进一步诊断。

分析和诊断问题是一个循环的过程：从理清问题后最初的灵感开始，收集数据，确认相关信息，重新思考/调查，找突破点，提出行动方案，验证和测试，收集更多信息…重复直至最终找到原因。

定位原因

通过上面的步骤循环，我们可能找到“我们认为”的问题原因，但是由于人的思维习惯，很容易有很多的“想当然“，存在认知偏差和条件反射。

所以，正式下结论前，我们还需要重新斟酌，想想导致问题发生的数据库运行基本原理，并结合用户的环境，形成一个证据链，通过相应的事实和理由来证实确实是我们指出的原因导致现象发生。

这其实是最重要的一个环节，就像是法官的举证和审判。

记得电影《唐人街探案》中唐仁在完成找到“失落的黄金”、查明“真凶”的陈述中，不仅仅是一些证据的罗列，而是要形成一条证据链，能够讲述一个完整的故事，表明真相，让观众和警察都会信服。

第3步：解决方案

作为分析诊断问题三板斧的最后一斧，则是根据原因找到最佳的解决方案。

解决方案三要素

这一步骤的内容主要包括三个要素，即：做什么（What）、为什么（Why）、怎么办（How）。

做什么（What），就是根据上一步找到的问题原因制定解决方案。这个部分中，我门要思考充分，尽可能地想出所有的解决草案。

为什么（Why），是论证解决方案的部分。我们要根据基本原理和经验案例或者测试来论证解决方案的有效性。

怎么办（How），最后一个步骤是依靠我们的专业性，提出最佳的解决方案，所谓最佳的解决方案是在理解用户业务和技术影响的基础上，在当前情境中找到影响最小，最有效果的解决方法。另外，为了适用于不同水平的客户和减少追加问题，我们需要给出具体的详细的实施步骤。

小结

本章主要介绍了据库问题分析和诊断的三个主要流程：

第1步：形成共识
第2步：分析和诊断
第3步：解决方案

关于技术的一些思考：

新手与专家的区别
问题的处理能力
思考方法

并且提供了一份数据库性能诊断清单。