闰秒问题的全面解读与防范闰秒问题的全面解读与防范 闰秒问题的全面解读与防范dafsdf 闰秒问题的全面解读与防范
什么是闰秒?
闰秒是指为保持协调世界时接近于世界时时刻,由国际计量局统一规定在年底或年中(也可能在季末)对协调世界时增加或减少1秒的调整。由于地球自转的不均匀性和长期变慢性(主要由潮汐摩擦引起的),会使世界时(民用时间)和原子时之间相差超过到±0.9秒时,调整时将世界时向前拨1秒(负闰秒,最后一分钟为59秒)或向后拨1秒(正闰秒,最后一分钟为61秒),闰秒调整一般在公历年末或公历六月末。
目前,全球已经进行了26次闰秒调整,每次的调整如下:
实施年份 |
6月30日23:59:60 |
12月31日23:59:60 |
1972年 |
+1秒 |
+1秒 |
1973年 |
—— |
+1秒 |
1974年 |
—— |
+1秒 |
1975年 |
—— |
+1秒 |
1976年 |
—— |
+1秒 |
1977年 |
—— |
+1秒 |
1978年 |
—— |
+1秒 |
1979年 |
—— |
+1秒 |
1981年 |
+1秒 |
—— |
1982年 |
+1秒 |
—— |
1983年 |
+1秒 |
—— |
1985年 |
+1秒 |
—— |
1987年 |
—— |
+1秒 |
1989年 |
—— |
+1秒 |
1990年 |
—— |
+1秒 |
1992年 |
+1秒 |
—— |
1993年 |
+1秒 |
—— |
1994年 |
+1秒 |
—— |
1995年 |
—— |
+1秒 |
1997年 |
+1秒 |
—— |
1998年 |
—— |
+1秒 |
2005年 |
—— |
+1秒 |
2008年 |
—— |
+1秒 |
2012年 |
+1秒 |
—— |
2015年 |
+1秒 |
—— |
2016年 |
—— |
+1秒 |
我们不难看出,在2016年12月31号,即将迎来最近一次闰秒调整,出现23:59:60的情况。这里大家需要注意的是,这里指的是UTC时间,也就是格林尼治时间时间。由于我们中国是处于东八区,那么我们面临的闰秒问题,即将出现2017/01/01 07:59:60的情况。
好像很快就到闰秒了?!莫慌,今天我们带领大家全面认识和有效防范闰秒问题。
根据Oracle 官方文档Information Center: Leap Second Information for All Products - Database- Exadata - Middleware - Exalogic - Linux - Sun - Fusion - EBS - JDE - Siebel -Peoplesoft (文档 ID 2019397.2) 中的建议,我们来逐个分析闰秒对我们来讲有哪些影响,从该文档的描述来看,闰秒问题几乎影响所有操作系统,也包括Oracle exadata、ODA、SupperCluster环境等。
闰秒的影响
闰秒的出现,可能导致Oracle 集群重启,甚至主机crash,同时根据相关文档描述也可能导致出现CPU 使用100%的情况
听说闰秒问题可能导致Linux hung或者内核crash 是吗?
确实存在这个问题可能性,而且闰秒问题影响的Linux版本还是比较多的,无论是REDHAT内核还是Oracle UEK内核都一样。根据文档,从Linux 4.X- Linux 6.x 的几乎所有版本都在受影响范围之内。
至于哪些版本受影响,哪些版本进行了修复,大家可以参考下面的表格:
表格一:
Red Hat Compatible Kernel |
||
Version |
Min. Fixed Version |
Fixed Date |
OL5 |
2.6.18-131.el5 |
2009-02-07 |
OL6 |
2.6.32-279.8.1.el6 |
2012-08-28 |
2.6.32-298.el6 |
2012-08-15 |
|
OL7 |
Not vulnerable |
表格二:
UEK1 Kernels (OL5 & OL6) |
||
Series |
Min. FixedVersion |
Fixed Date |
2.6.32-100.* |
All vulnerable |
|
2.6.32-200.* |
All vulnerable |
|
2.6.32-300.* |
2.6.32-300.34.1.el[56]uek |
2012-08-29 |
2.6.32-400.* |
2.6.32-400.6.1.el[56]uek |
2012-08-08 |
表格三:
UEK2 Kernels (OL5 & OL6) |
||
Series |
Min. Fixed Version |
Fixed Date |
2.6.39-100.* |
All vulnerable |
|
2.6.39-200.* |
2.6.39-200.30.1.el[56]uek |
2012-08-29 |
2.6.39-300.* |
2.6.39-300.7.0.el[56]uek |
2012-09-06 |
2.6.39-400.* |
Not vulnerable |
更多内容请参考:OracleLinux: leap seconds in Oracle Linux (文档 ID 2012659.1)
闰秒问题主要影响Oracle RAC环境,另外对于单机,如果数据库环境配置了ntp服务,并且使用了timestamp数据类型的话,也可能出现相关错误。
对于Oracle10.2.0.4之前的版本,如果满足如下2个条件,那么则会受闰秒的影响:
1) 启用了ntpd服务但是没有启用slew特性(默认不会启用)
2) 没有安装相关bug (5015469 或 6022204)的补丁
我相信现在已经很少有10.2.0.4之前的Oracle版本了,因此影响面积不会太大。当然也不排除某些客户的数据库环境仍然使用了一些较老的Oracle版本。
1、Oracle 单实例环境
2、使用了第三方集群管理软件,例如Veritas Storage Foundation、Solaris cluster等
3、Oracle RAC集群,且clusterware版本高于10.2.0.4的环境。
4、未使用ntp的环境也不受闰秒的影响。
注意,这里并非说这些环境完全不受闰秒的影响,如果假设一个Oracle 10.2.0.4的单实例数据库部署在Linux 5.5版本中,且启用了ntpd服务,当闰秒出现时,可能面临ORA-01852错误的问题。请参考后文描述。
闰秒与ORA-01852错误
对于Oracle ora-01852错误很好理解,当数据库中使用了date或timestamp列的数据类型时,当进行数据插入时,如果的value为60,那么比如会报错。因为Oracle只允许范围是0~59。当闰秒出现时,则会出现23:59:60的情况,如果应用程序插入时间时,使用了系统默认时间,且系统恰好受闰秒的影响,那么此时则会报错。
如下是一个例子:
SQL>create table t_1231(a number,b date);
Table created.
SQL>insert into t_1231 values(1,to_date('2016-12-31 23:59:60','yyyy-mm-dd hh24:mi:ss'));
insert into t_1231 values(1,to_date('2016-12-31 23:59:60','yyyy-mm-dd hh24:mi:ss'))
*
ERROR at line 1:
ORA-01852: seconds must be between 0 and 59
SQL>drop table t_1231;
Table dropped.
SQL>create table t_1231(a number,b timestamp(8));
Table created.
SQL>insert into t_1231 values(1,to_timestamp('2016-12-31 23:59:60.1','yyyy-mm-dd hh24:mi:ss.ff'));
insert into t_1231 values(1,to_timestamp('2016-12-31 23:59:60.1','yyyy-mm-dd hh24:mi:ss.ff'))
*
ERROR at line 1:
ORA-01852: seconds must be between 0 and 59
实际上,对于这种情况,可以通过使用varchar2来代替date或者timestamp类型。当然对于已经上线的业务系统,我们不可能再进行随意的修改,只能通过其他方法来进行规避。
如何解决闰秒对系统环境的影响
对于Oracle数据库环境来讲,推荐使用修复ntp服务的启动方式来进行解决闰秒的影响。这里针对不同的Oracle数据库环境,分别进行说明。
Solaris如果是Solairs 8、9、10版本,那么通过设置xntpd服务的“slew”特性来避免闰秒的影响。修改/etc/inet/ntp.conf添加如下内容:
slewalways yes
disable
修改完毕之后,重启ntpd服务即可,不同版本重启命令有所不同。
Solaris 10: svcadm restart ntp
Solaris 8 and 9: /etc/init.d/xntpd stop ; /etc/init.d/xntpd start
如果是Solaris10或者更新的版本,使用的是ntpd(NTPv4),那么可以通过启动NTPv4服务的 "slew_always = true"功能来避免。
建议在闰秒到来之前24小时将ntp服务停掉,并以 "slew_always = true" 的方式来启动。
不同的Solaris版本处理方式有所不同,这里不做过的描述,请参考Leap Second Handling in Solaris- NTPv3 and NTPv4 (文档 ID 1019692.1)。
LinuxAix修改/etc/sysconfig/ntpd参数文件,添加:OPTIONS="-u ntp:ntp -p/var/run/ntpd.pid -x" 然后重启ntpd服务。
注意,必须在闰秒到来之前修改并重启ntpd服务。
Hp unix修改/etc/rc.tcpip文件,并添加如下内容然后重启ntp服务。
start /usr/sbin/xntpd"$src_running" "-x"
修改/etc/rc.config.d/netdaemons文件,并增加如下内容:
NTPDATE_SERVER=
XNTPD=1
XNTPD_ARGS="-x"
然后重启ntp服务。
由于Oracle exadata环境也是Linux环境,因此闰秒必然对exadata环境也有一定影响。
当版本为12.1.2.1.0且默认安装的ntpd包为ntp-4.2.6p5-1.el6时,会受到闰秒的影响,oracle建议升级到12.1.2.1.1或者更新版本。当然升级的风险是比较大的,我们也不推荐这样做。
建议仍然采用调整ntp的方式来规避该问题。比如之前的将ntp以-x方式启动或者直接在闰秒来临之前先将ntpd服务停掉,等闰秒过去之后再启动ntpd服务即可。
闰秒对Oracle EM的影响
解决方法就是下面的方式来重置时间。
# /etc/init.d/ntpd stop
# date -s "`date`"
# /etc/init.d/ntpd start
总结
1、影响几乎所有的操作系统,特别是对于大部分Linux版本,可能导致系统出现hung、应用程序消耗cpu 100%的情况。
2、影响Oracle 10.2.0.4以下的老版本数据库环境,对于10.2.0.4+版本几乎是没有影响的。
3、建议通过调整操作系统的ntp服务来进行问题规避,例如以-x方式启动或者在闰秒来之前暂时关闭ntp服务,闰秒过去之后再启动即可。
4、闰秒问题并不可怕,请从容以对~