记一次稀里糊涂的故障处理过程

问题描述：

        前几天一大早同事发邮件说数据同步作业没有完成，另一同事（M）就开始着手处理，大概9点多的时候，同事M说中间库数据库用plsql连接提示：

ORA-12571: TNS：包写入程序失败。前段时间一直都是好的，今天连接不上数据库了。

系统环境：

     操作系统：Microsoft windows server 2003 enterprise edition service pack 2

     数据库： Oracle Database 11g Enterprise Edition Release 11.2.0.1.0

处理过程：

       1、听了同事大概说了一下具体的情况，起初怀疑是同事自己的tns没有配置好，但是同事说原来都是好的都是可以连接的。同时也对比了自己电脑配置的tns，和同事的完全一直，自己也无法登录了。初步怀疑是不是监听出现了问题。但是此时并没有很在意监听，我自己想当然的认为监听无非就是重启一下就好了嘛，就将监听检查忽略了过去。

       2、登录了服务器，检查内存等系统资源情况，发现都正常，不存在资源不够的情况。    

       3、检查是不是数据库服务器挂了，无法访问了，接下来的验证也否定了这个情况，同事ping了服务器，可以ping通，但是用tnsping则非常的慢，是不是数据库hang住了。

          使用远程连接登录服务器后，在cmd窗口中，使用sqlplus / as sysdba 登录，可以登录数据库。（数据库实例没有问题啊）

          检查数据库实例状态：

          select instance_name,status from v$instance;

          数据库实例状态为open。正常。

          检查数据库alter日志：

           日志里有报错

            TNS-12537: TNS: 连接关闭

               ns secondary err code: 12560

               nt main err code: 0

               nt secondary err code: 0

               nt OS err code: 0

               opiodr aborting process unknown ospid (18156) as a result of ORA-609

               Tue May 03 08:39:12 2016        

     到此时才更加的觉得是监听出现了问题，必须要看监听了。

      3。查看监听状态:

            lsnrctl status

           出现了异常的状况，非常的慢，大概10分钟，才显示出来信息。看到注册的数据库实例也是READY状态的，确定数据库实例是没有问题的，一定是监听哪里出现了问题。

          加上上边alter提示的连接关闭和在不停的用plsql连接过程中提示连接超时，想是不是连接到数据库的会话太多，导致的连接超时，此时又通过度娘得知，我在listener.ora文件中增加了INBOUND_CONNECT_TIMEOUT_LISTENER_NAME = 120和sqlnet.ora文件中增加SQLNET.INBOUND_CONNECT_TIMEOUT=180，两个参数，然后重启监听：lsnrctl stop ;lsnrctl start。很不幸，这两个命令也是非常的慢。那我就等吧，等两个命令起来后，用plsql连接数据库问题依旧。这个时候有点着急了，虽然说这是一个中间库，上边没有连接应用，但是这个库是作为传输我们hr数据的一个中转站，其他数据库要从这个数据库获取数据，供给其他应用使用。我突然想到了重启大法（因为数据库实例是好的，重启应该没有大的影响，重启了数据库实例和服务，事后我想想这也不影响监听啊，没用的步骤，相反这可能是一个危险的步骤，原因不明，万一起不来，我罪过就更大了），重启完后，问题依旧。

        这个时候应该有人会问，为什么不看监听日志，这也是我犯的另一个错误，我打不开listener.log这个日志，我就没有想办法看它，事后想想这绝对是一个不可饶恕的错误。

       已经过去一个多小时了，问题还是没有找到原因，很着急，没法了，我给同事说不行咱重新新建一个监听吧，把原来的删除了，同事说行。netca重新删除了原来的监听，新建了一个新名称的监听，再次查看监听状态，瞬间显示了所有的信息，同事说plsql连接恢复正常，数据访问正常。其他数据库访问正常。

      我瞬间郁闷了......

总结：

    问题是没有了，但是我还是不知道原因在哪，就把所有的日志都copy到我自己本地的机器上了，在仔细看看到底是什么问题。再次使用度娘查询下有没有类似的问题，果然发现了itpub上一篇文章，和我们的现象几乎是一模一样的：

http://blog.itpub.net/12679300/viewspace-1169839/。才发现了真正的原因：原来是监听日志大于4G了，触发了oracle的bug。才恍然大悟，为什么我们的突然好了，我重新新建了监听，监听日志也变了嘛。瞎猫碰上死耗子，撞大运的给解决了问题。（有人会说为什么不用Metalink账号查要用度娘，这里我要说下不是不想，是没有账号了，我才进的公司，之前也没有人专门负责维护oracle数据库，我也是兼职，原来的metalink账号也都不知道哪里去了，没有一个人知道）

   通过此事也知道了：1.学习oracle基础知识一定要扎实；2.不能放过一丝一毫的异常点（监听日志都打不开了，我尽然放过去了。）；3.对于数据一定要有敬畏感，必须要知道自己敲下去的命令意味着什么（没有找到原因前，我贸然的重启了数据库，还好运气好！）；4.对于数据库管理一定要规范，如果专职人员一直管理，这种问题是不应该出现的。

 

记录一下正确的处理办法：

1. 关闭监听记录日志

   lsnrctl>> set log_status of

2. 清理监听日志

   windows下重命名，备份，新建等

   linux下mv listener.log listener.log_bak

3. 开启监听记录日志

      lsnrctl>> set log_status on

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

转载于:http://blog.itpub.net/24626757/viewspace-2121292/