一、完全恢复
1，通过备份、归档日志、current log，将database恢复到failure 前最后一次commit状态
2，恢复步骤：a) CP还原所有或部分datafile; b)利用归档日志和当前日志做恢复
3，手工恢复可基于三个级别：
recover database 包括system表空间损坏或大部分datafile丢失，一般在mount状态进行
recover tablespace 非关键表空间损坏，表空间下某些datafile不能访问，在open下完成
recover datafile 单一或少数数据文件损坏，可在mount或open状态完成
4，恢复过程可查看的视图
v$recover_file 查看需要恢复的datafile
v$recovery_log 查看recover需要的redo日志
v$archived_log 查看已经归档的日志
5，非归档模式下只能做全备的完整还原，还原后缺失联机日志文件（没备份），需要mount下
alter database clear logfile group 组号 重建日志
6，例：缺失关键性数据文件后启动报错
①select file#，error from v$recover_file；查看缺失的数据文件
②将备份的直接CP 回 缺失的数据文件所在目录
③recover database；-------alter database open；
例：缺失某表空间的数据文件
①select file#, checkpoint_change# from v$datafile_header; 可看出哪个数据文件丢失
②alter tablespace #NAME offline immediate; //使表空间立即脱机，不进行检查
③open 状态下 将备份的dbf文件 cp回数据文件存放的目录
④recover tablespace #NAME ;
⑤alter tablespace #NAME online;
例：recover datafile
① recover datafile 6,7；
二、不完全恢复
1, 不完全恢复的特点：
1) 必须停机，在mount下运行重做日志。
2) 必须以sysdba身份连接进行不完全恢复。
3) 让整个database 回到过去某个时间点，不能避免数据丢失。
2. 不完全恢复（Incomplete recover） 适用环境：
1）在过去的某个时间点重要的数据被破坏。
2）最小化备份测试。
3）在做完全恢复时，丢失了部分归档日志或当前online redo log（考点）
4）当误删除了表空间时（使用备份的控制文件）
3. 不完全恢复的基本类型：
1）基于时间点 （until time): 使整个数据库恢复到过去的一个时间点前
2）基于scn （until change）： 使整个数据库恢复到过去的某个SCN前
3）基于cancel (until cancel)： 使整个数据库恢复到归档日志或当前日志的断点前
4）基于误删除表空间（使用备份的controlfile）： 使整个数据库恢复到误删除表空间前
4. 使用不完全恢复的几个步骤
1）利用logminer 工具，找出在某个时间点所作的DDL 或DML 误操作（包括：时间点、scn 、sql语句）
2）做当前数据库的最新全备。
3）使用还原点前的备份还原数据文件，
4）运用日志恢复所有数据文件，前滚至需要的时间点前停止。
5）使用resetlogs方式打开数据库。
范例1: 恢复过去某个时间点误删除的table，基于时间点的不完全恢复
①select name from v$archived_log;查看归档日志，按时间 估计误操作所在的日志大概范围；
②show parameter utl;为utl_file_dir设置一个logmnr目录 alter system set utl_file_dir='/u01/logmnr' scope=spfile; 重启
③execute dbms_logmnr_d.build('dict.ora','/u01/logmnr',dbms_logmnr_d.store_in_flat_file);
execute dbms_logmnr.add_logfile(logfilename=>'归档日志目录/arch0_133.log',options=>dbms_logmnr.new);
//若可确定误操作是发生在这一个日志只需这句，若只知道大概范围需继续添加日志
execute dbms_logmnr.add_logfile(logfilename=>'/归档目录700_134.log',options=>dbms_logmnr.addfile);//可继续添加
execute dbms_logmnr.start_logmnr(dictfilename=>'/u01/logmnr/dict.ora',options=>dbms_logmnr.ddl_dict_tracking);
select username,scn,to_char(timestamp,'yyyy-mm-dd hh24:mi:ss'),sql_redo from v$logmnr_contents WHERE lower(sql_redo) like 'drop table%'; //可找到删除的语句，几下SCN 或time
execute dbms_logmnr.end_logmnr;
④alter system checkpoint ; ---->shutdown abort;
⑤删除误操作对应的数据文件，将误操作之前的数据文件还原至此
⑥更具log miner提供的信息，做基于SCN 或time 的恢复
startup ---->recover database until time '2012-08-01 17:28:29'(change 879464)------->根据提示输入auto
⑦alter database open resetlogs; //日志被重置了 可手动切两次 去除UNUSED状态
5，基于backup controlfile 的恢复
语法： recover database until [time|change] using backup controlfile;
until [time|change]是可选的，就是说如果条件满足，仍然可以做到完全恢复。
例一：当前控制文件全部损坏，而数据文件备份，控制文件备份及当前日志处于不同SCN版本，它们之间又增加过表空间（数据文件）
模式：所有数据文件备份（老）------(新建表空间test)-----备份控制文件（次新）------日志文件（新）
①alter system switch logfile;
②alter database backup controlfile to '/u01/oradata/orcl/con.bak';
③此时test数据文件损坏----->shutdown abort
④恢复数据文件的备份，恢复控制文件 cp con.bak control01.ctl ....
⑤startup----->select file#,checkpoint_change# from v$datafile;
recover database using backup controlfile;
⑥alter database create datafile '/u01/oradata/orcl/test01.dbf';
recover database using backup controlfile;//auto归档前滚结束，需恢复当前日志
recover database using backup controlfile;//输入filename当前日志路径恢复
⑦alter database open resetlogs;
例二：当前控制文件损坏，新建表空间在备份控制文件之后
模式：全备（老）-----备份控制文件（次新）-----新建表空间abcd------日志文件（新）
步骤和例一类似，创建datafile之前查看select file#,name,checkpoint_change# from v$datafile;
select file#, name, checkpoint_change# from v$datafile_header;
可看出 日志文件向控制文件写内容时 找不到数据文件 ，起了个别的名字；故在创建datafile时用下面语句
alter database create datafile '/用v$datafile查到的那么路径名‘ as '/u01/oradata/orcl/test01.dbf';
1，通过备份、归档日志、current log，将database恢复到failure 前最后一次commit状态
2，恢复步骤：a) CP还原所有或部分datafile; b)利用归档日志和当前日志做恢复
3，手工恢复可基于三个级别：
recover database 包括system表空间损坏或大部分datafile丢失，一般在mount状态进行
recover tablespace 非关键表空间损坏，表空间下某些datafile不能访问，在open下完成
recover datafile 单一或少数数据文件损坏，可在mount或open状态完成
4，恢复过程可查看的视图
v$recover_file 查看需要恢复的datafile
v$recovery_log 查看recover需要的redo日志
v$archived_log 查看已经归档的日志
5，非归档模式下只能做全备的完整还原，还原后缺失联机日志文件（没备份），需要mount下
alter database clear logfile group 组号 重建日志
6，例：缺失关键性数据文件后启动报错
①select file#，error from v$recover_file；查看缺失的数据文件
②将备份的直接CP 回 缺失的数据文件所在目录
③recover database；-------alter database open；
例：缺失某表空间的数据文件
①select file#, checkpoint_change# from v$datafile_header; 可看出哪个数据文件丢失
②alter tablespace #NAME offline immediate; //使表空间立即脱机，不进行检查
③open 状态下 将备份的dbf文件 cp回数据文件存放的目录
④recover tablespace #NAME ;
⑤alter tablespace #NAME online;
例：recover datafile
① recover datafile 6,7；
二、不完全恢复
1, 不完全恢复的特点：
1) 必须停机，在mount下运行重做日志。
2) 必须以sysdba身份连接进行不完全恢复。
3) 让整个database 回到过去某个时间点，不能避免数据丢失。
2. 不完全恢复（Incomplete recover） 适用环境：
1）在过去的某个时间点重要的数据被破坏。
2）最小化备份测试。
3）在做完全恢复时，丢失了部分归档日志或当前online redo log（考点）
4）当误删除了表空间时（使用备份的控制文件）
3. 不完全恢复的基本类型：
1）基于时间点 （until time): 使整个数据库恢复到过去的一个时间点前
2）基于scn （until change）： 使整个数据库恢复到过去的某个SCN前
3）基于cancel (until cancel)： 使整个数据库恢复到归档日志或当前日志的断点前
4）基于误删除表空间（使用备份的controlfile）： 使整个数据库恢复到误删除表空间前
4. 使用不完全恢复的几个步骤
1）利用logminer 工具，找出在某个时间点所作的DDL 或DML 误操作（包括：时间点、scn 、sql语句）
2）做当前数据库的最新全备。
3）使用还原点前的备份还原数据文件，
4）运用日志恢复所有数据文件，前滚至需要的时间点前停止。
5）使用resetlogs方式打开数据库。
范例1: 恢复过去某个时间点误删除的table，基于时间点的不完全恢复
①select name from v$archived_log;查看归档日志，按时间 估计误操作所在的日志大概范围；
②show parameter utl;为utl_file_dir设置一个logmnr目录 alter system set utl_file_dir='/u01/logmnr' scope=spfile; 重启
③execute dbms_logmnr_d.build('dict.ora','/u01/logmnr',dbms_logmnr_d.store_in_flat_file);
execute dbms_logmnr.add_logfile(logfilename=>'归档日志目录/arch0_133.log',options=>dbms_logmnr.new);
//若可确定误操作是发生在这一个日志只需这句，若只知道大概范围需继续添加日志
execute dbms_logmnr.add_logfile(logfilename=>'/归档目录700_134.log',options=>dbms_logmnr.addfile);//可继续添加
execute dbms_logmnr.start_logmnr(dictfilename=>'/u01/logmnr/dict.ora',options=>dbms_logmnr.ddl_dict_tracking);
select username,scn,to_char(timestamp,'yyyy-mm-dd hh24:mi:ss'),sql_redo from v$logmnr_contents WHERE lower(sql_redo) like 'drop table%'; //可找到删除的语句，几下SCN 或time
execute dbms_logmnr.end_logmnr;
④alter system checkpoint ; ---->shutdown abort;
⑤删除误操作对应的数据文件，将误操作之前的数据文件还原至此
⑥更具log miner提供的信息，做基于SCN 或time 的恢复
startup ---->recover database until time '2012-08-01 17:28:29'(change 879464)------->根据提示输入auto
⑦alter database open resetlogs; //日志被重置了 可手动切两次 去除UNUSED状态
5，基于backup controlfile 的恢复
语法： recover database until [time|change] using backup controlfile;
until [time|change]是可选的，就是说如果条件满足，仍然可以做到完全恢复。
例一：当前控制文件全部损坏，而数据文件备份，控制文件备份及当前日志处于不同SCN版本，它们之间又增加过表空间（数据文件）
模式：所有数据文件备份（老）------(新建表空间test)-----备份控制文件（次新）------日志文件（新）
①alter system switch logfile;
②alter database backup controlfile to '/u01/oradata/orcl/con.bak';
③此时test数据文件损坏----->shutdown abort
④恢复数据文件的备份，恢复控制文件 cp con.bak control01.ctl ....
⑤startup----->select file#,checkpoint_change# from v$datafile;
recover database using backup controlfile;
⑥alter database create datafile '/u01/oradata/orcl/test01.dbf';
recover database using backup controlfile;//auto归档前滚结束，需恢复当前日志
recover database using backup controlfile;//输入filename当前日志路径恢复
⑦alter database open resetlogs;
例二：当前控制文件损坏，新建表空间在备份控制文件之后
模式：全备（老）-----备份控制文件（次新）-----新建表空间abcd------日志文件（新）
步骤和例一类似，创建datafile之前查看select file#,name,checkpoint_change# from v$datafile;
select file#, name, checkpoint_change# from v$datafile_header;
可看出 日志文件向控制文件写内容时 找不到数据文件 ，起了个别的名字；故在创建datafile时用下面语句
alter database create datafile '/用v$datafile查到的那么路径名‘ as '/u01/oradata/orcl/test01.dbf';
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/28275505/viewspace-1816439/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/28275505/viewspace-1816439/
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
