记一次生产库ORA-00257故障处理

故障现像

客户是一个虚拟机跑的生产库，前几天存储故障中断了几个小时服务，导致数据库都出现了坏块。

今天突然联系我说是业务系统不能用了，前台报错不能归档ORA-00257数据库，PLSQL也连不上，后台alert一直报错

复制代码

Errors in file D:\APP\ADMINISTRATOR\VIRTUAL\diag\rdbms\ORCL\ORCL\trace\ORCL_arc2_3736.trc:
ORA-00742: 日志读取在线程 1 序列 307139 块 7968 中检测到写入丢失情况
ORA-00312: 联机日志 1 线程 1: 'D:\APP\ADMINISTRATOR\VIRTUAL\ORADATA\ORCL\REDO01.LOG'
2026-05-26T19:33:34.821753+08:00
ARC2: All Archive destinations made inactive due to error 742
Committing creation of archivelog 'D:\ARCHIVELOG\ARC0000307139_1068117533.0001' (error 742)

客户还反馈了当前的定时rman备份也失败了，提示数据文件存在坏块

复制代码

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================

RMAN-03009: 位于 05/26/2026 01:08:27 的 c1 通道上的 backup 命令失败
ORA-19566: 超出损坏块限制 0 (文件 D:\APP\ADMINISTRATOR\VIRTUAL\PRODUCT\12.2.0\DBHOME_1\ORADATA\ORCL\XXX\XXX3.DBF)

连进去看了一下，应用这边的DBA也检测了下数据文件13号，发现一堆坏块，目测得有几百个。

复制代码

页 278049 标记为损坏
Corrupt block relative dba: 0x03443e21 (file 13, block 278049)
Completely zero block found during dbv:

页 278050 标记为损坏
Corrupt block relative dba: 0x03443e22 (file 13, block 278050)
Completely zero block found during dbv:

当然，还尝试了进行一下recover，很可惜，当时不知道谁给装了个标准版本的数据库。标准版没有block recover的功能。

复制代码

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: 位于 05/26/2026 16:43:00 的 recover 命令失败
RMAN-05009: 块介质恢复需要企业版

而且检查了下备份，他设置了保留1个备份的策略，但是之前好的备份己经都被清空了。。。

修复过程

还好，客户这边还有万能科力锐备份CDP的机器在跑，但不幸运的是故障的那天客户刚好关闭了一体机，但是好在还有个21号的备份，当前的实时CDP保护也是正常的。

沟通了一下客户，由于这个服务器是虚拟机，操作前建议客户给虚拟机打一个快照，以防万一，一切准备就绪后，开始执行操作。

其实操作也不复杂，查看一下故障的日志组当前是inactive

复制代码

SQL> SELECT group#, sequence#, status, archived, bytes/1024/1024 AS size_mb FROM v$log;

    GROUP#  SEQUENCE# STATUS           ARC    SIZE_MB
---------- ---------- ---------------- --- ----------
         1    3071339 INACTIVE         NO         200
         2    307307 INACTIVE         NO         200
         3    307308 CURRENT          NO         200

那行直接清空一下就好了alter database clear unarchived logfile group 1；

以下是执行输出

复制代码

2026-05-26T19:38:18.540507+08:00
WARNING! CLEARING REDO LOG WHICH HAS NOT BEEN ARCHIVED. BACKUPS TAKEN
    BEFORE 05/22/2026 03:58:14 (CHANGE 17763614136) CANNOT BE USED FOR RECOVERY.
Clearing online log 1 of thread 1 sequence number 307139
2026-05-26T19:38:18.603005+08:00
Thread 1 cannot allocate new log, sequence 307309
Online log 1 still clearing
  Current log# 3 seq# 307308 mem# 0: D:\APP\ADMINISTRATOR\VIRTUAL\ORADATA\ORCL\REDO03.LOG
2026-05-26T19:38:20.478012+08:00
Thread 1 advanced to log sequence 307309 (LGWR switch)
  Current log# 1 seq# 307309 mem# 0: D:\APP\ADMINISTRATOR\VIRTUAL\ORADATA\ORCL\REDO01.LOG
2026-05-26T19:38:20.759253+08:00
Completed: alter database clear unarchived logfile group 1

执行成功后alter system switch logfile;测试切换归档成功，业务恢复。告诉客户观察一阵没问题就可以把虚拟机快照删除了。

接下来是备份的问题，由于数据文件坏了，也没有最新的备份只好认载了，坏的还是数据表不是索引。坏就坏吧，但是RMAN备份还得备

修改下rman脚本，在里面添加13号数据文件允许300个坏块。。跳过。

复制代码

set maxcorrupt for datafile 13 to 300;

沟通了一下，把21号的科力锐的备份直接拉起虚拟机，几分钟就完事了，看一下虚拟机里的库还是完好的，剩下的交给业务处理吧，哪坏了不行再补哪里。

总结

有问题早发现啊！！这都好几天了，看来业务是真不用。