以往工作中曾经出现过数据库服务器系统时间向以前修改了3 个月(例如从 13 年改成 12 年)，这时再启动数据库时就会报ora-600 的错误。下面对数据库服务器的修改时间与SCN的关系做实验研究。
一、首先进行一个测试
1.关闭 DB
2. 修改系统时间
(1) 现在时间
(2)修改时间
将时间往前调整一下：
[root@singledb ~]# date -s 1/1/2015
THU Jan 1 00:00:00 EST 2015
(3)重新启动数据库
启动的时候并没有问题。
二、修改数据库服务器系统时间与数据库 SCN 的关系
通过前面的分析，我们可以看出修改系统时间和 SCN 没有直接的关系。但是如果不是特殊情况，我们不建议修改系统时间。系统稳定是第一位的，特别是在 RAC 环境，对时间要求更加严格。
虽然修改系统时间和 SCN 没有直接影响，但在测试中，发现它们之间是有联系的。下面进一步实验。
系统中由SMON进程维护一张表SMON_SCN_TIME，这张用于记录过去时间段中SCN(system change number)与具体的时间戳(timestamp)之间的映射关系，因为这种映射关系，所以SMON_SCN_TIME可以较为粗糙地(不精确地)定位某个SCN的时间信息。
查看smon_scn_time的信息
查看系统SCN号
从上面的几个查询结果我们发现二个问题：
(1) smon_scn_time 表中的 SCN(1972507) 小于系统当前的 SCN 值(1976352)。
(2) smon_scn_time 表中最后更新时间(2015-03-31 17:10:38)大于系统当前时间( 2015-01-1 00:03:03)。
由此我们推出一个结论： 当 smon_scn_time 最后更新时间大于系统时间时，SMON 不会将 SCN 与 TIMESTAMP 的映射结果写入到 sys.smon_scn_time 表中。
如果SCN与timestamp的映射不能写入到 smon_scn_time 表中，就不能进行 SCN 与 TIMESTAMP 转换，就不能利用 timestamp 进行相关的操作。
为了验证上面的结论，我们把系统改成大于 smon_scn_time 最后更新时间，再查看smon_scn_time和scn
这次成功写入 smon_scn_time 表。 由此可见：
(1)系统时间往后改(如从 2015 年1月改到 2015 年5月)，对数据库没有影响，但某些应用可能会受影响。
(2)系统时间往前改(如从2015 年4月改到 2015 年1月)，那么SMON不会将SCN与timestamp写入smon_scn_time 表。所以对于生产系统，在系统上线之前就应该校对好服务器时间，本着稳定第一的原则，上线之后不建议再修改DB服务器的时间。