很久没写博客了,也不知道这两年自己到底在干什么,今天心血来潮,写一篇。
事情是这样的,一个数据库,是windows下的11.2.0.4的版本,用来作为展示报表的后台数据库,之前一直正常,突然到下午的时候几个前台的开发反应说数据库无法登陆,虽然现在没有干DBA的活了,不过还是通过远程连接连上去看了一下,监听日志大概4GB左右,alert log只有几百MB,远程服务器上没有其他编辑器,所以没有办法查看监听日志,不过告警日志倒是能打开,里面从当天中午开始就一直报错,充斥着大量的ORA-3136错误.
自己尝试登陆了一下数据库,发现可以登录,但是大概至少十几秒中才能够连接成功,然后尝试重启了监听,发现监听使用了1521和8080两个端口,重启大概花了十几分钟才完成,期间重启有错误出现:
再次重启,终于能够启动起来了,但是发现链接依然很慢,而开发人员在另外一间办公室也尝试了登陆,依然没有办法链接,网上bing了一下没有找到合适的答案,在没有任何缓解的情况下,咨询了一个老司机,说是不是因为监听日志太大的缘故,我说日志有4GB了,于是去清理监听日志,这一招果然凑效,清理之后果然就正常了, 果然是经 历的case多,定位问题又快又准,服了。
事情是这样的,一个数据库,是windows下的11.2.0.4的版本,用来作为展示报表的后台数据库,之前一直正常,突然到下午的时候几个前台的开发反应说数据库无法登陆,虽然现在没有干DBA的活了,不过还是通过远程连接连上去看了一下,监听日志大概4GB左右,alert log只有几百MB,远程服务器上没有其他编辑器,所以没有办法查看监听日志,不过告警日志倒是能打开,里面从当天中午开始就一直报错,充斥着大量的ORA-3136错误.
点击(此处)折叠或打开
- Inbound connection timed out (ORA-3136)
点击(此处)折叠或打开
- TNS-01153: 未能处理字符串
再次重启,终于能够启动起来了,但是发现链接依然很慢,而开发人员在另外一间办公室也尝试了登陆,依然没有办法链接,网上bing了一下没有找到合适的答案,在没有任何缓解的情况下,咨询了一个老司机,说是不是因为监听日志太大的缘故,我说日志有4GB了,于是去清理监听日志,这一招果然凑效,清理之后果然就正常了, 果然是经 历的case多,定位问题又快又准,服了。
Inbound connection timed out (ORA-3136)Inbound connection timed out (ORA-3136) |
| |
| |
| |
| |
| |
| |
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/12216142/viewspace-2097508/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/12216142/viewspace-2097508/