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