技术头条 - 一个快速在微博传播文章的方式     搜索本站
您现在的位置首页 --> Oracle --> 大于2GB的Listener.log和运行超过198天的主机上的Oracle实例

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

浏览:4873次  出处信息

   在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限制。

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

建议继续学习:

  1. server日志的路径分析    (阅读:10110)
  2. AWStats简介:Apache/Windows IIS的日志分析工具的下载,安装,配置样例和使用(含6.9中文定义补丁)    (阅读:8858)
  3. 利用脚本分析日志并利用snmp自定义OID,再通过cacti画图    (阅读:8686)
  4. tomcat catalina.out日志切割每天生成一个文件    (阅读:8087)
  5. 分布式日志系统scribe使用手记    (阅读:8043)
  6. AWStats是一个基于Perl的WEB日志分析工具。    (阅读:6109)
  7. 使用nginx记日志    (阅读:5077)
  8. 在 shell 脚本里打日志    (阅读:4784)
  9. Sentry: 错误日志集中管理    (阅读:4355)
  10. 多服务器的日志合并统计――apache日志的cronolog轮循    (阅读:4192)
QQ技术交流群:445447336,欢迎加入!
扫一扫订阅我的微信号:IT技术博客大学习
© 2009 - 2024 by blogread.cn 微博:@IT技术博客大学习

京ICP备15002552号-1