归档模式下oracle如何手工进行不完全恢复实验（2）

1.不完全恢复的特点：
1）让整个 database 回到过去某个时间点，不能避免数据丢失。
2）想跳过坏日志而继续恢复所有其他工作是不可能的，前滚没有这个功能(考点）。
3）必须以 sysdba 身份连接进行不完全恢复，普通用户或 sysoper 都不行（考点）。
4）语句只有 recover database until 这种形式，表示整个数据库回到某个时间点或SCN，而 until 是指恢复在时间点前停止（考点）。
2.不完全恢复（Incomplete recover） 适用情况
1）在过去的某个时间点重要的数据被破坏。
2）在做完全恢复时，丢失了归档日志或当前 online redo log（考点）
3）当误删除了表空间时（有控制文件备份）
4）丢失了所有的控制文件，使用备份的控制文件恢复时（条件满足时可以完全恢复）
3.不完全恢复的基本类型：
1）基于时间点 （until time):    使整个数据库恢复到过去的一个时间点前
2）基于 scn （until change）：    使整个数据库恢复到过去的某个 SCN 前
2）基于 cancel (until cancel)：    使整个数据库恢复到归档日志或当前 日志的断点前
3）基于误删除表空间（使用备份的 controlfile）： 使整个数据库恢复到误删除表空间前

下面将针对第二种不完全恢复的类型进行练习：
1.对用户test下的表TEST_TAB（表空间为TEST_TS）进行实验

SQL>  select * from test.test_tab;
        ID
----------
         1
         2

SQL> insert into test.test_tab values (3);
SQL> commit;

2）模拟误删除表TEST_TAB，并 purge 

SQL>  drop table test.test_tab purge; 
SQL> select group#,sequence#,archived,status from v$log;
    GROUP#  SEQUENCE# ARCHIVED STATUS
---------- ---------- -------- ----------------
         1          1 YES      INACTIVE
         2          2 NO       CURRENT
         3          0 YES      UNUSED

SQL> alter system switch logfile;
SQL> /
SQL> /

[oracle@oracle 2018_09_29]$ cd /u01/app/oracle/flash_recovery_area/ORCL/archivelog/2018_09_29
[oracle@oracle 2018_09_29]$ ls
o1_mf_1_1_ftxldnsg_.arc  o1_mf_1_2_ftxoscn7_.arc  o1_mf_1_3_ftxosf3m_.arc  o1_mf_1_4_ftxosj9p_.arc

由此可知，删除语句记录于o1_mf_1_2_ftxoscn7_.arc归档日志文件中。
实验的原因，我们可以做此判断，现实中可能预估范围文件，逐一进行挖掘。

3）通过 logmr 找出误操作的 ddl 命令的 timestamp 或 san

SQL> show parameter utl_file_dir

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
utl_file_dir                         string

建立目录，用于日志挖掘

[oracle@oracle ORCL]$ cd /u01/app/oracle/flash_recovery_area/ORCL
[oracle@oracle ORCL]$ mkdir logmnr

SQL> alter system set utl_file_dir='/u01/app/oracle/flash_recovery_area/ORCL/logmnr' scope=spfile;

SQL> shutdown immediate ;
SQL> startup
SQL> show parameter utl_file_dir

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
utl_file_dir                         string      /u01/app/oracle/flash_recovery
                                                 _area/ORCL/logmnr

SQL> 下执行如下
execute dbms_logmnr_d.build('dict.ora','/u01/app/oracle/flash_recovery_area/ORCL/logmnr',dbms_logmnr_d.store_in_flat_file);
execute dbms_logmnr.add_logfile(logfilename=>'/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2018_09_29/o1_mf_1_1_ftxldnsg_.arc',options=>dbms_logmnr.new);
execute dbms_logmnr.add_logfile(logfilename=>'/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2018_09_29/o1_mf_1_2_ftxoscn7_.arc',options=>dbms_logmnr.addfile);
execute dbms_logmnr.start_logmnr(dictfilename=>'/u01/app/oracle/flash_recovery_area/ORCL/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%';
USERNAME                              SCN TO_CHAR(TIMESTAMP,'
------------------------------ ---------- -------------------
SQL_REDO
--------------------------------------------------------------------------------
UNKNOWN                           4114437 2018-09-29 09:34:52
drop table test.test_tab purge;

execute dbms_logmnr.end_logmnr;

4) 关闭数据库，删除所有 dbf，准备做不完全恢复
SQL>  shutdown abort

[oracle@oracle orcl]$ cd /u01/app/oracle/oradata/orcl
[oracle@oracle orcl]$ rm *.dbf

5）还原所有备份的数据文件
[oracle@oracle orcl]$ cp osbak2/*.dbf ./
6）根据 log miner 提供的信息，做基于时间点（2018-09-27 17:03:43）的不完全恢复

SQL> recover database until change 4114437

auto

7）resetlogs 方式打开数据库
SQL> alter database open resetlogs;

8）验证

SQL> select * from test.test_tab;

        ID
----------
         1
         3
         2

此时数据库整体已经不完全恢复到过去drop表之前的状态了，现实生中的情况可能不是这样使用的，现实中如果发现过去某个时间误删除了某个表，是先一致性关闭数据库，再做全备，然后按照上面的方法进行不完全恢复，再把误删除的表EXP出来的，进行最后完全备份恢复，恢复后再将先前EXP的表IMP，此时，其它用户或表的数据保持最新，误删除的表也恢复了正常。