手工不完全恢复

不完全恢复的特点

1. 让整个database回到过去的某个时间点；

不能跳过坏日志而继续恢复所有的其它工作，前滚没有这个功能。

必须以sysdba身份连接进行不完全恢复

语句只有recover database until这种形式，表示让数据库回到某个时间点或SCN，until是指恢复在时间点前停止

不完全恢复的适用环境

1. 在过去某个时间点重要的数据被破坏。

在做完全恢复时，丢失了归档日志和online redo log

误删了表空间(有控制文件备份)

丢失了所有的控制文件，使用备份的控制文件

不完全恢复的基本类型

1. 基于时间点(until time)

基于scn(until change)

基于cancel(until cancel)--恢复到归档日志或当前日志的断点前

基于误删除表空间(使用备份的控制文件)--恢复到误删除表空间前

传统的不完全恢复的操作步骤

1. 通过logmnr找到误删除的时间点

对现在的database做新全备(datafile、当前controlfile)

还原该时间点所有的datafile

以当前控制文件进入mount状态，对database做recover，恢复到误操作时间点

将恢复出来的table做逻辑备份(exp)

将新库还原

将导出的表导入database(imp)

logminer工具的使用

对redo log进行挖掘，找出某时间点所做DDL或DML操作(时间点、scn、sql语句)

DML

alter system set utl_file_dir='/opt/oracle/app/utl' scope=spfile;

SQL> show parameter utl

NAME TYPE VALUE

------------------------------------ ----------- ------------------------------

create_stored_outlines string

utl_file_dir string /opt/oracle/app/utl

execute dbms_logmnr.add_logfile(logfilename=>'/opt/oracle/app/fast_recovery_area/TEST/archivelog/2019_12_26/o1_mf_1_42_h08lyxql_.arc',options=>dbms_logmnr.new);--添加日志文件

execute dbms_logmnr.start_logmnr(dictfilename=>'/opt/oracle/app/utl/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%';--查询

execute dbms_logmnr.add_logfile(logfilename=>'/opt/oracle/app/fast_recovery_area/TEST/archivelog/2019_12_26/o1_mf_1_43_h08lyxql_.arc',options=>dbms_logmnr.addfile);--如果还有其他文件，再添加即可

execute dbms_logmnr.end_logmnr;--关闭日志挖掘

例子

恢复过去某个时间点误操作的table

1. 环境

误删除test5表，并purge了 –purge不能回滚和恢复

drop table test.test5 purge;

多切几次日志，删除test5的归档日志为：

/opt/oracle/app/fast_recovery_area/TEST/archivelog/2019_12_26/o1_mf_1_42_h08lyxql_.arc

通过logmr找出误操作的ddl命令的timestamp或scn(日志挖掘logminer)

SQL> show parameter UTL_FILE

NAME TYPE VALUE

------------------------------------ ----------- ------------------------------

utl_file_dir string /opt/oracle/app/utl

execute dbms_logmnr_d.build('dict.ora','/opt/oracle/app/utl',dbms_logmnr_d.store_in_flat_file);--创建字典文件

execute dbms_logmnr.add_logfile(logfilename=>'/opt/oracle/app/fast_recovery_area/TEST/archivelog/2019_12_26/o1_mf_1_42_h08lyxql_.arc',options=>dbms_logmnr.new);--添加日志文件

execute dbms_logmnr.start_logmnr(dictfilename=>'/opt/oracle/app/utl/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%';--查询

execute dbms_logmnr.add_logfile(logfilename=>'/opt/oracle/app/fast_recovery_area/TEST/archivelog/2019_12_26/o1_mf_1_43_h08lyxql_.arc',options=>dbms_logmnr.addfile);--如果还有其他文件，再添加即可

execute dbms_logmnr.end_logmnr;--关闭日志挖掘

关闭数据库，删除所有dbf,做不完全恢复

shutdown abort-------rm *.dbf-----还原备份的数据文件cp

根据log miner提供的信息，做基于时间点的不完全恢复

SQL> shutdown abort

ORACLE instance shut down.

SQL> startup

ORACLE instance started.

Total System Global Area 801112064 bytes

Fixed Size 2929496 bytes

Variable Size 545262760 bytes

Database Buffers 247463936 bytes

Redo Buffers 5455872 bytes

Database mounted.

ORA-01113: file 1 needs media recovery

ORA-01110: data file 1: '/opt/oracle/app/oradata/test/system01.dbf'

SQL> recover database until time '2019-12-26 13:55:23';

ORA-00279: change 3285787 generated at 12/25/2019 13:59:52 needed for thread 1

ORA-00289: suggestion :

/opt/oracle/app/fast_recovery_area/TEST/archivelog/2019_12_25/o1_mf_1_40_h062vq36_.arc

ORA-00280: change 3285787 for thread 1 is in sequence #40

Specify log: {=suggested | filename | AUTO | CANCEL}

auto

ORA-00279: change 3487761 generated at 12/25/2019 15:10:46 needed for thread 1

ORA-00289: suggestion :

/opt/oracle/app/fast_recovery_area/TEST/archivelog/2019_12_25/o1_mf_1_41_h065xvq

k_.arc

ORA-00280: change 3487761 for thread 1 is in sequence #41

ORA-00279: change 3691324 generated at 12/25/2019 16:03:07 needed for thread 1

ORA-00289: suggestion :

/opt/oracle/app/fast_recovery_area/TEST/archivelog/2019_12_26/o1_mf_1_42_h08lyxq

l_.arc

ORA-00280: change 3691324 for thread 1 is in sequence #42

Log applied.

Media recovery complete.

恢复完成，日志sequence重置