[20150917]恢复使用scn比time更好.txt

[20150917]恢复使用scn比time更好.txt

--oracle 提供一个函数SCN_TO_TIMESTAMP将scn转换成时间,但是这个存在一个精度问题,误差大约是3秒.
--转换实际上通过sys.SMON_SCN_TIME表.

--正是这样误差,一些恢复或者回滚到特定的时间点,使用scn更加准确.通过例子来说明问题.

1.检查测试环境:
SCOTT@test> @ver1
PORT_STRING                    VERSION        BANNER
------------------------------ -------------- --------------------------------------------------------------------------------
x86_64/Linux 2.4.xx            11.2.0.3.0     Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production

CREATE TABLE t (id number, update_scn number, commit_scn number,ins_date date);

BEGIN
  FOR i IN 1..9
  LOOP
   INSERT INTO t VALUES(i, dbms_flashback.get_system_change_number,userenv('commitscn'),sysdate);
   dbms_lock.sleep(1);
   COMMIT;
  END LOOP;
END;
/

--关于userenv('commitscn')可以参考我以前的链接:http://blog.itpub.net/267265/viewspace-1787037/
--[20150828]插入commit scn到记录.txt

SCOTT@test> SELECT ORA_ROWSCN, SCN_TO_TIMESTAMP(ORA_ROWSCN) c30, t.* FROM t;
ORA_ROWSCN C30                                     ID  UPDATE_SCN  COMMIT_SCN INS_DATE
----------- ------------------------------ ----------- ----------- ----------- -------------------
13201900710 2015-09-17 11:34:14.000000000            1 13201900686 13201900692 2015-09-17 11:34:08
13201900710 2015-09-17 11:34:14.000000000            2 13201900694 13201900694 2015-09-17 11:34:09
13201900710 2015-09-17 11:34:14.000000000            3 13201900696 13201900696 2015-09-17 11:34:10
13201900710 2015-09-17 11:34:14.000000000            4 13201900698 13201900698 2015-09-17 11:34:11
13201900710 2015-09-17 11:34:14.000000000            5 13201900700 13201900700 2015-09-17 11:34:12
13201900710 2015-09-17 11:34:14.000000000            6 13201900702 13201900703 2015-09-17 11:34:13
13201900710 2015-09-17 11:34:14.000000000            7 13201900705 13201900705 2015-09-17 11:34:14
13201900710 2015-09-17 11:34:14.000000000            8 13201900707 13201900707 2015-09-17 11:34:15
13201900710 2015-09-17 11:34:14.000000000            9 13201900709 13201900709 2015-09-17 11:34:17
9 rows selected.

--因为插入到1个数据块里面ORA_ROWSCN是最后的提交scn.应该改写如下:

SCOTT@test> SELECT SCN_TO_TIMESTAMP(commit_SCN) c30, t.* FROM t;
C30                                     ID  UPDATE_SCN  COMMIT_SCN INS_DATE
------------------------------ ----------- ----------- ----------- -------------------
2015-09-17 11:34:08.000000000            1 13201900686 13201900692 2015-09-17 11:34:08
2015-09-17 11:34:08.000000000            2 13201900694 13201900694 2015-09-17 11:34:09
2015-09-17 11:34:08.000000000            3 13201900696 13201900696 2015-09-17 11:34:10
2015-09-17 11:34:11.000000000            4 13201900698 13201900698 2015-09-17 11:34:11
2015-09-17 11:34:11.000000000            5 13201900700 13201900700 2015-09-17 11:34:12
2015-09-17 11:34:11.000000000            6 13201900702 13201900703 2015-09-17 11:34:13
2015-09-17 11:34:14.000000000            7 13201900705 13201900705 2015-09-17 11:34:14
2015-09-17 11:34:14.000000000            8 13201900707 13201900707 2015-09-17 11:34:15
2015-09-17 11:34:14.000000000            9 13201900709 13201900709 2015-09-17 11:34:17
9 rows selected.

--注意看SCN_TO_TIMESTAMP(commit_SCN)与后面的ins_date,前面3个一组,与后面的存在误差.

SCOTT@test> select * from t as of timestamp to_date('2015-09-17 11:34:08','yyyy-mm-dd hh24:mi:ss');
no rows selected

SCOTT@test> select * from t as of timestamp to_date('2015-09-17 11:34:09','yyyy-mm-dd hh24:mi:ss');
no rows selected

