Oracle Listener 无响应问题处理

         昨天接到现场电话，xxx系统中一个数据库实例里active进程突然增多，现场DBA感冒了，要求协助一下，问题集中在一个语句中：

         第一反应就是这个sql写的有性能问题，使用toad登陆数据库，找到该语句，并查看其执行计划，发现执行计划没有问题；

         手工执行一次该语句效率很高ms级别，按理说应该不会有问题，怪异！

         看看它究竟在等什么吧，查看v$session_wait 查看该语句造成的所有等待事件都是一个“single task message” ，还真不常见，找到Oracle的官方解释：

“ this event indicates that the session waits for the client side of the executable”

         这都已经登陆上来了，怎么还是客户端等待被执行的进程？ 我反应了10分钟才想明白，莫非这些表里里有dblink建立的表？

         排查发现其中一个表A确实是通过DB_LINK创建的同义词，于是查询了一下这个表A：

         select * from A 发现这个表一共3条数据，是个类型表，莫非我判断错了？

         截止到此，提醒一下，因为公司和现场有专线，我所有的操作一直都在第三方工具里，这个就是导致我问题定位慢的原因了；

         此时，开发的一个同事打电话给我，说就是这个库里的DB_LINK不好用了，我当时还说，不能啊，我整在用！ 同时我也想起了第三方工具的Cache的功能，莫非我的表数据已经被第三方工具缓存了？

         于是开crt，重新登录主机，登陆数据库 再次执行select * from A ;

         果然没有响应！ 问题由了眉目了！ 

         登陆当前库所在的主机 ping 了一下对端的主机IP地址，发现没有延迟

         tnsping了一下DB_LINK用的连接串发现无响应！ 原来是对端数据库监听的问题；

         于是走流程申请对端主机的dba用户，登陆主机后，该主机配置了5个监听 分别用于不同的工作，而唯独负责db_link的监听没响应！

         于是首先想到重启这个监听！ 现场重启后，问题貌似很快解决了。我当时也是手里有其它的工作，放下就不管了，没有细追究，心想可能是内存不够了，重启就好了。而且现场有个高手DBA，而且还是我的入门导师，我也就没有进行问题分析；

         第二天早晨8点刚到公司，现场DBA的电话就打过来了，让我帮忙一块看看，昨天的问题又出现了，这哥哥确实感冒了，要不也不至于轮到我出场！呵呵。

          登陆主机后首先向看还是那个监听的状况 我从本地直接登录了一次，速度很快！ 加上@sid 就无响应了，说明问题肯定在监听上无疑了。

           然后查看这个监听的日志，tail -f 该日志 惊人的一幕出现了，这个日志在飞快的刷屏，并不是我想的，没有任何响应！ 看来是它负载不过来了！

           仔细看了看日志，是因为应用程序配置的crontab里配置了n多 * * * * * 的进程，由于这些进程都是@sid的方式登陆的，所以这个监听一直都在繁忙的工作，而DB_LINK恰好和它用了一个监听！

           ok，问题查出来之后解决就简单了，配新监听，修改db_link的端口就解决了！

         

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/598601/viewspace-621158/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/598601/viewspace-621158/