Automatic Performance Diagnosis and Tuning in Oracle

One of the things that makes performance tuningdifficult is that the performance of different componentsof the database is often measured using unrelated metricslike buffer hit-ratio, transactions per second and averageI/O latency. Such unrelated metrics make it infeasible toweigh the performance impact of one component of thedatabase with the impact of others components. Tuningactions that are solely based on such metrics have atendency either to make the DBAs believe that thedatabase needs excessive hardware or to make just onecomponent of the database perform better with negligibleeffect on the total database throughput.Keeping these limitations in mind, we built theAutomatic Database Diagnostic Monitor (ADDM) inOracle 10g. ADDM automates the entire process ofdiagnosing performance issues and suggests relevanttuning recommendations with the primary objective ofmaximizing the total database throughput.Modern database systems have complicatedinteractions between their sub-components and have theability to work with a variety of applications. This resultsin a very large list of potential performance issues suchautomatic diagnosis solutions could identify. Also, as newdatabase technologies and applications are invented andolder ones are obsoleted, it is pivotal that automaticdiagnostic and tuning solutions can easily be adapted toaccommodate such changes.The objectives of an automatic performance diagnosisand tuning solution can be summarized as follows:• Should posses a holistic view of the database andunderstand the interactions between variousdatabase components.• Should be capable of distinguishing symptomsfrom the actual root-cause of performancebottlenecks.• Should provide mechanisms to diagnoseperformance issues on their first occurrence.• Should easily keep up with changingtechnologies.The remainder of the paper is organized as follows:We discuss related work in both academic research andcommercially available databases in Section 2. We definea new measure, Database Time, and describe in detail ourmethodology to solve this problem in Section 3. Wediscuss the various measurements that were required toimplement our solution in Section 4. We extend ourdefinition of Database Time to other models in Section 5and explain how ADDM plays a central role in Oracle10g’s self-managing framework in Section 6. We presentthe experiments we used to validate our implementationand their results in Section 7. Finally, we summarize ourconclusions in Section 8.2. Related WorkThe COMFORT project used an online feedback controlloop to solve individual tuning issues like load control forlocking, dynamic data placement among others [WE02,WE94]. Automated tuning systems have been proposed[HE97] that employ a feedback control mechanismlayered on top of a target system. A different school ofthought suggests that current database systems have toomany features, unpredictable performance and very low“gain/pain ratio”, and RISC-type simplification ofdatabase functionality is crucial to achieve automatictuning [WE02, CH00].Oracle’s previous solution for performance tuning wasStatspack [ORP8, ORP9, ORSP]. Statspack is a tool thattakes snapshots of database performance statistics andgenerates reports across a pair of snapshots. ThoughStatspack reports reduced the time it took for DBAs todiagnose performance issues [ORSP2], it still left theinterpretation of the report and the actual root-causeidentification to the DBAs. Oracle 9i has other selfoptimizingfeatures like dynamic runtime queryoptimization [ORQ9], self-configuring features for spaceand memory management [DA02, ORM9, EL03]. Referto Section 6 for a description of various Oracle 10g’smanageability features like “SQL Tuning Advisor” and“Segment Advisor”. IBM DB2 version 8.1 has featureslike “Health Center” for database monitoring and“Configuration Assistant” to assist DBAs in databaseconfiguration [IBP8, IBG8]. Similarly, SQL Server 2000provides performance tools like “Index Tuning Wizard”and “SQL Query Analyzer” to help the DBA achieveindividual performance goals and has monitoring toolslike “System Monitor objects” [CH97, MSPD].Commercially available databases have features tomanage some of their sub-components automatically,mechanisms to actively monitor database performance,and tools that make it easier for the DBA to achieve somespecific performance goals. However, none of them (untilOracle 10g) have a performance diagnosis and tuningsolution that automatically identifies the root-causesaffecting total database throughput.3. Automatic Performance DiagnosisPerformance of various components of the database aremeasured using different metrics. For example, theefficiency of the data-block buffer cache is expressed as apercentage in buffer hit-ratio; the I/O subsystem ismeasured using average read and write latencies; thedatabase throughput is measured using transactions-persecond.However, using these metrics, finding theperformance impact of a particular component over thetotal database throughput is extremely hard, if notinfeasible. For example, determining by how much wouldtransactions-per-second decrease if the average I/Olatency becomes twice as long is not trivial.