在研究数据库恢复的时候，想到数据库可以基于时间点恢复，前提条件是数据库要在自动归档模式下运行，并且有有效的冷备份或者热备份文件。在研究的时候，试图确定数据库恢复的时间精确度。在eygle的网站上有一篇文章讲到基于时间恢复的例子，我仔细看了和研究了一番，不过还是有些疑问，oracle 以归档日志和重做日志来重演oracle的操作，究竟在重演到规定的时间段的时候，是以什么为准的？是以发生某个操作的时间点为准，还是以写入到归档日志的时间为准？最后发现，这两个都很难确定。最后看到还原的过程中有记录的SCN，就想根据SCN和时间的转换关系来研究基于时间点的恢复。

        后来发现oracle查询SCN的函数，不是很准确，只能近似值，根据这些近似值和警告日志中记录的SCN，来比对还原到的位置，下边是实验的内容：

SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER
------------------------
                  913828

SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER
------------------------
                  913829

SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER
------------------------
                  913829

SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER
------------------------
                  913830

SQL> select current_scn from v$database;

CURRENT_SCN
-----------
     913845

SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER
------------------------
                  913848

SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER
------------------------
                  913849

SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER
------------------------
                  913850

SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER
------------------------
                  913850

SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER
------------------------
                  913850

SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER
------------------------
                  913851

SQL> select current_scn from v$database;

CURRENT_SCN
-----------
     913853

SQL> set time on;
08:41:47 SQL> create table scott.t (id int);

表已创建。

08:41:54 SQL> insert into scott.t values(1);

已创建 1 行。

08:42:16 SQL> commit;

提交完成。

08:42:20 SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER
------------------------
                  913902

08:42:26 SQL>
08:42:29 SQL>
08:42:30 SQL>
08:42:30 SQL>
08:42:30 SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER
------------------------
                  913904

08:42:32 SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER
------------------------
                  913911

08:42:35 SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER
------------------------
                  913913

08:42:43 SQL> insert into scott.t values(7);

已创建 1 行。

08:43:03 SQL> commit;

提交完成。

08:43:06 SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER
------------------------
                  913923

08:43:10 SQL>
08:43:22 SQL>
08:43:22 SQL>
08:43:22 SQL>
08:43:22 SQL>
08:43:22 SQL>
08:43:22 SQL>
08:43:31 SQL>
08:43:33 SQL>
08:43:39 SQL> insert into scott.t values(39);

已创建 1 行。

08:44:02 SQL> commit;

提交完成。

08:44:05 SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER
------------------------
                  913949

08:44:10 SQL>
08:44:13 SQL>
08:44:13 SQL>
08:44:14 SQL>
08:44:16 SQL>
08:44:17 SQL>
08:44:17 SQL> drop table scott.t;

表已删除。

08:44:29 SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER
------------------------
                  914545

08:44:32 SQL>
08:44:34 SQL>
08:44:34 SQL> shutdown immediate
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
08:45:04 SQL> select dbms_flashback.get_system_change_number from dual;
select dbms_flashback.get_system_change_number from dual
*
第 1 行出现错误:
ORA-01034: ORACLE not available

08:53:55 SQL> startup mount
ORACLE 例程已经启动。

Total System Global Area  448790528 bytes
Fixed Size                  1291096 bytes
Variable Size             390073512 bytes
Database Buffers           50331648 bytes
Redo Buffers                7094272 bytes
数据库装载完毕。
08:54:08 SQL> select dbms_flashback.get_system_change_number from dual;
08:55:40 SQL> recover database until time '2012-05-17 08:44:02';
ORA-00279: 更改 832372 (在 05/15/2012 16:13:43 生成) 对于线程 1 是必需的
ORA-00289: 建议:
D:\ORACLE\PRODUCT\10.2.0\ARCHIVELOG\ARCHIVE_1_1_783360009.ARCLOG
ORA-00280: 更改 832372 (用于线程 1) 在序列 #1 中

08:55:56 指定日志: {=suggested | filename | AUTO | CANCEL}
auto
ORA-00279: 更改 832704 (在 05/16/2012 09:39:07 生成) 对于线程 1 是必需的
ORA-00289: 建议:
D:\ORACLE\PRODUCT\10.2.0\ARCHIVELOG\ARCHIVE_1_1_783423547.ARCLOG
ORA-00280: 更改 832704 (用于线程 1) 在序列 #1 中

