oracle完全恢复实例

完全恢复：不丢数据
前提条件：所需要的归档日志文件和online redo log都在。

下面的步骤，实际上是根据cuug陈老师的实例过程进程的操作，各位可以可以从百度文库上下载他的案例科技。

完全恢复方式之一：数据库在mount状态下进行恢复
一、搭建环境
 1、scott往test表插入数据，同时切换日志，每个日志组都要切换一次，目的是产生归档日志。
 SQL> select count(*) from test;
 
   COUNT(*)
 ----------
       896
  2、再次插入数据，这一次不提交SQL> select SEQUENCE#,MEMBERS,STATUS from v$log;

  SEQUENCE#    MEMBERS STATUS
 ---------- ---------- ----------------
         31          1 CURRENT
         29          1 INACTIVE
         30          1 INACTIVE
        
  3、主机断电，导致某个数据文件损坏（控制文件没有损坏）
 
 SQL> shutdown abort;
 ORACLE instance shut down.
  rm -f users01.dbf
 
二、恢复数据库
 1、主机加电，尝试打开数据库
 SQL> startup
 ORACLE instance started.
 
 Total System Global Area  305491968 bytes
 Fixed Size                  1336176 bytes
 Variable Size             239078544 bytes
 Database Buffers           58720256 bytes
 Redo Buffers                6356992 bytes
 Database mounted.
 ORA-01157: cannot identify/lock data file 4 - see DBWR trace file
 ORA-01110: data file 4: '/oracle/oradata/ocp5/users01.dbf'
 提示某个数据文件损坏，无法识别。

 2、从最近的备份中转储相应的数据文件到目标位置。
 cp /ocp/21030110/users01.dbf /oracle/oradata/ocp5/

 3、尝试打卡数据库
 SQL> alter database open;
 alter database open
 *
 ERROR at line 1:
 ORA-01113: file 4 needs media recovery
 ORA-01110: data file 4: '/oracle/oradata/ocp5/users01.dbf'

 为什么知道该文件要进行介质恢复？oracle 根据控制文件里面记录的数据文件应有的检查点号与
 数据文件头检查点号进行比较
 SQL> column CHECKPOINT_CHANGE# format 999999999999;
 SQL> select name,CHECKPOINT_CHANGE# from v$datafile;
 
 NAME                                     CHECKPOINT_CHANGE#
 ---------------------------------------- ------------------
 /oracle/oradata/ocp5/system01.dbf                   1143391
 /oracle/oradata/ocp5/sysaux01.dbf                   1143391
 /oracle/oradata/ocp5/undotbs01.dbf                  1143391
 /oracle/oradata/ocp5/users01.dbf                    1143391
 /oracle/oradata/ocp5/etc                            1143391
 /oracle/oradata/ocp5/room                           1143391
 /oracle/oradata/ocp5/undo001.dbf                    1143391
 /oracle/oradata/ocp5/undotbs2.dbf                   1143391
 
 
 SQL> select name,checkpoint_change# from  v$datafile_header;
 
 NAME                                     CHECKPOINT_CHANGE#
 ---------------------------------------- ------------------
 /oracle/oradata/ocp5/system01.dbf                   1143391
 /oracle/oradata/ocp5/sysaux01.dbf                   1143391
 /oracle/oradata/ocp5/undotbs01.dbf                  1143391
 /oracle/oradata/ocp5/users01.dbf                    1112985
 /oracle/oradata/ocp5/etc                            1143391
 /oracle/oradata/ocp5/room                           1143391
 /oracle/oradata/ocp5/undo001.dbf                    1143391
 /oracle/oradata/ocp5/undotbs2.dbf                   1143391
 
 通过比较发现，控制文件记录的users表空间的数据文件头的检查点号与控制文件记录的不一致。
 因此需要介质恢复。
 4、对数据库进行recovery
 SQL> recover database;
 ORA-00279: change 1112985 generated at 01/10/2013 02:34:35 needed for thread 1
 ORA-00289: suggestion : /ocp/archive/1_22_782432234.dbf
 ORA-00280: change 1112985 for thread 1 is in sequence #22

 Specify log: {=suggested | filename | AUTO | CANCEL}

 oracle 通过日志中的scn的范围，来确定需要用到哪个归档日志。注意看22的编号。
 
 SQL> select SEQUENCE#,FIRST_CHANGE#,NEXT_CHANGE# from v$archived_log;
 
  SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
 ---------- ------------- ------------
         10        923979       925496
         11        925496       925580
         12        925580       927230
         13        927230       927548
         14        927548       954335
         15        954335       984378
         16        984378      1005780
         18       1015261      1040469
         17       1005780      1015261
         19       1040469      1090180
         20       1090180      1102743
 
  SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
 ---------- ------------- ------------
         21       1102743      1102762
         22       1102762      1113474
         23       1113474      1113501
         24       1113501      1137976
         25       1137976      1143194
         26       1143194      1143266
         27       1143266      1143292
         28       1143292      1143302
         29       1143302      1143379
         30       1143379      1143391

 通过观察警告日志文件，我们发现，oracle 恢复的时候，是使用archvie log + online redo log进行的。
 ALTER DATABASE RECOVER    CONTINUE DEFAULT 
 Media Recovery Log /ocp/archive/1_22_782432234.dbf
 ORA-279 signalled during: ALTER DATABASE RECOVER    CONTINUE DEFAULT  ...
 ALTER DATABASE RECOVER    CONTINUE DEFAULT 
 Media Recovery Log /ocp/archive/1_23_782432234.dbf
 ORA-279 signalled during: ALTER DATABASE RECOVER    CONTINUE DEFAULT  ...
 ALTER DATABASE RECOVER    CONTINUE DEFAULT 
 Media Recovery Log /ocp/archive/1_24_782432234.dbf
 ORA-279 signalled during: ALTER DATABASE RECOVER    CONTINUE DEFAULT  ...
 ALTER DATABASE RECOVER    CONTINUE DEFAULT 
 Media Recovery Log /ocp/archive/1_25_782432234.dbf
 ORA-279 signalled during: ALTER DATABASE RECOVER    CONTINUE DEFAULT  ...
 ALTER DATABASE RECOVER    CONTINUE DEFAULT 
 Media Recovery Log /ocp/archive/1_26_782432234.dbf
 ORA-279 signalled during: ALTER DATABASE RECOVER    CONTINUE DEFAULT  ...
 ALTER DATABASE RECOVER    CONTINUE DEFAULT 
 Media Recovery Log /ocp/archive/1_27_782432234.dbf
 ORA-279 signalled during: ALTER DATABASE RECOVER    CONTINUE DEFAULT  ...
 ALTER DATABASE RECOVER    CONTINUE DEFAULT 
 Media Recovery Log /ocp/archive/1_28_782432234.dbf
 Recovery of Online Redo Log: Thread 1 Group 2 Seq 29 Reading mem 0
   Mem# 0: /oracle/oradata/ocp5/redo02.log
 Recovery of Online Redo Log: Thread 1 Group 3 Seq 30 Reading mem 0
   Mem# 0: /oracle/oradata/ocp5/redo03.log
 Recovery of Online Redo Log: Thread 1 Group 1 Seq 31 Reading mem 0
   Mem# 0: /oracle/oradata/ocp5/redo01.log
 Media Recovery Complete (ocp5)
 Completed: ALTER DATABASE RECOVER    CONTINUE DEFAULT 
 
 再次检查控制文件和数据文件头的检查点号是否一致。
 SQL> select name,checkpoint_change# from v$datafile;
 
 NAME                                     CHECKPOINT_CHANGE#
 ---------------------------------------- ------------------
 /oracle/oradata/ocp5/system01.dbf                   1164727
 /oracle/oradata/ocp5/sysaux01.dbf                   1164727
 /oracle/oradata/ocp5/undotbs01.dbf                  1164727
 /oracle/oradata/ocp5/users01.dbf                    1164727
 /oracle/oradata/ocp5/etc                            1164727
 /oracle/oradata/ocp5/room                           1164727
 /oracle/oradata/ocp5/undo001.dbf                    1164727
 /oracle/oradata/ocp5/undotbs2.dbf                   1164727
 
 SQL> select name,checkpoint_change# from  v$datafile_header;
 
 NAME                                     CHECKPOINT_CHANGE#
 ---------------------------------------- ------------------
 /oracle/oradata/ocp5/system01.dbf                   1164727
 /oracle/oradata/ocp5/sysaux01.dbf                   1164727
 /oracle/oradata/ocp5/undotbs01.dbf                  1164727
 /oracle/oradata/ocp5/users01.dbf                    1164727
 /oracle/oradata/ocp5/etc                            1164727
 /oracle/oradata/ocp5/room                           1164727
 /oracle/oradata/ocp5/undo001.dbf                    1164727
 /oracle/oradata/ocp5/undotbs2.dbf                   1164727
 
 5、尝试打开数据库。
 SQL> alter database open;
 
 Database altered.
 
 6、验证数据是否丢失。
 
 SQL> select count(*) from test;
 
   COUNT(*)
 ----------
        896
  
   最后一条，因为未提交，所以回滚了。
  
 总结，在mount下进行恢复，适合所有的数据文件损坏恢复。但是要求归档和redo完整。
 要点：把数据库所有数据库文件往回倒到一个一致的点，然后一起往前推。
 
 

