您的位置：首页 > 数据库 > Oracle

ORACLE11g 没有控制文件如何通过rman备份恢复数据的详细实战过程

2016-10-18 20:14 751 查看
 
 

1、副总裁需要裸恢复的严峻现实

集团总部的信息部负责人给我打电话说为了找一年前的记录，所以需要对一年前2015年5月1日的数据进行恢复。而2016年初因为进行迁移，所以有些文件可能丢失，手上只有rman全备文件，希望在一天之内找回，集团一个副总裁在等着这个数据有急用。
 
我在电话里面说马上去做，接完电话，想到只有rman备份文件，而且是备份的数据文件，没有控制文件没有参数文件的备份，所以普通的
（1）      先恢复控制文件restore controlfile from ‘…bak’;
（2）      然后catalog start with ‘/data/2015-05-01/’注册备份文件，
（3）      最后restore database;recover database;恢复数据库。
三板斧的常规途径是彻底的行不通了，咋办？咋办？咋办呢？……
 
 

2、先进行数据文件的剥离

突然想起以前记得看过关于restoreDatafileTo数据抽取的操作思路，大概是如果没有控制文件后，可以从rman的数据文件备份和归档日志备份里面抽取数据文件，然后重新建立控制文件，再用resetlogs方式打开数据库：
 
因为抽取命令里面需要填写一个个数据文件，这里有个前提是自己要熟悉自己的oracle实例的文件目录，知道备份的时候oracle实例有多少个数据文件（包括文件存放目录），这样就可以快速的整理出来抽取命令的sql。如果这些都忘记了，还可以去备份日志文件里面去查看check下，一般备份日志文件里面都会有的。
 
根据以前记录整理下抽取命令：
DECLARE
 devtype varchar2(256);
 done boolean;
 BEGIN
  devtype:=sys.dbms_backup_restore.deviceAllocate (type=>'',ident=>'t1');
  sys.dbms_backup_restore.restoreSetDatafile;
  sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>01, toname=>'/home/oradata/powerdes/system01.dbf');
  sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>02, toname=>'/home/oradata/powerdes/sysaux01.dbf');
  sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>03, toname=>'/home/oradata/powerdes/undotbs01.dbf');
  sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>04, toname=>'/home/oradata/powerdes/users01.dbf');
  sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>05, toname=>'/home/oradata/powerdes/powerdesk01.dbf');
  sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>06, toname=>'/home/oradata/powerdes/plas01.dbf');
  sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>07, toname=>'/home/oradata/powerdes/pl01.dbf');
  sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>08, toname=>'/home/oradata/powerdes/help01.dbf');
  sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>09, toname=>'/home/oradata/powerdes/adobelc01.dbf');
  sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>10, toname=>'/home/oradata/powerdes/sms01.dbf');
  sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>11, toname=>'/home/oradata/powerdes/plcrm01.dbf');
  sys.dbms_backup_restore.restoreBackupPiece(done=>done, handle=>'/data/2015-05-01/full_POWERDES_20150501_3566.bak', params=>null);
  sys.dbms_backup_restore.deviceDeallocate;
  END;
/ 
 
 
执行过程如下：
[oracle@pldb236 oradata]$ rlwrap sqlplus / as sysdba
 
SQL*Plus: Release 11.2.0.1.0 Production on Mon Oct 17 21:19:32 2016
 
Copyright (c) 1982, 2009, Oracle.  All rights reserved.
 
 
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
 
DECLARE
owerdes/system01.dbf');
  sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>02, toname=>'/home/oradata/powerdes/sysaux01.dbf');
  sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>03, toname=>'/home/oradata/powerdes/undotbs01.dbf');
 devtype varchar2(256);
 done boolean;
 BEGIN
  devtype:=sys.dbms_backup_restore.deviceAllocate (type=>'',ident=>'t1');
  sys.dbms_backup_restore.restoreSetDatafile;
  sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>01, toname=>'/home/oradata/powerdes/system01.dbf');
  sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>02, toname=>'/home/oradata/powerdes/sysaux01.dbf');
  sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>03, toname=>'/home/oradata/powerdes/undotbs01.dbf');
  sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>04, toname=>'/home/oradata/powerdes/users01.dbf');
  sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>05, toname=>'/home/oradata/powerdes/powerdesk01.dbf');
  sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>06, toname=>'/home/oradata/powerdes/plas01.dbf');
  sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>07, toname=>'/home/oradata/powerdes/pl01.dbf');
  sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>08, toname=>'/home/oradata/powerdes/help01.dbf');
  sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>09, toname=>'/home/oradata/powerdes/adobelc01.dbf');
  sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>10, toname=>'/home/oradata/powerdes/sms01.dbf');
  sys.dbms_backup_restore.restoreDatafileTo(dfnumber=>11, toname=>'/home/oradata/powerdes/plcrm01.dbf');
  sys.dbms_backup_restore.restoreBackupPiece(done=>done, handle=>'/data/2015-05-01/full_POWERDES_20150501_3566.bak', params=>null);
  sys.dbms_backup_restore.deviceDeallocate;
  END;
 21  / 
