今年6月30号又将面临闰秒(leap seconds)的影响
本站文章除注明转载外，均为本站原创： 转载自love wife love life —Roger的Oracle/MySQL/PostgreSQL数据恢复博客
本文链接地址: 今年6月30号又将面临闰秒(leap seconds)的影响
什么是闰秒？
闰秒是在协调世界时（UTC）中增加或减少一秒，使它与平太阳时贴近所做调整。UTC，是透过广播作为民用时的官方时间基础，它使用非常精确的原子钟来维护。要保持UTC与平太阳时的一致性，偶尔需要调整，也就是”跳个”1秒来做调整，就是所谓添加闰秒（请参阅ΔT）。闰秒时间现在是由国际地球自转和参考座标系统服务（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]。(来自维基百科)
闰秒的出现时间
闰秒的影响
从当前所了解的一些参考资料来看，主要是针对linux和solaris存在影响。 主要影响是因为使用ntp的缘故。
对于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 的中间版本.
对于solaris，影响solaris 8、9、10等几个版本，最新的solaris 11不受影响。
闰秒对Oracle的影响
1）对于Oracle RAC
如果是11.2以下版本的rac（10.2.0.4/5不受影响)，那么可能出现节点重启的情况，详见 mos文档:
NTP leap second event causing Oracle Clusterware node reboot (文档 ID 759143.1)
备注：如果使用了第三方管理软件，那么不受影响，如果是仅用Oracle clusterware，那么则会有问题。
2）非RAC环境
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
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.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
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 |
相关参考文档:
Leap seconds (extra second in a year) and impact on the Oracle database. (文档 ID 730795.1)
Leap Second on Oracle SuperCluster (文档 ID 1991954.1)
Leap Second on Oracle SuperCluster (文档 ID 1991954.1)
What Leap Second Affects Occur In Tuxedo? (文档 ID 1461363.1)
NTP leap second event causing Oracle Clusterware node reboot (文档 ID 759143.1)
http://www-01.ibm.com/support/docview.wss?uid=swg21602521
总结：
1、对于传统企业来讲如果使用linux，10204+的版本应该没有任何影响（排除timestamp的问题外)
2、建议检查应用，如果使用了timestamp，那么应用可能会报错ORA-01852
3、闰秒主要影响linux和solaris.
4、2015年6月30号将会出现如下的情形：
23:59:57 -> 23:59:58 -> 23:59:59 -> 23:59:60 -> 00:00:00 -> 00:00:01
Leave a Reply
You must be logged in to post a comment.