"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.
--
with regards
Dusan Bolek
Received on Sun Nov 23 2003 - 11:46:19 CST
