首页 » ORACLE, 系统相关 » Troubleshooting Dataguard SYNC同步模式时网络问题

Troubleshooting Dataguard SYNC同步模式时网络问题

有时跟踪 Data Guard 后台服务很有帮助,因此我们可以查看匹配的 NSSn 和 RFS 跟踪。对于深入研究,我们还希望在 Data Guard 配置的两端运行 tcpdump 捕获,并且可能在中间的网络组件上运行。为了最大限度地减少设备上的处理开销和捕获文件中的噪音,我们希望数据包过滤器尽可能具体。只是源IP和目标IP还不够好,我们还需要一个端口号。理想情况下,我们将以下过滤器应用于“tcpdump”,以捕获整个 NSS <-> RFS 流量(仅此而已):

tcpdump 'host and port '

NSS n是将重做数据从主节点传送到备用节点的进程。n是与重做传输配置的 LOG_ARCHIVE_DEST_n 参数匹配的数字,获取主要主机的 IP 很容易,即使 Data Guard 有单独的网络。
但是我们如何获取 NSSn 进程的 PORT 呢?
方法 A

select ses.sid, ses.serial#, ses.machine, ses.port, prc.pname, prc.spid, prc.stid, prc.tracefile
from gv$session ses
join gv$process prc on (prc.inst_id = ses.inst_id and prc.addr = ses.paddr)
where prc.pname like 'NSS%'

方法 B
使用与第一种方法相同的查询来获取主节点上 NSSn 进程的 SPID。通过 SPID,我们可以使用“ss”Linux 实用程序找到 TCP 连接详细信息:

ss -o -p -n -i | grep [NSS spid]

或使用netstat查看端口与进程

[oracle@oel7db1 ~]$ netstat -tanelpod
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       User       Inode      PID/Program name     Timer
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      0          19490      -                    off (0.00/0/0)
tcp        0      0 0.0.0.0:1521            0.0.0.0:*               LISTEN      54321      36668      19732/tnslsnr        off (0.00/0/0)
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      0          22533      -                    off (0.00/0/0)
tcp        0      0 127.0.0.1:6010          0.0.0.0:*               LISTEN      0          25698      -                    off (0.00/0/0)
tcp        0      0 192.168.56.19:22        192.168.56.1:14539      ESTABLISHED 0          25664      -                    keepalive (0.00/0/0)
tcp        0    112 192.168.56.19:22        192.168.56.1:14536      ESTABLISHED 0          25580      -                    on (0.07/0/0)
tcp6       0      0 :::111                  :::*                    LISTEN      0          19492      -                    off (0.00/0/0)
tcp6       0      0 fe80::36b7:9b71:65:1521 :::*                    LISTEN      54321      36654      19732/tnslsnr        off (0.00/0/0)
tcp6       0      0 :::22                   :::*                    LISTEN      0          22535      -                    off (0.00/0/0)
tcp6       0      0 ::1:6010                :::*                    LISTEN      0          25697      -                    off (0.00/0/0)
tcp6       0      0 :::30631                :::*                    LISTEN      54321      26414      6954/ora_d000_anbob  off (0.00/0/0)
tcp6       0      0 fe80::36b7:9b71:65:1521 fe80::36b7:9b71:6:57238 ESTABLISHED 54321      36752      19732/tnslsnr        keepalive (7091.96/0/0)
tcp6       0      0 fe80::36b7:9b71:6:57238 fe80::36b7:9b71:65:1521 ESTABLISHED 54321      36751      6942/ora_lreg_anbob  off (0.00/0/0)

[oracle@oel7db1 ~]$ sysctl -a  2>&1 |grep keepalive
net.ipv4.tcp_keepalive_intvl = 75
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_time = 7200

在 Oracle 12c 中,Data Guard 同步模式的等待链如下:

"log file sync" (foreground process)
    => "SYNC Remote Write" (LGWR)
        => "Redo Transport MISC" (NSSn)

SQL 跟踪
当出现DATAGURD 同步hang或性能问题时,您可以在 NSSn(主)和 RFS(备用)上启用 SQL 跟踪.

RFS 进程观察
RFS 跟踪文件名在“v$process”中与实际上可能不同,RFS 不是后台进程(v$session.type = ‘USER’)。 RFS 跟踪文件不会在具有该名称的文件系统上实现。

RAC 和 Data Guard
在 MMA 环境中,您可能希望从所有主实例(在具有应用实例的主机上)捕获流量:

tcpdump '(host  and port ) or (host  and port )'

案例

对NSS/RFS 进程的 SQL 跟踪,

NSS2 trace file:

WAIT #0: nam='Redo Transport MISC' ela= 205429

NSS2 trace file:
WAIT #0: nam=’SQL*Net message from client’ ela= 207662

这告诉我们,发送方和接收进程都在网络堆栈上等待, 等待时间都只有 200 多毫秒。接下来是在主数据库服务器和备用数据库服务器上运行 TCP 数据包捕获 (tcpdump),以查看网络堆栈上发生了什么。

