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

pagesflames_at_usa.net (Dusan Bolek) wrote in message news:<1e8276d6.0311230946.53e89231_at_posting.google.com>...
> "Niall Litchfield" <niall.litchfield_at_dial.pipex.com> wrote in message news:<3fbfbe7b$0$25674$cc9e4d1f_at_news.dial.pipex.com>...
> > I dislike the idea as well, for these reasons.
> >
> > 1) Its an overhead.
> > 2) It isn't targeted so it cannot give you useful data
> > 3) what will you do with 4000*500mb trace files?
> > 4) statspack will give you systemwide data and information as well.
> > 5) you should be looking at problem sessions or problem processes, these are
> > exactly amenable to tracing.
> >
> >
> > What is the business case for making this change and what happened in your
> > test with 4000 simulated users?
>
> I should probably apologize myself. It would be a better idea to show
> the whole picture not just a limited part of it.
> So the problem is that we're preparing move from one server (SF15k
> 8.1.7) to another (pSeries 9.2). Before we do this, we need to know
> how the new server will take this load. Problem is that developers do
> not know much about what's going on in this database. The database
> we're talking about serves as central repository for some customer
> related information. Other distributed database (50 of them) are
> opening and closing session on demand via DB link.
> What other here wants is to create test script that will simulate
> load, so we can compare these two servers. We can't use trace only for
> sessions, because these session are randomly created and closed on
> demand. We can't use any application trace, because selects are
> burried in the code (too bad) and distributed over 50 databases (even
> worse).
> My idea is to take no care about application and just create generic
> load (some selects randomly picked from application) and use this as
> comparing script. I think that as comparison measurement this should
> be sufficient and is much more safe than the other option.
> Right now, we do not have any significant problems with this database,
> so this is not a performance tuning! I do not care about problematic
> sessions or any sql tunning. I just need to prove that this will work
> with new server and keep some desired performance level, that's all.

I would suggest the following text:

Scaling Oracle8i: Building Highly Scalable Oltp System Architectures James Morle
Addison-Wesley, Paperback, Bk&CD edition, Published December 1999, 513 pages, ISBN 0201325748

you can find it here:

http://www.bookpool.com/.x/q65x6kqv1i/ss/1?qs=morle

hth.

Pd Received on Sun Nov 23 2003 - 16:43:49 CST