PL/SQL procedure successfully completed.
 
SQL>
 
 
后台alert日志会显示正在不停的剥离出文件到指定目录里面去：
 
CKPT started with pid=13, OS id=23993
Mon Oct 17 21:16:59 2016
SMON started with pid=14, OS id=23995
Mon Oct 17 21:16:59 2016
RECO started with pid=15, OS id=23997
Mon Oct 17 21:16:59 2016
MMON started with pid=16, OS id=23999
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
Mon Oct 17 21:16:59 2016
MMNL started with pid=17, OS id=24001
starting up 1 shared server(s) ...
ORACLE_BASE from environment = /oracle/app/oracle
Mon Oct 17 21:20:14 2016
Full restore complete of datafile 7 to datafile copy /home/oradata/powerdes/pl01.dbf.  Elapsed time: 0:00:27
  checkpoint is 11106141982
  last deallocation scn is 11082135537
Full restore complete of datafile 8 to datafile copy /home/oradata/powerdes/help01.dbf.  Elapsed time: 0:00:03
  checkpoint is 11106141982
  last deallocation scn is 9881798870
Full restore complete of datafile 9 to datafile copy /home/oradata/powerdes/adobelc01.dbf.  Elapsed time: 0:00:01
  checkpoint is 11106141982
Mon Oct 17 21:20:32 2016
Full restore complete of datafile 10 to datafile copy /home/oradata/powerdes/sms01.dbf.  Elapsed time: 0:00:10
  checkpoint is 11106141982
Mon Oct 17 21:21:25 2016
Full restore complete of datafile 3 to datafile copy /home/oradata/powerdes/undotbs01.dbf.  Elapsed time: 0:01:23
  checkpoint is 11106141982
  last deallocation scn is 11106022955
  Undo Optimization current scn is 11106076830
Mon Oct 17 21:22:28 2016
Full restore complete of datafile 4 to datafile copy /home/oradata/powerdes/users01.dbf.  Elapsed time: 0:02:53
  checkpoint is 11106141982
  last deallocation scn is 11082633897
Mon Oct 17 21:23:47 2016
Full restore complete of datafile 11 to datafile copy /home/oradata/powerdes/plcrm01.dbf.  Elapsed time: 0:04:11
  checkpoint is 11106141982
  last deallocation scn is 11100156728
Mon Oct 17 21:25:30 2016
Full restore complete of datafile 1 to datafile copy /home/oradata/powerdes/system01.dbf.  Elapsed time: 0:05:34
  checkpoint is 11106141982
  last deallocation scn is 11039454999
  Undo Optimization current scn is 11106076830
Mon Oct 17 21:28:10 2016
Full restore complete of datafile 2 to datafile copy /home/oradata/powerdes/sysaux01.dbf.  Elapsed time: 0:08:27
  checkpoint is 11106141982
  last deallocation scn is 11101587434
Mon Oct 17 21:29:11 2016
Full restore complete of datafile 6 to datafile copy /home/oradata/powerdes/plas01.dbf.  Elapsed time: 0:09:33
  checkpoint is 11106141982
  last deallocation scn is 11082142314
 
 

3、建立控制文件

数据文件抽取成功后，需要单独自己创建控制文件，如果不知道如何创建controlfile的命令，可以在线上生成trace文件一般默认的控制文件是二进制的，打开来是乱码的 ，备份一个trace出来 可以打开看到语句了,$ORACLE_BASE/admin/$ORACLE_SID/udump目录下，生成的新的 trace 文件里，trace文件有生成控制文件的脚本，使用如下命令alter database backup controlfile to trace as'/oracle/app/oracle/admin/powerdes/pfile/control.sql';可以得到创建控制文件的sql命令。
 