为什么在重新传输数据包之前始终需要 200 毫秒?
Linux 内核中有一个用于 TCP 重传的指数回退算法,它在这个环境中从 200 毫秒开始:

$ grep '^CONFIG_HZ' /boot/config-$(uname -r)
CONFIG_HZ_1000=y
CONFIG_HZ=1000

$ grep '#define TCP_RTO_MIN' /usr/src/kernels/$(uname -r)/include/net/tcp.h
#define TCP_RTO_MIN ((unsigned)(HZ/5))

1000 赫兹/5 = 200 毫秒(周期)。在这种情况下,重传只是偶尔发生,相对于总数据包量,退避算法永远不会启动,RTO 保持在 200 毫秒。重传超时是按端口计算的,当前值可以使用“ss”命令显示。例如:

$ ss -o -p -n -i sport = :2483
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
tcp ESTAB 0 0 ::ffff:192.168.56.60:2483 ::ffff:192.168.56.1:46218 users:(("oracle_3485_dev",pid=3485,fd=16)) timer:(keepalive,9min52sec,0)
ts sack cubic wscale:7,7 rto:208 rtt:7.382/13.049 ato:40 mss:1448 rcvmss:1448 advmss:1448 cwnd:10 bytes_acked:5897 bytes_received:4860 send 15.7Mbps lastsnd:8237 lastrcv:8238 lastack:8237 pacing_rate 31.4Mbps rcv_rtt:60 rcv_space:28960
tcp ESTAB 0 0 ::ffff:192.168.56.60:2483 ::ffff:192.168.56.1:46086 users:(("oracle_2024_dev",pid=2024,fd=16)) timer:(keepalive,4min45sec,0)
ts sack cubic wscale:7,7 rto:212 rtt:11.107/15.77 ato:40 mss:1448 rcvmss:1448 advmss:1448 cwnd:10 bytes_acked:7009 bytes_received:7710 send 10.4Mbps lastsnd:1515530 lastrcv:1515611 lastack:315015 pacing_rate 20.9Mbps rcv_rtt:54 rcv_space:28960

可以看到一个端口的 RTO=208,另一个端口的 RTO=212,但它们都接近 200ms。

我们对于它可以做些什么呢?
理想情况下,您不希望在您的网络中发生 TCP 重新传输,但这不会发生,毕竟 TCP 旨在处理有损网络。在这个系统中,重传不到所有 Data Guard 流量的 0.1%,但对交易应用程序的影响是真实的。由于 TCP_RTO_MIN 和回退算法被硬连接到 Linux 内核中,我只知道一种更改最小 RTO 的方法:
为 Data Guard 流量设置单独的网络路由(如果您还没有因为其他原因)和在 IP 路由级别设置 RTO:

ip route change dev proto kernel scope link src rto_min 10ms

由于重传发生在 10 毫秒而不是 200 毫秒之后,这减轻了对 LGWR 和等待发送重做数据的前台进程的影响。您可以将 RTO 设置多低取决于您的网络特性,并且您可能需要拨入该值以免导致额外的重传。

ss -o -p -n -i sport = :2483
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
tcp ESTAB 0 0 ::ffff:192.168.56.60:2483 ::ffff:192.168.56.1:45430 users:((“oracle_1651_dev”,pid=1651,fd=16)) timer:(keepalive,9min52sec,0)
ts sack cubic wscale:7,7 rto:11 rtt:0.303/0.43 ato:40 mss:1448 rcvmss:1448 advmss:1448 cwnd:10 bytes_acked:5897 bytes_received:4860 send 382.3Mbps lastsnd:5082 lastrcv:5421 lastack:5082 pacing_rate 764.3Mbps retrans:0/2 rcv_rtt:31 rcv_space:28960
tcp ESTAB 0 0 ::ffff:192.168.56.60:2483 ::ffff:192.168.56.1:45438 users:((“oracle_1655_dev”,pid=1655,fd=16)) timer:(keepalive,9min54sec,0)
ts sack cubic wscale:7,7 rto:11 rtt:0.291/0.334 ato:40 mss:1448 rcvmss:1448 advmss:1448 cwnd:10 bytes_acked:5896 bytes_received:4860 send 398.1Mbps lastsnd:5082 lastrcv:5556 lastack:5082 pacing_rate 794.1Mbps retrans:0/2 rcv_rtt:69 rcv_space:28960
由于 IP 路由配置,套接字级 RTO 现在开始于 10 毫秒(实际上在上例中为 11 毫秒)。

在OSW的netstat中可以看到tcp重传包非常我TcpRetransSegs, 可以尝试配置启用SACK,减少重传包量。修改内核参数net.ipv4.tcp_sack

Selective Acknowledgement: SACK
To overcome above problem, Selective Acknowledgement(SACK) mechanism was devised and defined by RFC-2018. With Selective Acknowledgement(SACK), user ‘B’ above uses its TCP options field to inform user ‘A’ about all the segments(1,2,4,6,8-13) it has received successfully, so user ‘A’ needs to retransmit only segments 3, 5, and 7, thus considerably saving the network bandwidth and avoiding further congestion.

打赏

, ,

目前这篇文章还没有评论(Rss)

我要评论