Re: Performance advice

"Paul Watson" <paul@oninit.com> wrote in message news:4086234F.F15D6FD2@oninit.com... > > CDI had this argument a while back. I start with the server and work > back via the engine and then the SQL. > First tune sql...decided what you want the engine to do first. Then tune how it does it. onstat -u and look for sessions with unnormal disk reads/writes. Get ridof sequential scans on large tables for OLTP sessions. Check the right indicies exist and are being used. Reduce the load on the engine first. Then tune the engine once you know what you want it to do. Once the app and the engine are tuned once you should have got rid of MOST performance issues. Then revisit the sql in light of how the engine is performing if you need to get better performance. Can we uses Jack Parkers 'set at a time' rather than 'row of a time' idea to get even better performance. Then tune the engine again. > -- > Paul Watson # > Oninit Ltd # Growing old is mandatory > Tel: +44 1436 672201 # Growing up is optional > Fax: +44 1436 678693 # > Mob: +44 7818 003457 # > www.oninit.com #

David Williams wrote: > > First tune sql...decided what you want the engine to do first. > Then tune how it does it. Tempered by the fact that if you've done it a few times, you know the application and don't need to measure the same results for the 50th time... Of course, we know nothing about sumGirls application, but she has now replied that it's an OLTP site, and there are still a lot of broad assumptions that hold. Which is lucky, or a newsgroup wouldn't be able to help anyone.