突然挂掉Oracle 1月前突然挂掉一桩谜题的解开（oracle 1月前）

突然挂掉Oracle 1月前突然挂掉：一桩谜题的解开

在数据库运维中，突然的故障总是让人非常头痛，特别是个案比较复杂或者问题比较玄学的情况下更是如此。最近，我们公司的数据库出现了一桩这样的案例，整个数据库突然异常停止，所有业务都无法正常访问，这让我们在排查问题上花费了相当多的时间和精力。最终，我们成功解决了这个问题，本文就来和大家分享一下这个故事。

1. 故障现象和症状

在我们的Oracle数据库出现故障时，系统管理员收到了监控告警信息，报告数据库处于不正常状态。在进一步排查后，发现数据库无法访问，业务端的应用全部报错。在进一步查看日志和数据库状态信息时，我们发现以下异常症状：

– 无法连接到数据库实例

– 监控告警显示各项指标均异常

– 数据库日志中显示大量的无法写入和读取的错误

– 数据库最终进入了“MOUNTED”模式，无法正常服务

这些异常症状提示我们问题比较严重，需要处理，否则业务将因此受到很大影响。

2. 故障排查与分析

为了确保故障被解决，我们按照以下步骤来排查问题：

2.1 检查数据库环境

我们需要检查数据库环境，包括数据库实例、监听器、系统账户等等。我们采用以下命令检查：

$ ps -ef|grep ora_

$ netstat -anp|grep 1521

$ id oracle

$ cd $ORACLE_HOME/dbs

$ sqlplus “/ as sysdba”

$ select status from v$instance;

2.2 检查数据库日志

我们需要检查数据库的日志文件，包括数据库的alert日志，trace日志以及SQL执行日志等，这些日志记录了数据库的运行状态和故障信息。我们采用以下命令检查：

$ tl -f alert_$ORACLE_SID.log

$ grep ORA- *.trc

$ vi listener.log

2.3 检查数据库恢复状态

如果故障发生在数据库的归档和恢复过程中，那么我们需要检查数据库恢复状态，以确定恢复是否正常。我们采用以下命令检查：

$ select sequence#, status, first_time, next_time from

v$archived_log order by sequence#;

2.4 检查数据库内存和I/O使用情况

我们需要检查数据库内存和I/O使用情况，以确定是否是因为系统资源限制导致数据库崩溃。我们采用以下命令检查：

$ top

$ iostat -x 1 10

$ vmstat 1

通过以上排查步骤，我们最终确定了问题的来源，是数据库文件系统的一个文件损坏导致了数据库的崩溃。

3. 故障解决

确定问题的根源之后，我们需要采取相应的措施来解决问题，让数据库恢复正常服务。在本案例中，我们采用以下解决方法：

3.1 修复文件系统

我们首先使用fsck命令检查和修复损坏的文件系统。该命令是Linux/Unix系统中用于检查磁盘文件系统错误的工具。在修复完成后，我们再次尝试启动数据库实例，发现数据库已经可以正常服务。

3.2 重新导出表空间

由于在解决问题时我们不得不使用了fsck命令来修复文件系统，这可能会导致部分数据被损坏。为了保证数据的完整性，我们在恢复数据库后重新导出了所有表空间，以确保数据的正确性。

4. 总结

本次故障虽然给我们带来了很多麻烦和困难，但我们也从中获得了很多经验和教训。在这次故障中，我们了解到如何排查故障、如何使用相关的工具和命令来解决问题。当然，我们也学会了更好的备份和恢复策略，以更好地应对未来的故障和问题。通过不断的探索和实践，我们能够不断提高自己的能力，从而更好地为我们的业务服务。