ORA-13636错误参数不对导致顾问功能异常，远程帮忙修复解决方案分享

这个ORA-13636错误，说白了就是数据库里面一个叫“自动数据库诊断监视器”（ADDM）的智能分析功能，因为某些关键的参数设置得不对头，导致它“罢工”了，没办法正常干活，ADDM就像是数据库的定期体检医生，每隔一小时会自动检查一下数据库的健康状况，生成一份报告，告诉你哪里可能有问题，比如性能瓶颈啊、资源争用啊，它一罢工,你就少了一个很重要的诊断帮手。

这个错误信息通常会伴随着类似“用于执行操作的参数无效”这样的描述，核心问题就出在初始化参数上，根据一些技术社区比如Oracle官方支持社区和ITPUB论坛上的案例分享,最常见的原因是两个参数设置上的冲突或者不合理。

第一个关键参数是STATISTICS_LEVEL，这个参数就像是控制数据库信息收集详细程度的总开关，ADDM要能正常工作，这个开关必须打到“TYPICAL”或者“ALL”档位才行，如果你或者之前的人不小心把这个参数设成了“BASIC”，那就坏事了，在“BASIC”模式下，数据库为了节省资源，会关闭很多高级功能，其中就包括ADDM需要依赖的很多性能统计数据，ADDM医生没有了化验单和检查数据，自然就没办法给你出诊断报告了，所以就会报ORA-13636错误。

第二个关键参数是CONTROL_MANAGEMENT_PACK_ACCESS，这个参数有点特别，它控制着你是否被授权使用Oracle的一些高级管理功能包，其中就包含ADDM所在的“诊断包”，很多数据库在安装创建的时候，可能没有购买或者没有启用这些付费的高级功能包，那么这个参数默认可能就是“NONE”或者没有包含“DIAGNOSTIC”，这样一来，即使你把STATISTICS_LEVEL设对了，ADDM功能本身因为授权问题也是被禁用的状态，你去强行调用它，它也会告诉你“我没这个权限”,从而抛出同样的错误。

远程帮忙修复这个问题，过程其实不复杂，但需要非常小心，因为修改数据库参数是有风险的，我通常会通过像TeamViewer、AnyDesk这样的远程桌面软件，或者直接通过SSH终端连接到客户的数据库服务器进行操作，整个修复思路就是像医生看病一样，先诊断病因,再对症下药。

第一步，肯定是确认问题，我会先让客户告诉我完整准确的错误信息，然后登录到数据库服务器，以具有SYSDBA权限的用户（比如SYS用户）连接到数据库，我会执行一个简单的SQL查询命令：SHOW PARAMETER STATISTICS_LEVEL 和 SHOW PARAMETER CONTROL_MANAGEMENT_PACK_ACCESS，这两个命令就像是听诊器和血压计，能立刻告诉我这两个关键参数的当前设置是什么，百分之八九十的情况，通过这两条命令就能立刻找到病根——要么是STATISTICS_LEVEL被设成了BASIC，要么是CONTROL_MANAGEMENT_PACK_ACCESS没有包含DIAGNOSTIC。

第二步，就是制定治疗方案并实施,这里需要分情况讨论：

如果问题是STATISTICS_LEVEL设成了BASIC，那么修复方案很简单，就是把它改回TYPICAL，但是修改参数也分两种方式：一种是只修改当前内存中的值，命令是ALTER SYSTEM SET STATISTICS_LEVEL = TYPICAL;，这样改完立刻生效，但缺点是数据库重启后，这个设置又会变回原来的样子，另一种是修改参数文件（spfile）中的值，命令是ALTER SYSTEM SET STATISTICS_LEVEL = TYPICAL SCOPE = SPFILE;，这样改不会立刻生效，但能保证数据库下次重启后这个设置是永久正确的，为了彻底解决问题，我通常会建议客户采用第二种方式，然后安排时间重启数据库，或者如果条件允许,两种方式一起做。

如果问题是CONTROL_MANAGEMENT_PACK_ACCESS设置不对，这就稍微复杂一点，因为它涉及到功能授权，我需要和客户确认他们的Oracle许可证是否允许使用诊断包，如果允许，那么就可以将其设置为包含“DIAGNOSTIC”，通常完整的设置是“DIAGNOSTIC+TUNING”，修改命令同样是ALTER SYSTEM SET CONTROL_MANAGEMENT_PACK_ACCESS = 'DIAGNOSTIC+TUNING' SCOPE = SPFILE;。这里要特别强调一个巨大的坑：根据Oracle官方文档和一些血泪教训分享，这个参数是静态参数，意味着修改它之后，必须重启数据库才能生效，光执行完命令是不行的，必须重启，很多人在这一步忘了重启，然后发现错误依旧,就会很困惑。

第三步，验证修复效果，在完成参数修改并确保数据库已经重新启动（如果是静态参数）后，需要再次验证，我会重新登录数据库，再次执行SHOW PARAMETER命令确认参数已经正确设置，我会尝试手动运行一次ADDM分析，比如通过DBMS_ADVISOR包或者Oracle Enterprise Manager界面，看看是否还会报ORA-13636错误，如果能够成功生成ADDM报告,那就说明问题已经彻底解决了。

在整个远程修复过程中，沟通非常重要，我会一边操作一边向客户解释每一步是在做什么，为什么要这么做，特别是强调重启数据库的必要性和安排重启时间窗口，避免影响客户的业务系统正常运行，操作前再三确认SQL命令的准确性，执行修改命令前也最好再 double-check 一下，因为一旦参数改错，可能导致更严重的问题，把修改前后的参数值、执行的命令、重启操作等都简单记录下来，发给客户备案，方便他们日后查看，这样一套流程下来，通常都能顺利解决这个因参数不对导致的ORA-13636错误。