NTP故障导致系统时间超过正常时间2小时影响

1 对数据建库影响

今日对数据库主机进行重启，主机起来后发现系统得时间为2019-09-25 04:15：00，而正常得时间应该为2019-09-25 01:15：00

显然系统时间不对，数据库已经正常启动。产生影响

1 对数据库的插入，采用sysdate进行数据库插入降导致数据异常。

2 对于数据库的调度job将运行。

修改系统时间对于数据库本身没有什么影响，数据库是已scn号来记录。 25日在进行查看发现已经正常

SQL> set lines 120
SQL> col scn format 999999999999999999999999.99
SQL> col time_dp for a40
SQL> select * FROM (select scn,time_dp from sys.smon_scn_time order by 2 DESC) WHERE ROWNUM<20;

                         SCN TIME_DP
---------------------------- ----------------------------------------
           12910537911935.00 2019-09-25 07:19:09
           12910537382853.00 2019-09-25 07:14:06
           12910537381718.00 2019-09-25 07:14:03
           12910534565674.00 2019-09-25 07:09:00
           12910534431947.00 2019-09-25 07:05:44
           12910534090595.00 2019-09-25 07:00:41
           12910534081515.00 2019-09-25 07:00:23
           12910533376789.00 2019-09-25 06:55:20
           12910533353556.00 2019-09-25 06:55:08
           12910532101087.00 2019-09-25 06:50:05
           12910531905004.00 2019-09-25 06:47:26

                         SCN TIME_DP
---------------------------- ----------------------------------------
           12910531738495.00 2019-09-25 06:42:22
           12910531721643.00 2019-09-25 06:42:16
           12910531470071.00 2019-09-25 06:37:11
           12910531448479.00 2019-09-25 06:36:59
           12910531111340.00 2019-09-25 06:31:54
           12910531101467.00 2019-09-25 06:31:45
           12910530863371.00 2019-09-25 06:26:41
           12910530861892.00 2019-09-25 06:26:38

19 rows selected.
 

 

本文转载于http://m.blog.itpub.net/25462274/viewspace-2152481/

Oracle DB 服务器 系统时间修改问题 与 SCN 关系的深入研究Oracle DB 服务器 系统时间修改问题 与 SCN 关系的深入研究

论坛里一个朋友说将DB 服务器系统时间往往后修改了3个月（从11年改成10年），启动DB报600的错误。 

一. 先做个测试

1.1 关闭DB

SQL> shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

1.2 修改系统时间

1.2.1 现在时间

[root@singledb ~]# date

Tue Jan 25 11:05:32 EST 2011

 

1.2.2 修改时间

将时间往前调整一下：

[root@singledb ~]# date -s 1/1/2011 

Sat Jan 1 00:00:00 EST 2011

[root@singledb ~]# date

Sat Jan 1 00:00:22 EST 2011

 

1.3启动DB

SQL> startup

ORACLE instance started.

Total System Global Area 360710144 bytes

Fixed Size 1219424 bytes

Variable Size 117441696 bytes

Database Buffers 239075328 bytes

Redo Buffers 2973696 bytes

Database mounted.

Database opened.

 

启动并没有问题，也没有遇到网友的600错误。

 

二. SCN 

 在这里先对SCN 的知识做下说明。之前的blog里也有说明：

 RedoLog Checkpoint 和 SCN关系

 http://blog.csdn.net/tianlesoftware/archive/2010/01/24/5251916.aspx

SCN是当Oracle数据更新后，由DBMS自动维护去累积递增的一个数字。 当一个事务commit时，LGWR会将log buffer写入redo log file，同时也会将该事务的 SCN同步写入到redo log file内(wait-until-completed)。因此当你commit transaction时， 在成功的讯息返回之前，LGWR必须先完整的完成上述行为之后，否则你是看不到提交成功的响应讯息。

系统时间标记与scn 之间存在一张表，即SYS 下的SMON_SCN_TIME。

SQL> desc sys.smon_scn_time

名称 是否为空? 类型

----------------------------------------- -------- ---------------------------

THREAD NUMBER

TIME_MP NUMBER

TIME_DP DATE

SCN_WRP NUMBER

SCN_BAS NUMBER

NUM_MAPPINGS NUMBER

TIM_SCN_MAP RAW(1200)

SCN NUMBER

ORIG_THREAD NUMBER

每隔5 分钟，系统产生一次系统时间标记与scn 的匹配并存入SYS.SMON_SCN_TIME 表(由SMON 进程来进行Update操作)，该表中记录了最近1440个系统时间标记与scn 的匹配记录，由于该表只维护了最近的1440 条记录，即最近5 天内的记录。

对 系统时间标记与scn 的每5 分钟匹配一次 做个说明，比如：

 SCN:339988 对应 2011-01-25 17:00:00

 SCN:339989对应2011-01-25 17:05:00，

 当查询2011-01-25 17:00:00 到2011-01-25 17:04:59 这段时间点内的SCN时，oracle 都会将其匹配为SCN:339988。

查看SCN 和 timestamp 之间的对应关系：

select scn,to_char(time_dp,'yyyy-mm-dd hh24:mi:ss') from sys.smon_scn_time order by 2;

查询目前系统最新的SCN:

 select dbms_flashback.get_system_change_number from dual;

timestamp 与 SCN 互换的2个方法：

select timestamp_to_scn(to_date('2011-01-25 12:10:00','yyyy-mm-dd hh24:mi:ss')) from dual;

select scn_to_timestamp(351277605) from dual;

在Metalink 搜到一篇Timestamp与SCN 之间映射关系的文章，原文参考：

 How to map SCN with Timestamp before 10g [ID 365536.1]

 http://blog.csdn.net/tianlesoftware/archive/2011/01/25/6163757.aspx

