The main thrust of this presentation is how to react quickly and efficiently when the performance of the database comes under question. The performance of the database is at the heart of many companies. The importance of performance is especially easy to see with the proliferation of web sites where customers often decide for or against the use of a sight based on response time. Degraded (or nonexistent) reponse time can mean huge losses of money at many sites, such as telecom billing, thus the enormous interest in resolving response time problems as quickly as possible.
Often when the performance of the database degrades a crises can ensue and it can be hard to think about the best way to resolve the crises and people are pointing the finger at everyone and the database tends to be a typical scape goat.
This presentations presents a quick step by step method to verify that the performace problem isn't coming from the database (its important to have proof) or if it is comming from the database, then these steps will quickly identify where they are coming from. Knowing where the problem is coming from is neccessary to be able to apply perssure/resources in the right place whether its to the CTO to buy new hardware, to Oracle to fix a bug, to have developers fix bad sql, or for the dba to tune the database add indexes, etc