NSSn<\/strong> is the process shipping the redo data from primary to standby. n<\/strong> is the number matching the LOG_ARCHIVE_DEST_n<\/strong> parameter for your redo transport configuration<\/em><\/p>\n Getting the IP of the primary host is easy, even if there is a separate network for Data Guard. Method A<\/strong> In our example the port is 18274 resulting in this “tcpdump” command:<\/p>\n Method B<\/strong> Voil\u00e0.<\/p>\n SQL trace<\/strong> Primary<\/p>\n Standby<\/p>\n Observation about the RFS process<\/strong> RAC and Data Guard<\/strong> Sometimes it is helpful to trace Data Guard background services so we can look at matching NSSn and RFS traces. For deep dives we also want to run TCP captures on both ends of a Data Guard configuration, and possibly on network components in the middle. To minimize processing overhead on devices and noise in […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-482","post","type-post","status-publish","format-standard","hentry","category-internals"],"_links":{"self":[{"href":"https:\/\/www.spotonoracle.com\/index.php?rest_route=\/wp\/v2\/posts\/482","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.spotonoracle.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.spotonoracle.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.spotonoracle.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.spotonoracle.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=482"}],"version-history":[{"count":27,"href":"https:\/\/www.spotonoracle.com\/index.php?rest_route=\/wp\/v2\/posts\/482\/revisions"}],"predecessor-version":[{"id":513,"href":"https:\/\/www.spotonoracle.com\/index.php?rest_route=\/wp\/v2\/posts\/482\/revisions\/513"}],"wp:attachment":[{"href":"https:\/\/www.spotonoracle.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=482"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.spotonoracle.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=482"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.spotonoracle.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=482"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\nBut how do we get the PORT of the NSSn process?<\/p>\n
\nIdentify the NSSn process on the primary:<\/p>\n\r\nselect ses.sid, ses.serial#, ses.machine, ses.port, prc.pname, prc.spid, prc.stid, prc.tracefile\r\nfrom gv$session ses\r\n join gv$process prc on (prc.inst_id = ses.inst_id and prc.addr = ses.paddr)\r\nwhere prc.pname like 'NSS%'\r\n;\r\n<\/pre>\n
![\"\"](\"https:\/\/www.spotonoracle.com\/wp-content\/uploads\/2019\/08\/primary-NSSx.png\")
<\/a>
\nThe trick is to use the SPID as it is reflected in “v$session.process” on the standby database instance. In this case we query for process 4582 on the standby database:<\/p>\n\r\nselect ses.sid, ses.serial#, ses.machine, ses.port, prc.pname, prc.spid, prc.stid, prc.tracefile\r\nfrom gv$session ses\r\n join gv$process prc on (prc.inst_id = ses.inst_id and prc.addr = ses.paddr)\r\nwhere ses.process = '4582'\r\n;\r\n<\/pre>\n
![\"\"](\"https:\/\/www.spotonoracle.com\/wp-content\/uploads\/2019\/08\/standby-RFS.png\")
<\/a><\/p>\n\r\ntcpdump 'host 192.168.55.71 and port 18274'\r\n<\/pre>\n
\nUse the same query to get the SPID of the NSSn process on the primary as in the first method.
\nWith the SPID we can find the TCP connection details using the “ss” Linux utility:<\/p>\n\r\nss -o -p -n -i | grep 4582\r\n<\/pre>\n
![\"\"](\"https:\/\/www.spotonoracle.com\/wp-content\/uploads\/2019\/08\/primary-ss.png\")
<\/a><\/p>\n
\nObviously, with the respective SID\/SERIAL# combinations you can enable the SQL trace on NSSn (primary) and RFS (standby):<\/p>\n\r\nexec dbms_monitor.session_trace_enable(session_id=> 83, serial_num => 57385, waits => true, binds => false)\r\n<\/pre>\n
\r\nexec dbms_monitor.session_trace_enable(session_id=> 191, serial_num => 37747, waits => true, binds => false)\r\n<\/pre>\n
\nThe RFS trace file name shows as “DEV1_ora_4187.trc” in “v$process”. In fact, RFS is not a background process (v$session.type = ‘USER’).
\nBut here’s an oddity, when activating SQL trace on RFS the trace file does not materialize on the filesystem with that name. It actually materializes with “DEV1_rfs_4187.trc”.
\n![\"\"](\"https:\/\/www.spotonoracle.com\/wp-content\/uploads\/2019\/08\/RFS-trace-file-name.png\")
<\/a><\/p>\n
\nIn a MMA environment you’d probably want to capture traffic from all primary instances (on the host with the apply instance):<\/p>\n\r\ntcpdump '(host <primary IP A> and port <NSSn port A>) or (host <primary IP B> and port <NSSn port B>)'\r\n<\/pre>\n","protected":false},"excerpt":{"rendered":"