Oracle Alert 日志频繁告警 12170 TNS-12535/TNS-00505，我看看怎么个事儿？

大家好，这里是公众号 DBA学习之路，致力于分享数据库领域相关知识。

前言

本章目标：掌握本章核心知识点 前置要求：完成前序章节学习 预计时长：60 分钟

节后巡检一套 Oracle 11GR2 的库，发现 alert 日志很大，于是看看 alert 日志里都记录了啥？好家伙，一打开日志发现全是告警 TNS-12170/12535/12560/00505，一眼刷不到头：

Bash

1***********************************************************************
2Fatal NI connect error 12170.
3
4  VERSION INFORMATION:
5        TNS for Linux: Version 11.2.0.4.0 - Production
6        Oracle Bequeath NT Protocol Adapter for Linux: Version 11.2.0.4.0 - Production
7        TCP/IP NT Protocol Adapter for Linux: Version 11.2.0.4.0 - Production
8  Time: 06-FEB-2025 00:16:10
9  Tracing not turned on.
10  Tns error struct:
11    ns main err code: 12535
12
13TNS-12535: TNS:operation timed out
14    ns secondary err code: 12560
15    nt main err code: 505
16
17TNS-00505: Operation timed out
18    nt secondary err code: 110
19    nt OS err code: 0
20Thu Feb 06 00:20:32 2025
21***********************************************************************

这明显是个老朋友了，对 Oracle DBA 来说太常见了，但是大多数人往往都选择视而不见，正好有案例，我打算记录一下解决过程。

问题描述

首先可以通过 oerr 看一下这个报错的描述：

Bash

1[oracle@lucifer:~]$ oerr ora 12170
212170, 00000, "TNS:Connect timeout occurred"
3// *Cause:  The server shut down because connection establishment or
4// communication with a client failed to complete within the allotted time
5// interval. This may be a result of network or system delays; or this may
6// indicate that a malicious client is trying to cause a Denial of Service
7// attack on the server.
8// *Action: If the error occurred because of a slow network or system,
9// reconfigure one or all of the parameters SQLNET.INBOUND_CONNECT_TIMEOUT,
10// SQLNET.SEND_TIMEOUT, SQLNET.RECV_TIMEOUT in sqlnet.ora to larger values.
11// If a malicious client is suspected, use the address in sqlnet.log to
12// identify the source and restrict access. Note that logged addresses may
13// not be reliable as they can be forged (e.g. in TCP/IP).

简单来说，就是连接超时了，可能是网络慢或者有人搞破坏。例如，拔网线、防火墙断开连接或客户端崩溃且未通知服务器等。

再看这次的案例：

Bash

1Fatal NI connect error 12170.
2
3  VERSION INFORMATION:
4        TNS for Linux: Version 11.2.0.4.0 - Production
5        Oracle Bequeath NT Protocol Adapter for Linux: Version 11.2.0.4.0 - Production
6        TCP/IP NT Protocol Adapter for Linux: Version 11.2.0.4.0 - Production
7  Time: 06-FEB-2025 00:16:10
8  Tracing not turned on.
9  Tns error struct:
10    ns main err code: 12535
11
12TNS-12535: TNS:operation timed out
13    ns secondary err code: 12560
14    nt main err code: 505
15
16TNS-00505: Operation timed out
17    nt secondary err code: 110
18    nt OS err code: 0
19Thu Feb 06 00:20:32 2025

错误堆栈依次为 12170/TNS-12535/12560/TNS-00505，这表示已建立的连接由于网络问题而超时。在这种情况下 Oracle 服务器进程无法确定客户端状态，它必须等到 TCP keepalive 超时（可能是几个小时），然后该进程将终止，上述消息将打印在 alert 日志中。所以，这是一个网络/应用程序问题，而不是数据库的错误。

📢 注意：Oracle 11GR1 版本之前同样的信息 'Fatal NI connect error 12170' 是写入 sqlnet.log 中的。

当 Oracle 安装在不同的操作系统（OS）时，对于 nt secondary err code 错误代码有所不同：

