大於2GB的Listener.log和執行超過198天的主機上的Oracle例項

在Oracle業界混的兄弟們肯定聽說過以下的2個傳說：

1. LISTENER.LOG日誌大小不能超過2GB，超過會導致LISTENER監聽器無法處理新的連線

2. 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檔案大小的限制，具體見：

 

 

在AIX 的JFS檔案系統上也存在過類似的2g限制。

 

 

[oracle@vrh8 log]$ ls -lh listener.log
-rw-r----- 1 oracle oinstall 3.0G Oct 25 07:28 listener.log

[oracle@vrh8 log]$ lsnrctl status

LSNRCTL for Linux: Version 10.2.0.5.0 - Production on 25-OCT-2012 07:29:44

Copyright (c) 1991, 2010, Oracle. All rights reserved.

Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
STATUS of the LISTENER
------------------------
Alias LISTENER
Version TNSLSNR for Linux: Version 10.2.0.5.0 - Production
Start Date 25-OCT-2012 07:24:59
Uptime 0 days 0 hr. 4 min. 45 sec
Trace Level off
Security ON: Local OS Authentication
SNMP OFF
Listener Log File /s01/oracle/product/10.2.0.5/db_1/network/log/listener.log
Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=vrh8)(PORT=1521)))
Services Summary...
Service "G10R25" has 1 instance(s).
Instance "G10R25", status READY, has 1 handler(s) for this service...
Service "G10R25XDB" has 1 instance(s).
Instance "G10R25", status READY, has 1 handler(s) for this service...
Service "G10R25_XPT" has 1 instance(s).
Instance "G10R25", status READY, has 1 handler(s) for this service...
The command completed successfully

C:\Users\ML>sqlplus system/oracle@192.168.1.191:1521/G10R25

[oracle@vrh8 log]$ tail -f listener.log

25-OCT-2012 07:31:52 * (CONNECT_DATA=(SERVICE_NAME=G10R25)(CID=(PROGRAM=D:\app\ML\product\11.2.0\dbhome_1\bin\sqlplus.exe)(HOST=XIANGBLI-CN)(USER=ML))) * (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.1.6)(PORT=56013)) * establish * G10R25 * 0
25-OCT-2012 07:31:55 * service_update * G10R25 * 0
25-OCT-2012 07:32:06 * (CONNECT_DATA=(SERVICE_NAME=G10R25)(CID=(PROGRAM=D:\app\ML\product\11.2.0\dbhome_1\bin\sqlplus.exe)(HOST=XIANGBLI-CN)(USER=ML))) * (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.1.6)(PORT=56017)) * establish * G10R25 * 0
25-OCT-2012 07:32:10 * service_update * G10R25 * 0
25-OCT-2012 07:32:12 * (CONNECT_DATA=(SERVICE_NAME=G10R25)(CID=(PROGRAM=D:\app\ML\product\11.2.0\dbhome_1\bin\sqlplus.exe)(HOST=XIANGBLI-CN)(USER=ML))) * (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.1.6)(PORT=56018)) * establish * G10R25 * 0
25-OCT-2012 07:32:13 * service_update * G10R25 * 0
25-OCT-2012 07:32:17 * (CONNECT_DATA=(SERVICE_NAME=G10R25)(CID=(PROGRAM=D:\app\ML\product\11.2.0\dbhome_1\bin\sqlplus.exe)(HOST=XIANGBLI-CN)(USER=ML))) * (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.1.6)(PORT=56020)) * establish * G10R25 * 0

 

 

以上演示用以證明至少在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即追加到檔案的尾端，一般來說追加寫方式不會因為檔案越大寫地越慢。

 

 

access("/etc/listener.ora", F_OK)       = -1 ENOENT (No such file or directory)
access("/s01/oracle/product/10.2.0.5/db_1/network/admin/listener.ora", F_OK) = -1 ENOENT (No such file or directory)
open("/s01/oracle/product/10.2.0.5/db_1/network/log/listener.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = 3
fstat(3, {st_mode=S_IFREG|0640, st_size=3145741535, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f60cadc3000

 

我想說明的是對於 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號有《 4612267  OCI client spins when machine uptime >= 249 days》、 《OCI CLIENT IS IN AN INFINITE LOOP WHEN MACHINE UPTIME HITS 248 DAYS》。

 

這個BUG之所以能讓大家銘記，恐怕與其會因為和主機執行的天數而觸發的特點不無關係； 10.2.0.1是10gR2的base release，又因為國內有大量的企業對資料庫的版本patchset升級不夠重視，所以該BUG在07、08年之前時不時地給業界的朋友帶去困擾。

 

但實際上該 BUG被發現後，Oracle立即釋出了在10.2.0.1上的one-off patch來解決該問題，而且在後續的10.2.0.2 patchset中也引入了對該BUG的修復，換而言之除非你仍在使用版本10.2.0.1，否則你無需要擔心主機不重啟執行到某一日子會導致Oracle出故障。

 

雖說該BUG可以透過種種手段修復，乃至若干年後大家開始真正大規模部署或升級到10gR2後(國內大規模用10gR2按照maclean的瞭解在07、08年之後)，基本都是安裝base release 10.2.0.1或升級到10.2.0.4/10.2.0.5，部分產品資料庫有還在用10.2.0.2或10.2.0.3的，但是絕大多數(90%以上)重要的資料庫不會用10.2.0.1的情況下，以上這一長串是大背景。

 

Maclean在行走江湖之際，特別是在運營商那裡， 還是有聽到或是系統整合上、或是運維外包、或是電信業的服務提供商的工程師， 仍在向甲方的同學傳誦這個198/248/249(24.9)天的故事， 而且說起這個故事時繪聲繪色，大有錢鍾書小說裡《圍城》：”李梅亭忙把長沙緊急的訊息告訴寡婦，加油加醬，如火如荼，就彷彿日本軍部給他一個人的機密情報”的風采。

 

執行超過198天的主機上的Oracle可能遇到BUG導致CPU大量消耗這個傳說，對於版本10.2.0.1來說是不錯的，所以也並不能說這個資訊是不正確的。 但是對於patch set 10.2.0.2以後的版本無需杞人憂天這個問題了，雖然重啟一下主機無傷大雅，但小機畢竟不是Windows，重啟一下多少也要耗些晨光就是了。