Monthly Archives: March 2024

最近很多人都在讨论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 … Continue reading →