I discovered a limitation in SQLNet tracing while troubleshooting a RMAN problem (tested on Oracle 12.2 only).<\/p>\n
In general, when a dedicated server process is making a connection to another database instance, at the same time it’s acting as a client of this remote database. But, curiously, a client trace won’t be generated for such process. <\/p>\n
For example, this is happening during rman “duplicate from active”. In this case, a dedicated server process of an rman auxiliary channel is connecting to the primary database. <\/p>\n
This can be seen from the following excerpt of the v$sesison output on the primary and the auxiliary database:<\/p>\n
select spid,process,s.program,client_info \r\n from v$process p,v$session s where s.paddr = p.addr<\/code><\/pre>\nAuxiliary database:<\/p>\n
SPID PROCESS PROGRAM CLIENT_INFO\r\n---- ------- --------------------------- -------------------\r\n 1128<\/span> 11885 rman@aux_server (TNS V1-V3) rman channel=chaux1\r\n<\/code><\/pre>\nPrimary database:<\/p>\n
SPID PROCESS PROGRAM CLIENT_INFO\r\n----- ------- ---------------------------- -----------\r\n21226 1128 oracle@aux_server (TNS V1-V3)<\/span><\/code><\/pre>\nAs you can see, the dedicated server process 1128<\/span> on the auxiliary server is also connected to the primary database instance, but its client SQLNet trace won’t be generated.<\/p>\nI’m sharing this finding, because it’s so easy to misinterpret the trace if you’re not aware that some piece of information is missing. <\/p>\n","protected":false},"excerpt":{"rendered":"
SQLNet client trace is missing. Continue Reading