Azure Windows 虚拟机上的 Oracle 数据库连接问题(ORA-03135)

Azure Windows 虚拟机上的 Oracle 数据库连接问题(ORA-03135)

我们正在 Azure Windows VM 上运行 Oracle 19c 数据库。我们的配置如下:

  • Azure Windows 虚拟机
    • 标准 B4ms(4 个 vcpus,16 GiB 内存)
    • 公共 IP 地址的“空闲超时”为 30 分钟(允许的最大值)。
    • Oracle 数据库 19c

从 VM 运行时,不会断开任何“空闲 SQL 会话”,但从公共 IP 地址访问时,“空闲 SQL 连接”会在 30 分钟后断开。

ORA-03135: connection lost contact

我们希望我们的“空闲 SQL 连接”能够持久,这是我们迄今为止尝试过的:

  1. 编辑 sqlnet.ora 文件如下(客户端和服务器):
SQLNET.EXPIRE_TIME = 1000000
SQLNET.INBOUND_CONNECT_TIMEOUT = 1000000
  1. 编辑 tnsnames.ora 文件如下(客户端和服务器):
(ENABLE=BROKEN)

目前我正在尝试实现 Oracle keep-alive 包,但是没有成功。

对此有任何指导或想法吗?谢谢

[更新] 我找到了一个解决方案,这是我为了修复它所做的事情:

  1. 将“sqlnet.ora”恢复正常(客户端和服务器)
  2. 在“tnsnames.ora”文件上配置(ENABLE=BROKEN)(仅在客户端上)
  3. 使用以下参数在 Regedit 上设置 TCP KeepAlive(仅在客户端上)(https://docs.microsoft.com/en-us/sql/connect/jdbc/connecting-to-an-azure-sql-database?view=sql-server-ver15
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"KeepAliveTime"=dword:00007530
"KeepAliveInterval"=dword:000003e8
"TcpMaxDataRetransmissions"=dword:00000010
  1. 重启客户端

答案1

您需要在客户端计算机上更改一个或两个内核可调参数。要使 TCP keepalive (ENABLE=BROKEN) 有用。默认情况下,Linux 内核会在 2 小时后发送第一个 TCP keepalive 探测:

Linux 内核:

# cat /proc/sys/net/ipv4/tcp_keepalive_time
7200
Delay before the 1st probe is sent - after 2 hours !!!

# cat /proc/sys/net/ipv4/tcp_keepalive_intvl
75
Interval between probes.

# cat /proc/sys/net/ipv4/tcp_keepalive_probes
9
The number of "lost" probes indicating that the connection is dead.

当将 keepavlive 时间和 keepalive 间隔设置为 5 秒(仅用于测试。30 秒对于生产来说应该足够了)时,您应该在 TCP 转储中看到类似这样的内容:

[~]# tcpdump -pni ens224 -v "tcp port 1521 and ( tcp[tcpflags] & tcp-ack != 0 and ( (ip[2:2] - ((ip[0]&0xf)<<2) ) - ((tcp[12]&0xf0)>>2) ) == 0 )"
tcpdump: listening on ens224, link-type EN10MB (Ethernet), capture size 262144 bytes
14:56:49.994675 IP (tos 0x0, ttl 64, id 12096, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.8.200.37196 > 192.168.8.212.ncube-lm: Flags [.], cksum 0x9313 (incorrect -> 0x4b94), ack 2263270845, win 359, options [nop,nop,TS val 78140944 ecr 7133273], length 0
14:56:49.994829 IP (tos 0x0, ttl 64, id 55327, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.8.212.ncube-lm > 192.168.8.200.37196: Flags [.], cksum 0xadcf (correct), ack 1, win 207, options [nop,nop,TS val 7138281 ecr 78110940], length 0
14:56:55.002668 IP (tos 0x0, ttl 64, id 12097, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.8.200.37196 > 192.168.8.212.ncube-lm: Flags [.], cksum 0x9313 (incorrect -> 0x2474), ack 1, win 359, options [nop,nop,TS val 78145952 ecr 7138281], length 0
14:56:55.002809 IP (tos 0x0, ttl 64, id 55328, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.8.212.ncube-lm > 192.168.8.200.37196: Flags [.], cksum 0x9a3f (correct), ack 1, win 207, options [nop,nop,TS val 7143289 ecr 78110940], length 0
14:57:00.010680 IP (tos 0x0, ttl 64, id 12098, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.8.200.37196 > 192.168.8.212.ncube-lm: Flags [.], cksum 0x9313 (incorrect -> 0xfd53), ack 1, win 359, options [nop,nop,TS val 78150960 ecr 7143289], length 0
14:57:00.011296 IP (tos 0x0, ttl 64, id 55329, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.8.212.ncube-lm > 192.168.8.200.37196: Flags [.], cksum 0x86af (correct), ack 1, win 207, options [nop,nop,TS val 7148297 ecr 78110940], length 0

6 packets captured
6 packets received by filter
0 packets dropped by kernel

相关内容