最近很多人都在讨论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 errors
- All dispatchers and shared servers shutdown
- CLOSE: 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