ORACLE手工不完全恢复

4.1 不完全恢复的特点：     
      1）让整个database 回到过去某个时间点，不能避免数据丢失。
      2）想跳过坏日志而继续恢复所有其他工作是不可能的，前滚没有这个功能(注意点）。
      3）必须以sysdba身份连接进行不完全恢复，普通用户或sysoper都不行（注意点）。
      4）语句只有recover database until 这种形式，表示整个数据库回到某个时间点或SCN，而until是指恢复在时间点前停止（注意点）。


4.2 不完全恢复（Incomplete recover） 适用环境：
       1）在过去的某个时间点重要的数据被破坏。
       2）在做完全恢复时，丢失了归档日志或当前online redo log（注意点）
       3）当误删除了表空间时（有控制文件备份）
       4）丢失了所有的控制文件，使用备份的控制文件恢复时  （条件满足时可以完全恢复）     
        
4.3 不完全恢复的基本类型：
      1）基于时间点 （until time): 使整个数据库恢复到过去的一个时间点前
      2）基于scn （until change）： 使整个数据库恢复到过去的某个SCN前
      3）基于cancel (until cancel)： 使整个数据库恢复到归档日志或当前日志的断点前
      4）基于误删除表空间（使用备份的controlfile）： 使整个数据库恢复到误删除表空间前
      
4.4、logminer 工具的使用
     
     对redo log 进行挖掘，找出在某个时间点所作的DDL 或DML 误操作（包括：时间点、scn 、sql语句）
                                                                                            
4.5 不完全恢复范例：


范例1:


恢复过去某个时间点误删除的table


4.5.1 基于时间点的不完全恢复


1）环境：scott用户在test表空间下有个t1表


SQL> conn scott/scott
SQL> select * from t1;


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


2）误删除了t1表，并purge了。


SQL> drop table t1 purge;
SQL> select * from v$log;
 
    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARCHIVED STATUS           FIRST_CHANGE# FIRST_TIME
---------- ---------- ---------- ---------- ---------- -------- ---------------- ------------- -----------
         1          1        131   52428800          1 YES     INACTIVE               1875893 2012-6-13 1
         2          1        132   52428800          1 YES     INACTIVE               1896385 2012-6-13 1
         3          1        133   52428800          1 NO       CURRENT                1916973 2012-7-18 1 


SQL> alter system switch logfile;
SQL> /
SQL> /
 
SQL> select name from v$archived_log;


NAME
--------------------------------------------------------------------------------
...
/u01/disk1/timran/arch_1_782662700_129.log
/u01/disk1/timran/arch_1_782662700_130.log
/u01/disk1/timran/arch_1_782662700_131.log
/u01/disk1/timran/arch_1_782662700_132.log
/u01/disk1/timran/arch_1_782662700_133.log //drop table t1 purge这个动作的日志条目记录在此归档日志里了。
/u01/disk1/timran/arch_1_782662700_134.log
/u01/disk1/timran/arch_1_782662700_135.log
 
116 rows selected


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


SQL> show parameter utl


NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
create_stored_outlines           string
utl_file_dir                         string      /home/oracle/logmnr


SQL> execute dbms_logmnr_d.build('dict.ora','/home/oracle/logmnr',dbms_logmnr_d.store_in_flat_file); 
 
SQL> execute dbms_logmnr.add_logfile(logfilename=>'/u01/disk1/timran/arch_1_782662700_133.log',options=>dbms_logmnr.new);
 
SQL> execute dbms_logmnr.add_logfile(logfilename=>'/u01/disk1/timran/arch_1_782662700_134.log',options=>dbms_logmnr.addfile); 
  
SQL> execute dbms_logmnr.start_logmnr(dictfilename=>'/home/oracle/logmnr/dict.ora',options=>dbms_logmnr.ddl_dict_tracking);
 
SQL> 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,'YYYY-MM-DDH SQL_REDO
------------------------------ ---------- ------------------------------ -----------------------------------------------
SCOTT                             1918000 2012-08-01 17:28:29           drop table t1 purge;


SQL> execute dbms_logmnr.end_logmnr;


4） 关闭数据库，删除所有dbf，准备做不完全恢复