Oracle 11gR2数据库文件丢失后的恢复测试


2.2.2关键数据文件丢失
[oracle@mycentos orcl]$ rm system01.dbf;
关闭数据库后,过程与崩溃后恢复数据非关键数据文件的过程一样。
 
三、日志文件丢失的测试
  当前的配置是所有的group都只有一个成员,在group1中新增一个成员,使其变成2个成员,其他group仍然只有一个成员。
 
3.1丢失inactive日志文件的恢复测试
  删除第二个日志组,并且模拟数据库崩溃
  在未关机状态下,数据库能继续运行,但是日志文件中会有告警信息。
    shutdown abort;
    startup mount;
    alter database clear unarchived logfile group 2; #此命令会重建第二组日志文件
    alter database open;


  删除第一组日志的一个成员:
    rm redo01.log
    shutdown abort;
    startup;
  数据库可以正常打开。redo01.log的状态变成了INVALID.
  使用alter database clear unarchived logfile group 1;重建日志文件


3.2丢失CURRENT日志文件的恢复测试
  当第一组为CURRENT或actives时,删除第一组日志的一个成员,数据库可以正常打开。
  第三组为CURRENT,并且只有一个成员时,删除第三组的日志。
  startup 命令报错,并且在执行clear unarchived logfile时会报
  ORA-01624: log 3 needed for crash recovery of instance orcl (thread 1)的错误。
  alter database open;#会报ORA-00313的错误
  因此需要用其他方式来打开数据库:
方法一:使用不完全恢复:
  RMAN>RESTORE DATABASE;
  RMAN>RECOVER DATABASE UNTIL TIME 'SYSDATE-5/1440';#具体的时间可以看归档日志的生成时间
  SQL>alter database open resetlogs;
方法二:直接使用不完全恢复,不用RMAN。
  SQL>alter system set "_allow_resetlogs_corruption"=true scope=spfile;
  SQL>shutdown abort;
  SQL>startup mount;
  SQL> recover database until cancel;
  SQL> alter database open resetlogs;


3.3丢失归档日志文件,并且需要恢复数据库。
使用RMAN不完全恢复至某一个时间点。
3.4丢失所有联机重做日志文件的测试
参照丢3.2失CURRENT日志文件的恢复测试
 
 
四、丢失控制文件的测试
4.1当控制文件有多个副本时,删除其中一个控制文件,模拟数据库崩溃的情况。
在数据库关闭的情况下,将副本复制成已删除的控制文件的名字,能正常打开数据库。
4.2 控制文件所有成员丢失,模拟数据库崩溃
4.2.1 有备份控制文件的情况下,使用备份的控制文件恢复数据库。
SQL>startup nomount;
RMAN>set dbid 1443678834#可以查看备份的控制文件获得DBID
RMAN>restore controlfile from '/backup/c-1443678834-20160723-00';
SQL>alter system set "_allow_resetlogs_corruption"=true scope=spfile;
SQL>shutdown abort;
  SQL>startup mount;
  SQL> recover database using backup controlfile until cancel;
    #输入AUTO,应用归档日志后,再输入一遍recover database .......,输入online redo的路径+名称
  SQL> alter database open resetlogs;#数据不会丢失
  #有需要的话要重建临时表空间
  #ALTER TABLESPACE TEMP ADD TEMPFILE '/u01/app/oracle/oradata/orcl/temp01.dbf' SIZE 1G;


4.2.2 没有备份的控制文件,则需要重建控制文件。
在删除控制文件之前,获取控制文件的创建语句:
1)alter database backup controlfile to trace as '/home/oracle/crontol_trace.trc';
2)从/home/oracle/crontol_trace.trc文件中获得如下语句:
CREATE CONTROLFILE REUSE DATABASE "ORCL" RESETLOGS  ARCHIVELOG
    MAXLOGFILES 16
    MAXLOGMEMBERS 3
    MAXDATAFILES 100
    MAXINSTANCES 8
    MAXLOGHISTORY 292
LOGFILE
  GROUP 1 '/u01/app/oracle/oradata/orcl/redo01.log'  SIZE 50M BLOCKSIZE 512,
  GROUP 2 '/u01/app/oracle/oradata/orcl/redo02.log'  SIZE 50M BLOCKSIZE 512,
  GROUP 3 '/u01/app/oracle/oradata/orcl/redo03.log'  SIZE 50M BLOCKSIZE 512,
  GROUP 4 '/u01/app/oracle/oradata/orcl/redo_04.log'  SIZE 50M BLOCKSIZE 512
DATAFILE
  '/u01/app/oracle/oradata/orcl/system01.dbf',
  '/u01/app/oracle/oradata/orcl/sysaux01.dbf',
  '/u01/app/oracle/oradata/orcl/undotbs01.dbf',
  '/u01/app/oracle/oradata/orcl/users01.dbf',
  '/u01/app/oracle/oradata/orcl/test_01.dbf',
  '/u01/app/oracle/oradata/orcl/test_02.dbf'
CHARACTER SET ZHS16GBK;
如果没有使用1)中的语句获取创建语句,也可以根据实际情况重建控制文件。
删除所有的控制文件,并且模拟数据库崩溃。
恢复的过程如下:
1)startup nomount;
2)执行创建控制文件的语句,直接复制语句或放在脚本里均可。
3)之后执行:
SQL>alter system set "_allow_resetlogs_corruption"=true scope=spfile;
SQL>shutdown abort;
  SQL>startup mount;
  SQL> recover database using backup controlfile until cancel;
    #输入AUTO,应用归档日志后,再输入一遍recover database .......,输入online redo的路径+名称
  SQL> alter database open resetlogs;#数据不会丢失
    重建临时表空间
    ALTER TABLESPACE TEMP ADD TEMPFILE '/u01/app/oracle/oradata/orcl/temp01.dbf' SIZE 1G;


五、在只有一份备份的情况下,其余文件均丢失后,打开数据库
在数据库崩溃之后:
1)启动数据库至nomount,开启RMAN并设置dbid
SQL>startup nomount;
RMAN>set dbid 1443678834
2)还原控制文件
RMAN>restore controlfile from '/backup/c-1443678834-20160723-00';
SQL>alter database mount;
3)还原数据文件
  RMAN>restore database;
4)执行不完全恢复:
    SQL>alter system set "_allow_resetlogs_corruption"=true scope=spfile;
    SQL>shutdown abort;
    SQL>startup mount;
    SQL> recover database using backup controlfile until cancel;
  因为日志文件、归档日志文件都已经被删除,所以选择cancel不执行恢复。
    SQL> alter database open resetlogs;
  之后检查各文件是否正常。
 
 
六、总结
从模拟在线日志文件、控制文件丢失的过程中可以发现,当这些文件有副本时,可以很快地打开数据库,从而降低恢复数据库的难度。

猜你喜欢

转载自www.linuxidc.com/Linux/2016-08/134074.htm