I discovered a limitation in SQLNet tracing while troubleshooting a RMAN problem (tested on Oracle 12.2 only).
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.
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.
This can be seen from the following excerpt of the v$sesison output on the primary and the auxiliary database:
select spid,process,s.program,client_info
from v$process p,v$session s where s.paddr = p.addrAuxiliary database:
SPID PROCESS PROGRAM CLIENT_INFO
---- ------- --------------------------- -------------------
1128 11885 rman@aux_server (TNS V1-V3) rman channel=chaux1
Primary database:
SPID PROCESS PROGRAM CLIENT_INFO
----- ------- ---------------------------- -----------
21226 1128 oracle@aux_server (TNS V1-V3)As you can see, the dedicated server process 1128 on the auxiliary server is also connected to the primary database instance, but its client SQLNet trace won’t be generated.
I’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.
I wouldn’t expect a client sqlnet trace file but a serverside sqlnet trace file since rman is implemented serverside (as opposed to exp client). Isn’t TRACE_LEVEL_SERVER=16 giving you any traces when rman connects to auxiliary database?
You’re right – the “missing” client trace information is indeed contained in the server trace file, for example:
In conclusion, not only does the SQLNet server trace file for the RMAN dedicated server process on the auxiliary database contain the server trace of this process, but also it entails the client trace information of the primary database connection.
Thank you for pointing that out.