Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: SQL Trace on very busy server - experiences, warnings, horror stories ...

Re: SQL Trace on very busy server - experiences, warnings, horror stories ...

From: Anurag Varma <avdbi_at_hotmail.com>
Date: Sat, 22 Nov 2003 15:30:10 GMT
Message-ID: <6iLvb.4481$yy5.218@nwrdny01.gnilink.net>

"Dusan Bolek" <pagesflames_at_usa.net> wrote in message news:1e8276d6.0311210801.2e5bd33a_at_posting.google.com...
> Greetings,
>
> does anyone here has an experience with using SQL_TRACE = True on
> quite busy business critical system?
> Right now, one guy here wants to use SQL Trace on 24x7 business
> critical server with up to 4000 concurrent users. Database is 8.1.7EE
> 64-bit on Solaris (SF15k). During peaks, CPUs occupation is about 80%,
> with day averages between 50% - 60%.
> My feelings about this are somehow mixed. I fear that we can run into
> big trouble, because performance of system can go down and client's
> voices high.
> The problem with SQL_TRACE is that it is a static parameter, so if we
> will encounter any problem we will be forced to restart our database
> during peak hours. So for me is really important to estimate
> probability that we will need to do this. I can think about switching
> SQL Trace off and restarting server as backup solution with 10%
> probability, but I can't accept this as fifty-fifty scenario.
> I've used SQL Trace in past, but never on server of such importance
> and with load that is quite high. Do you have any experiences with
> this? I would accept even horror stories and suggestions like "never
> do that, you fool!" :-)
>
> P.S. Maybe I'm too cautious, but I really dislike this whole idea.
> However, I can't operate just with my feelings. I need some solid
> ground to make qualified decision.
>
> Thanks
>
> --
> Dusan Bolek

Dusan,

Apart from what others have told you.
I'll also second that you should not turn it for the whole system. Even if you do, do it in a way that you can turn it off.

One way I'd suggest is to use oradebug.

To turn sqltrace for another session:

sqlplus "/ as sysdba"
SQL> oradebug setospid <spid>
SQL> oradebug event 10046 trace name context forever, level 8

You can write a dynamic sql to get all the spid's to trace (Make sure they are all the user spid's)....

Then turn them off at will. Thats the key ... if users start complaining .. or the trace data gets too much...
turn it off without shutting down the system.

HTH
Anurag Received on Sat Nov 22 2003 - 09:30:10 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US