Any parameter to measure the Performance between two server

Question

Currently I am running more 20 dvlp database in 2 cpu 2 GB RAM Windows2000
server
We are curently in process of upgrading the infarasturcutre
We are moving the DB the a 2003 STD R 2 server with 4gb Ram and 2 processor
I ahve configure everything in the new server except Moving of Dbs from old to NEW server
versions 8,9 10gr2
But starngley i feel the new server performs slowly when compared to old server not frpm DB point of view but while copying between different disks in the same NEW server
It takes long time than usual across our office
Tomorrow i will be moving a few DBS to the new machine
Everythinh s going to be same in the Init.ora.No change in SGA or INIT parameters execept the driectory structure
i want run the DBs in OLD and NEW machine and compare the response time
Willbe sufficent enough to give an idea whether the new server is performing better or worse
Any susgestions
Message was edited by:
Maran Viswarayar

Answer 1

I don't think so, it depends on the way you conduct
your testing environment, how you build it, and
what's the goal of this test. I wouldn't name it
synthetic test, I name it standarized test
environment.Just to be clear, I have nothing against doing synthetic tests, and I don't intend "synthetic" to be in any way derogatory. This sort of testing can be quite valuable. You just need to be careful about extrapolating the performance of this sort of testing to the performance that your application will actually achieve. Since the workload your application is performing is generally going to be quite different than the synthetic workload you're describing, the comparison may not be direct.
OS performance metrics can be gathered directly with
the OS party. But knowing exactly how your database
will perform in your specific environment ... You'll
have to make up a testing environment.All true. Knowing how your database will perform, particularly on I/O intensive operations, though, doesn't tell you how a particular application running in your database may perform. Your application may, for example, be CPU bound or may be doing very non-random IO operations.
Given that the original poster is seeing odd disk behavior, and his primary concern is with the IO subsystem, I would suggest starting the test there.
Performance problems have always been multifactorial,
and this always makes a tuning approach to be
obscure. Unless a professional has enough practical
experience, it becomes a black box problem where
interactig subsystems will make it difficult the goal
of finding the most meaningful performance thread and
its interactions.Very true
I have used this test approach and it has assisted me
in obtaining an environment free of subjectivities
where I have been able to benchmark Oracle behaviour
on different platforms.
This kind of test has also helped me in creating
controled stressing situations where I can
proactively plot potential bottlenecks and meassure
different rdbms architectural aspects such as
transactional mechanism, sorting, undo segments,
latches, networking, etc. just to name a few, at
different load scenarios.Synthetic test loads are excellent for this sort of database performance investigation, agreed.
It is sometimes difficult to find hundreds of
volunteers to test the application to find the point
of maximum sessions with minimum response time. This
testing approach has been useful in hiring a variable
number of virtual volunteers that are willing to test
the environment any time. So it has also allowed me
to create useful reports, such as the "users load vs.
response time" which helped me in predicting my
system operational ceilings, and it has been pretty
accurate.If we're talking about testing application performance, rather than testing generic database performance, I'd maintain that you shouldn't need any volunteers. You should have scripts that replicate the key business operations the application does and you should have a harness that can start up arbitrary numbers of concurrent sessions (admittedly, you may need a handful of volunteers to launch these scripts from a sufficient number of laptops).
It all depends on the way you define your test
environment.100% agreed.
Justin