Oracle 数据库访问故障（TNS-12535、TNS-00505）解决思路

Oracle 数据库访问故障（TNS-12535、TNS-00505）解决思路

用户的两节点 Oracle（11g） 集群10月4日突然无法访问，修复后于10月10日又发生同样的故障。把解决思路做一下记录，希望对从事数据库的同行有一点启发。

一、问题描述

1、10月4日

数据库无法连接，置看主机 IP 地址发现，集群没有分配 scanlP，查看服务器状态发现如下问题：

（1）节点1集群无法连接，节点2正常，但集群的 scanlP 没有漂移到节点2；

（2）查看主机信息，发现主机存储空间占用过多（几百个 GB 的存储空间被使用），经过查询发现是生成了大量的监听日志。

listener.log 文件的大小达到了 200 多个 GB，alert 目录下生成了大量的 xml 文件，文件总大小达到200 多个 GB。

listener.log 文件如下（下面的截图是清理过的，没有保存清理之前的截图）：

alert 目录内容如下（该目录中的总文件大小达到 200GB）：

解决方法：

（1）把 listener.log 文件清空；

（2）把 alert 目录下的 xml 文件删除，只保留 log.xml。

清理日志之后，集群恢复正常，业务恢复正常。

2、10月10日

数据库访问速度变慢，查看服务器状态也是正常的（没有查看主机的磁盘利用情况），但客户反映所有业务已经停止。征得客户同意，重启 oracle 集群，但在关闭集群时发生异常，集群也无法启动。然后重启操作系统。

服务器重启后2号节点能够正常运行，scanIP 也自动分配到2号节点，用户业务恢复。但发现1号节点的 oracle 集群不能启动。查看主机信息发现和10月4号的情况完全相同，也是生成了大量的监听日志，文件大小占据了所有磁盘空间。如下图所示：

清理了 listener.log 文件了 alert 目录下的 xml 文件之后，服务器和 oracle 集群恢复正常。

考虑到相同的问题在一周以内连续发生两次，这次清理之后还可能再发生同样的问题，需要查找问题的根源所在。

二、故障原因

导出 alert 日志（/u01/app/oracle/diag/rdbms/hisdb/hisdb1/trace/alert_hisdb1 .log），查看其中的错误信息．查看日志发现有大量的客户端访问超时信息：

#################################################################################
# 9月23号， 客户端： 172.170.51.55
#################################################################################
Fatal NI connect error 12170.

  VERSION INFORMATION:
	TNS for Linux: Version 11.2.0.4.0 - Production
	Oracle Bequeath NT Protocol Adapter for Linux: Version 11.2.0.4.0 - Production
	TCP/IP NT Protocol Adapter for Linux: Version 11.2.0.4.0 - Production
  Time: 23-SEP-2022 14:08:23
  Tracing not turned on.
  Tns error struct:
    ns main err code: 12535
    
TNS-12535: TNS:operation timed out
    ns secondary err code: 12560
    nt main err code: 505
    
TNS-00505: Operation timed out
    nt secondary err code: 110
    nt OS err code: 0
  Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=172.170.51.55)(PORT=1900))


#################################################################################
# 10月9号， 客户端： 172.170.51.41
#################################################################################
Fatal NI connect error 12170.

  VERSION INFORMATION:
	TNS for Linux: Version 11.2.0.4.0 - Production
	Oracle Bequeath NT Protocol Adapter for Linux: Version 11.2.0.4.0 - Production
	TCP/IP NT Protocol Adapter for Linux: Version 11.2.0.4.0 - Production
  Time: 09-OCT-2022 18:52:20
  Tracing not turned on.
  Tns error struct:
    ns main err code: 12535
    
TNS-12535: TNS:operation timed out
    ns secondary err code: 12560
    nt main err code: 505
    
TNS-00505: Operation timed out
    nt secondary err code: 110
    nt OS err code: 0
  Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=172.170.51.41)(PORT=56590))

#################################################################################
# 10月10号， 客户端： 192.168.0.64
#################################################################################
Fatal NI connect error 12170.

  VERSION INFORMATION:
	TNS for Linux: Version 11.2.0.4.0 - Production
	Oracle Bequeath NT Protocol Adapter for Linux: Version 11.2.0.4.0 - Production
	TCP/IP NT Protocol Adapter for Linux: Version 11.2.0.4.0 - Production
  Time: 10-OCT-2022 03:24:14
  Tracing not turned on.
  Tns error struct:
    ns main err code: 12535
    
TNS-12535: TNS:operation timed out
    ns secondary err code: 12560
    nt main err code: 505
    
TNS-00505: Operation timed out
    nt secondary err code: 110
    nt OS err code: 0
  Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.0.64)(PORT=3430))

查阅相关资料发现：

该问题产生的原因为：由于 Automatic Diagnostic Repository 中的 Oracle Net diagnostic 在默认情况下是开启的，当数据库和客户端的连接超过特定时间，就会把连接信息写入到 alert 日志中，产生大量的监听日志，导致相关的日志文件不断增大。

三、解决思路

1、修改 listener.ora 文件，增加如下内容：

DIAG_ADR_ENABLED_LISTENER=OFF
INBOUND_CONNECT_TIMEOUT_LISTENER=180

如下图所示：

2、重新加载监听配置文件，如下图所示：

3、查看监听状态，如下图所示：

修复之后运行24小时，查看主机存储空间以及监听日志信息，没有出现异常。如下图所示：

（1）磁盘占用信息：

（2）alert 目录信息：

（3）oracle.log 文件信息