最近遇到一个ORACLE本身的日志bug问题。查询过程让人很惊心！

最近维护的网站突然报数据库访问不了，很奇怪，都没人动过，无缘无故访问不了DB，用plsql登录下，发现报错无监听，更奇怪了。

后面重新建监听还是没用，最后同事发现是ORACLE日志达到4G造成的，删掉listen.log就好了，汗颜到不行。

这时候朋友怀疑是不是监听器配置问题，就把原先的监听器删除重建了下，问题依然。

网上有个解决TNS-12535错误的案例，平台和版本都很类似，如下：

1、在 sqlnet.ora文件中 增加如下行:

DIAG_ADR_ENABLED = OFF

2、在listener.ora文件中增加如下行:

DIAG_ADR_ENABLED_<listenername> = OFF

如何监听是listener时,则前面的名称为:DIAG_ADR_ENABLED_LISTENER = OFF

3、重新启动windows服务管理中的监听程序.先停止,然后再重新启动.

4、检查结果.发现可以了,返回的值在10毫秒.有时为0毫秒.成功!!

但这并不是问题发生原因，在继续排查过程中偶然发现监听日志大小居然为4G。然后把这现象告诉了Luocs。

过了一会儿，Luocs回应是Oracle一个BUG，BUG号为9879101 : THE CONNECT THROUGH LISTENER WAS SLOW WHEN LISTNER LOG GROWED 4GB。

 

一篇文章，里面给出了解决方法：

You can solve this problem by deleting the large listener in $ORACLE_BASE\diag\tnslsnr\
    
     \listener\trace\
     
      .log 1) Stop the listener process using the command line or Control Panel Service. 2) Delete the log file(s) that are at or approaching the 4G size limit at this location: $ORACLE_BASE\diag\tnslsnr\
      
       \listener\trace\
       
        .log 3) Issue any lsnrctl command and you will see a new listener.log in its place under: $ORACLE_BASE\diag\tnslsnr\
        
         \listener\trace\ Since ADR Diagnostics are enabled for this listener these steps cannot be done dynamically using the lsnrctl utility. e.g. LSNRCTL>set log_file mylog Will yield: TNS-01251: Cannot set trace/log directory under ADR. However, it is possible to disable the flat file listener logging using the following commands: LSNRCTL>set current_listener 
         
           LSNRCTL>set log_status OFF LSNRCTL>save_config
         
        
       
      
     
    

我就按照以上说明如下进行：

1）LSNRCTL进入交互模式

2）执行set current_listener LISTENER

3）set log_status off

4）stop 停止监听器

5）手工删除ADR指定的监听日志路径下的listener.log文件

6）start重启监听器

7）status查看状态

到此问题解决。

虽然最后解决过程仅仅耗费了短短几分钟时间，但整个排错过程却是令人惊讶。在此整理，并与遇到同样问题的朋友分享。