However, in earlier releases, while there is a system object - SYS.SMON_SCN_TIME that will provide the SCN to TIME mapping information. There is no conversion facility provided. 

SYS.SMON_SCN_TIME will have a maximum of 1440 rows and each record will be for a 5 minute period. Oracle maintains this information for maximum of 5 days after which the records will be recycled.

This means that data is stored 12 times per hour * 24 hours * 5 days=1440 rows. 

SCN value is stored internally as :

i. SCN_wrap

ii. SCN_base

Whenever the SCN is incremented, the BASE component is incremented first unil it reaches it maximum. Once the BASE reaches the maximum value allowed, it is initialized to zero again after incrementing the WRAP by 1.

--开始时WRAP 为0，即SCN_WRP=0. 当BASE增长到最大值后，SCN_BAS变为0. 同时SCN_WRP 增长到1

Using this logic, we can calculate the timestamp of the SCN as follows:

(SCN_WRP * 4294967296) + SCN_BAS should give us the SCN in the number format

--SCN 的计算公式，这里我们看出SCN 是根据SCN_BAS计算出来的。和系统时间是没有关系的。 只是方便我们来进行操作，如闪回恢复，而将SCN 和 系统时间每隔5分钟进行一次映射。 映射完后，由SMON进程将映射关系写入SMON_SCN_TIME表。 可以把SCN 看成是Oracle 内部的时间。

To get the time/date for an SCN value in 9i, use the following example:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-- (a) Get the current SCN base.

SQL>select max(scn_bas) SCN_BASE from smon_scn_time;

1603342197

-(b) Get the complete SCN and the timestamp.

SQL> alter session set NLS_DATE_FORMAT='DD-MON-YY HH:MI:SS';

SQL> select time_dp TIMESTAMP, scn_wrp*4294967296+SCN_bas SCN from smon_scn_time where scn_bas='1603342197';

TIMESTAMP SCN

------------------ ----------

28-JUL-06 05:31:08 8252235517813

这篇文章将的是10g之前的。 在metalink上搜了半天，只找到一条区别，就是11g下smon_scn_time 存储的记录可以超过1440条。

在这里插一句，10g的g 表示Grid. 

三. 修改系统时间与SCN 关系

 通过前面2节的分析，可以看出修改系统时间和SCN没有直接的关系。在第一节中也做了测试。 对于DB 服务器如何修改时间：

 （1）停止应用

 （2）停止数据库

 （3）修改时间

 不过，如果不是特殊情况，不建议修改。稳定第一。尤其是RAC 环境，对时间要求更严格。

在这里说了，修改系统时间和SCN 没有直接影响，但我在测试中，发现他们是有联系的。

SQL> alter session set nls_date_format='yyyy-mm-dd hh24:mi:ss';

Session altered.

SQL> select sysdate from dual;

SYSDATE

-------------------

2010-01-01 01:21:58

SQL> select * from ( select scn,to_char(time_dp,'yyyy-mm-dd hh24:mi:ss') time from sys.smon_scn_time order by 2 desc) where rownum<10;

 SCN TIME

---------- -------------------

 943223 2012-01-01 02:43:33

 943058 2012-01-01 02:38:14

 942811 2012-01-01 02:33:02

 922652 2012-01-01 00:01:52

 922182 2012-01-01 00:00:45

 920862 2011-01-25 11:46:21

 920717 2011-01-25 11:41:17

 920571 2011-01-25 11:36:38

 919996 2011-01-25 11:31:21

9 rows selected.

SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER

------------------------

 945394

从上面的几个查询结果我们发现二个问题：

（1）smon_scn_time表中的SCN（943223） 小于系统当前的SCN值（945394）。

（2）smon_scn_time表中最后更新时间（2012-01-01 02:43:33）大于系统当前时间（2010-01-01 01:21:58）。

由此我们推出一个结论：当smon_scn_time最后更新时间大于系统时间时，SMON不会将SCN 与TIMESTAMP的映射结果写入到sys.smon_scn_time表中。

如果SCN 与TIMESTAMP的映射不能写入到smon_scn_time表中，我们就不能进行SCN 与TIMESTAMP转换，就不能利用timestamp进行相关的操作，如恢复。参考：

 Oracle 不同故障的恢复方案

 http://blog.csdn.net/tianlesoftware/archive/2010/12/30/6106178.aspx

为了验证上面的结论，我们把系统改成大于smon_scn_time最后更新时间。

SQL> select sysdate from dual;

SYSDATE

-------------------

2012-02-01 00:00:16

SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER

------------------------

 946462

SQL> select * from ( select scn,to_char(time_dp,'yyyy-mm-dd hh24:mi:ss') time from sys.smon_scn_time order by 2 desc) where rownum<10;

SCN TIME

---------- -------------------

 945872 2012-02-01 00:00:51 

 943223 2012-01-01 02:43:33

 943058 2012-01-01 02:38:14

 942811 2012-01-01 02:33:02

 922652 2012-01-01 00:01:52

 922182 2012-01-01 00:00:45

 920862 2011-01-25 11:46:21

 920717 2011-01-25 11:41:17

 920571 2011-01-25 11:36:38

这次成功写入smon_scn_time表。由此可见：

（1）系统时间往后改（如从2011年改到2012年），对DB 没有影响，可能某些应用可能会受影响。

（2）系统时间往前改（如从2011年改到2010年），那么SMON 不会将SCN 与timestamp写入smon_scn_time表。

所以对于生产系统，在系统上线之前就应该校队好系统时间，本着稳定第一的原则，上线之后就不建议在修改DB 服务器的时间了。