我对Oracle RMAN恢复的理解.docx

1、我对Oracle RMAN恢复的理解我对Oracle RMAN恢复的理解零散思路：可能遇到的恢复情况：因为数据库无法启动或正常使用需要恢复；因为数据误删除或表空间、表的误删除等需要将数据库或其中某表空间、表或表中数据恢复到过去某时间点；RMAN恢复原则：恢复不外乎就是恢复如下一些文件：数据文件（也有可能是表空间），控制文件，归档日志文件（见后面关于归档日志恢复部分），在线日志文件，初始化参数文件，全库恢复需要在MOUNT状态下，表空间或数据文件的恢复可以在OPEN状态下进行，控制文件归档日志文件在线日志文件初始化参数文件常用的恢复命令：/对数据库进行完全介质恢复归档模式，控制文件、初始化参数文

2、件、归档日志文件和重做日志文件都完好无损，其余数据文件全部丢失，可将数据库恢复到崩溃前那一刻的状态：Rmanstartup mount;Rmanrestore database;Rmanrecover database delete archivelog;Rmanalter database open;？那以上情况下，非归档模式应如何处理？这种情况下感觉应该有几种情况：首先非归档模式下的备份只可能是一致性备份，而且非归档模式下没有归档日志，因此恢复时要考虑最近一次备份和数据库崩溃期间的在线日志文件是否都还在，如果在则直接执行restore和recover然后正常打开数据库即可，而如果在线日志文

3、件已经部分或全部丢失，则首先restore最近一次备份，然后执行recover database until cancel命令，据说此时该命令并不会执行任何恢复操作，只是提示控制文件不再使用原有重做日志，最后以resetlogs方式打开数据库。在三思的书中，文字性提到了一种方法：首先恢复之前备份的控制文件，然后执行restore和recover命令，最后以resetlogs方式打开数据库。感觉这种方式很有道理而前一种思路似乎有问题：前一种思路中实际是用当前的控制文件在进行恢复操作，而当前的控制文件很有可能有前次备份中所不具有的新加的数据文件，那么这样在备份的时候是不是会出问题呢？ 以上都需要具

4、体验证！/恢复表空间和数据文件mount或open状态都可Tablespace:Rmansql alter tablespace tbs1 offline immediate;Rmanrestore tablespace tbs1;Rmanrecover tablespace tbs1;Rmansql alter tablespace tbs1 online;Datafile:Rmansql alter database datafile 9 offline;Rmanrestore datafile 9;Rmanrecover datafile 9;Rmansql alter datafile

5、 9 online;或Rmanset newname for datafile 3 to f:newlocationsysaux01.dbf;Rmanrestore datafile 3;Rmanswitch datafile 3;Rmanrecover datafile 3;/恢复归档日志文件特别：三思告诉我们：“恢复归档文件也是使用restore命令，如果只是为了在恢复数据文件后应用归档文件，那并不需要手动归档文件进行恢复，RMAN会在recover的时候自动对适当的归档进行恢复。单独恢复归档文件一般是有特别的需求，如创建了Data Guard环境，Standy端丢失了部分归档文件，必须从

6、Primary端重新获取等等。”/恢复控制文件这里所说的恢复是指仅恢复控制文件本身，应该还有一种“基于控制文件的不完全恢复”，不知和这种情况是否相同（当所有控制文件全部丢失或者误删除了表空间时（闪回数据库能办到吗？），需要执行控制文件的恢复）。其实本身是一种解决方案下的多种情况： 情景1：归档、有恢复目录、控制文件全部丢失或部分数据文件或表空间丢失情景2：归档、无恢复目录、控制文件全部丢失或部分数据文件或表空间丢失前景3：非归档、有恢复目录、控制文件全部丢失或部分数据文件或表空间丢失情景4：非归档、无恢复目录、控制文件全部丢失或部分数据文件或表空间丢失1、 从自动备份中恢复Rmanset DB

7、ID=1415261003;Rmanstartup nomount;Rmanrestore controlfile from autobackup;Rmanalter database mount;(Rmanrestore controlfile to d:oraclenewctlfcontrolfile01.ctl from autobackup;恢复到指定位置)Rmanrecover database;Rmanalter database open resetlogs;2、 从备份集中恢复Rmanset DBID=1415261003;Rmanstartup nomount;Rmanres

8、tore controlfile from d:backupc-1415261003-20110522-00;(Rmanrestore controlfile to d:oraclenewctlfcontrolfile01.ctl from autobackup;恢复到指定位置)Rmanalter database mount;Rmanrecover database;Rmanalter database open resetlogs;/恢复初始化参数文件(方法基本与控制文件的恢复相同)Rman set DBID=1415261003;Rmanstartup nomount;Rmanresto

