关于作者：
江健，薄冰科技创始人，甲骨文ACE，11G OCM，拥有多年甲骨文设计、管理和实施经验，精通数据库优化、甲骨文CBO和并行性。 Eagle Eye 监控核心设计和开发人员，是一名高级 python Web 开发人员。
背景
最近我访问客户网站时，客户报告说数据库几天前遇到了一个“bug”，希望我们能帮忙排查。
客户反馈现象如下：有一个非常核心的系统数据库，突然有一天用xxx schema登录后，正在运行的SQL处于并行状态，DOP非常高，在多次故障定位失败的情况下，只能暂时使用并行max servers参数将并发降低到32，以缓解过度并发的压力。
故障确认
我们来看看前几天数据库的情况，失败期确实很高。
切换到单个SQL操作**的情况，DOP非常高，然后被节流，这与客户描述一致。
我打开旁边的监测报告，DOP被大幅降级。
初始并行度为192，逻辑CPU为96，与自动并行时数据库的默认并发度非常相似。
初步调查
在客户的带领下，确认故障期与客户描述基本一致。 仅听描述，似乎有一个触发器用于在会话级别调整并发性或与资源管理器相关的东西。
但是，这是客户的核心生产系统，理论上应该不可能进行猜想的调整。 通过快速调查，证实了该猜想不正确。
二次检查
经过初步调查，我不禁怀疑客户的描述是否有问题。 顶层活动按用户过滤，突然发现用户级别没有并行性，很多运行在xxx用户下的SQL都没有并行性，其实只有一个并发度高的SQL。 这也说明，最初的调查方向已经偏离。
此SQL文本未并行指定提示，结合观察到的信息，有点怀疑，想找应用确认最近有没有变化。 甲方的另一位DBA斩钉截铁地说，一定没有改过，不仅没改过，还怀疑是Oracle的bug。
当他说这可能是一个错误时，我想申请在机器上做跟踪的许可，但在我说之前，我问他为什么怀疑这是一个错误。 他说了一句话，让我下定决心要写一篇文章来记录这个案例：“因为之前的SQL执行异常，他会用SQL Profile来修复SQL执行计划，但经过这次修复，完全没有效果。
震惊的罪魁祸首
实际上有一个sqlprofile？ 令我惊讶的是，为什么我忽略了 SQLprofile SQL 基线疑难解答。
主要原因是他们之前已经优化过自己的系统，他们知道他们很难对核心进行更改，并且经常需要详细演示添加索引的好处，以及可能的危害，首先在测试中，准生产环境来验证逻辑读取的缩减率， 然后演示哪些 SQL 受到影响，并描述对 Redo 的影响。
拿着这些材料再去开发团队（嗯，外资企业），预约开会，多得到n封邮件确认，然后安排生产（每周只有一天可以生产在清晨），第二天生产完毕，需要在工厂观察，确保生产仓库的安全。
根据我对他们流程的了解，我几乎可以原谅自己对 sqlprofile 的疏忽。 看了一下SQL对应的执行计划，就有一个sqlprofile，它以sys开头，一般不在addm sql tune中。
确认了这一点，问题基本定位了，马上验证，果然这个系统的SQLprofile让SQL使用高并行度，并且让客户的DBA新生成的SQLprofile没有生效，结合审计等信息，后来也确认确实是甲方的另一个DBA在晚上运行了ADDM报告，并且看到报告给出的建议的好处，非常诱人，于是很快就采纳了这个建议，并请了几天假。
回顾和反思
这个案例在技巧上并不强，有很多值得深思的地方，但我感受最深的是，在系统数据库的运维中，对运维人员运维行为的监督严重不足。 然而，正是这种高权重、无监督的运维，经常带来故障，而且是相对难以排除的，至少经常是甲方DBA难以定位的故障。
在历史文章中有很多这样的情况，比如偷偷收集系统统计信息、省略添加磁盘命令、不重启就修改参数、重启后失败等。 弥补这种失误的办法，就是成为规矩，加入巡查，那么有没有好的做法来预测敌人的机会，防止它发生呢？ 有成熟实践或对这类问题有顾虑的朋友，欢迎在评论区交流。