AI 助力快速定位数据库难题

最近很多人都在讨论 AI 能否替代人类工作的话题，最近笔者正好遇到一个 AI 帮自己快速定位问题的实例，分享给大家，一起来切身感受下 AI 对于解决数据库问题的价值吧。

事情的经过是这样，有个朋友咨询我，说他最近遇到一个客户的数据库问题现象非常诡异。

就是有一套 Oracle 数据库实例不知何时变成了 mount 状态，但客户确认这套库之前是 open 成功的，而且也有数据库监测，数据库若有重启就会告警，可监控期间也没有发现数据库有任何重启行为。

而且，实例的启动时间，也是上次 open 数据库的时间。

看到这样的描述，首先要确认下，启动时间，是否 open 的动作成功了？

另外，监控是否有问题，建议人工通过 alert 告警日志搜索是否有数据库状态改变的痕迹。

这个做法并不是不相信客户，是因为问题 troubleshooting 都讲究一个证据链，就好像律师一样，要收集现有证据然后基于这些证据来找到问题本质。

于是就开始收集证据：

1. alert 告警日志，上次 open 的操作是成功的

Physical standby database opened for read only access.Completed: alter database open

2. 遍历搜索重启操作

在上次 open 动作之后的时间点，没有发生过重启。

3. 实例当前状态和启动时间

确认是 mount 状态，启动时间是上次 open 的时间没错。

嗯，以上这些基础验证朋友其实在之前排查时也都做过，也正因为各种搜索也没有找到有用的信息，所以问我有没有遇到过这个情况？

我其实也没有遇到过，且当时正在外地出差，又约好了客户时间要马上出发去现场做交流，所以并没太多时间深入去帮忙排查这个问题。

基础理论和操作大家都很清楚：

• Oracle 的启动流程，是经过 nomount、mount、open 三个阶段

• 已经 open 的数据库，如果想要切换成其他状态，正常操作是需要先 shutdown 关闭数据库，再启动到某个状态

可这个与现在的事实相违背，难道说某种情况下可以不重启直接从 open 状态到 mount 状态？

带着这个疑问问了下基于 LLM 的 AI，没指望没经过 RAG 专门训练的通用 AI 能直接定位问题，但从其回复的内容还是看到一句话引起了我的关注：

手动执行了 ALTER DATABASE CLOSE 的命令...

Oracle 有这个手工执行的命令吗？恐怕 99%的人都不知道吧。

alter database close;

按照这个命令搜索告警日志，有，但是在上次启动数据库之前，也就是和本次问题无关。

而且这是正常 shutdown 命令关闭时，系统标出的那种分解操作。

但其实这个操作很容易理解，说白了，就是按 Oracle 的启动流程，是经过 nomount、mount、open 三个阶段；

那逆向操作的话，自然也应该可以类似分为 close、dismount、instance shutdown 三个阶段。

虽然无关，也不会有人人工发起这个命令，但是印证了这个想法，就是某些情况下，的确可能从 open 直接到 mount，而不需要经过实例的重启，自然数据库实例的启动时间也不会变。

让朋友去告警日志搜下 close 关键字看有没有蛛丝马迹，然后就赶去客户现场工作了。

交流回来之后，朋友果然按此发现了直接的证据，在上次 open 和现在发现 mount 状态的期间，找到日志：

Close the database due to recovery session errorsAll dispatchers and shared servers shutdownCLOSE: killing server sessions.

close 看起来就是从 open 直接到 mount 的一个过程，不算重启。

这里是因为 recovery session errors，触发了这个操作，当然，这里的 recovery session errors 具体啥错误和原因就继续分析 trc 匹配就好了，属常规操作不再赘述。

后面朋友还在测试环境去测了下手工执行这个 close 的命令，确认是可执行的，而且还发现在告警日志中也会明确提示出这并不是公开支持的命令：

Warning: ALTER DATABASE CLOSE is not a publicly supported command.

朋友最后好奇问我最初的怀疑切入点是不是基于什么内部文档找到的有关资料，我说没那么神秘，正赶着去客户没时间查啥内部文档，直接问的 AI，而且只是通用的 AI，如果是经过 RAG（Retrieval-Augmented Generation）专业训练过的，理论上可参考性会更强，有兴趣大家可以试试看，有条件的还可以去构建属于自己或所在企业的专业知识库。

总结下，虽然这个 case，AI 并没有帮我直接定位问题，但它提到了这个我之前并没关注过的一条命令 —— "ALTER DATABASE CLOSE"。这让我对自己的推理和猜测产生了信心，从而更有方向地快速分析问题，并最终找到了根本原因。

所以，与其抵触 AI 担忧其是否会抢走我们的工作，不如拥抱 AI，利用 AI 技术助力我们的工作更加得心应手。

文章转载自：AlfredZhao

原文链接：https://www.cnblogs.com/jyzhao/p/18081760/ai-zhu-li-kuai-su-ding-wei-shu-ju-ku-nan-ti

体验地址：http://www.jnpfsoft.com/?from=001