9、re spfile from autobackup;Rmanalter database mount;Rmanrecover database;/恢复联机重做日志文件0、 查询联机日志状态情况v$log中记录联机重做日志组的信息；v$logfile中记录联机重做日志组对应的日志文件；SQLselect group#, thread#, sequence#, members, archived, status from v$log;SQLselect group#, member from v$logfile;1、 日志组中的某个日志成员损坏多元化重做日志的目的就是为了防止日志成员的介质失败。如

10、果某个日志组的一个日志成员出现介质失败，那么数据库仍然可以正常工作。首先查询：SQLselect member from v$logfile where status=INVALID;然后使用alter database drop logfile member命令删除该日志成员，注意，如果出现损坏的日志成员是当前日志组的日志成员，那么该日志成员将不能被删除，需要进行手工的切换：SQLalter system switch logfile;SQLalter database drop logfile member c:orclredo01_2.log;在删除了日志成员之后，需要为该日志组添加新的

11、日志成员，注意新增加的日志成员状态也为INVALID：SQLalter database add logfile member c:orclredo01_3.log to group 1;2、 丢失非当前的联机重做日志文件先查询出丢失的联机重做日志文件组及其包含的联机重做日志文件然后修复：SQLalter database clear logfile group 1;该命令重建该组重做日志文件即可。特别！在精通Oracle 10g备份与恢复一书中关于此部分的介绍分类更细：(1)、在OPEN状态下非活动日志组的所有日志成员全部损坏出现此种情况，数据库仍然正常工作，只是当切换到该日志组时，因为其内

12、容不能被归档，所以后台进程LGWR会处于等待状态。为了使得后台进程LGWR可以继续工作，DBA应该清楚该日志组(我理解此种情景是针对归档模式而言的，非归档模式没得这种问题)：SQLalter database clear unarchived logfile group 1;(2)、在关闭状态下非活动日志组的所有日志成员全部损坏新增加新的日志组，删除原有日志组，然后打开数据：SQLalter database add logfile (d:orclredo04_1.log, c:orclredo04_2.log) size 10M;SQLalter database drop logfile

13、group 1;SQLalter database open;3、 丢失当前的联机重做日志文件此种情况下不能直接重建，而是应该执行不完全恢复需要修改一个隐藏的初始化参数：SQLalter system set “_ALLOW_RESETLOGS_CORRUPTION”=TRUE SCOPE=SPFILE;该参数设为TRUE时，Oracle在OPEN时会跳过一些一致性的检查。特别！在精通Oracle 10g备份与恢复一书中关于此部分的介绍分类更细：(1)、在OPEN状态下当前日志组的所有日志成员全部损坏当数据库处于OPEN状态时，如果当前日志组的所有日志成员全部损坏，那么当后台进程LGWR将事物

14、写入该日志组时，实例会被自动关闭，并报错。出现这种情况下，需要执行不完全恢复：RMANstartup mount;RMANrestore database;RMANrecover database until cancel;RMANalter database open resetlogs;(2)、在关闭状态下当前日志组的所有日志成员全部损坏当在关闭状态下当前日志组出现损坏时，因为数据文件、控制文件都处于完全一致状态，所以DBA只需要执行基于CANCEL的不完全恢复即可：RMANstartup mount;RMANrecover database until cancel;RMANalter

15、database open resetlogs;/RMAN不完全恢复0、 执行不完全恢复后，因为要以resetlogs方式打开数据库，而此时会重新建立重做日志，清空原有重做日志的内容（同时归档日志也全部删除了），而且过去的备份也不能直接使用了（但好像听说从Oracle Database 10g开始，Oracle提供了新的安全机制可以确保归档日志不会被覆盖，从而使得在恢复数据库时可以使用早期数据库副本的备份），因此强烈建议读者删除早期所有的备份，并重新备份数据库：RMANrundelete noprompt backup;delete noprompt copy;backup database

16、format=d:backup%d_%s.bak;sql alter system archive log current;1、 基于时间恢复基于时间点恢复是指当出现用户错误（例如误删除表、误截断表等）时，先使用restore database命令转储所有数据文件备份，再使用recover database命令将数据库恢复到用户错误点的状态，从而恢复用户数据。(有时需要结合LogMiner来确定误操作时间点)RMANrunstartup force mount;set until time=2011-05-22 22:03:00;restore database;recover databas

17、e;sql alter database open resetlogs;2、 基于SCN恢复RMANrunstartup force mount;set until scn=511927;restore database;recover database;sql alter database open resetlogs;3、 基于日志序列号恢复RMANrunstartup force mount;set until sequence=6;restore database;recover database;sql alter database open resetlogs;4、 基于备份控制文

18、件恢复RMANstartup force nomount;RMANset dbid=123456;RMANrestore controlfile form autobackup;RMANalter database mount;RMANrunset until time=2011-05-22 22:39:00;restore database;recover database;sql alter database open resetlogs;/恢复讹误的数据块(block media recovery,简写为BMR)当我们访问某个数据文件发现其出现数据块讹误时，例如如下错误消息：ORA-01

