RMAN恢复丢失的系统数据文件

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 ： 13764045638    QQ号:47079569    邮箱：service@parnassusdata.com

RMAN 备份、复原和恢复系统数据文件

和一般的数据文件相比，系统数据文件恢复表空间是不同的，最大的不同是系统表空间包含数据字典，需要一直进行更新，操作数据库时，包含数据库数据字典信息的任何数据文件恢复不能进行 ，这有点像小鸡和鸡蛋哪个先存在的的问题，因为我们想要更新一些信息，但是需要恢复位置本身。, 所以，通过回做数据库，使其处于安装状态完成系统数据文件的复原，剩下的步骤和之前探讨的一般数据文件恢复操作时相同的，现在，查看结果。

从丢失的系统数据文件恢复

因为多媒体故障， Bob 丢失了系统表空间的数据文件，查询数据字典视图时，收到下列错误信息:

ERROR at line 1: ORA-00604: error occurred at recursive SQL level 1 ORA-01116: error in opening database file 1 ORA-01110: data file 1: '/u02/oradata/db1/system01.dbf' ORA-27041: unable to open file Linux Error: 2: No such file or directory Additional information: 3 SQL>

Bob 决定恢复数据文件，于是，他需要关闭数据库，在非安装模式下重启，然后复原和恢复数据文件，为测试该情景，删除系统01.dbf 文件，因为我们处于基于系统的 Linux ，我们甚至可以在数据库打开时移动文件，请注意，如果在Windows 系统上操作，是不可能的，现在尝试查询任何数据字典视图，会出现该情景一开始出现的错误信息。  

Bob 检查RMAN 信息库中系统表空间的所有备份:

RMAN> list backup of tablespace system; using target database control file instead of recovery catalog

List of Backup Sets =================== BS Key  Type LV Size      Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 1       Full    565.38M    DISK       00:00:30     23-OCT-09 BP Key: 1   Status: AVAILABLE Compressed: NO  Tag: TAG20091023T154137 Piece Name: /u01/app/oracle/flash_recovery_area/ORCL/backupset/2009_10_23/ o1_mf_nnndf_TAG20091023T154137_5g30bt6z_.bkp List of Datafiles in backup set 1 File LV Type Ckp SCN    Ckp Time  Name ---- -- ---- ---------- --------- ---- 1      Full 477201     23-OCT-09 /u01/app/oracle/oradata/orcl/system01.dbf

完成系统01.dbf 文件备份之后，他准备好进行恢复，但是，因为他正在恢复系统数据文件 ，他需要使用中止模式关闭数据库，在安装模式下重启，如下: 

SQL> shut abort; SQL> startup mount;

现在他尝试从RMAN恢复文件:

RMAN> restore datafile 1;

于是文件恢复完成，Bob 检查物理文件的状态以确保文件是否得到恢复 使用RMAN肯定不会出现问题，但进行交叉检查会更好!

$ ls system* system01.dbf

现在他检查以观察有多少需要恢复，例如，从检查点位置到另一个位置，此文件使用以下查询:

SQL> select file#,checkpoint_change#, status, recover from v$datafile_header;

     FILE# CHECKPOINT_CHANGE# STATUS  REC ---------- ------------------ ------- --- 1             477201 ONLINE   YES 2             503455 ONLINE   NO 3             503455 ONLINE   NO 4             503455 ONLINE   NO 5             503455 ONLINE   NO

从检查点 477201 到 503455，他需要恢复文件，他尝试再次恢复和检查文件状态:

RMAN> recover datafile 1; SQL> select checkpoint_change#, status, recover FROM v$datafile_header;

CHECKPOINT_CHANGE# STATUS  REC ------------------ ------- --- 509975 ONLINE  NO 503455 ONLINE  NO 503455 ONLINE  NO 503455 ONLINE  NO 503455 ONLINE  NO 

正如我们看到的，文件的recover=YES 状态变成了 NO，同时，和剩下的文件一起，该文件也进行了同步，现在 Bob准备安全打开数据库，如下:

SQL> alter database open; Database altered.

注释:   任何系统关联的数据文件恢复后，立刻重新对整个数据库进行备份，是一个很好的实践。