SQL数据库并发访问客户负载高的问题分析

          最近拜访客户时，客户反馈前几天数据库遇到了问题，希望我们能帮忙看看并找出问题。客户反馈现象如下:有一个非常核心的系统数据库。突然有一天用XXXschema登录后，运行的SQL并行运行，DOP很高。如果多次定位故障失败，只能临时使用parallel_max_servers参数降低到32，缓解并发压力过大。故障确认，先看数据库前几天的情况，AAS的故障期确实很高。切换到单个SQL运行，DOP很高，然后受到限制，与客户描述一致。顺手打开旁边的监控报告，DOP明显降级。初始并行度192引人注目，逻辑CPU为96，非常像自动并行时数据库默认并发度。当然，整个数据库肯定没有自动并行打开。

初步排查在客户的带领下，确认故障期与客户描述基本一致。单听描述似乎是调整会话级别并发的触发器，或者与resourcemanager有关。但这是客户的核心生产系统，理论上不可能调整猜测。通过快速调查，证实了猜测不正确。二次排查，经过初步调查，我不禁怀疑客户描述是否有问题。根据用户的过滤，顶级活动突然发现并非用户级平行。许多XXX用户运行的SQL并不平行。事实上，只有一个SQL并发性很高。这也说明初步调查方向偏离。这个SQL文本没有hint指定并行。结合观察到的信息，我有点怀疑我想找一个应用程序来确认最近是否有任何变化。甲方的另一位DBA坚定地说，他肯定没有改变，不仅没有改变，而且怀疑这是ORACLE的错误。当他说可能是bug的时候，我想申请权限，在机器上做一个trace。在他说话之前，我问他为什么怀疑是bug。他说了一句让我下定决心写一篇文章来记录CASE的话:因为之前SQL执行异常，他会用SQL_PROFILE固定SQL执行计划，这次固定后完全没有效果。

震惊的元凶，令我惊讶的是，为什么我忽略了SQLPROFILE/SQLBASELINE的调查。主要原因是他们对他们的系统进行了优化，知道他们的核心很难通常，添加索引需要详细论证添加索引带来的好处和可能的危害。首先，在测试中，阅读准生产环境验证逻辑以降低比例，然后论证受影响的SQL是什么，并描述对REDO的影响。拿着这些材料，和开发team(嗯，外资企业)约个时间开会。获得N多封邮件确认后，再安排生产(每周只能在某一天凌晨生产)。生产结束后的第二天，需要在工厂观察，以确保生产库的安全。根据我对他们流程的理解，我差点原谅自己对这个SQLPROFILE的失调。看看SQL相应的执行计划，SQLPROFILE确实由SYS主导，通常由addm/sqltune来完成。确认后，问题基本定位。经过立即验证，正是SYSSQLPROFILE使SQL高度平行，客户DBA新生成的SQLPROFILE无效。结合审计等信息，后来确认甲方的另一个DBA在夜间运行了addm报告，看到了报告给出的建议收入，非常吸引人，于是迅速采纳了建议，休假了几天。

复盘反思，这个案例技巧不强，有很多值得反思的点，但我感触最深的是系统/数据库运维中对运维人员/DBA运维行为的监管严重不足。正是这种高权限、不受监管的运维频繁导致故障，相对难以调查，至少往往是甲方DBA本身难以定位的故障。历史文章中有很多这样的案例，比如偷偷收集系统统计信息，错过添加命令，改变参数不重启，重启后出现故障等等。弥补这种故障的方法就是变成规则，加入检查。