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.
微信扫一扫，打赏作者吧～
对不起，这篇文章暂时关闭评论。