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

7天前 12.2k 0

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的数据文件需要进行恢复。

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

根据查询结果,确认只有#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: {=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'

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

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

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

通过归档日志查看,确认缺少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;

}

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

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

确认缺失的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: {=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日志无其他告警信息,并进行读写测试,确认能够正常写入,至此整个恢复全部完成。

总结

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

相关文章

最新发布!MySQL 9.0 的向量 (VECTOR) 类型文档更新
国产数据库中级认证HCIP-openGauss经验分享
保障数据完整性与稳定性:数据库一致性
OceanBase 里的 DDL 超时时间
OceanBase v3.1.x 将不再更新版本 | 社区月报2024.6
openGauss Developer Day 2024 | SIG组工作会议亮点回看!

发布评论