大于2GB的Listener.log和运行超过198天的主机上的Oracle实例

在Oracle业界混的兄弟们肯定听说过以下的2个传说：

LISTENER.LOG日志大小不能超过2GB，超过会导致LISTENER监听器无法处理新的连接

Oracle Instance实例所在的主机运行超过198天必须重启，否则会遇到Oracle BUG

第一条传说LISTENER.LOG日志不能超过2GB，这个绝对是老DBA津津乐道要向新手介绍的经典经验之一，这条传说带来的负面思想是Oracle数据库的监听器最好不要启动过长时间， LISTENER.LOG日志的内容也要定期清理(这条还是应当推荐的)。 以上这个问题在本世纪初大量32bit OS存在的情况下仍是真理，毕竟在当时2GB的文件还算是挺大的。 引起该问题的主要原因是大量32bit OS自带的文件系统不支持2GB以上的文件，导致监听器append write，例如在Solaris 2.6上： OS Limits ~~~~~~~~~ Release Max file-system size Max OS File size < Solaris 2.6 1Tb (UFS) 2Gb >= Solaris 2.6 1Tb (40 bits) 1Tb   在32bit 的Linux上也存在过该2GB文件大小的限制，具体见：   http://lkml.indiana.edu/hypermail/linux/kernel/9912.3/0009.html http://linuxmafia.com/faq/VALinux-kb/2gb-filesize-limit.html   在AIX 的JFS文件系统上也存在过类似的2g限制。    

    以上演示用以证明至少在X86-64bit Linux+Oracle 10.2.0.5下不会因为Listener.log超过3GB而导致无法创建连接。 有必要指出的是tnslsnr进程一般使用标准C函数Write写出到Listener.log，在打开listener.log文件时使用的是O_WRONLY|O_CREAT|O_APPEND，O_APPEND即追加到文件的尾端，一般来说追加写方式不会因为文件越大写地越慢。    

  我想说明的是对于 LISTENER.LOG不能超过2GB的这种信仰在10年前是值得推广的，但是对于现在来说已经过时了，虽然我们仍推荐定期清理 LISTENER.LOG 结论： 除非是老旧的32bit OS，否则一般都不会再有2GB的文件大小限制(你也可以如此判断，如果文件系统上的数据文件能超过2GB，则自证) 对于LISTENER.LOG不能超过2GB这个故事已经因为操作系统的不断更新换代而成为传说。 LISTENER.LOG>2G LIMIT的一些NOTE: Listener Fails to Start With ORA-12547 or Core Dumps at Start Attempt [ID 237737.1] Listener hangs due to LISTENER.LOG exceeding 2Gb file size limit on Solaris 2.6 (Doc ID 156098.1)   另一个传说就是 Oracle实例所在主机不能连续运行超过198或者248/249天的故事，这个故事的起因是有同学在版本10.2.0.1(据说9i上也可能遇到)的一个主机运行198/248/249(24.9)天后OCI Client出现SPIN自旋消耗大量CPU的BUG，SPIN的起因是sltrgatime64()函数对times()函数的死循环调用；BUG号有《

版权声明：原创作品，如需转载，请注明出处。否则将追究法律责任

本文转自maclean_007 51CTO博客，原文链接:http://blog.51cto.com/maclean/1278469