rman恢复:数据文件丢失,控制文件丢失,联机日志文件丢失(非当前使用与当前使用)...

rman恢复示例                                                             以下操作均参考了君三思大仙的书——涂抹oracle

归档模式有备份,丢失数据文件的恢复
1.创建全库备份
rman>backup database;
2.构造数据

3.模拟文件丢失
关闭数据库shutdown immediate后(不关闭无法删除数据文件,因为被db锁定),残忍的删除user01.dbf数据文件. 

4.尝试打开数据库,未遂

5.执行恢复
另开窗口登录,输入restore datafile 4;

继续整

查找一下刚才创建的测试数据:一切都恢复正常了,你微微一笑(因为是测试,你不紧张,换生产数据库基本就吓尿了)


附送一个SQL来查询表空间及其关联的数据文件:(来自君三思大仙儿,以上很多的资料和例子都来自君三思大仙儿的说)

select ts.tablespace_name,df.file_name,df.file_id,df.status from dba_tablespaces ts,
    (select tablespace_name,file_id,file_name,status from dba_data_files
        union all
     select tablespace_name,file_id,file_name,status rom dba_temp_files) df
where ts.tablespace_name = df.tablespace_name


其中file_id为1的有俩,有点意思,暂不知道为啥




归档模式无备份,丢失数据文件的恢复(归档不备份,作死的节奏)
并不是所有数据文件丢失都能够被恢复,同样也不是所有数据文件丢失都需要恢复,比如system表空间数据文件丢失或损坏,除非借助备份,否则无法直接恢复.如果是临时表空间的数据文件丢了,就没啥大事——重建一个即可,因为它是临时的.

1.创建演示环境


sql>create user weiye identified by weiye default tablespace bobtest quota unlimited on bobtest;
sql>grant connect,resource to weiye;
sql>grant create session to weiye
sql>grant create table to weiye
sql>conn weiye/weiye
新建个表并insert几条数据


2.模拟文件丢失
关闭数据库手动删除数据文件bobtest,重启数据库,如下报错

3.执行修复
首先要通过alter database create datafile命令重建一个该文件,可指定新路径.
sql>alter database create datafile 'D:\oracle\product\10.2.0\oradata\bob\bobtest01.dbf' as 'D:\oracle\product\10.2.0\oradata\bob\bobtest01.dbf';
然后再
sql>recover datafile 8;
sql>alter database open;





期间我演示失败,因为我用现有的老早建立的表空间bobtest来做演示,随后在恢复的过程中,建立同名数据文件时报错

如上的演示成功的关键是:从创建时间起所有的重做日志都在!老早前的bobtest建立的归档早就没了,导致初次演示不成功.

最后重新建立新的表空间,建立新用户,建立新表,由这些新生成的信息来验证上面的演示.

如上的演示成功的关键是:从创建时间起所有的重做日志都在!
重建数据文件后,通过recover命令应用所有的重做日志文件的方式,重建该数据文件中的内容.

这次修复并没用rman,属于"用户管理的备份和恢复",某些特殊情况下,用户管理的备份和恢复还是有点优势的.
如果想用rman处理如上问题:
rman>restore datafile 8;
默认情况下restore会将数据文件修复到原来位置,如想恢复到其他位置,用set
rman>recover datafile 8;
rman>alter database open;



丢失控制文件的恢复
nocatalog模式下,rman创建的备份都在目标数据库的控制文件中,一旦控制文件丢失,不仅目标数据库崩溃,rman的备份信息也丢失,这种情况下,有控制文件备份,还有救(没有也有点希望:写脚本创建控制文件)

恢复控制文件之前,必须知道目标数据库的DBID(本人的是13834161)

关闭数据库,然后删除控制文件(作死,facebook),控制文件丢了,也就能nomount了
sql>startup nomount
另开窗口连到rman并指定dbid
>rman target /
rman>set dbid=13834161
之前创建的备份都是nocatalog模式进行的,控制文件丢失,一切配置都没了,show all一下:都恢复成了默认值

显式指定控制文件备份集的方式恢复控制文件:
rman>restore controlfile from 'D:\oracle\bobbackup\BOB_30_%P_C-13834161-20131230-14';
--指定控制文件,要找个新一点的控制文件,如果没指定to字句,控制文件会被恢复到初始化参数control_files指定的路径下

rman>alter database mount;
rman>recover database;
rman>alter database open resetlogs;--由于是通过备份的控制文件恢复,必须指定resetlogs


丢失联机重做日志文件的恢复
联机日志正常情况下都有冗余,丢了一个问题不大.

丢失非当前的联机重做日志文件
sql>shutdown immediate
删除online redo日志组2——REDO02.LOG,REDO02A.LOG
sql>startup

sql>alter database clear logfile group 2;
sql>alter database open;
非当前联机日志损坏不一定导致数据库崩溃,因为非当前日志暂未用到,数据库还能正常运行,但早晚会切到损坏日志组,此时文件无法访问而导致报错.


丢失当前的联机重做日志文件(测试时我心里都有些突突)
当前联机重做日志丢失,有备份也会丢失数据.

模拟文件丢失
sql>shutdown abort
sql>startup mount;--同时删除日志组4的文件
sql>alter database open;

尝试直接修复联机重做日志文件
sql>alter database clear logfile group 4;

根据错误可知,丢失的重做日志文件中包含必备的重做信息,无法被clear

执行不完全恢复
归档模式而且有备份,正常情况下只丢失当前联机重做日志文件中的数据,如果没有备份,就只能强制恢复了,介绍一个
隐藏的初始化参数:
sql>alter system set "_allow_resetlogs_corruption"=true scope=spfile;
_allow_resetlogs_corruption是一个隐藏参数,设置该参数为true后,oracle在open时会跳过一些一致性的检查.

关闭并重启到mount状态:
sql>shutdown immediate
sql>startup mount
对数据库进行不完全恢复:
sql>recover database until cancel;
输入cancel
然后通过open resetlogs方式打开数据库:
sql>alter database open resetlogs;

善后处理:这种恢复方式比较极端,很有可能导致数据库中数据不一致.alter日志估计报很多错误,因此,一旦打开了建议马上通过export逻辑
导出的方式执行一次full export,然后新建数据库,再通过import导入之前导出的二进制文件.






































 


 

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

转载于:http://blog.itpub.net/25025926/viewspace-1065705/