ANBOB™

科学上有两种时间计量系统：基于地球自转的天文测量而得出的“世界时”和以原子振荡周期确定的“原子时”。“世界时”由于地球自转的不稳定（由地球物质分布不均匀和其它星球的摄动力等引起的）会带来时间的差异，“原子时”（一种较恒定的时制，由原子钟得出）则是相对恒定不变的。这两种时间尺度速率上的差异，一般来说一至二年会差大约1秒时间。1971年国际计量大会通过决议：使用“协调世界时(UTC) ”来计量时间。当“协调世界时”和“世界时”之差超过0.9秒时，国际地球自转服务组织（IERS）就负责对“协调世界时”拨快或拨慢1秒，这就是闰秒。闰秒一般加在公历年末或公历六月末。

不增加闰秒的影响
如果不增加闰秒会有什么影响呢？如果按照世界时与原子时之间时差的累积速度来看（43年减慢了25秒），大概在七八千年后，太阳升起的时间可能就会与现在相差2个小时了，本来中午12点太阳当头照，而七八千年后就要下午2点太阳才当头照了。

因为我国是东八时区(UTC+8),所以我国将在北京时间2017年1月1日的7时59分59秒也会做闰秒调整和全球同步，到时会出现7:59:60的特殊现象。但是我们常用的电子产品如果有时间自动校正都不会影响.但是对时间敏感的系统不可忽略,像航天领域, 我们的数据库系统应该也要做好检查, 润秒有可能会使OS Reboot,应用HANG, Clusterware restart问题.

关于ORACLE环境在ORACLE MOS Information Center: Leap Second Information for All Products – Database – Exadata – Middleware – Exalogic – Linux – Sun – Fusion – EBS – JDE – Siebel – Peoplesoft (Doc ID 2019397.2)中描述的很详细.The next leap second will be added on December 31, 2016 23:59:60 UTC.

2017/1/1这次增加一秒后显示为:

23:59:57 -> 23:59:58 -> 23:59:59 -> 23:59:60 -> 00:00:00 -> 00:00:01

数据库以下环境不会受影响:

1, 单实例数据库
2, 使用了第三方 cluster 软件，如 Sun Cluster or Veritas SFRAC 配置。
3, 使用 Oracle Clusterware 10.2.0.4（Server Patch Set）,11.1.0.7, 11.2.0.3, 12.1.0.1及更高的GI版本
4, 没有配置NTP, 系统使用本地时间,不会关心闰秒,因为没有做时间调整,而是会与实际相差1秒

以下10.2.0.4以前(老)的版本的RAC环境会可能受影响,但同时满足如下2个条件：

1. xntpd daemon does not have slewing enabled (default) or does not have PLL mode disabled (default)
2.  not have a fix for bug 5015469 or bug 6022204 or the Oracle Clusterware version does have a fix for at least one these defects, but due to Solaris CR#6595936 the alarm signal arrival has been delayed exceeding the oprocd 0.5 sec default margin (only Solaris)

解决方法:
ORACLE同样是推荐修改NTP方式

a). 在linux中修改/etc/sysconfig/ntpd中，修改:
OPTIONS="-u ntp:ntp -p /var/run/ntpd.pid -x"，使用-x参数启动ntp。

b). 在solaris中修改/etc/inet/ntp.conf中，添加:
slewalways yes
disable pll

c). 在AIX中修改/etc/rc.tcpip文件
start /usr/sbin/xntpd "$src_running" "-x"   ,增加-x

d). 在HPUX中修改/etc/rc.config.d/netdaemons
NTPDATE_SERVER=
XNTPD=1
XNTPD_ARGS="-x"

e). 其它系统咨询厂商

NOTE:
Restart the xntpd and Clusterware after change NTP

另外:如果数据库当时insert xx:xx:60的闰秒到时间类型字段时会出现ora-1852, 解决方法可以用varchar2储存. 这难道是有些银行库字段使用varchar存储时间列的原因?我不知道.

下列MySQL版本不会受闰秒影响:

5.5 and higher.
version 5.1.31 and higher
version 5.0.74 and higher

1,The function NOW() will return ...:59:59 twice.
2,Even if the OS shows ...:59:60 will MySQL change it to ...:59:59.

ORACLE LINUX 和 OVM影响:

对于Linux而言 ，内核版本大于2.6.22的都受影响,含OEL5,6,\UEK\ RHEL4,5,6,7\ SUSE11,  对于RHEL环境建议阅读这篇Resolve Leap Second Issues in Red Hat Enterprise Linux

对于这个问题的预防可以使用下面的方法:

/etc/init.d/ntpd stop
date -s “`date`”
/etc/init.d/ntpd start

对OEM\ Java API 的影响

闰秒对于JVM的影响可能会出现java进程cpu使用100%现象, 同样oracle 的EM或Cloud Control也是基于java的应用,  影响的版本从10.2.0.5 到 12c, 包含EM agnet和OMS,  解决方法是reset 时间, 重启应用, 如果不能解决重启服务器.

对于ORACLE EXADATA的影响

对于EXADATA没有运行在 12.1.2.1.0.版本上的环境不需要执行操作, 但是如果是这个版本, 参考MOS note 1986986.1更新NTP配置.

References:
百度百科
Information Center: Leap Second Information for All Products – Database – Exadata – Middleware – Exalogic – Linux – Sun – Fusion – EBS – JDE – Siebel – Peoplesoft (Doc ID 2019397.2)
How Leap Second Affects The OS Clock on Linux and Oracle VM (Doc ID 1453523.1)
NTP leap second event causing Oracle Clusterware node reboot (Doc ID 759143.1)
Related questions with leap second on mysql (Doc ID 1450441.1)

打赏

微信扫一扫，打赏作者吧～