作者归档：Lynn

关于Lynn

Oracle DBA is my Occupation dream, Focus on Oracle, Love the life! I hope I can make a difference in this industry.

生活的意义

发表回复

自去年11月从帝都迁徙到魔都，也许是因为换了一个环境，心境也随之发生了些许变化，但总体上对于这些改变还算满意。不过最近内心却又开始焦躁不安了，我时常会思考如何让自己的生活变得更有意义，至少能满足于所选择的生活，这也许就是所谓的得了一种间歇性思考人生意义的病。

思考人生的意义，每每想到此，我才发现曾经我完全高估了自己，原来我也怕孤独和寂寞，原来我也是一个内心空白的人，最后唯有拼命工作才可以让自己感觉到原来我还活着。

到底什么样的生活才是自己希望得到的，曾思考良久，觉得应该是择一城一人慢慢终老，可是随时光更迭，才发现这一人可能今生再也不会出现，这一城今生也无法安居，于是开始思考如何独自过好自己的一生。

心气再高的人，也都会有低到尘埃里去的时候，或许选择稳定的人生，比起选择奋斗和改变，还需要更大的决心。而我们所有的恐惧，其实都来自于，我们太偏执于获得结局时的皆大欢喜，只有无所凭借的时候，我们才能获得真正的自由。

如果有朝一日，我们选择把自己关在一个家庭里，如果有朝一日，我们为自己选择了一种笃行一世的生活方式，那一定是因为，我们在那里获得了一种真正的自由与喜乐。

倘若我足够爱你，那么即使此时窗外的茫茫大雪覆盖了来去的路径，即使此生乏味琐碎如尘埃，即使未来人生的漫漫长路永远都是一成不变的安静与寂寞，我想这大抵也没有什么好害怕的了。

本文部分节选于微信公众号《十点读书》文章《意气与尘埃》。

闰秒对Oracle RAC的影响

发表回复

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:  
                   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

3）Oracle EM agent或OMS过度Linux OS CPU
该情况所涉及的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或是系统。

4.总结
除了按照上述Oracle建义来应对闰秒事件所造成的结果，同时为了尽可能避免闰秒事件可能导致的影响，最好是在闰秒日调整之前半小时，先将数据库环境下NTP Server和Client时间同步，然后停止服务器NTP，当闰秒调整结束后再开启服务器NTP继续同步。

5.参考文档
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