- you can turn sql trace on at the session level, but only from the
session itself. The SQL to issue is 'alter session set sql_trace=true'.
To end sql trace from a session, 'alter session set sql_trace=true'. If
you can't get to the app code (say you bought a package) and the app does
not provide a backdoor for you to issue SQLs, then you are stuck with
global sql_trace in init.ora. I'm still waiting for Oracle to implement a
machenism that the DBA can use to turn sql trace on for a specific user
session...
- timed_statistics are not just used by sql_trace. B/Estat also uses
stats collected by timed_statistics. As a general rule, I've always turned
timed_statistics on for the production DBs I monitor. I have not found
time_statistics incurs noticeable overhead on the DBs I have worked on.
Pei
DBA
azaman <azaman_at_ibm.net> wrote in article <34BF8C9D.6242_at_ibm.net>...
> Hi Everyone
>
> Please help me understand the following two init.ora parameters:
>
> o sql_trace
> o timed_statistics
>
> Questions:
>
> 1. Can I set these parameters to TRUE at session level ?
>
> 2. If timed_statistics is set to TRUE and sql_trace set to
> FALSE at instance level , is the system incurring any
> overheads because of timed_statistics being set to TRUE ?
>
> 3. Is this a sensible plan :
> Have timed_statistics set to TRUE and sql_trace set
> to FLASE at instance level.
>
> Only set sql_trace to TRUE at session level if
> required.
>
> I will really appreciate an -email with any information.
>
> Arif Zaman ( azaman_at_ibm.net)
>
Received on Mon Jan 19 1998 - 00:00:00 CST
