今天好多朋友都在讨论Leap Second(润秒）的问题（不少集成商和客户都收到Oracle的通告了）：
Oracle官方的解释也很清晰：
Oracle所有产品线关于润秒的说明：
Information Center: Leap Second Information for All Products – Database – Exadata – Middleware – Exalogic – Linux – Sun – Fusion – EBS – JDE – Siebel – Peoplesoft (Doc ID 2019397.2)
.
MySQL也会有相应的影响，比如 NOW() 函数会返回2次的xx:59:59，具体请参考oracle官方的推荐。
.
其他：
1，Tuxedo没这个问题：
No, there is no Tuxedo issue with “Leap Second” because Tuxedo uses the UNIX epoch.
.
2，Exalytics有：
Exalytics is affected with Leap second issue till Patchset 3. Leap second Issue is fixed in kernel 2.6.32-300.29.1.
.
3，一些Oracle的带库（其他带库，使用到相关NTP功能的都应该以此类推的考虑，具体需要问各自厂商）
All other tape products not using NTP, like SL8500, SL3000, 9×40, T10K and VSM4/5 are not exposed.
The NTP protocol can be used to sync time with most tape product software, using the Solaris or Linux OS.
.
4，其他Oracle相关应用和可能的表现：
比如某个进程100% CPU，例如EM 具体参见：
Enterprise Manager Management Agent or OMS CPU Use Is Excessive near Leap Second Additions on Linux (Doc ID 1472651.1)
Leap second hang – CPU can be seen at 100% Note 1472421.1
.
5，没使用NTP 的不涉及这个问题（但是在不同环境如果不使用NTP可能有其他问题，比如exadata上，NTP不当问题可能导致cell重启）。注意受影响的NTP版本：ntp-4.2.6-*，该问题在ntp-4.2.6-p5-3.el6_6 fixed了。
还有 ntp-4.2.2/4.2.4 这两种ntp版本没有问题。
.
6，推荐的解决方法：修改/etc/sysconfig/ntpd中的下面：
OPTIONS=”-u ntp:ntp -p /var/run/ntpd.pid -x”
注意其中的 -x
这个设置实际上是Oracle自从10g后，RAC配置中的标准配置，在文档中有明确的NTP配置说明（使用-x）。
.
7，下面的Oracle RDBMS 版本fixed了oracle润秒的问题：
MOS的原文如下(该文是以日本 +9区为例的，中国是正8区，因此时间是明早7:59:60)：
What is the "leap second"? The "leap second" is a world wide time adjustment by inserting or deleting one whole second to keep UTC (Universal Time, Coordinated) close to the mean solar time. Such adjustment would be made at 23:59:59 on Jun 30 or at 23:59:59 on Dec 31(UTC). Note that the clock is adjusted in UTC. Thus in Japan(UTC+9), it would be adjusted at 08:59:59 on Jul/Jan 1st. If it is inserted, the real clock will be adjusted as follows: 23:59:57 -> 23:59:58 -> 23:59:59 -> 23:59:60 -> 00:00:00 -> 00:00:01 A leap second would be deleted by omitting second 23:59:59 on one of these days, although this has never happened: 23:59:57 -> 23:59:58 -> 00:00:00 -> 00:00:01 Note that the clock is adjusted in UTC. Thus in Japan(UTC+9), it would be adjusted at 8:59:59AM on Jul/Jan 1st. What might be a problem with leap second? At the time inserting/deleting a second, OS clock(ex. obtained by gettimeofday()) could show "abnormal" time, like 23:59:60. This would not be a problem for Linux kernel, as it does not refer to the OS clock, but jiffies(kernel internal counter) instead. However, many applications could not handle the "abnormal" time and it would be a cause of a hang up of the applications, or OS reboot kicked by them. Please contact your application vendor and confirm if there are any issues with leap second. It depends on kernel, ntp configuration and OS environment what time would be returned from OS at the leap second. For example, inserting a second would bring 23:60:00 like: Case A: 2012/06/30 23:59:59.759058705 2012/06/30 23:59:59.862213189 2012/06/30 23:59:59.965647209 2012/06/30 23:59:60.068161514 <- shows 23:59:60.### 2012/06/30 23:59:60.175351284 2012/06/30 23:59:60.278096054 2012/06/30 23:59:60.381168210 2012/06/30 23:59:60.483526254 2012/06/30 23:59:60.591406966 2012/06/30 23:59:60.694055754 2012/06/30 23:59:60.797548683 2012/06/30 23:59:60.900835003 2012/07/01 00:00:00.005271538 2012/07/01 00:00:00.107279748 2012/07/01 00:00:00.219733676 or backward time, twice 23:59:59 like: Case B: 2012/06/30 23:59:59.759058705 2012/06/30 23:59:59.862213189 2012/06/30 23:59:59.965647209 2012/06/30 23:59:59.068161514 <- time backward 1sec 2012/06/30 23:59:59.175351284 2012/06/30 23:59:59.278096054 2012/06/30 23:59:59.381168210 2012/06/30 23:59:59.483526254 2012/06/30 23:59:59.591406966 2012/06/30 23:59:59.694055754 2012/06/30 23:59:59.797548683 2012/06/30 23:59:59.900835003 2012/07/01 00:00:00.005271538 2012/07/01 00:00:00.107279748 2012/07/01 00:00:00.219733676 or same time for 1 sec at 23:59:59 like: Case C: 2012/06/30 23:59:59.759058705 2012/06/30 23:59:59.862213189 2012/06/30 23:59:59.965647209 2012/06/30 23:59:59.965647209 <- same time for 1sec 2012/06/30 23:59:59.965647209 2012/06/30 23:59:59.965647209 2012/06/30 23:59:59.965647209 2012/06/30 23:59:59.965647209 2012/06/30 23:59:59.965647209 2012/06/30 23:59:59.965647209 2012/06/30 23:59:59.965647209 2012/06/30 23:59:59.965647209 2012/07/01 00:00:00.005271538 2012/07/01 00:00:00.107279748 2012/07/01 00:00:00.219733676 On the other hand, deleting a second would bring below: Case D: 2012/06/30 23:59:58.759058705 2012/06/30 23:59:58.862213189 2012/06/30 23:59:58.965647209 2012/07/01 00:00:00.005271538 <- no 23:59:59.### 2012/07/01 00:00:00.107279748 2012/07/01 00:00:00.219733676 And, there is another Case E, where the kernel does not care about the leap second, and just continues to count up its clock independently from UTC. In this case, OS clock would drift one second, and will be adjusted by ntp if configured. How about Linux without ntp? If your Linux box does not refer to ntp (ntpd service does not run), the OS clock would be affected by /etc/localtime file, which is originated in /usr/share/zoneinfo/ or /usr/share/zoneinfo/right/. By default, the Linux (including Oracle Linux) installer generates /etc/localtime from /usr/share/zoneinfo/, which does not take regard any of leap seconds. Thus it would be Case E above. If the latest "tzdata" package is installed which includes the leap second reflection date, and also /etc/localtime file was overwritten with a zoneinfo file from /usr/share/zoneinfo/right/, the OS clock would be Case A when the leap second is inserted and Case D when the leap second is deleted. However, most users do not need to consider this case, since /etc/localtime is from /usr/share/zoneinfo/ by default. How about Linux with ntp? At first, ntp should be started with "-x" option to avoid rapid clock adjustment, which is described in OPTIONS= line in /etc/sysconfig/ntpd file: OPTIONS="-u ntp:ntp -p /var/run/ntpd.pid -x" The following is in the case of "-x" option is being specified. Otherwise, OS clock could be adjusted very rapidly regardless of leap second: If your Linux system uses ntp (the ntpd service runs), it is more complicated and version-dependent. There are several cases: ntp >= 4.2.2p1-9(OL5U3 or later) runs ntp < 4.2.2p1-9 runs and on physical(baremetal) server ntp < 4.2.2p1-9 runs and on Oracle VM(Xen) Dom0, or DomU(PVM with kernel-ovs/kernel-xen) ntp < 4.2.2p1-9 runs and on Oracle VM DomU(HVM) The reason there are many cases depends on three conditions: whether ntpd receives leap indicator(=01 or 10) from its parent ntp server whether ntpd notify the leap second to kernel how the kernel handle the leap second "leap indicator" is a flag which is delivered from a parent ntp server, which indicates the next leap second is forthcoming. This can be confirmed by ntpq command: # ntpq -c rv assID=0 status=06c4 leap_none, sync_ntp, 12 events, event_peer/strat_chg,version="ntpd 4.2.2p1@1.1570-o Wed Nov 16 20:15:02 UTC 2011 (1)", processor="x86_64", system="Linux/2.6.32-300.4.1.el5uek", leap=01, stratum=5, precision=-20, rootdelay=358.828, rootdispersion=80.082, peer=35040, refid=10.137.32.190, reftime=d365b71e.438957d3 Tue, May 22 2012 15:56:30.263, poll=10, clock=d365c2f0.21f062cc Tue, May 22 2012 16:46:56.132, state=4, offset=0.921, frequency=-63.452, jitter=0.066, noise=0.328, stability=0.010, tai=0 where leap=01 means ntpd will insert a sec, leap=10 means will delete a sec, leap=00 means do nothing, leap=11 means it has not synced yet. This is from a parent ntp server, thus you can not control whether this indicator is set or not. In the case leap=00 means "do nothing", OS clock would be Case E. In fact, ntp >= 4.2.2p1-9 (with -x option) does not inform Linux kernel the status of leap indicator even if leap=01 or leap=10 is issued from its parent ntp server, due to the fix below: * Thu Sep 04 2008 Miroslav Lichvar <mlichvar@redhat.com> 4.2.2p1-9.el5 - disable kernel discipline when -x option is used (#431729) With this fix in place, Case E applies. If ntp < 4.2.2p1-9, ntpd informs the Linux kernel of the leap status via a system call "adjtimex(tx.modes=ADJ_STATUS, tx_status = STA_INS/STA_DEL)". In this case, the result of OS clock adjustment depends on the Linux kernel. If Linux kernel runs on a physical(baremetal) server, it handles the leap second insertion as Case B (could be backward) and deletion as Case D If Linux kernel is kernel-ovs or kernel-xen in a PVM, it handles leap second insertion as Case C (can never be backward) and deletion as Case D If it is not a Linux, or on HVM, it would depend on the OS We can check whether OS receives leap=01/10 from ntpd by running ntptime. In this example output inserting a sec (in the case of leap=01): # ntptime ntp_gettime() returns code 0 (OK) time d39a117d.015a0000 Sun, Jul 1 2012 8:59:57.005, (.005280), maximum error 16384000 us, estimated error 16384000 us ntp_adjtime() returns code 0 (OK) modes 0x0 (), offset 0.000 us, frequency 0.000 ppm, interval 1 s, maximum error 16384000 us, estimated error 16384000 us, status 0x10 (INS), time constant 2, precision 1.000 us, tolerance 512 ppm,