SCOTT@test> select * from t as of timestamp to_date('2015-09-17 11:34:10','yyyy-mm-dd hh24:mi:ss');
no rows selected

SCOTT@test> select * from t as of timestamp to_date('2015-09-17 11:34:11','yyyy-mm-dd hh24:mi:ss');
         ID  UPDATE_SCN  COMMIT_SCN INS_DATE
----------- ----------- ----------- -------------------
          1 13201900686 13201900692 2015-09-17 11:34:08
          2 13201900694 13201900694 2015-09-17 11:34:09
          3 13201900696 13201900696 2015-09-17 11:34:10

--可以发现11:34:08插入第1条数据,理论讲11:34:09已经提交,至少11:34:10应该能看到第1条记录,而实际上执行:
--select * from t as of timestamp to_date('2015-09-17 11:34:11','yyyy-mm-dd hh24:mi:ss');才看到记录.

SCOTT@test> select * from t as of scn 13201900692;
no rows selected

SCOTT@test> select * from t as of scn 13201900693;
         ID  UPDATE_SCN  COMMIT_SCN INS_DATE
----------- ----------- ----------- -------------------
          1 13201900686 13201900692 2015-09-17 11:34:08

SCOTT@test> select * from t as of scn 13201900694;
         ID  UPDATE_SCN  COMMIT_SCN INS_DATE
----------- ----------- ----------- -------------------
          1 13201900686 13201900692 2015-09-17 11:34:08

SCOTT@test> select * from t as of scn 13201900695;
         ID  UPDATE_SCN  COMMIT_SCN INS_DATE
----------- ----------- ----------- -------------------
          1 13201900686 13201900692 2015-09-17 11:34:08
          2 13201900694 13201900694 2015-09-17 11:34:09

--可以发现scn可以很精确的定位相关记录.从这些测试可以发现在一些恢复回滚到特定的时间点,选择scn更加好更加准确.

--当然如果如果你选择恢复until time 不存在这个问题.下午我重新测试,在dg上打开flashback.

--删除表,重新插入:
--主数据库:
SCOTT@test> select * from t;
         ID  UPDATE_SCN  COMMIT_SCN INS_DATE
----------- ----------- ----------- -------------------
          1 13201922719 13201922723 2015-09-17 15:37:10
          2 13201922725 13201922725 2015-09-17 15:37:11
          3 13201922727 13201922736 2015-09-17 15:37:12
          4 13201922738 13201922739 2015-09-17 15:37:13
          5 13201922741 13201922741 2015-09-17 15:37:14
          6 13201922743 13201922743 2015-09-17 15:37:15
          7 13201922745 13201922745 2015-09-17 15:37:16
          8 13201922747 13201922747 2015-09-17 15:37:17
          9 13201922749 13201922749 2015-09-17 15:37:18
9 rows selected.

SCOTT@test> select * from t as of timestamp to_date('2015-09-17 15:37:13','yyyy-mm-dd hh24:mi:ss');
         ID  UPDATE_SCN  COMMIT_SCN INS_DATE
----------- ----------- ----------- -------------------
          1 13201922719 13201922723 2015-09-17 15:37:10
          2 13201922725 13201922725 2015-09-17 15:37:11

--在dg上flashback:

SYS@testdg> flashback database to timestamp  to_date('2015-09-17 15:37:13','yyyy-mm-dd hh24:mi:ss');
Flashback complete.

SYS@testdg> alter database open read only ;
Database altered.

SYS@testdg> select * from scott.t;
          ID   UPDATE_SCN   COMMIT_SCN INS_DATE
------------ ------------ ------------ -------------------
           1  13201922719  13201922723 2015-09-17 15:37:10
           2  13201922725  13201922725 2015-09-17 15:37:11
           3  13201922727  13201922736 2015-09-17 15:37:12

--说明不存在这个问题,但是使用scn将跟准确一些.

时间: 2024-08-01 02:50:41

[20150917]恢复使用scn比time更好.txt的相关文章

[20160406] 恢复until scn NNN.txt

[20160406] 恢复until scn NNN.txt --昨天别人问的问题,如果使用rman恢复,restore database until scn NNN;是恢复到NNN,还是NNN-1. --我个人的理解应该是NNN-1.包括像UNTIL SEQUENCE integer 以及UNTIL TIME xxx;也是少1个或者少1秒. --实际上我以前如果做测试,我自己总是查询误操作的scn,然后仅仅恢复到减去1的scn号.(感觉这样比较保险^_^) until prep.到...为止,