Solaris：nt secondary err code: 145（ETIMEDOUT 145 /* Connection timed out */）
Linux：nt secondary err code: 110（ETIMEDOUT 110 Connection timed out）
HP-UX：nt secondary err code: 238（ETIMEDOUT 238 /* Connection timed out */）
AIX：nt secondary err code: 78（ETIMEDOUT 78 /* Connection timed out */）
Windows：nt secondary err code: 60（Winsock 错误：10060）

很明显，当前案例的操作系统就是 Linux 了。

问题重现

为了更深入的理解，我们可以重现一下这个问题。

在模拟开始前，我们先了解一下操作系统 TCP KeepAlive 机制的原理：

当建立 TCP 链接后，如果应用程序或者上层协议一直不发送数据，或者隔很长一段时间才发送数据，当链接很久没有数据报文传输时就需要通过 keepalive 机制去确定对方是否在线，链接是否需要继续保持。当超过一定时间没有发送数据时，TCP 会自动发送一个数据为空的报文给对方，如果对方回应了报文，说明对方在线，链接可以继续保持，如果对方没有报文返回，则在重试一定次数之后认为链接丢失，就不会释放链接。

TCP的keepalive机制是用来在非活跃的连接上发送保活探测数据包，以检测对端是否仍然活跃。如果对端不响应，可以断定连接已经断开，并且可以采取相应的动作。

操作系统的 TCP keepalive 有 3 个参数（这是 Linux 参数，当然其它操作系统也有类似的参数）：

tcp_keepalive_time：在开始发送保活探测数据包之前，TCP 连接处于非活动状态的时间。
tcp_keepalive_intvl：如果对端没有任何响应，保活探测包的发送间隔。
tcp_keepalive_probes：在认定连接失效之前，发送保活探测包的次数。

查看 Linux 系统的默认值：

Bash

1## 保活时间，默认为 7200s
2[root@oracle11g:/root]# sysctl net.ipv4.tcp_keepalive_time
3net.ipv4.tcp_keepalive_time = 7200
4## 发生间隔，默认为 75s
5[root@oracle11g:/root]# sysctl net.ipv4.tcp_keepalive_intvl
6net.ipv4.tcp_keepalive_intvl = 75
7## 重试次数，默认为 9次
8[root@oracle11g:/root]# sysctl net.ipv4.tcp_keepalive_probes
9net.ipv4.tcp_keepalive_probes = 9

这里为了快速模拟，我已经提前将服务端的 tcp_keepalive 临时改变为 5 分钟，重试次数为 3 次（需要在最初客户端建立连接前修改，否则不生效）：

Bash

1## 第一步就需要执行修改，然后再在客户端模拟连接
2[root@oracle11g:/root]# sysctl -w net.ipv4.tcp_keepalive_time=300
3net.ipv4.tcp_keepalive_time = 300
4[root@oracle11g:/root]# sysctl -w net.ipv4.tcp_keepalive_probes=3
5net.ipv4.tcp_keepalive_probes = 3

使用客户端连接一套 11GR2 测试环境，确定会话和服务器进程：

Bash

1[oracle@oracle19c:/home/oracle]$ sqlplus lucifer/oracle@192.168.6.60/lucifer
2
3SQL*Plus: Release 19.0.0.0.0 - Production on Thu Feb 6 10:56:38 2025
4Version 19.3.0.0.0
5
6Copyright (c) 1982, 2019, Oracle.  All rights reserved.
7
8
9Connected to:
10Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
11With the Partitioning, OLAP, Data Mining and Real Application Testing options
12
13LUCIFER@192.168.6.60/lucifer SQL> select s.sid,s.serial#,p.spid from v$session s, v$process p, (select * from v$mystat where rownum=1) ms where s.paddr=p.addr and s.sid=ms.sid;
14
15       SID    SERIAL# SPID
16---------- ---------- ------------------------
17      2273         31 36644

客户端的端口可以通过 listener.log 来标识，在本例中为 61809：

Bash

1Thu Feb 06 10:56:39 2025
206-FEB-2025 10:56:39 * (CONNECT_DATA=(SERVICE_NAME=lucifer)(CID=(PROGRAM=sqlplus)(HOST=oracle19c)(USER=oracle))) * (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.6.194)(PORT=61809)) * establish * lucifer * 0
306-FEB-2025 10:56:42 * service_update * lucifer * 0

