我对Oracle RMAN恢复的理解
我对Oracle RMAN恢复的理解
零散思路：
可能遇到的恢复情况：
因为数据库无法启动或正常使用需要恢复；
因为数据误删除或表空间、表的误删除等需要将数据库或其中某表空间、表或表中数据恢复到过去某时间点；
RMAN恢复原则：
恢复不外乎就是恢复如下一些文件：数据文件（也有可能是表空间），控制文件，归档日志文件（见后面关于归档日志恢复部分），在线日志文件，初始化参数文件，
全库恢复需要在MOUNT状态下，
表空间或数据文件的恢复可以在OPEN状态下进行，
控制文件
归档日志文件
在线日志文件
初始化参数文件
常用的恢复命令：
//对数据库进行完全介质恢复
归档模式，控制文件、初始化参数文件、归档日志文件和重做日志文件都完好无损，其余数据文件全部丢失，可将数据库恢复到崩溃前那一刻的状态：
Rman>startup mount;
Rman>restore database;
Rman>recover database delete archivelog;
Rman>alter database open;
？那以上情况下，非归档模式应如何处理？
这种情况下感觉应该有几种情况：首先非归档模式下的备份只可能是一致性备份，而且非归档模式下没有归档日志，因此恢复时要考虑最近一次备份和数据库崩溃期间的在线日志文件是否都还在，如果在则直接执行restore和recover然后正常打开数据库即可，而如果在线日志文件已经部分或全部丢失，则首先restore最近一次备份，然后执行recover database until cancel命令，据说此时该命令并不会执行任何恢复操作，只是提示控制文件不再使用原有重做日志，最后以resetlogs方式打开数据库。在三思的书中，文字性提到了一种方法：首先恢复之前备份的控制文件，然后执行restore和recover命令，最后以resetlogs方式打开数据库。感觉这种方式很有道理而前一种思路似乎有问题：前一种思路中实际是用当前的控制文件在进行恢复操作，而当前的控制文件很有可能有前次备份中所不具有的新加的数据文件，那么这样在备份的时候是不是会出问题呢？ 以上都需要具体验证！！！
//恢复表空间和数据文件
mount或open状态都可
Tablespace:
Rman>sql ‘alter tablespace tbs1 offline immediate’;
Rman>restore tablespace tbs1;
Rman>recover tablespace tbs1;
Rman>sql ‘alter tablespace tbs1 online’;
Datafile:
Rman>sql ‘alter database datafile 9 offline’;
Rman>restore datafile 9;
Rman>recover datafile 9;
Rman>sql ‘alter datafile 9 online’;
或
Rman>set newname for datafile 3 to ‘f:newlocationsysaux01.dbf’;
Rman>restore datafile 3;
Rman>switch datafile 3;
Rman>recover datafile 3;
//恢复归档日志文件
特别：三思告诉我们：“恢复归档文件也是使用restore命令，如果只是为了在恢复数据文件后应用归档文件，那并不需要手动归档文件进行恢复，RMAN会在recover的时候自动对适当的归档进行恢复。单独恢复归档文件一般是有特别的需求，如创建了Data Guard环境，Standy端丢失了部分归档文件，必须从Primary端重新获取等等。”
//恢复控制文件
这里所说的恢复是指仅恢复控制文件本身，应该还有一种“基于控制文件的不完全恢复”，不知和这种情况是否相同（当所有控制文件全部丢失或者误删除了表空间时（闪回数据库能办到吗？），需要执行控制文件的恢复）。其实本身是一种解决方案下的多种情况：
情景1：归档、有恢复目录、控制文件全部丢失或部分数据文件或表空间丢失
情景2：归档、无恢复目录、控制文件全部丢失或部分数据文件或表空间丢失
前景3：非归档、有恢复目录、控制文件全部丢失或部分数据文件或表空间丢失
情景4：非归档、无恢复目录、控制文件全部丢失或部分数据文件或表空间丢失
1、 从自动备份中恢复
Rman>set DBID=1415261003;
Rman>startup nomount;
Rman>restore controlfile from autobackup;
Rman>alter database mount;
(Rman>restore controlfile to ‘d:oraclenewctlfcontrolfile01.ctl’ from autobackup;恢复到指定位置)
Rman>recover database;
Rman>alter database open resetlogs;
2、 从备份集中恢复
Rman>set DBID=1415261003;
Rman>startup nomount;
Rman>restore controlfile from ‘d:backupc-1415261003-20110522-00’;
(Rman>restore controlfile to ‘d:oraclenewctlfcontrolfile01.ctl’ from autobackup;恢复到指定位置)
Rman>alter database mount;
Rman>recover database;
Rman>alter database open resetlogs;
//恢复初始化参数文件(方法基本与控制文件的恢复相同)
Rman> set DBID=1415261003;
Rman>startup nomount;
Rman>restore spfile from autobackup;
Rman>alter database mount;
Rman>recover database;
//恢复联机重做日志文件
0、 查询联机日志状态情况
v$log中记录联机重做日志组的信息；
v$logfile中记录联机重做日志组对应的日志文件；
SQL>select group#, thread#, sequence#, members, archived, status from v$log;
SQL>select group#, member from v$logfile;
1、 日志组中的某个日志成员损坏
多元化重做日志的目的就是为了防止日志成员的介质失败。如果某个日志组的一个日志成员出现介质失败，那么数据库仍然可以正常工作。
首先查询：SQL>select member from v$logfile where status=’INVALID’;
然后使用alter database drop logfile member命令删除该日志成员，注意，如果出现损坏的日志成员是当前日志组的日志成员，那么该日志成员将不能被删除，需要进行手工的切换：
SQL>alter system switch logfile;
SQL>alter database drop logfile member ‘c:orclredo01_2.log’;
在删除了日志成员之后，需要为该日志组添加新的日志成员，注意新增加的日志成员状态也为INVALID：
SQL>alter database add logfile member ‘c:orclredo01_3.log’ to group 1;
2、 丢失非当前的联机重做日志文件
先查询出丢失的联机重做日志文件组及其包含的联机重做日志文件
然后修复：
SQL>alter database clear logfile group 1;
该命令重建该组重做日志文件即可。
特别！在《精通Oracle 10g备份与恢复》一书中关于此部分的介绍分类更细：
(1)、在OPEN状态下非活动日志组的所有日志成员全部损坏
出现此种情况，数据库仍然正常工作，只是当切换到该日志组时，因为其内容不能被归档，所以后台进程LGWR会处于等待状态。为了使得后台进程LGWR可以继续工作，DBA应该清楚该日志组(我理解此种情景是针对归档模式而言的，非归档模式没得这种问题)：
SQL>alter database clear unarchived logfile group 1;
(2)、在关闭状态下非活动日志组的所有日志成员全部损坏
新增加新的日志组，删除原有日志组，然后打开数据：
SQL>alter database add logfile (‘d:orclredo04_1.log’, ‘c:orclredo04_2.log’) size 10M;
SQL>alter database drop logfile group 1;
SQL>alter database open;
3、 丢失当前的联机重做日志文件
此种情况下不能直接重建，而是应该执行不完全恢复
需要修改一个隐藏的初始化参数：
SQL>alter system set “_ALLOW_RESETLOGS_CORRUPTION”=TRUE SCOPE=SPFILE;
该参数设为TRUE时，Oracle在OPEN时会跳过一些一致性的检查。
特别！在《精通Oracle 10g备份与恢复》一书中关于此部分的介绍分类更细：
(1)、在OPEN状态下当前日志组的所有日志成员全部损坏
当数据库处于OPEN状态时，如果当前日志组的所有日志成员全部损坏，那么当后台进程LGWR将事物写入该日志组时，实例会被自动关闭，并报错。出现这种情况下，需要执行不完全恢复：
RMAN>startup mount;
RMAN>restore database;
RMAN>recover database until cancel;
RMAN>alter database open resetlogs;
(2)、在关闭状态下当前日志组的所有日志成员全部损坏
当在关闭状态下当前日志组出现损坏时，因为数据文件、控制文件都处于完全一致状态，所以DBA只需要执行基于CANCEL的不完全恢复即可：
RMAN>startup mount;
RMAN>recover database until cancel;
RMAN>alter database open resetlogs;
//RMAN不完全恢复
0、 执行不完全恢复后，因为要以resetlogs方式打开数据库，而此时会重新建立重做日志，清空原有重做日志的内容（同时归档日志也全部删除了），而且过去的备份也不能直接使用了（但好像听说从Oracle Database 10g开始，Oracle提供了新的安全机制可以确保归档日志不会被覆盖，从而使得在恢复数据库时可以使用早期数据库副本的备份），因此强烈建议读者删除早期所有的备份，并重新备份数据库：
RMAN>run{
delete noprompt backup;
delete noprompt copy;
backup database format=’d:backup%d_%s.bak’;
sql ‘alter system archive log current’;
}
1、 基于时间恢复
基于时间点恢复是指当出现用户错误（例如误删除表、误截断表等）时，先使用restore database命令转储所有数据文件备份，再使用recover database命令将数据库恢复到用户错误点的状态，从而恢复用户数据。(有时需要结合LogMiner来确定误操作时间点)
RMAN>run{
startup force mount;
set until time=’2011-05-22 22:03:00’;
restore database;
recover database;
sql ‘alter database open resetlogs’;
}
2、 基于SCN恢复
RMAN>run{
startup force mount;
set until scn=511927;
restore database;
recover database;
sql ‘alter database open resetlogs’;
}
3、 基于日志序列号恢复
RMAN>run{
startup force mount;
set until sequence=6;
restore database;
recover database;
sql ‘alter database open resetlogs’;
}
4、 基于备份控制文件恢复
RMAN>startup force nomount;
RMAN>set dbid=123456;
RMAN>restore controlfile form autobackup;
RMAN>alter database mount;
RMAN>run{
set until time=’2011-05-22 22:39:00’;
restore database;
recover database;
sql ‘alter database open resetlogs’;
}
//恢复讹误的数据块(block media recovery,简写为BMR)
当我们访问某个数据文件发现其出现数据块讹误时，例如如下错误消息：
ORA-01578：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,66,127
blockrecover datafile 19 block 44 datafile 22 block 203;
//恢复到以前的Incarnation
我们可能面临到的一种情况是：需要使用上次执行resetlogs命令打开数据库前生成的一个备份来还原数据库，或者可能需要还原到执行上一个resetlogs命令之前的时间点。
这种恢复在是否使用来恢复目录时存在差别，原因很显然：恢复目录能够永久（至少是长时间）保存控制文件和备份信息，当然也就包括来所记录的各个版本的Incarnation；而仅使用控制文件时，我们看到的控制文件肯定是当前的版本，有可能稍早的备份或者Incarnation信息已经被覆盖，所以要恢复当前控制文件中已经没有的Incarnation，则首先需要从备份中还原出包含相应Incarnation的控制文件。
前提假设：并且最近使用resetlogs命令执行过时间点恢复。现在需要使用执行resetlogs命令之前一个备份来恢复数据库。
1、 使用恢复目录恢复前一个Incarnation
RMAN>list incarnation;
List of Database Incarnations
DB Key Inc key DB Name DB ID CUR Reset SCN Reset Time
-------- -------- ------------ ------ ------ ----- ------------ --------------
1 2 RECOVER 2539725638 NO 763059 08-JUL-02
1 123 RECOVER 2539725638 YES 764905 09-JUL-02
RMAN>startup force nomount;
RMAN>reset database to incarnation 2;
database reset to incarnation 2 in recovery catalog
RMAN>restore controlfile;
Finished restore at 10-JUL-02
RMAN>alter database mount;
database mounted
RMAN>restore database until scn 764904;
Finished restore at 10-JUL-02
RMAN> recover database until scn 764904;
starting media recovery
……
Finished restore at 10-JUL-02
RMAN>alter database open resetlogs;
new incarnation of database registerd in recovery catalog
starting full resync of recovery catalog
full resync complete
RMAN>list incarnation;
List of Database Incarnations
DB Key Inc key DB Name DB ID CUR Reset SCN Reset Time
-------- -------- ------------ ------ ------ ----- ------------ --------------
1 2 RECOVER 2539725638 NO 763059 08-JUL-02
1 123 RECOVER 2539725638 NO 764905 09-JUL-02
1 245 RECOVER 2539725638 YES 764905 10-JUL-02
2、 不使用恢复目录恢复前一个Incarnation
RMAN>list incarnation of database;
List of Database Incarnations
DB Key Inc key DB Name DB ID STATUS Reset SCN Reset Time
-------- -------- ------------ ------ ------ --- ---------- ------------ --------------
1 1 RECOVER 2539725638 PARENT 1 30-AUG-05
2 2 RECOVER 2539725638 PARENT 534907 03-OCT-05
3 3 RECOVER 2539725638 PARENT 3586765 04-FEB-06
4 4 RECOVER 2539725638 PARENT 3599781 05-FEB-06
5 5 RECOVER 2539725638 PARENT 3715262 08-FEB-06
6 6 RECOVER 2539725638 CURRENT 4296046 20-FEB-06
RMAN>shutdown immediate;
RMAN>startup mount;
RMAN>reset database to incarnation 5;
RMAN>restore database until scn 4296041;
RMAN>recover database until scn 4296041;
List of Database Incarnations
DB Key Inc key DB Name DB ID STATUS Reset SCN Reset Time
-------- -------- ------------ ------ ------ --- ---------- ------------ --------------
1 1 RECOVER 2539725638 PARENT 1 30-AUG-05
2 2 RECOVER 2539725638 PARENT 534907 03-OCT-05
3 3 RECOVER 2539725638 PARENT 3586765 04-FEB-06
4 4 RECOVER 2539725638 PARENT 3599781 05-FEB-06
5 5 RECOVER 2539725638 CURRENT 3715262 08-FEB-06
6 6 RECOVER 2539725638 ORPHAN 4296046 20-FEB-06
RMAN>alter database open resetlogs;
List of Database Incarnations
DB Key Inc key DB Name DB ID STATUS Reset SCN Reset Time
-------- -------- ------------ ------ ------ --- ---------- ------------ --------------
1 1 RECOVER 2539725638 PARENT 1 30-AUG-05
2 2 RECOVER 2539725638 PARENT 534907 03-OCT-05
3 3 RECOVER 2539725638 PARENT 3586765 04-FEB-06
4 4 RECOVER 2539725638 PARENT 3599781 05-FEB-06
5 5 RECOVER 2539725638 PARENT 3715262 08-FEB-06
6 6 RECOVER 2539725638 PARENT 4296046 20-FEB-06
7 7 RECOVER 2539725638 CURRENT 4296046 20-FEB-06
[@more@]来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/14338195/viewspace-1052467/ ，如需转载，请注明出处，否则将追究法律责任。
