ITPub博客

首页 > 数据库 > Oracle > 从SCN 看基于时间点的恢复

从SCN 看基于时间点的恢复

原创 Oracle 作者:genweihua 时间:2012-05-21 16:17:29 0 删除 编辑
         在研究数据库恢复的时候,想到数据库可以基于时间点恢复,前提条件是数据库要在自动归档模式下运行,并且有有效的冷备份或者热备份文件。在研究的时候,试图确定数据库恢复的时间精确度。在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'对应的时间也不一致,这其中的原因值得深入研究,先把研究结果记录在这里,为进一步接着研究做准备!

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/22275400/viewspace-730504/,如需转载,请注明出处,否则将追究法律责任。

上一篇: Ora 01031 错误
下一篇: 写给自己的故事
请登录后发表评论 登录
全部评论

注册时间:2009-08-28

  • 博文量
    111
  • 访问量
    559082