完全恢复方式二：数据库在open状态下打开
 1、主机断电，导致某个数据文件损坏
 
 SQL> shutdown abort;
 ORACLE instance shut down.
 
 rm -f users01.dbf
 
 2、主机加电，尝试打开数据库
 SQL> startup
 ORACLE instance started.
 
 Total System Global Area  305491968 bytes
 Fixed Size                  1336176 bytes
 Variable Size             239078544 bytes
 Database Buffers           58720256 bytes
 Redo Buffers                6356992 bytes
 Database mounted.
 ORA-01157: cannot identify/lock data file 4 - see DBWR trace file
 ORA-01110: data file 4: '/oracle/oradata/ocp5/users01.dbf'
 
 提示缺少文件，从最近的备份中，把文件传到目标位置
 cp users01.dbf /oracle/oradata/ocp5/
 
 3、尝试打卡数据库
 SQL> alter database open;
 alter database open
 *
 ERROR at line 1:
 ORA-01113: file 4 needs media recovery
 ORA-01110: data file 4: '/oracle/oradata/ocp5/users01.dbf'
 提示需要介质恢复
 
 4、为了提高数据库的可用性，可以把损坏的数据文件offline，可以指定文件名称，也可指定序号。
 SQL> alter database datafile '/oracle/oradata/ocp5/users01.dbf' offline;
 
 Database altered
 
 
 SQL> alter database open;
 
 Database altered.
 
 5、使用recover tablespace或者datafile方式，恢复损坏的数据文件
 SQL> recover datafile 4;
 ORA-00279: change 1112985 generated at 01/10/2013 02:34:35 needed for thread 1
 ORA-00289: suggestion : /ocp/archive/1_22_782432234.dbf
 ORA-00280: change 1112985 for thread 1 is in sequence #22
 
 
 Specify log: {=suggested | filename | AUTO | CANCEL}
 auto
 ORA-00279: change 1113474 generated at 01/10/2013 02:44:17 needed for thread 1
 ORA-00289: suggestion : /ocp/archive/1_23_782432234.dbf
 ORA-00280: change 1113474 for thread 1 is in sequence #23
 
 
 ORA-00279: change 1113501 generated at 01/10/2013 02:45:12 needed for thread 1
 ORA-00289: suggestion : /ocp/archive/1_24_782432234.dbf
 ORA-00280: change 1113501 for thread 1 is in sequence #24
 
 
 ORA-00279: change 1137976 generated at 01/10/2013 21:41:13 needed for thread 1
 ORA-00289: suggestion : /ocp/archive/1_25_782432234.dbf
 ORA-00280: change 1137976 for thread 1 is in sequence #25
 
 
 ORA-00279: change 1143194 generated at 01/10/2013 22:11:39 needed for thread 1
 ORA-00289: suggestion : /ocp/archive/1_26_782432234.dbf
 ORA-00280: change 1143194 for thread 1 is in sequence #26
 
 
 ORA-00279: change 1143266 generated at 01/10/2013 22:13:31 needed for thread 1
 ORA-00289: suggestion : /ocp/archive/1_27_782432234.dbf
 ORA-00280: change 1143266 for thread 1 is in sequence #27
 
 
 ORA-00279: change 1143292 generated at 01/10/2013 22:14:16 needed for thread 1
 ORA-00289: suggestion : /ocp/archive/1_28_782432234.dbf
 ORA-00280: change 1143292 for thread 1 is in sequence #28
 
 
 ORA-00279: change 1143302 generated at 01/10/2013 22:14:40 needed for thread 1
 ORA-00289: suggestion : /ocp/archive/1_29_782432234.dbf
 ORA-00280: change 1143302 for thread 1 is in sequence #29
 
 
 ORA-00279: change 1143379 generated at 01/10/2013 22:15:16 needed for thread 1
 ORA-00289: suggestion : /ocp/archive/1_30_782432234.dbf
 ORA-00280: change 1143379 for thread 1 is in sequence #30
 
 
 Log applied.
 Media recovery complete.
 
 6、把文件online
 SQL> alter database datafile 4 online;
 
 Database altered.
 
 7、验证数据的准确性
 SQL> select count(*) from test;
 
   COUNT(*)
 ----------
        896
 
 总结：以open方式恢复数据文件，适合普通的数据文件损坏，原理是数据库open时，不会检查online或者read only的数据库文件，
 但不适合system、undo、sysaux等表空间损坏。有点：可以提高数据库的可用性。
 
 
