存储故障导致Oracle 19c 数据文件处于recover状态的恢复案例

1.背景

某次平台分布式存储故障，导致数据库出现ORA-00376、ORA-01110数据文件不可读报错，本文将整个恢复过程进行整理记录。

2.报错信息

在进行租户数据库打开操作时，出现了如下报错：

ORA-00376: file 17 cannot be read at this time

ORA-01110: data file 17: '+DATA/UTCDB/B8ECC80679A639CEE0533C2BE50A0960/DATAFILE/undotbs1.381.1061913699'

ORA-00376表示数据文件不可读，ORA-01110表示有问题的数据文件是#17.

查看数据文件

3.恢复过程

3.1查看数据文件状态

select file#,name,status,enabled from v$datafile WHERE STATUS ='RECOVER';

状态为recover的数据文件需要进行恢复。

根据查询结果，确认只有#17文件需要进行恢复。

3.2进行数据文件恢复

recover datafile '+DATA/UTCDB/B8ECC80679A639CEE0533C2BE50A0960/DATAFILE/undotbs1.381.1061913699';

恢复出现报错：

SQL> recover datafile '+DATA/UTCDB/B8ECC80679A639CEE0533C2BE50A0960/DATAFILE/undotbs1.381.1061913699';

ORA-00279: change 14550891521 generated at 10/26/2022 02:40:31 needed for

thread 2

ORA-00289: suggestion : +ARCH

ORA-00280: change 14550891521 for thread 2 is in sequence #31426

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

auto

ORA-00308: cannot open archived log '+ARCH'

ORA-17503: ksfdopn:2 Failed to open file +ARCH

ORA-15045: ASM file name '+ARCH' is not in reference form

ORA-00308: cannot open archived log '+ARCH'

报错原因：缺少归档日志，是由于每次备份完成后会删除已经备份的归档日志，所以导致所需要的归档日志缺失。

进入磁盘组归档目录查看归档日志信息：

通过归档日志查看，确认缺少31426号归档日志文件

归档日志恢复：

RUN {

ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE';

send 'NSR_ENV=(NSR_SERVER=nx-zwe-1202-E11-17u-BeiFen-r4900,NSR_CLIENT=nxghoracle1)';

restore archivelogfrom logseg=31426 until logseg=31434 thread 2;

release channel ch00;

}

恢复后再查看归档日志信息：

确认缺失的31426号归档日志文件已经恢复

归档日志恢复完成后再次进行数据文件recover：

SQL> recover datafile '+DATA/UTCDB/B8ECC80679A639CEE0533C2BE50A0960/DATAFILE/undotbs1.381.1061913699';

ORA-00279: change 14550891521 generated at 10/26/2022 02:40:31 needed for

thread 2

ORA-00289: suggestion :

+ARCH/UTCDB/ARCHIVELOG/2022_10_26/thread_2_seq_31426.2540.1119089863

ORA-00280: change 14550891521 for thread 2 is in sequence #31426

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

auto

ORA-00279: change 14550891521 generated at 10/26/2022 02:20:32 needed for

thread 1

ORA-00289: suggestion :

+ARCH/UTCDB/ARCHIVELOG/2022_10_26/thread_1_seq_31554.1405.1119090161

ORA-00280: change 14550891521 for thread 1 is in sequence #31554

ORA-00279: change 14550891551 generated at 10/26/2022 02:40:33 needed for

thread 1

ORA-00289: suggestion :

+ARCH/UTCDB/ARCHIVELOG/2022_10_26/thread_1_seq_31555.262.1119090161

ORA-00280: change 14550891551 for thread 1 is in sequence #31555

Log applied.

Media recovery complete.

根据提示信息，确认恢复已经完成。

进行数据文件online：

由于恢复的文件是offline状态，需要手动online。

alter database datafile '+DATA/UTCDB/B8ECC80679A639CEE0533C2BE50A0960/DATAFILE/undotbs1.381.1061913699' online;

数据库文件状态检查：

执行检查命令：select file#,name,status,enabled from v$datafile WHERE STATUS ='RECOVER';

再无recover状态文件后，说明整个实例下所有需要恢复的文件已经完成。

3.3进行数据库open以及读写验证

执行数据库打开命令：

alter pluggable database XXX open instances=all;

整个打开过程无报错，alter日志无其他告警信息，并进行读写测试，确认能够正常写入，至此整个恢复全部完成。

4.总结

整个恢复过程相对比较简单，在遇到相同的问题进行恢复时，至关重要的就是归档日志。大家在平时的运维过程中，要优化自己的备份策略，如果频繁出现类似问题，就需要保留较长时间的备份以及归档日志，确保出现问题时能够很快的恢复，减少业务系统中断时间。