我对Oracle RMAN恢复的理解.docx
《我对Oracle RMAN恢复的理解.docx》由会员分享，可在线阅读，更多相关《我对Oracle RMAN恢复的理解.docx（12页珍藏版）》请在冰豆网上搜索。
我对OracleRMAN恢复的理解
我对OracleRMAN恢复的理解
零散思路：
可能遇到的恢复情况：
因为数据库无法启动或正常使用需要恢复；
因为数据误删除或表空间、表的误删除等需要将数据库或其中某表空间、表或表中数据恢复到过去某时间点；
RMAN恢复原则：
恢复不外乎就是恢复如下一些文件：
数据文件（也有可能是表空间），控制文件，归档日志文件（见后面关于归档日志恢复部分），在线日志文件，初始化参数文件，
全库恢复需要在MOUNT状态下，
表空间或数据文件的恢复可以在OPEN状态下进行，
控制文件
归档日志文件
在线日志文件
初始化参数文件
常用的恢复命令：
//对数据库进行完全介质恢复
归档模式，控制文件、初始化参数文件、归档日志文件和重做日志文件都完好无损，其余数据文件全部丢失，可将数据库恢复到崩溃前那一刻的状态：
Rman>startupmount;
Rman>restoredatabase;
Rman>recoverdatabasedeletearchivelog;
Rman>alterdatabaseopen;
？
那以上情况下，非归档模式应如何处理？
这种情况下感觉应该有几种情况：
首先非归档模式下的备份只可能是一致性备份，而且非归档模式下没有归档日志，因此恢复时要考虑最近一次备份和数据库崩溃期间的在线日志文件是否都还在，如果在则直接执行restore和recover然后正常打开数据库即可，而如果在线日志文件已经部分或全部丢失，则首先restore最近一次备份，然后执行recoverdatabaseuntilcancel命令，据说此时该命令并不会执行任何恢复操作，只是提示控制文件不再使用原有重做日志，最后以resetlogs方式打开数据库。
在三思的书中，文字性提到了一种方法：
首先恢复之前备份的控制文件，然后执行restore和recover命令，最后以resetlogs方式打开数据库。
感觉这种方式很有道理而前一种思路似乎有问题：
前一种思路中实际是用当前的控制文件在进行恢复操作，而当前的控制文件很有可能有前次备份中所不具有的新加的数据文件，那么这样在备份的时候是不是会出问题呢？
以上都需要具体验证！
！
！
//恢复表空间和数据文件
mount或open状态都可
Tablespace:
Rman>sql‘altertablespacetbs1offlineimmediate’;
Rman>restoretablespacetbs1;
Rman>recovertablespacetbs1;
Rman>sql‘altertablespacetbs1online’;
Datafile:
Rman>sql‘alterdatabasedatafile9offline’;
Rman>restoredatafile9;
Rman>recoverdatafile9;
Rman>sql‘alterdatafile9online’;
或
Rman>setnewnamefordatafile3to‘f:
newlocationsysaux01.dbf’;
Rman>restoredatafile3;
Rman>switchdatafile3;
Rman>recoverdatafile3;
//恢复归档日志文件
特别：
三思告诉我们：
“恢复归档文件也是使用restore命令，如果只是为了在恢复数据文件后应用归档文件，那并不需要手动归档文件进行恢复，RMAN会在recover的时候自动对适当的归档进行恢复。
单独恢复归档文件一般是有特别的需求，如创建了DataGuard环境，Standy端丢失了部分归档文件，必须从Primary端重新获取等等。
”
//恢复控制文件
这里所说的恢复是指仅恢复控制文件本身，应该还有一种“基于控制文件的不完全恢复”，不知和这种情况是否相同（当所有控制文件全部丢失或者误删除了表空间时（闪回数据库能办到吗？
），需要执行控制文件的恢复）。
其实本身是一种解决方案下的多种情况：
情景1：
归档、有恢复目录、控制文件全部丢失或部分数据文件或表空间丢失
情景2：
归档、无恢复目录、控制文件全部丢失或部分数据文件或表空间丢失
前景3：
非归档、有恢复目录、控制文件全部丢失或部分数据文件或表空间丢失
情景4：
非归档、无恢复目录、控制文件全部丢失或部分数据文件或表空间丢失
1、从自动备份中恢复
Rman>setDBID=1415261003;
Rman>startupnomount;
Rman>restorecontrolfilefromautobackup;
Rman>alterdatabasemount;
（Rman>restorecontrolfileto‘d:
oraclenewctlfcontrolfile01.ctl’fromautobackup;恢复到指定位置）
Rman>recoverdatabase;
Rman>alterdatabaseopenresetlogs;
2、从备份集中恢复
Rman>setDBID=1415261003;
Rman>startupnomount;
Rman>restorecontrolfilefrom‘d:
backupc-1415261003-20110522-00’;
（Rman>restorecontrolfileto‘d:
oraclenewctlfcontrolfile01.ctl’fromautobackup;恢复到指定位置）
Rman>alterdatabasemount;
Rman>recoverdatabase;
Rman>alterdatabaseopenresetlogs;
//恢复初始化参数文件（方法基本与控制文件的恢复相同）
Rman>setDBID=1415261003;
Rman>startupnomount;
Rman>restorespfilefromautobackup;
Rman>alterdatabasemount;
Rman>recoverdatabase;
//恢复联机重做日志文件
0、查询联机日志状态情况
v$log中记录联机重做日志组的信息；
v$logfile中记录联机重做日志组对应的日志文件；
SQL>selectgroup#,thread#,sequence#,members,archived,statusfromv$log;
SQL>selectgroup#,memberfromv$logfile;
1、日志组中的某个日志成员损坏
多元化重做日志的目的就是为了防止日志成员的介质失败。
如果某个日志组的一个日志成员出现介质失败，那么数据库仍然可以正常工作。
首先查询：
SQL>selectmemberfromv$logfilewherestatus=’INVALID’;
然后使用alterdatabasedroplogfilemember命令删除该日志成员，注意，如果出现损坏的日志成员是当前日志组的日志成员，那么该日志成员将不能被删除，需要进行手工的切换：
SQL>altersystemswitchlogfile;
SQL>alterdatabasedroplogfilemember‘c:
orclredo01_2.log’;
在删除了日志成员之后，需要为该日志组添加新的日志成员，注意新增加的日志成员状态也为INVALID：
SQL>alterdatabaseaddlogfilemember‘c:
orclredo01_3.log’togroup1;
2、丢失非当前的联机重做日志文件
先查询出丢失的联机重做日志文件组及其包含的联机重做日志文件
然后修复：
SQL>alterdatabaseclearlogfilegroup1;
该命令重建该组重做日志文件即可。
特别！
在《精通Oracle10g备份与恢复》一书中关于此部分的介绍分类更细：
（1）、在OPEN状态下非活动日志组的所有日志成员全部损坏
出现此种情况，数据库仍然正常工作，只是当切换到该日志组时，因为其内容不能被归档，所以后台进程LGWR会处于等待状态。
为了使得后台进程LGWR可以继续工作，DBA应该清楚该日志组（我理解此种情景是针对归档模式而言的，非归档模式没得这种问题）：
SQL>alterdatabaseclearunarchivedlogfilegroup1;
（2）、在关闭状态下非活动日志组的所有日志成员全部损坏
新增加新的日志组，删除原有日志组，然后打开数据：
SQL>alterdatabaseaddlogfile（‘d:
orclredo04_1.log’,‘c:
orclredo04_2.log’）size10M;
SQL>alterdatabasedroplogfilegroup1;
SQL>alterdatabaseopen;
3、丢失当前的联机重做日志文件
此种情况下不能直接重建，而是应该执行不完全恢复
需要修改一个隐藏的初始化参数：
SQL>altersystemset“_ALLOW_RESETLOGS_CORRUPTION”=TRUESCOPE=SPFILE;
该参数设为TRUE时，Oracle在OPEN时会跳过一些一致性的检查。
特别！
在《精通Oracle10g备份与恢复》一书中关于此部分的介绍分类更细：
（1）、在OPEN状态下当前日志组的所有日志成员全部损坏
当数据库处于OPEN状态时，如果当前日志组的所有日志成员全部损坏，那么当后台进程LGWR将事物写入该日志组时，实例会被自动关闭，并报错。
出现这种情况下，需要执行不完全恢复：
RMAN>startupmount;
RMAN>restoredatabase;
RMAN>recoverdatabaseuntilcancel;
RMAN>alterdatabaseopenresetlogs;
（2）、在关闭状态下当前日志组的所有日志成员全部损坏
当在关闭状态下当前日志组出现损坏时，因为数据文件、控制文件都处于完全一致状态，所以DBA只需要执行基于CANCEL的不完全恢复即可：
RMAN>startupmount;
RMAN>recoverdatabaseuntilcancel;
RMAN>alterdatabaseopenresetlogs;
//RMAN不完全恢复
0、执行不完全恢复后，因为要以resetlogs方式打开数据库，而此时会重新建立重做日志，清空原有重做日志的内容（同时归档日志也全部删除了），而且过去的备份也不能直接使用了（但好像听说从OracleDatabase10g开始，Oracle提供了新的安全机制可以确保归档日志不会被覆盖，从而使得在恢复数据库时可以使用早期数据库副本的备份），因此强烈建议读者删除早期所有的备份，并重新备份数据库：
RMAN>run{
deletenopromptbackup;
deletenopromptcopy;
backupdatabaseformat=’d:
backup%d_%s.bak’;
sql‘altersystemarchivelogcurrent’;
}
1、基于时间恢复
基于时间点恢复是指当出现用户错误（例如误删除表、误截断表等）时，先使用restoredatabase命令转储所有数据文件备份，再使用recoverdatabase命令将数据库恢复到用户错误点的状态，从而恢复用户数据。
（有时需要结合LogMiner来确定误操作时间点）
RMAN>run{
startupforcemount;
setuntiltime=’2011-05-2222:
03:
00’;
restoredatabase;
recoverdatabase;
sql‘alterdatabaseopenresetlogs’;
}
2、基于SCN恢复
RMAN>run{
startupforcemount;
setuntilscn=511927;
restoredatabase;
recoverdatabase;
sql‘alterdatabaseopenresetlogs’;
}
3、基于日志序列号恢复
RMAN>run{
startupforcemount;
setuntilsequence=6;
restoredatabase;
recoverdatabase;
sql‘alterdatabaseopenresetlogs’;
}
4、基于备份控制文件恢复
RMAN>startupforcenomount;
RMAN>setdbid=123456;
RMAN>restorecontrolfileformautobackup;
RMAN>alterdatabasemount;
RMAN>run{
setuntiltime=’2011-05-2222:
39:
00’;
restoredatabase;
recoverdatabase;
sql‘alterdatabaseopenresetlogs’;
}
//恢复讹误的数据块（blockmediarecovery,简写为BMR）
当我们访问某个数据文件发现其出现数据块讹误时，例如如下错误消息：
ORA-01578：
ORACLEdatablockcorrupted（file#19,block#44）
ORA-01110：
datafile19:
‘d:
oracleoradatadatamydb_maintbs_01.dbf’
如果没有BMR，我们必须从一个备份中恢复这个数据文件，关键是在恢复过程中用户不能使用该数据文件中的数据，相反使用BMR只恢复讹误的数据块，这时需要使用blockrecover命令：
blockrecoverdatafile19block44;
如果有必要，可以同时恢复多个数据文件中的多个数据块：
blockrecoverdatafile19block44,66,127
blockrecoverdatafile19block44datafile22block203;
//恢复到以前的Incarnation
我们可能面临到的一种情况是：
需要使用上次执行resetlogs命令打开数据库前生成的一个备份来还原数据库，或者可能需要还原到执行上一个resetlogs命令之前的时间点。
这种恢复在是否使用来恢复目录时存在差别，原因很显然：
恢复目录能够永久（至少是长时间）保存控制文件和备份信息，当然也就包括来所记录的各个版本的Incarnation；而仅使用控制文件时，我们看到的控制文件肯定是当前的版本，有可能稍早的备份或者Incarnation信息已经被覆盖，所以要恢复当前控制文件中已经没有的Incarnation，则首先需要从备份中还原出包含相应Incarnation的控制文件。
前提假设：
并且最近使用resetlogs命令执行过时间点恢复。
现在需要使用执行resetlogs命令之前一个备份来恢复数据库。
1、使用恢复目录恢复前一个Incarnation
RMAN>listincarnation;
ListofDatabaseIncarnations
DBKeyInckeyDBNameDBIDCURResetSCNResetTime
-----------------------------------------------------------------------
12RECOVER2539725638NO76305908-JUL-02
1123RECOVER2539725638YES76490509-JUL-02
RMAN>startupforcenomount;
RMAN>resetdatabasetoincarnation2;
databaseresettoincarnation2inrecoverycatalog
RMAN>restorecontrolfile;
Finishedrestoreat10-JUL-02
RMAN>alterdatabasemount;
databasemounted
RMAN>restoredatabaseuntilscn764904;
Finishedrestoreat10-JUL-02
RMAN>recoverdatabaseuntilscn764904;
startingmediarecovery
……
Finishedrestoreat10-JUL-02
RMAN>alterdatabaseopenresetlogs;
newincarnationofdatabaseregisterdinrecoverycatalog
startingfullresyncofrecoverycatalog
fullresynccomplete
RMAN>listincarnation;
ListofDatabaseIncarnations
DBKeyInckeyDBNameDBIDCURResetSCNResetTime
-----------------------------------------------------------------------
12RECOVER2539725638NO76305908-JUL-02
1123RECOVER2539725638NO76490509-JUL-02
1245RECOVER2539725638YES76490510-JUL-02
2、不使用恢复目录恢复前一个Incarnation
RMAN>listincarnationofdatabase;
ListofDatabaseIncarnations
DBKeyInckeyDBNameDBIDSTATUSResetSCNResetTime
-------------------------------------------------------------------------------
11RECOVER2539725638PARENT130-AUG-05
22RECOVER2539725638PARENT53490703-OCT-05
33RECOVER2539725638PARENT358676504-FEB-06
44RECOVER2539725638PARENT359978105-FEB-06
55RECOVER2539725638PARENT371526208-FEB-06
66RECOVER2539725638CURRENT429604620-FEB-06
RMAN>shutdownimmediate;
RMAN>startupmount;
RMAN>resetdatabasetoincarnation5;
RMAN>restoredatabaseuntilscn4296041;
RMAN>recoverdatabaseuntilscn4296041;
ListofDatabaseIncarnations
DBKeyInckeyDBNameDBIDSTATUSResetSCNResetTime
-------------------------------------------------------------------------------
11RECOVER2539725638PARENT130-AUG-05
22RECOVER2539725638PARENT53490703-OCT-05
33RECOVER2539725638PARENT358676504-FEB-06
44RECOVER2539725638PARENT359978105-FEB-06
55RECOVER2539725638CURRENT371526208-FEB-06
66RECOVER2539725638ORPHAN429604620-FEB-06
RMAN>alterdatabaseopenresetlogs;
ListofDatabaseIncarnations
DBKeyInckeyDBNameDBIDSTATUSResetSCNResetTime
-------------------------------------------------------------------------------
11RECOVER2539725638PARENT130-AUG-05
22RECOVER2539725638PARENT53490703-OCT-05
33RECOVER2539725638PARENT358676504-FEB-06
44RECOVER2539725638PARENT359978105-FEB-06
55RECOVER2539725638PARENT371526208-FEB-06
66RECOVER2539725638PARENT429604620-FEB-06
77RECOVER2539725638CURRENT429604620-FEB-06
升级会员 