大于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文件大小的限制,具体见:

 

http://lkml.indiana.edu/hypermail/linux/kernel/9912.3/0009.html
http://linuxmafia.com/faq/VALinux-kb/2gb-filesize-limit.html

 

在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,重启一下多少也要耗些晨光就是了。

 

 

 

关注dbDao.com的新浪微博

扫码关注dbDao.com 微信公众号:

  1. 任何时候看来都不要轻易相信传说,时时要有质疑的精神。
    It’s like “Seeing is believing” or “Don’t believe it, test it” :)
    谢谢Maclean精彩分析,分享。

  2. Pingback: SQL Server 2014 Essentials for Oracle DBAs: (01) Database and Instances | Munin-Hugin.com

  3. 我遇到的 在64位 windows下 oracle 11gR2 listener.log大于 4G多的时候 程序无法通过监听链接数据库 清空日志就好了 为啥呢?

  4. 我遇到了 windows 64位下 oracle 11gR2 listener.log大于4G多就无法通过监听器链接oracle了 为啥呢

  5. 我遇到了 windows 64位下 oracle 11gR2 listener.log大于4G多就无法通过监听器链接oracle了 为啥呢

  6. 我遇到了 windows 64位下 oracle 11gR2 listener.log大于4G多就无法通过监听器链接oracle了 为啥呢

  7. 我遇到了 windows 64位下 oracle 11gR2 listener.log大于4G多就无法通过监听器链接oracle了 为啥呢

沪公网安备 31010802001379号

TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569