拔掉客户端和服务器之间的网线，或者通过 iptables 命令断开连接，监控服务器的连接：

Bash

1## 宕掉网卡
2[root@oracle19c:/root]# nmcli connection show 
3NAME    UUID                                  TYPE      DEVICE 
4ens192  882d9815-b6c2-4a6d-a1d9-514e120be9bd  ethernet  ens192 
5virbr0  34fa23fb-9193-4872-85d7-0a7615a12311  bridge    virbr0 
6[root@oracle19c:/root]# nmcli connection down ens192 
7
8## 防火墙断开
9## iptables -A INPUT -p tcp -s 192.168.6.194 --sport 61809 -j DROP
10## iptables -nL

可以看到，即使网线已被拔出（或连接已被 iptables 断开），操作系统角度来看 TCP 连接仍处于已建立状态：

Bash

1[root@oracle11g:/root]# date
2Thu Feb  6 10:58:02 CST 2025
3[root@oracle11g:/root]# lsof -Pani :61809
4COMMAND   PID   USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
5oracle  36644 oracle   14u  IPv6  70337      0t0  TCP 192.168.6.60:1521->192.168.6.194:61809 (ESTABLISHED)

服务器进程在 oracle 端仍然存在：

SQL

1SYS@lucifer SQL> select sysdate,s.sid,s.serial#,p.spid,event,status,state from v$session s, v$process p where s.paddr=p.addr and s.sid=2273;
2
3SYSDATE                   SID    SERIAL# SPID                     EVENT                                                            STATUS   STATE
4------------------ ---------- ---------- ------------------------ ---------------------------------------------------------------- -------- -------------------
506-FEB-25                2273         31 36644                    SQL*Net message from client                                      INACTIVE WAITING

使用 ss 命令可以确定当前连接的 keepalive 时间：

Bash

1[root@oracle11g:/root]# ss -tuanop '( sport = :1521 and dport = :61809 )'
2Netid               State                Recv-Q                Send-Q                                       Local Address:Port                                         Peer Address:Port                Process               
3tcp                 ESTAB                0                     0                                    [::ffff:192.168.6.60]:1521                               [::ffff:192.168.6.194]:61809                users:(("oracle",pid=36644,fd=14)) timer:(keepalive,27sec,0)

等待一会儿后，数据库 alert 告警日志显示以下消息：

Bash

1***********************************************************************
2
3Fatal NI connect error 12170.
4
5  VERSION INFORMATION:
6        TNS for Linux: Version 11.2.0.4.0 - Production
7        Oracle Bequeath NT Protocol Adapter for Linux: Version 11.2.0.4.0 - Production
8        TCP/IP NT Protocol Adapter for Linux: Version 11.2.0.4.0 - Production
9  Time: 06-FEB-2025 11:12:18
10  Tracing not turned on.
11  Tns error struct:
12    ns main err code: 12535
13    
14TNS-12535: TNS:operation timed out
15    ns secondary err code: 12560
16    nt main err code: 505
17    
18TNS-00505: Operation timed out
19    nt secondary err code: 110
20    nt OS err code: 0
21  Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.6.194)(PORT=61809))

再次查看进程已经不存在：

Bash

1[root@oracle11g:/root]# ss -tuanop '( sport = :1521 and dport = :61809 )'
2Netid                  State                  Recv-Q                  Send-Q                                   Local Address:Port                                   Peer Address:Port                 Process  
3[root@oracle11g:/root]# lsof -Pani :61809

📢 注意：在 12C 或更高版本上，如果启用了 DCD，则服务器进程的 tcp keepalive 时间将更改为 DCD 间隔值。

具体可参考：Oracle Net 12c: DCD (Dead Connection Detection ) 功能的改变 (Doc ID 2403921.1)

到这，这个问题的模拟也就结束了。

解决方案

说了这么多，还没有给解决方案，别急，来了！

调整防火墙

防火墙 (FW) 在当今的网络中已经很常见，用于保护网络环境。防火墙识别 TCP 协议并记录客户端服务器套接字端点。此外，FW 识别 TCP 连接关闭，然后将释放为记录打开连接而分配的资源。对于每对端点，防火墙还必须分配一些资源（可能很小）。

