Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> c.d.o.server -> Re: SQL Trace on very busy server - experiences, warnings, horror stories ...
"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.
I dislike the idea as well, for these reasons.
What is the business case for making this change and what happened in your test with 4000 simulated users?
-- Niall Litchfield Oracle DBA Audit Commission UK ***************************************** Please include version and platform and SQL where applicable It makes life easier and increases the likelihood of a good answer ******************************************Received on Sat Nov 22 2003 - 13:52:33 CST