Jorma, Performance tuning is a complex subject. There really isn't a list of 10 things to watch for. Every system is different.
I would (attempt to) summarize tuning by these five steps: 1.) Have a capacity/performance target in mind. If you don't know where you're going, how will you know if you have gotten there? 2.) Monitor your response times as load increases. Can you achieve your response time target at the specified load? If so, you're done, successful test, congratulations. If not, continue to next step. 3.) Actively monitor what's going on in the database, while it's happening. It's always easier to see it in real time than just looking at random StatsPack snapshots taken at 5 or 10 or 15 minute intervals. (Not that I'm saying StatsPack shouldn't be collected. I'm just saying don't rely on StatsPack as your only source of info about the database.) The V$ Wait Interface is your friend. If you're not familiar with it, go to http://www.hotsos.com/ and get Mogens Norgaard's paper, Introducing the V$ Wait Interface. Where is the database spending it's time? What's the bottleneck? If you identify a few trouble sessions, you may want to dive deeper w/ some 10046 traces at level 8 on specific sessions. You almost certainly do NOT want to do this instance wide. 4.) Once you have some indication as to what's going on in the database, you need to see how the system is doing overall. On most flavors of *nix, where I'm comfortable, sar (System Activity Reporter) is an excellent tool. Use it to determine if you have any systemwide CPU, memory, or I/O contention. (Other OSes almost certainly have similar utilities.) 5.) Address the biggest bottleneck. This is where it can't be summarized in a simple step. You need to understand the bottleneck, so that you can understand how to tune it. If may be latch contention. Depending on the latch, it could be poorly tuned SQL, or lack of bind variables, or simple CPU capacity limits, or a whole host of things. I/O contention? Could be anything from poorly designed and/or configured RAID array to poorly tuned SQL, or who knows what. Determine the cause of the biggest bottleneck and minimize or eliminate it. There you have it, Mark's Simplified Performance Tuning, in five easy steps! ;-) -Mark On Wed, 2002-10-02 at 02:08, [EMAIL PROTECTED] wrote: > Ave ! > > I like to hear Your opinion about the most importat > issues, what should be monitored from the database (8.1.7, SUN) during > perfomance testing. The purpose in this case, is limit the > monitoring to concern only about 10 most important ones. > > I have difficulties to make my mind to pick up the right ones, so > if You had to have made similar kind of decisions or have opinions, > please let me know. > > TIA > Jorma > ----------------------------------------------------------------- > Name: Jorma Vuorio Phone: +358-9-7180 67759 > Company: Nokia Business Infrastucture Fax: +358-9-7180 67465 > Address: P.O.Box 321, FIN-00045 NOKIA GROUP, FINLAND > Internet: [EMAIL PROTECTED] Mobile: +358-50-486 8043 > ----------------------------------------------------------------- -- -- Mark J. Bobak Oracle DBA [EMAIL PROTECTED] "It is not enough to have a good mind. The main thing is to use it well." -- Rene Descartes -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Mark J. Bobak INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
