incremental backup恢复错误一例-白红宇

incremental backup恢复错误一例

阅读量：797 次

发布时间：2023-03-25

本文共 3237 字，大约阅读时间需要 10 分钟。

Oracle Standby数据库恢复错误处理及解决方法

在实际操作中，Oracle Standby数据库的恢复过程中可能会遇到各种错误。以下是我们在实际工作中遇到的一个典型问题及其解决方法，希望能为有类似需求的朋友提供参考。

错误现象

在进行shutdown standby操作后，将restore standby controlfile恢复到/u01/rmanbak/fordg/control01.ctl时，发现控制文件覆盖了现有的控制文件。随后，数据库启动后出现以下错误：

Sat Mar 23 06:42:37 CST 2013
alter database recover managed standby database disconnect from session using current logfile
Sat Mar 23 06:42:37 CST 2013
Attempt to start background Managed Standby Recovery process (stdby)
MRP0 started with pid=29, OS id=11519
Sat Mar 23 06:42:37 CST 2013
MRP0: Background Managed Standby Recovery process started (stdby)
Sat Mar 23 06:42:37 CST 2013
RFS[2]: Archived Log: '/u01/archivelog/stdby/arc_2_9373_789583539.dbf'
...
Sat Mar 23 06:42:41 CST 2013
RFS[1]: Archived Log: '/u01/archivelog/stdby/arc_1_7751_789583539.dbf'
Sat Mar 23 06:42:42 CST 2013
RFS[2]: Archived Log: '/u01/archivelog/stdby/arc_2_9381_789583539.dbf'
Sat Mar 23 06:42:42 CST 2013
Managed Standby Recovery starting Real Time Apply
Sat Mar 23 06:42:42 CST 2013
Errors in file /u01/app/oracle/admin/stdby/bdump/stdby_dbw0_11458.trc:
ORA-01157: cannot identify/lock data file 24 - see DBWR trace file
ORA-01110: data file 24: '+DATA/in_sz_data'
ORA-17503: ksfdopn:2 Failed to open file +DATA/in_sz_data
ORA-15001: diskgroup "DATA" does not exist or is not mounted
ORA-15077: could not locate ASM instance serving a required diskgroup
ORA-29701: unable to connect to Cluster Manager
Sat Mar 23 06:42:42 CST 2013
Errors in file /u01/app/oracle/admin/stdby/bdump/stdby_dbw0_11458.trc:
ORA-01157: cannot identify/lock data file 25 - see DBWR trace file
ORA-01110: data file 25: '/u01/oradata/stdby/in_sz_data'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
...
分析：因为主库新建过数据文件，从主库恢复过来的控制文件中包含了这些文件，而从库却没有这些文件。

解决方法

步骤一：创建缺失的数据文件

首先，我们需要在Standby数据库中创建这些缺失的数据文件。可以通过以下SQL命令实现：

alter database create datafile '+DATA/in_sz_data' as '/u01/oradata/stdby/in_sz_data.312.789659222';
alter database create datafile '/u01/oradata/stdby/in_sz_data' as '/u01/oradata/stdby/in_sz_data.312.789659223';
alter database create datafile '/u01/oradata/stdby/in_sz_data.9154.810742355' as '/u01/oradata/stdby/in_sz_data.312.789659224';
alter database create datafile '/u01/oradata/stdby/in_ac_data.9090.810742665' as '/u01/oradata/stdby/in_ac_data.9090.810742665';

步骤二：重新执行恢复操作

接下来，我们需要重新使用RMAN进行恢复操作。具体步骤如下：

catalog start with '/u01/rmanbak/fordg/';
search for all files that match the pattern '/u01/rmanbak/fordg/';
catalog the files as prompted;
run {
  allocate channel dsk0 type disk;
  allocate channel dsk1 type disk;
  allocate channel dsk2 type disk;
  restore standby controlfile to '/u01/rmanbak/fordg/control01.ctl';
  recover database noredo;
}

注意事项

文件传输问题：在之前的操作中，由于使用了FTP上传文件，导致文件路径发生了变化。建议改用NFS文件传输方式，确保文件路径一致性。

服务器端配置：

服务器端：安装并配置NFS服务。
```
exportfs -rv /u01/rmanbak
```

客户端：挂载NFS共享目录并验证：
```
showmount -e 192.168.13.109
```

文件完整性检查：在恢复过程中，确保所有相关文件已存在且可读。如果发现文件缺失或损坏，需及时修复。

步骤三：验证恢复结果

在完成恢复操作后，建议执行以下验证步骤：

SQL> select name from v$datafile where file#=26;

结果应显示文件路径：

/u01/oradata/stdby/in_sz_data.312.789659224

如果发现文件缺失或无法访问，可能需要重新启动数据库并切换为普通MOUNT状态：

SQL> shutdown immediate;
SQL> startup mount;

总结

通过以上方法，我们成功解决了Standby数据库恢复过程中的文件覆盖问题，并确保了数据库的正常运行。这种方法不仅适用于本案例，还可以为其他类似问题提供参考。

转载地址：http://syhfk.baihongyu.com/

你可能感兴趣的文章