ORA-00279: 更改 863506 (在 05/16/2012 15:55:37 生成) 对于线程 1 是必需的
ORA-00289: 建议:
D:\ORACLE\PRODUCT\10.2.0\ARCHIVELOG\ARCHIVE_1_2_783423547.ARCLOG
ORA-00280: 更改 863506 (用于线程 1) 在序列 #2 中
ORA-00278: 此恢复不再需要日志文件
'D:\ORACLE\PRODUCT\10.2.0\ARCHIVELOG\ARCHIVE_1_1_783423547.ARCLOG'

ORA-00279: 更改 865633 (在 05/16/2012 17:07:56 生成) 对于线程 1 是必需的
ORA-00289: 建议:
D:\ORACLE\PRODUCT\10.2.0\ARCHIVELOG\ARCHIVE_1_1_783450476.ARCLOG
ORA-00280: 更改 865633 (用于线程 1) 在序列 #1 中

ORA-00279: 更改 866067 (在 05/16/2012 17:42:23 生成) 对于线程 1 是必需的
ORA-00289: 建议:
D:\ORACLE\PRODUCT\10.2.0\ARCHIVELOG\ARCHIVE_1_1_783452543.ARCLOG
ORA-00280: 更改 866067 (用于线程 1) 在序列 #1 中

ORA-00279: 更改 887631 (在 05/16/2012 19:57:03 生成) 对于线程 1 是必需的
ORA-00289: 建议:
D:\ORACLE\PRODUCT\10.2.0\ARCHIVELOG\ARCHIVE_1_2_783452543.ARCLOG
ORA-00280: 更改 887631 (用于线程 1) 在序列 #2 中
ORA-00278: 此恢复不再需要日志文件
'D:\ORACLE\PRODUCT\10.2.0\ARCHIVELOG\ARCHIVE_1_1_783452543.ARCLOG'

ORA-00279: 更改 888618 (在 05/16/2012 20:18:46 生成) 对于线程 1 是必需的
ORA-00289: 建议:
D:\ORACLE\PRODUCT\10.2.0\ARCHIVELOG\ARCHIVE_1_1_783461926.ARCLOG
ORA-00280: 更改 888618 (用于线程 1) 在序列 #1 中

ORA-00279: 更改 890319 (在 05/16/2012 20:52:41 生成) 对于线程 1 是必需的
ORA-00289: 建议:
D:\ORACLE\PRODUCT\10.2.0\ARCHIVELOG\ARCHIVE_1_1_783463961.ARCLOG
ORA-00280: 更改 890319 (用于线程 1) 在序列 #1 中

已应用的日志。
完成介质恢复。
08:56:22 SQL> alter database open resetlogs;

数据库已更改。

08:57:06 SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER
------------------------
                  914254

08:57:54 SQL> select current_scn from v$database;

CURRENT_SCN
-----------
     914268

08:58:22 SQL> select * from scott.t;

        ID
----------
         1
         7
09:05:26 SQL> select to_char(scn_to_timestamp(913947),'yyyy-mm-dd hh24:mi:ss') f
rom dual;