这里有个前提是自己要熟悉自己的oracle实例的文件目录，知道备份的时候oracle实例有多少个数据文件，有多少个redo log文件，这样就可以快速的整理出来创建控制文件的sql。如果这些都忘记了，还可以去备份日志文件里面去查看check下，一般备份日志文件里面都会有的。
 
整理出来创建控制文件sql命令如下：
（1）命令如下
CREATE CONTROLFILE REUSE SET DATABASE "POWERDES" RESETLOGS ARCHIVELOG
    MAXLOGFILES 16
    MAXLOGMEMBERS 3
    MAXDATAFILES 100
    MAXINSTANCES 8
    MAXLOGHISTORY 2920
DATAFILE
  '/home/oradata/powerdes/system01.dbf',
  '/home/oradata/powerdes/sysaux01.dbf',
  '/home/oradata/powerdes/undotbs01.dbf',
  '/home/oradata/powerdes/users01.dbf',
  '/home/oradata/powerdes/powerdesk01.dbf',
  '/home/oradata/powerdes/plas01.dbf',
  '/home/oradata/powerdes/pl01.dbf',
  '/home/oradata/powerdes/help01.dbf',
  '/home/oradata/powerdes/adobelc01.dbf',
  '/home/oradata/powerdes/sms01.dbf',
  '/home/oradata/powerdes/plcrm01.dbf'
LOGFILE
  GROUP 1 '/home/oradata/powerdes/redo01.log'  SIZE 50M BLOCKSIZE 512,
  GROUP 2 '/home/oradata/powerdes/redo02.log'  SIZE 50M BLOCKSIZE 512,
  GROUP 3 '/home/oradata/powerdes/redo03.log'  SIZE 50M BLOCKSIZE 512
CHARACTER SET ZHS16GBK;
 
（2）执行过程如下：
SQL>
CREATE CONTROLFILE REUSE SET DATABASE "POWERDES" RESETLOGS ARCHIVELOG
    MAXLOGFILES 16
    MAXLOGMEMBERS 3
    MAXDATAFILES 100
    MAXINSTANCES 8
    MAXLOGHISTORY 2920
DATAFILE
  '/home/oradata/powerdes/system01.dbf',
  '/home/oradata/powerdes/sysaux01.dbf',
  '/home/oradata/powerdes/undotbs01.dbf',
  '/home/oradata/powerdes/users01.dbf',
  '/home/oradata/powerdes/powerdesk01.dbf',
  '/home/oradata/powerdes/plas01.dbf',
  '/home/oradata/powerdes/pl01.dbf',
  '/home/oradata/powerdes/help01.dbf',
  '/home/oradata/powerdes/adobelc01.dbf',
  '/home/oradata/powerdes/sms01.dbf',
  '/home/oradata/powerdes/plcrm01.dbf'
LOGFILE
  GROUP 1 '/home/oradata/powerdes/redo01.log'  SIZE 50M BLOCKSIZE 512,
  GROUP 2 '/home/oradata/powerdes/redo02.log'  SIZE 50M BLOCKSIZE 512,
  GROUP 3 '/home/oradata/powerdes/redo03.log'  SIZE 50M BLOCKSIZE 512
 23  CHARACTER SET ZHS16GBK;
 
Control file created.
 
SQL>
 
 

4、进行数据恢复

开始执行数据恢复，还是依然在sql窗口里面进行操作的，操作如下：
#(1) 执行recover恢复
SQL> recover database using backup controlfile until cancel ;
ORA-00279: change 11106141982 generated at 05/01/2015 03:00:08 needed for
thread 1
ORA-00289: suggestion :
/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/2016_10_17/o1_mf_1_32
117_%u_.arc
ORA-00280: change 11106141982 for thread 1 is in sequence #32117
 
 
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}  # 这里一般选择输入cancel即可
cancel
ORA-10879: error signaled in parallel recovery slave
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 2 needs more recovery to be consistent
ORA-01110: data file 2: '/home/oradata/powerdes/sysaux01.dbf'
 
 
SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01194: file 2 needs more recovery to be consistent
ORA-01110: data file 2: '/home/oradata/powerdes/sysaux01.dbf'
 
 
# 这时，我们无法将数据库打开，一直报ORA-01194错误，说明数据库的SCN号和数据文件的SCN号不一致了。这是因为控制文件我们不是从备份集里面恢复回来的，而是在抽取数据文件后手动建立的控制文件，因此要比数据文件的SCN号要大（甚至特殊情况当前的数据库的会是0）。通过对v$database和v$datafile的checkpoint_change#列的查询，可以确定出本次操作中当前数据库的checkpoint_chenage#为0，两者完全不一致导致通过resetlogs打开数据库异常。
 
