闰秒问题的全面解读与防范

最新推荐文章于 2023-04-25 17:10:33 发布

AlanChen

最新推荐文章于 2023-04-25 17:10:33 发布

阅读量3k

点赞数 1

分类专栏： Oracle DBA

Oracle DBA 专栏收录该内容

12 篇文章 3 订阅

订阅专栏

转载 2016-12-28 李真旭闰秒问题的全面解读与防范闰秒问题的全面解读与防范闰秒问题的全面解读与防范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
OL6	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 环境？

闰秒问题主要影响Oracle RAC环境，另外对于单机，如果数据库环境配置了ntp服务，并且使用了timestamp数据类型的话，也可能出现相关错误。

对于Oracle10.2.0.4之前的版本，如果满足如下2个条件，那么则会受闰秒的影响：

1）启用了ntpd服务但是没有启用slew特性（默认不会启用）

2）没有安装相关bug （5015469 或 6022204）的补丁

我相信现在已经很少有10.2.0.4之前的Oracle版本了，因此影响面积不会太大。当然也不排除某些客户的数据库环境仍然使用了一些较老的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