晚上十点多,一个朋友联系我说他们的数据库有问题,客户连接不上数据库,没有任何报错,就是卡住,也不提示任何信息.
这是一台windows 数据库,单实例数据库版本为11.2.0.1.远程到服务器之后查看数据库,发现数据库运行正常,查看监听发现异常,使用lsnrctl status 直接卡住.尝试使用lsnrctl start启动,发现报错监听已经存在,查看监听服务确实已经启动.
这种情况第一反应就是监听日志文件达到了4G,导致无法写日志.根据经验进入到$ORACLE_HOEM/diag/tnslsnr下面的目录下查看监听日志文件,发现文件只有1M.
难道是监听的名称错了?查看listener.ora文件发现监听的名称也是对的.
还有一种可能,是服务器的端口占满了,但是那种情况是监听都无法启动,使用netstat -an查看端口发现也是正常的,远没有达到65535个,这里突然先入了僵局...
查找了一下mos,一篇文章也是说监听的日志文件达到了4GB导致的,但是查了没有啊?
这里我又详细检查了一下listener.ora文件,如下:
发现了一个关键的配置信息:
ADR_BASE_LISTENER=
这里配置的是ORACLE_HOME\log,正常的配置应该是ORACLE_BASE目录才对
这个配置是配置ADR目录的,也就是说监听的日志文件将写到此目录下,而不是ORACLE_BASE\diag下
因此我靠经验到$ORACLE_BASE\diag\tnslsnr下查看的trace监听日志文件是不对的.
进入到$ORACLE_HOME\log下的tnslsnr查看trace文件,发现listener.log确实达到了4GB,停止监听,将此文件删除即可.
万事不要凭经验,其实oracle提供了命令让我们查看监听日志文件:
lsnrctl
>show log_file
可以查看监听日志xml文件的位置.
对于一些没有人维护的数据库,特别是windows系统,建议直接将oracle 监听日志关闭
>set log_status off
>save_config
这次故障从我接手到恢复花费了20分钟,业务也就至少停了20分钟,这个系统是一个7x24小时的核心系统,停20分钟影响还是非常大的,其实最开始通过故障现象我就定位到了可能是文件过大导致的,如果一开始直接通过命令查看日志文件路径,只要2分钟就可以解决故障.
