大半夜,接到客户电话,数据库挂了,下面所有客户端连接不上了.由于是7*24小时业务,因此客户很着急,让客户发了报错截图,第一感觉是归档日志满了,但是客户那边有定时删除日志脚本啊,不应该啊,报错截图如下
赶紧和客户要了远程进行查看,明显归档日志空间是足够的.再检查归档日志路径报错,如下:
错误很明显了,归档日志在归档redo的时候发现了redo出现了写丢失.
检查alert日志也是同样的错误:
什么是写丢失呢?
写丢失说明oracle在写redo的日志的时候,由于某种原因,一般可能是cache缓存问题,导致lowr进程在写redo的时候发生了写丢失.
而在进行归档的时候,对redo进行校验发现redo日志出现坏块,因此无法进行归档.
可能产生写丢失的原因:服务器问题,例如服务器cache,存储问题例如存储的cache故障,意外掉电等.
这里明显不是意外掉电,那么就是有可能是服务器或者存储cache故障导致.
我们这里比较幸运的是redo的写丢失并没有导致数据库直接宕机,仅仅是导致了日志无法归档.
故障解决
由于只是redo日志无法归档,因此我们可以进行手工强制清除未归档的日志.
根据上面的报错信息可以看到是100034号日志无法归档.因此只需要清除此日志,语法如下:
Alter database clear unarchived logfile group XXXX;
清除完成之后,重新设置一下归档日志的状态:
alter system set log_archive_dest_state_1=enable;
参考oracle官方文档如下:
Database Crashe with ORA-16038/ORA-742 Errors (Doc ID 2064718.1)
SOLUTION
SQL> alter system dump logfile ‘E:\ARCHIVELOGS\xxx\REDO03.LOG’ validate;
Clear the log in order to enable the archival again
SQL> select group#,member from v$logfile;
SQL> alter database clear unarchived logfile group ;
Should be group# 3 , if yes
After this , take a full backup, because the old one would not be useful anymore because of the lost of archive log sequence .
https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=378047153651334&id=2064718.1&displayIndex=3&_afrWindowMode=0&_adf.ctrl-state=17nxrq8cj0_1056
————————————————
版权声明：本文为CSDN博主「久违的太阳」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/su377486/article/details/104420362