完全恢复方式三、控制文件和数据文件损坏
 
 1、主机断电，导致所有的数据文件和控制文件损坏。这里删除了控制文件，sys*文件
 2、主机加电尝试打开数据库。
 SQL> startup
 ORACLE instance started.
 
 Total System Global Area  305491968 bytes
 Fixed Size                  1336176 bytes
 Variable Size             247467152 bytes
 Database Buffers           50331648 bytes
 Redo Buffers                6356992 bytes
 ORA-00205: error in identifying control file, check alert log for more info
 
 打开失败，数据库启动到了nomount状态。
 
 3、把备份的控制文件转储到目标位置
 cp control* /oracle/oradata/ocp5/
 cp sys* /oracle/oradata/ocp5/
 
 4、把数据库启动到mount状态
 SQL> alter database mount;
 
 Database altered.
 
 5、尝试打开数据库
 SQL> alter database open;
 alter database open
 *
 ERROR at line 1:
 ORA-01113: file 1 needs media recovery
 ORA-01110: data file 1: '/oracle/oradata/ocp5/system01.dbf'
 
 6、对数据库进行recovery
 SQL> recover database;
 ORA-00283: recovery session canceled due to errors
 ORA-01122: database file 3 failed verification check
 ORA-01110: data file 3: '/oracle/oradata/ocp5/undotbs01.dbf'
 ORA-01207: file is more recent than control file - old control file
 提示恢复失败，因为使用的控制文件是旧的，无法失败最新的undo 文件，无法做完全恢复。
 
 7、重建控制文件，重建过程中，oracle会扫描undo文件，获取最新的信息来更新当前信息。
 SQL> alter database backup controlfile to trace;
 
 Database altered.
 产生的文件在user_dump_dest中
 
 8、将数据库关闭，开启到nomount状态，执行重建控制文件的语句。
 
  vi ocp5_ora_5217.trc
 
 CREATE CONTROLFILE REUSE DATABASE "OCP5" NORESETLOGS  ARCHIVELOG
     MAXLOGFILES 16
     MAXLOGMEMBERS 3
     MAXDATAFILES 100
     MAXINSTANCES 8
     MAXLOGHISTORY 292
 LOGFILE
   GROUP 1 '/oracle/oradata/ocp5/redo01.log'  SIZE 50M BLOCKSIZE 512,
   GROUP 2 '/oracle/oradata/ocp5/redo02.log'  SIZE 50M BLOCKSIZE 512,
   GROUP 3 '/oracle/oradata/ocp5/redo03.log'  SIZE 50M BLOCKSIZE 512
 -- STANDBY LOGFILE
 DATAFILE
   '/oracle/oradata/ocp5/system01.dbf',
   '/oracle/oradata/ocp5/sysaux01.dbf',
   '/oracle/oradata/ocp5/undotbs01.dbf',
   '/oracle/oradata/ocp5/users01.dbf',
   '/oracle/oradata/ocp5/etc',
   '/oracle/oradata/ocp5/room',
   '/oracle/oradata/ocp5/undo001.dbf',
   '/oracle/oradata/ocp5/undotbs2.dbf'
 CHARACTER SET WE8MSWIN1252
 ;
 
 重建结束后，查看v$log视图，看当前的序列号是否更新。（这里有一点疑问，因为之前没有看v$log,因此没比较，这里是陈老师的
 例子里的动作，不过那个演示里，提示的是redo log与控制文件的序列号不一致，因为此处有待确定，各位可在自己实验时关注一下）
 SQL> select GROUP#,SEQUENCE# from v$log;
 
     GROUP#  SEQUENCE#
 ---------- ----------
          1         31
          3         33
          2         32
 9、执行完全恢复
 
 10、打开数据库，验证数据准确性。
 
 总结：这个案例中，关键在与控制文件丢失了，即使从备份中拿来，也会与其他的数据文件或log文件不一致，因为控制文件是之前的，
 而数据文件或log文件在往前走，这时需要重建控制文件，会自动从现有的数据文件及log中提前信息。
 
 其实如果控制文件有多路，当其中一个损坏时，只需要关闭数据库，把拷贝一个好的来替换坏的，就可以了，不需要做其他动作。
 

