大于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