当客户端或服务器关闭通信时，它会发送 TCP FIN 类型数据包，这是正常的套接字关闭行为。然而，客户端服务器通信突然终止而没有通过发送 FIN 数据包正确关闭端点的情况并不罕见。例如，当客户端或服务器崩溃、断电或网络错误导致无法向另一端发送关闭数据包时。在这种情况下，防火墙并不知道端点是否继续使用仍然处于打开的那些通道。作为被动模式，它无法确定端点是否仍然处于活动状态。因为不可能永远维护资源，而且，在未知的时间内一直保持端口开放是一种安全威胁。因此，防火墙会对那些在预定时间内保持空闲状态的连接实施封锁。

最初，FW 旨在保护应用程序服务器、网络，然后保护客户端/服务器连接。考虑到这些，以小时为单位的超时（大多数固件默认为 1 小时）是合理的。随着更复杂的安全方案的出现，FW 不仅存在于客户端和服务器之间，还存在于不同的应用服务器（内网、非军事区（DMZ）等）和数据库服务器之间。因此，服务器之间通信的 1 小时空闲时间范围可能不合适。

建议：调整防火墙设置，以获得最大空闲时间。当然这是一个安全设置，所以应该由网络或系统管理员完成。

调整 Oracle 参数

数据库连接中，如果一端是监听进程（可能是专用进程或调度程序进程），当连接被阻断时，后端无法知道客户端是否还能发送请求。这会导致资源浪费，比如数据库会话、锁和文件描述符等。

解决办法是让后端“主动”一点，使用 DCD（死连接检测）来检查连接是否还正常。

具体操作是在服务器端的 $ORACLE_HOME/network/admin/sqlnet.ora 文件中设置 SQLNET.EXPIRE_TIME=10（10分钟）。这样，如果10分钟内没有活动，服务器会向客户端发送一个小探测包。如果客户端没有回应，服务器就会关闭连接并释放资源。

DCD（死连接检测）有两个好处：

如果 SQLNET.EXPIRE_TIME 比防火墙的空闲超时时间短，防火墙会把这个探测包当作活动信号，不会中断连接，除非客户端或服务器真的出了问题。
如果 SQLNET.EXPIRE_TIME 比防火墙的空闲超时时间长，一旦连接中断，数据库会很快发现并关闭连接。

第一种情况适合连接来自应用服务器时使用，第二种情况则适合客户端应用。

DCD 是在应用层和 TCP/IP 协议上工作的。如果你设置了 SQLNET.EXPIRE_TIME=10，也就是说如果断电或网络中断 10 分钟，连接不会被立即标记为死亡。

一旦你修改了 SQLNET.EXPIRE_TIME 的设置，不需要重启监听器或数据库，新的连接会立刻生效。但是，已经存在的连接不会受到影响，只有新建立的连接才会使用这个新设置。所以，在全部连接都更新之前，你可能还会遇到一些超时问题。

治标不治本

最后，还有一个治标不治本的方法，就是屏蔽掉这些告警日志，不让他写入 alert 日志。可以通过设置以下参数来关闭 Automatic Diagnostic Repository (ADR)，这样 Oracle 的网络诊断信息就不会被写入到 alert 日志文件中。

1.关闭 SQLNET 的 ADR：

在服务器的 sqlnet.ora 文件中添加以下参数 DIAG_ADR_ENABLED = OFF。

2.关闭监听器的 ADR：

在服务器的 listener.ora 文件中添加以下参数：DIAG_ADR_ENABLED_<监听器名称> = OFF，将 <监听器名称> 替换为实际的监听器名字。比如，如果监听器名字是 LISTENER，参数就写成：DIAG_ADR_ENABLED_LISTENER = OFF。

修改后，需要重新加载 reload 或重启 restart 监听，让设置生效。

简单来说，就是通过改这两个文件，关掉 ADR，避免网络诊断信息写进日志，改完后别忘了重启监听！

写在最后

大家处理问题的时候，一定要见微知著，深入研究，这样才能真正学习到东西，干中学，学中干！

本文部分内容参考自 MOS 文章：