完全恢复方式四：未备份的数据文件损坏
适合环境：要求从创建该数据文件开始，所有的归档日志都在。

1、创建表空间
SQL> create tablespace test datafile '/oracle/oradata/ocp5/test01.dbf' size 50m;

Tablespace created.

2、创建表，并且放在新建的表空间里。
SQL>  create table test2  tablespace test as select * from scott.emp;

3、主机断电，导致新建的数据文件损坏。
SQL> shutdown abort;
ORACLE instance shut down.

4、主机加电，尝试打开数据库
SQL> startup
ORACLE instance started.

Total System Global Area  305491968 bytes
Fixed Size                  1336176 bytes
Variable Size             247467152 bytes
Database Buffers           50331648 bytes
Redo Buffers                6356992 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 9 - see DBWR trace file
ORA-01110: data file 9: '/oracle/oradata/ocp5/test01.dbf'

5、由于该数据文件没有备份，我们可以使用重建数据文件的方式进行：
SQL> alter database create datafile '/oracle/oradata/ocp5/test01.dbf';

Database altered.

6、对数据文件进行recovery
SQL> recover datafile '/oracle/oradata/ocp5/test01.dbf';
Media recovery complete.

7、尝试打开数据库
SQL> alter database open;

Database altered.

8、验证数据完整性
 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23169974/viewspace-752525/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/23169974/viewspace-752525/