TO_CHAR(SCN_TO_TIME
-------------------
2012-05-17 08:34:25

09:05:37 SQL> select timestamp_to_scn(to_date('2012-05-17 08:44:02','yyyy-mm-dd hh24:mi:s
s')) from dual;

TIMESTAMP_TO_SCN(TO_DATE('2012-05-1708:44:02','YYYY-MM-DDHH24:MI:SS'))
----------------------------------------------------------------------
                                                                913563
SQL> select timestamp_to_scn(to_date('2012-05-17 08:34:25','yyyy-mm-dd hh24:mi:s
s')) from dual;

TIMESTAMP_TO_SCN(TO_DATE('2012-05-1708:34:25','YYYY-MM-DDHH24:MI:SS'))
----------------------------------------------------------------------
                                                                913563

SQL>
警告日志中内容：

ALTER DATABASE RECOVER  database until time '2012-05-16 08:44:02' 
Thu May 17 08:55:39 2012
Media Recovery Start
 parallel recovery started with 2 processes
Thu May 17 08:55:40 2012
Media Recovery failed with error 19907
ORA-283 signalled during: ALTER DATABASE RECOVER  database until time '2012-05-16 08:44:02'  ...
Thu May 17 08:55:56 2012
ALTER DATABASE RECOVER  database until time '2012-05-17 08:44:02' 
Thu May 17 08:55:56 2012
Media Recovery Start
 parallel recovery started with 2 processes
Media Recovery start incarnation depth : 6, target inc# : 9, irscn : 832703
ORA-279 signalled during: ALTER DATABASE RECOVER  database until time '2012-05-17 08:44:02'  ...
Thu May 17 08:56:04 2012
ALTER DATABASE RECOVER    CONTINUE DEFAULT 
Thu May 17 08:56:04 2012
Media Recovery Log D:\ORACLE\PRODUCT\10.2.0\ARCHIVELOG\ARCHIVE_1_1_783360009.ARCLOG
ORA-279 signalled during: ALTER DATABASE RECOVER    CONTINUE DEFAULT  ...
Thu May 17 08:56:05 2012
ALTER DATABASE RECOVER    CONTINUE DEFAULT 
Thu May 17 08:56:05 2012
Media Recovery Log D:\ORACLE\PRODUCT\10.2.0\ARCHIVELOG\ARCHIVE_1_1_783423547.ARCLOG
ORA-279 signalled during: ALTER DATABASE RECOVER    CONTINUE DEFAULT  ...
Thu May 17 08:56:10 2012
ALTER DATABASE RECOVER    CONTINUE DEFAULT 
Thu May 17 08:56:10 2012
Media Recovery Log D:\ORACLE\PRODUCT\10.2.0\ARCHIVELOG\ARCHIVE_1_2_783423547.ARCLOG
ORA-279 signalled during: ALTER DATABASE RECOVER    CONTINUE DEFAULT  ...
Thu May 17 08:56:12 2012
ALTER DATABASE RECOVER    CONTINUE DEFAULT 
Thu May 17 08:56:12 2012
Media Recovery Log D:\ORACLE\PRODUCT\10.2.0\ARCHIVELOG\ARCHIVE_1_1_783450476.ARCLOG
ORA-279 signalled during: ALTER DATABASE RECOVER    CONTINUE DEFAULT  ...
Thu May 17 08:56:13 2012
ALTER DATABASE RECOVER    CONTINUE DEFAULT 
Thu May 17 08:56:13 2012
Media Recovery Log D:\ORACLE\PRODUCT\10.2.0\ARCHIVELOG\ARCHIVE_1_1_783452543.ARCLOG
ORA-279 signalled during: ALTER DATABASE RECOVER    CONTINUE DEFAULT  ...
Thu May 17 08:56:14 2012
ALTER DATABASE RECOVER    CONTINUE DEFAULT 
Thu May 17 08:56:14 2012
Media Recovery Log D:\ORACLE\PRODUCT\10.2.0\ARCHIVELOG\ARCHIVE_1_2_783452543.ARCLOG
ORA-279 signalled during: ALTER DATABASE RECOVER    CONTINUE DEFAULT  ...
Thu May 17 08:56:15 2012
ALTER DATABASE RECOVER    CONTINUE DEFAULT 
Thu May 17 08:56:15 2012
Media Recovery Log D:\ORACLE\PRODUCT\10.2.0\ARCHIVELOG\ARCHIVE_1_1_783461926.ARCLOG
ORA-279 signalled during: ALTER DATABASE RECOVER    CONTINUE DEFAULT  ...
Thu May 17 08:56:17 2012
ALTER DATABASE RECOVER    CONTINUE DEFAULT 
Thu May 17 08:56:17 2012
Media Recovery Log D:\ORACLE\PRODUCT\10.2.0\ARCHIVELOG\ARCHIVE_1_1_783463961.ARCLOG
Thu May 17 08:56:18 2012
Recovery of Online Redo Log: Thread 1 Group 2 Seq 1 Reading mem 0
  Mem# 0: D:\ORACLE\PRODUCT\10.2.0\ORADATA\STUDY\REDO02.LOG
Thu May 17 08:56:19 2012
Recovery of Online Redo Log: Thread 1 Group 1 Seq 2 Reading mem 0
  Mem# 0: D:\ORACLE\PRODUCT\10.2.0\ORADATA\STUDY\REDO01.LOG
Thu May 17 08:56:20 2012
Incomplete Recovery applied until change 913947
Completed: ALTER DATABASE RECOVER    CONTINUE DEFAULT 
Thu May 17 08:56:46 2012
alter database open resetlogs
Thu May 17 08:56:46 2012
RESETLOGS after incomplete recovery UNTIL CHANGE 913947
Resetting resetlogs activation ID 2801033899 (0xa6f462ab)
Online log D:\ORACLE\PRODUCT\10.2.0\ORADATA\STUDY\REDO03.LOG: Thread 1 Group 3 was previously cleared
Thu May 17 08:56:49 2012

 

从中可以看到'2012-05-1708:44:02 和'2012-05-1708:34:25 由时间转成SCN是一样，可是通过查询，查出来的SCN则是不一样，再一个在这个两个时间段内，也进行数据操作和数据提交操作，根据文档说明，SCN在数据库提交和回滚过程中会变化，可是在这两个时间段中间，数据库进行了提交操作，而SCN从查询上来说没有变化，这是一件令人费解的事，oracle还原的时间点，和SCN'对应的时间也不一致，这其中的原因值得深入研究，先把研究结果记录在这里，为进一步接着研究做准备！