[20170302]异常恢复scn到那里3.txt

[20170302]异常恢复scn到那里3.txt --//如果oracle数据库异常关闭,打开数据库自动执行实例恢复,这个恢复scn到那里呢? --//通过例子说明:实际上http://blog.itpub.net/267265/viewspace-2134551/链接已经提到,重复测试: 1.环境: SYS@book> @ &r/ver BANNER ---------------------------------------------------------------------

[20161019]数据文件offline后恢复到那个scn

[20161019]数据文件offline后恢复到那个scn号.txt --前一天别人问的问题,如果数据文件offline时,online要恢复,一般恢复到scn是多少,是offline时的scn吗? --总不见得如果长时间offline,要应用许多归档日志吧,通过测试说明问题: 1.环境: SYS@book> @ &r/ver1 PORT_STRING                    VERSION        BANNER ----------------------------

Oracle RMAN高级恢复概述(五) 如何验证备份是否可恢复

如果备份不可恢复,那么它就没有用处. RMAN 提供了一种不需要还原数据库就能检查数据库还原能力的方法,并且为用户提供了几个检查选项. 1.restore preview命令 该命令可以查看RMAN 使用哪个备份集来执行特定的恢复. 该命令将列出还原所需的备份集的详细信息. RMAN> restore database preview; 启动 restore 于 08-7月 -10 使用通道 ORA_DISK_1 备份集列表 =================== BS 关键字  类型 LV 大

【BBED】丢失归档文件情况下的恢复

[BBED]丢失归档文件情况下的数据文件的恢复   1.1  BLOG文档结构图     1.2  前言部分   1.2.1  导读和注意事项 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识,~O(∩_∩)O~: ① 若丢失归档情况下数据文件的恢复,bbed和隐含参数(重点) ② 数据库启动过程中的介质恢复,scn号的关系 ③ BBED如何修改文件头 ④ 归档和非归档模式下数据库的全备     Tips:        ① 若文章代码格式有错乱,推荐使用QQ

网站被K的恢复路程:心态最重要

做得好好的几个站,一夜之间发现全都被K掉,一页都不剩,几乎所有的站长遇到这种情况的时候都是茫然失策吧.心情也一下子掉到谷底之中.也许还有一部分站长认为只要坚持,网站肯定会恢复的,但是他们自己也知道,想恢复一个被K掉的网站谈何容易啊.即使有些站长坚持十几天,但是在这十几天过后发现网站还是没有恢复的迹象,那么心情也会变得浮躁起来.笔者的好几个站在六月份的时候遇到了一次大地震,一夜之间,全部被K掉,到9月的时候才刚刚恢复了收录,但是快照还停留在9月初,在被K掉后,笔者的心情也由坚持的收态转向了浮躁,不

回收站清空了怎么恢复 推荐使用顶尖数据恢复

随着科技的发展,用户对电脑的了解也更加的深入,在以前,很多用户对回收站的认识仅限于回收删除文件,不过现在很多用户都了解到,回收站存储在C盘下,一旦垃圾文件过多,会影响电脑的运行速度.大部分的用户都养成了一个习惯,那就是随时清空回收站,可是,如果清空的回收站中有重要文件怎么办?我们该如何恢复回收站中的文件呢? 其实,回收站是操作系统设置的一个特殊的文件夹,默认在每个分区根目录下的 RECYCLE文件夹中,不过这个文件夹是隐藏的,用户是看不到的.当用户删除文件后,系统只是将文件发到了这个RECYCL

备份恢复6——rman配置和设置

原文转自:http://blog.csdn.net/tianlesoftware/article/details/5674309 一. 配置数据库以ARCHIVELOG 模式运行  在ORACLE 10g 之前,在将数据库置入Archivelog 模式后,需要启动arch进程. 设置参数LOG_ARCHIVE_START 为true,也可启动arch进 程.在10g以后,不需要使用该方法,当数据库处于archivelog模式时,Oracle 会自动启动arch进程. Arch 进程由LGWR 进

备份恢复4.3——rman备份恢复综合演练

1. 检查数据库模式:   sqlplus /nolog     conn /as sysdba    archive log list (查看数据库是否处于归档模式中)    若为非归档,则修改数据库归档模式.    startup mount    alter database archivelog    alter database open 2.连接到target数据库 命令: connect target  /  (connect target system/oracle@ora10g