1.什么是闰秒
闰秒是在协调世界时（UTC中增加或减少一秒，使它与平太阳时贴近所做调整。UTC，是透过广播作为民用时的官方时间基础，它使用非常精确的原子钟来维护。要保持UTC与平太阳时的一致性，偶尔需要调整，也就是“跳个”1秒来做调整，就是所谓添加闰秒。闰秒时间现在是由国际地球自转和参考作坐标系统服务（IERS）来确认，而在1988年1月1日之前是由国际时间局（BIH）承担这项职责。
当要增加正闰秒时，这一秒是增加在第二天的00:00:00之前，效果是延缓UTC第二天的开始。当天23:59:59的下一秒被记为23:59:60，然后才是第二天的00:00:00。如果是负闰秒的话，23:59:58的下一秒就是第二天的00:00:00了，但目前还没有负闰秒调整的需求。需要时的日长度必须低于1750-1892年的平均日长度，才会累积足够调整1秒所需要的时间。除了每天4毫秒的波动外，日长度自1700年以来都保持一样[1]。然而，从历史上的日食观测则显示，自公元前700年以来，每个世纪的日长度大约增加1.7毫秒[2]。（来自维基百科）
2.闰秒的出现时间
3.闰秒的影响
从当前所了解的参考资料信息来看，闰秒主要会对Linux和Solaris平台系统存在影响，其主要影响是因为使用NTP的缘故，可能会导致OS CPU使用率100%。对于Oracle Database影响，则主要可能会导致RAC节点重启，EM OMS或Agent所导致的OS CPU使用100%，以及因为执行与时间戳数据类型相关的SQL而导致的ORA-01852错误。
3.1对于Linux影响
内核版本大于2.6.22的都受影响，详见：
http://www-01.ibm.com/support/docview.wss?uid=swg21602521
主要是可能出现CPU使用100%的情况，详见Leap Second Hang – CPU Can Be Seen at 100% (文档 ID 1472421.1)，根据该文档描述，主要影响是Linux 4.4 – Linux 6.2的中间版本。该情况所涉及的OS环境版本范围：
Oracle VM – Version 2.1.1 to 3.1.1 [Release OVM211 to OVM31]
Linux OS – Version Oracle Linux 4.4 to Oracle Linux 6.2 with Unbreakable Enterprise Kernel [2.6.39] [Release OL4U4 to OL6U2]
Information in this document applies to any platform.
当ntpd调用adjtimex(2)告知kernel插入a leap second所导致livelock而引发的bug
解决办法：
# /etc/init.d/ntpd stop
# date -s “`date`” (reset the system clock)
# /etc/init.d/ntpd start
Or Reboot the Server.
3.2对于Solaris影响
影响Solaris 8、9、10等几个版本，最新的Solaris 11不受影响，解决办法与3.1类似，重启NTP或系统。
3.3闰秒对Oracle的影响
1）RAC集群节点重启
该情况所涉及的Oracle环境版本范围：
Oracle Server – Enterprise Edition – Version 10.1.0.2 to 11.1.0.7 [Release 10.1 to 11.1]
Oracle Solaris on SPARC (64-bit)
Oracle Solaris on x86-64 (64-bit)
Sun Solaris SPARC (64-bit)Sun Solaris x86-64 (64-bit)
Oracle Clusterware and patchsets 10.2.0.1 – 11.1.0.7
Sun Solaris 5.8 – 5.10 adjusting time through NTP daemon (xntpd)
解决办法：
（1）对于通用平台OS下NTP都应该使用NTP daemon with -x 参数选项，对于Solaris还要进行如下操作来避免集群node reboot：
Configure xntpd Solaris daemon running on the Oracle Clusterware cluster node to
disable PLL mode and enable slewing
adding to the /etc/inet/ntp.conf file the two lines: 3）Oracle EM agent或OMS过度Linux OS CPU 4.总结 5.参考文档
slewalways yes
disable pll
To restart xntpd the commands are:
Solaris 10: svcadm restart ntp
Solaris 8 and 9: /etc/init.d/xntpd stop ; /etc/init.d/xntpd start
这里还需要注意一点（针对Sun Solaris），如果无法保证NTP server和client时间同步，在重启集群或系统之前一定要先修改ntp.conf文件重启xntpd服务。
2）打Oracle Clusterware patch bundles or a recent MLR (i.e. MLR # 9 or higher) in order to resolve bugs 5015469 and 6022204补丁。针对Sun CR#6595936问题，可以修改cluster oprocd daemon进程的timeout margin>5s解决。
（2）ORA-01852错误
由于闰秒事件导致一分钟>60秒，此时如果恰好在数据库中执行插入带有时间戳的SQL语句时会报ORA-01852错误。
该情况所涉及的Oracle Database环境版本范围：
Oracle Database – Enterprise Edition – Version 8.1.7.4 and later
Oracle Database – Standard Edition – Version 8.1.7.4 and later
Information in this document applies to any platform.
出现该报错的原因是因为Oracle数据库无法存储大于59秒的日期时间戳数据
解决办法：
创建varchar2数据类型表去存储闰秒的时间戳记录：
SQL> select * from v$version;
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - Production
PL/SQL Release 11.2.0.2.0 - Production
CORE 11.2.0.2.0 Production
TNS for Linux: Version 11.2.0.2.0 - Production
NLSRTL Version 11.2.0.2.0 - Production
SQL> create table t_630(a number,b timestamp(8));
Table created.
SQL> insert into t_630 values(1,to_timestamp('2015-06-10 12:10:10.1','yyyy-mm-dd hh24:mi:ss.ff'));
1 row created.
A B
---------- ---------------------------------------------------------------------------
1 10-JUN-15 12.10.10.10000000 PM
SQL> insert into t_630 values(2,to_timestamp('2015-06-30 23:59:60','yyyy-mm-dd hh24:mi:ss'));
insert into t_630 values(2,to_timestamp('2015-06-30 23:59:60','yyyy-mm-dd hh24:mi:ss'))
*
ERROR at line 1:
ORA-01852: seconds must be between 0 and 59
对于此问题，Oracle建议使用varchar2数据类型来替代timestamp
SQL> drop table t_630 purge;
Table dropped.
SQL> create table t_630(a number,b varchar2(30));
Table created.
SQL> insert into t_630 values(1,'2015-06-10 12:10:10');
1 row created.
SQL> insert into t_630 values(2,'2015-06-30 23:59:60');
1 row created.
SQL> commit;
Commit complete.
SQL> select * from t_630;
A B
---------- ------------------------------
1 2015-06-10 12:10:10
2 2015-06-30 23:59:60
该情况所涉及的Oracle EM环境版本范围：
Enterprise Manager Base Platform – Version 10.2.0.5 to 10.2.0.5 [Release 10.2]
Enterprise Manager Base Platform – Version 11.1.0.1 to 11.1.0.1 [Release 11.1]
Enterprise Manager Base Platform – Version 12.1.0.1.0 and later
Linux x86
Linux x86-64
该情况在系统层面表现可能如下：
Check top on the system:
$ top – 09:38:24 up 354 days, 5:48, 4 users, load average: 6.49, 6.34, 6.44
Tasks: 296 total, 4 running, 292 sleeping, 0 stopped, 0 zombie
Cpu(s): 97.2%us, 1.8%sy, 0.0%ni, 0.7%id, 0.1%wa, 0.1%hi, 0.2%si, 0.0%st
Mem: 15991M total, 15937M used, 53M free, 107M buffers
Swap: 8110M total, 72M used, 8038M free, 13614M cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
22564 oracle 16 0 1400m 421m 109m S 353 2.6 2225:11 java <<<<<<< Note: Java PID consuming 353% CPU
7294 oracle 17 0 3096m 108m 104m S 22 0.7 0:02.61 oracle
Check for the following message from dmesg:
$ dmesg | grep -i leap
[10703552.860274] Clock: inserting leap second 23:59:60 UTC
解决办法：
该情况的解决办法与3.1类似，重启NTP或是系统。
除了按照上述Oracle建义来应对闰秒事件所造成的结果，同时为了尽可能避免闰秒事件可能导致的影响，最好是在闰秒日调整之前半小时，先将数据库环境下NTP Server和Client时间同步，然后停止服务器NTP，当闰秒调整结束后再开启服务器NTP继续同步。
Leap seconds (extra second in a year) and impact on the Oracle database. (文档 ID 730795.1)
Enterprise Manager Management Agent or OMS CPU Use Is Excessive near Leap Second Additions on Linux (文档 ID 1472651.1)
Leap Second on Oracle SuperCluster (文档 ID 1991954.1)
NTP leap second event causing Oracle Clusterware node reboot (文档 ID 759143.1)
leap seconds in Oracle Linux (文档 ID 2012659.1)
Insert leap seconds into a timestamp column fails with ORA-01852 (文档 ID 1553906.1)
Leap Second Time Adjustment (e.g. on June 30, 2015 at 23:59:59 UTC) and Its Impact on Exadata Database Machine (文档 ID 1986986.1)
ODA (Oracle Database Appliance): Leap Second adjustment impact (文档 ID 2015972.1)
Related questions with leap second on mysql (文档 ID 1450441.1)
http://www-01.ibm.com/support/docview.wss?uid=swg21602521