Re: How to read SQL*NET Trace files and which parameter is suitable?

"MATHEW KING" <bzbzzb_at_hotmail.com> wrote in message news:528c8daf.0402280756.7a928615_at_posting.google.com...
> Hi,
>
> I wanted to get some information about SQL*Net tracing.
> As far as my knowledge is concern there are several approaches
> available to enable tracing of SQL*NET.
>
> For Example:
>
> TRACE_LEVEL_SERVER=SUPPORT (For Server Tracing)
>
> TRACE_LEVEL_CLIENT=USER (For client tracing)
>
> I like to say that for (For Server Tracing) we use
> TRACE_LEVEL_SERVER=SUPPORT
> for enabling tracing, but it generates a lots of information, on the
> other side TRACE_LEVEL_CLIENT=USER generates limited information.
>
> What we can do if we want to trace a particular session over the
> network ,which perform backup operations on database server?
>
> And how should we read the SQL*NET trace file, because its contents
> can't be readable?
>
> THANKS
>
> Bilal

Trace_level_client and trace_level_server are two *different* parameters, which can both get identical values.
If you would set *both* of them to support you would get *exactly* the same information.
You can't enable sql*net tracing for a specific session, you either trace sqlnet or you don't.
There is trcasst tool to format the trace files and to obtain information. I'm not sure why you would want to trace backup operations and whether a **sql*net trace** is suitable for that. The traffic would be minimal. I'm guessing you are confusing sql tracing and sql*net tracing. If you want to obtain statement info, you would better use sql tracing.

-- 
Sybrand Bakker
Senior Oracle DBA

to reply remove '-verwijderdit' from my e-mail address