ORA-13901错误找不到对象，远程帮忙修复故障的那些事儿

（引用来源：一位匿名的Oracle数据库管理员口述经历）

这事儿说起来还挺有意思的,那次是我一个老同学突然在深夜给我打来电话，声音火急火燎的，他在外地一家公司管着个挺重要的业务系统，那天晚上做常规维护，好像是要调整一下数据库的某个参数，结果操作完没多久，业务系统就报警了，日志里哗哗地报一个从来没见过的错误：ORA-13901。

他当时就懵了,赶紧在内部的技术群里问，大家都说没见过这个错，没办法，他只好找到我，知道我捣鼓Oracle年头多，兴许见过，他直接把错误信息截图从聊天软件上甩了过来，我一看，ORA-13901，后面还跟着一串描述，大概意思是“找不到ADDM任务‘AUTO_健康检查_任务’”。

我第一反应也是愣了下,ORA-开头的错误我见过不少，什么ORA-00942表不存在啊，ORA-00001违反唯一约束啊，都是常客，但这个13901，确实有点冷门，我让他别慌，先说说他维护时干了啥，他说他就执行了一个修改参数的语句，把那个叫“CONTROL_MANAGEMENT_PACK_ACCESS”的参数值给改了。

我一听这个参数名,心里咯噔一下，这个参数可不是随便能动的玩意儿，它管着Oracle数据库里那些高级诊断和管理功能包的访问权限，我赶紧让他把改参数前后的值都告诉我，他说之前的值是“DIAGNOSTIC+TUNING”，他想着精简一下，就给改成了“DIAGNOSTIC”。

“问题八成就在这儿了！”我对着电话那头说，我让他立刻登录到数据库服务器上，用有管理员权限的账号连上去，那时候已经是晚上十点多了，我俩就开着语音，我在这头指挥，他在那头操作。

我告诉他,这个AUTO_健康检查_任务，是Oracle数据库自动运行的一个健康检查任务，属于“TUNING” tuning pack（优化包）的一部分，他直接把TUNING的访问权限给关掉了，数据库再想去调度这个自动任务的时候，自然就找不到它了，所以抛出了这个“找不到对象”的13901错误。

“那现在咋办？系统一直报错，虽然业务好像还没断，但看着吓人啊。”我同学语气里透着焦虑。

我说：“别急，原理搞清楚了就好办，两个办法：一个是治标，直接把那个报错的任务禁用掉；另一个是治本，把参数改回原来的值，让任务能正常跑起来，你选哪个？”

他犹豫了一下,问哪个更稳妥，我建议治本，因为那个自动健康检查任务其实挺有用的，能帮我们提前发现一些数据库的性能隐患，他同意了，我一步步指导他：先创建一个临时的参数文件（pfile），把那个关键参数的值改回“DIAGNOSTIC+TUNING”，然后关闭数据库，再使用这个临时参数文件启动数据库到nomount状态，最后重建服务器参数文件（spfile）并正常启动数据库。

这个过程听起来简单,但对当时神经紧绷的他来说，每一步都像拆弹，我让他把每一条命令敲完都告诉我反馈是什么，确保没错，当他最后执行完startup命令，数据库顺利启动，他赶紧查看报警日志，发现那个烦人的ORA-13901错误果然不再出现了。

他长舒了一口气,在电话里连声道谢，说真是救急了，我也松了口气，开玩笑说：“下次再动这种高级参数，可得先查查文档或者问问我啊。”

这件事给我的印象很深,ORA-13901这个错误本身不算复杂，但它背后反映出一个常见问题：有时候我们一个不经意的操作，可能会影响到系统一些看似不相关、但又很关键的内部机制，远程帮忙解决问题，就像医生远程问诊，关键不在于背下了多少种病的药方，而在于能快速、准确地找到病因，那次能顺利解决，靠的就是对Oracle这些功能包之间依赖关系的理解，以及一步步冷静的排查，以后遇到稀奇古怪的错误，别光盯着错误代码本身，多想想最近做了什么改动，往往就能找到突破口。