oracle检查监听是否启动,windows 2003 server上oracle 11.2.0.1 监听listener启动关闭及查看状态运行缓慢...

故障现象

某客户反映，应用时断时续，连接不上数据库

数据库版本：

oracle 11.2.0.1

操作系统版本

windows 2003 server

处理过程

经过分析与诊断，

1，  客户windows2003主机，共计安装5个数据库实例，如下：

2，问题表现为：应用连接忽断忽慢，通过tnsping ebizdev，发现最高延迟达到53240ms,或者hang在哪儿没反应

3，登陆到ebizdev数据库实例，因为客户反映应用连接不上此数据库

select event from v$session where wait_class<>'Idle';

只有一条记录，说明数据库很闲，没人用啊

4，应用连接不上，会不会监听出了问题，尝试查看监听状态

lsnrctl status

此命令一运行，就hang在哪儿不动了，特别慢

多次尝试上次命令，结果相同，慢，hang在哪儿

5，查看监听日志

发现监听日志目录里面的文件共计达到7G左右，经在MOS查找，发现如果监听日志文件过大，会导致应用连接数据库非常慢或者HANG

清理监听器日志文件

请参考：How to Rotate or Purge Listener Log Data to Avoid Large listener.log File? (文档 ID 1457196.1)

6，然后重启监听，问题依旧

7，我们知道自11G开始，监听器日志文件位下如下位置，从上述可知，云服务器共创建了5个数据库实例，会不会其它的数据库实例没有使用另外的监听日志文件，即原来的名称listener.log，为何这样想呢，因为监听启动特别慢，监听进程要向监听日志文件写日志，因为不同数据库实例配置的监听日志文件不一致，导致监听进程写入混乱，所以启动特别慢

8，沿着这个思路，找到旧的监听日志文件listener.log,大家注意观察，看修改日期，listener.log文件更新到8月2号，而其它的trc文件一直更新到最近的日期

9，查看上述最新的TRC文件，发现如下内容

这下真相大白，和我前面的分析是一致的，因为每个数据库实例使用的监听日志文件不一样，导致监听进程在注册数据库实例时出现混乱

10，有了思路，哪我们就可以上述的旧的listener.log删除，让所有数据库实例使用统一的新的log.xml

删除报错，再一次佐证了，旧的监听日志文件仍有进程使用

11，处理方法：

@关闭所有的数据库实例，这样旧的监听日志文件就可以释放出来，不被锁定，最终删除此文件

@重启所有的数据库实例，启动监听，一切正常

12，验证

lsnrctl stop

lsnrctl start

lsnrctl status

sqlplus sys/system@cmcc as sysdba

sqlplus sys/system@ceec as sysdba

sqlplus sys/system@ebizdev as sysdba

sqlplus sys/system@orcl as sysdba

sqlplus sys/system@ebizdes as sysdba

13,告知客户，应用正常使用