19、578：ORACLE data block corrupted (file # 19, block # 44)ORA-01110：data file 19: d:oracleoradatadatamydb_maintbs_01.dbf如果没有BMR，我们必须从一个备份中恢复这个数据文件，关键是在恢复过程中用户不能使用该数据文件中的数据，相反使用BMR只恢复讹误的数据块，这时需要使用blockrecover命令：blockrecover datafile 19 block 44;如果有必要，可以同时恢复多个数据文件中的多个数据块：blockrecover datafile 19 block 44

20、,66,127blockrecover datafile 19 block 44 datafile 22 block 203;/恢复到以前的Incarnation我们可能面临到的一种情况是：需要使用上次执行resetlogs命令打开数据库前生成的一个备份来还原数据库，或者可能需要还原到执行上一个resetlogs命令之前的时间点。这种恢复在是否使用来恢复目录时存在差别，原因很显然：恢复目录能够永久（至少是长时间）保存控制文件和备份信息，当然也就包括来所记录的各个版本的Incarnation；而仅使用控制文件时，我们看到的控制文件肯定是当前的版本，有可能稍早的备份或者Incarnation信息已

21、经被覆盖，所以要恢复当前控制文件中已经没有的Incarnation，则首先需要从备份中还原出包含相应Incarnation的控制文件。前提假设：并且最近使用resetlogs命令执行过时间点恢复。现在需要使用执行resetlogs命令之前一个备份来恢复数据库。1、 使用恢复目录恢复前一个IncarnationRMANlist incarnation;List of Database IncarnationsDB Key Inc key DB Name DB ID CUR Reset SCN Reset Time- - - - - - - -1 2 RECOVER 2539725638 NO 7

22、63059 08-JUL-021 123 RECOVER 2539725638 YES 764905 09-JUL-02RMANstartup force nomount;RMANreset database to incarnation 2;database reset to incarnation 2 in recovery catalogRMANrestore controlfile;Finished restore at 10-JUL-02RMANalter database mount;database mountedRMANrestore database until scn 76

23、4904;Finished restore at 10-JUL-02RMAN recover database until scn 764904;starting media recoveryFinished restore at 10-JUL-02RMANalter database open resetlogs;new incarnation of database registerd in recovery catalogstarting full resync of recovery catalogfull resync completeRMANlist incarnation;Lis

24、t of Database IncarnationsDB Key Inc key DB Name DB ID CUR Reset SCN Reset Time- - - - - - - -1 2 RECOVER 2539725638 NO 763059 08-JUL-021 123 RECOVER 2539725638 NO 764905 09-JUL-021 245 RECOVER 2539725638 YES 764905 10-JUL-022、 不使用恢复目录恢复前一个IncarnationRMANlist incarnation of database;List of Database

25、 IncarnationsDB Key Inc key DB Name DB ID STATUS Reset SCN Reset Time- - - - - - - - -1 1 RECOVER 2539725638 PARENT 1 30-AUG-052 2 RECOVER 2539725638 PARENT 534907 03-OCT-053 3 RECOVER 2539725638 PARENT 3586765 04-FEB-064 4 RECOVER 2539725638 PARENT 3599781 05-FEB-065 5 RECOVER 2539725638 PARENT 371

26、5262 08-FEB-066 6 RECOVER 2539725638 CURRENT 4296046 20-FEB-06RMANshutdown immediate;RMANstartup mount;RMANreset database to incarnation 5;RMANrestore database until scn 4296041;RMANrecover database until scn 4296041;List of Database IncarnationsDB Key Inc key DB Name DB ID STATUS Reset SCN Reset Ti

27、me- - - - - - - - -1 1 RECOVER 2539725638 PARENT 1 30-AUG-052 2 RECOVER 2539725638 PARENT 534907 03-OCT-053 3 RECOVER 2539725638 PARENT 3586765 04-FEB-064 4 RECOVER 2539725638 PARENT 3599781 05-FEB-065 5 RECOVER 2539725638 CURRENT 3715262 08-FEB-066 6 RECOVER 2539725638 ORPHAN 4296046 20-FEB-06RMANa

28、lter database open resetlogs;List of Database IncarnationsDB Key Inc key DB Name DB ID STATUS Reset SCN Reset Time- - - - - - - - -1 1 RECOVER 2539725638 PARENT 1 30-AUG-052 2 RECOVER 2539725638 PARENT 534907 03-OCT-053 3 RECOVER 2539725638 PARENT 3586765 04-FEB-064 4 RECOVER 2539725638 PARENT 3599781 05-FEB-065 5 RECOVER 2539725638 PARENT 3715262 08-FEB-066 6 RECOVER 2539725638 PARENT 4296046 20-FEB-067 7 RECOVER 2539725638 CURRENT 4296046 20-FEB-06