Bty：如果这里当前数据库v$database的值不为0，但是仍然比数据文件v$datafile里面的值大，那么则会不停报ORA-01152错误。
SQL> select checkpoint_change# from v$database;
 
CHECKPOINT_CHANGE#
------------------
                    0
 
SQL> select file#,checkpoint_change# from v$datafile;
 
     FILE# CHECKPOINT_CHANGE#
---------- ------------------
          1        1.1106E+10
          2        1.1106E+10
          3        1.1106E+10
          4        1.1106E+10
          5        1.1106E+10
          6        1.1106E+10
          7        1.1106E+10
          8        1.1106E+10
          9        1.1106E+10
         10        1.1106E+10
         11        1.1106E+10
 
11 rows selected.
 
 
SQL>
 
 
 
 文章源地址：http://blog.csdn.net/mchdba/article/details/52852157，未经过作者mchdba（黄杉）允许，谢绝转载。

怎么办呢？这个时候，就需要我们使用_allow_resetlogs_corruption的隐含参数来处理了。

整个调整的目标是强制启动数据库，设置此参数之后，在数据库Open过程中，Oracle会跳过某些一致性检查，从而使数据库可能跳过不一致状态，Open打开:
# 启动隐含参数
SQL> alter system set "_allow_resetlogs_corruption"=true scope=spfile;
 
System altered.
 
SQL> # 然后重启数据库，使参数生效，在此基础上再次恢复数据库
SQL> shutdown immediate;
 
ORA-01109: database not open
 
 
Database dismounted.
ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started.
 
Total System Global Area 6680915968 bytes
Fixed Size              2213936 bytes
Variable Size              4898949072 bytes
Database Buffers    1744830464 bytes
Redo Buffers                34922496 bytes
Database mounted.
SQL> recover database using backup controlfile until cancel;
ORA-00279: change 11106141982 generated at 05/01/2015 03:00:08 needed for
thread 1
ORA-00289: suggestion :
/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/2016_10_17/o1_mf_1_32
117_%u_.arc
ORA-00280: change 11106141982 for thread 1 is in sequence #32117
 
 
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
ORA-10879: error signaled in parallel recovery slave
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 2 needs more recovery to be consistent
ORA-01110: data file 2: '/home/oradata/powerdes/sysaux01.dbf'
 
# 然后使用resetlogs打开数据库，成功了。
SQL>  alter database open resetlogs;
 
Database altered.
 
SQL>
 
# 然后检查scn，都是统一的了。
select checkpoint_change# from v$database;
select file#,checkpoint_change# from v$datafile;
 
 
 
然后使用业务表数据来判断是否已经恢复成功到这一天，查看后确认成功：
SQL> select t2.* from(select t.uiid,t.updated_date from plas.plas_acct t where t.updated_date is not null   order by t.updated_date desc ) t2 where rownum <10;
 
UIID                                                  UPDATED_DATE
-------------------------------------------------- ------------
wangyu1                                                  01-MAY-15
gaihy                                                          01-MAY-15
xuhl                                                   01-MAY-15
dingchuan1                                               01-MAY-15
zhangcong                                                01-MAY-15
chenwh2                                                  01-MAY-15
yuli2                                                  01-MAY-15
zhangxya                                         01-MAY-15
qiuwj                                                          01-MAY-15
 
9 rows selected.
 
SQL>
 
 
至此，没有控制文件下通过rman恢复一年的数据做成了，然后通过expdp导出需要的数据，之后对数据库进行恢复或者重建等等。

后续处理：
关闭参数：alter system set "_allow_resetlogs_corruption"=false scope=spfile;
重启数据库：shutdown; startup;

深度思考：
使用dbms_backup_restore的局限性在于，抽取RestoreDatafileTo的时候，必须知道rman备份片信息，知道所有的数据文件信息，这样才能完整的抽取出所有的数据文件，然后进行不一致恢复。
 
参考文章地址：http://blog.itpub.net/11590946/viewspace-750511/
 
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 点击这里给我发消息
标签： 
相关文章推荐
新的分享
章节导航