When an Oracle database becomes slow, the first question every DBA needs to answer is:<\/p>\n\n\n\n
What is actually causing the performance problem?<\/strong><\/p>\n\n\n\n Is it CPU? Instead of guessing, an Oracle DBA should follow a systematic troubleshooting approach.<\/p>\n\n\n\n In this guide, we will learn how to troubleshoot Oracle Database performance using AWR, ASH, ADDM, wait events, Top SQL, and execution plans<\/strong>.<\/p>\n\n\n\n The examples are useful for Oracle Database 19c and newer environments, including Oracle AI Database 26ai.<\/p>\n\n\n\n Oracle Database performance tuning is the process of identifying the reason a database is taking too long to complete work and then making targeted changes to improve performance.<\/p>\n\n\n\n A simple performance-tuning process is:<\/p>\n\n\n\n Identify the problem \u2192 Collect evidence \u2192 Find the root cause \u2192 Apply the fix \u2192 Validate the result<\/strong><\/p>\n\n\n\n The most important part is to avoid making changes before understanding the problem.<\/p>\n\n\n\n For example, if CPU utilization is high, increasing CPU may not solve the real problem.<\/p>\n\n\n\n A single SQL statement performing unnecessary work could be responsible for most of the CPU usage.<\/p>\n\n\n\n Therefore, the first question should always be:<\/p>\n\n\n\n Why is the resource being consumed?<\/strong><\/p>\n\n\n\n Oracle performance problems generally fall into a few common categories.<\/p>\n\n\n\n A database may become slow because the server is spending too much time processing CPU-intensive workload.<\/p>\n\n\n\n Common symptoms include:<\/p>\n\n\n\n The important question is:<\/p>\n\n\n\n Which SQL or workload is consuming the CPU?<\/strong><\/p>\n\n\n\n Do not immediately increase CPU resources. First identify the workload responsible.<\/p>\n\n\n\n An Oracle database can also become slow when sessions spend significant time waiting for disk or storage operations.<\/p>\n\n\n\n Common symptoms include:<\/p>\n\n\n\n However, high I\/O does not always mean the storage system is the problem.<\/p>\n\n\n\n For example:<\/p>\n\n\n\n A poorly designed SQL statement may read millions of blocks unnecessarily.<\/p>\n\n\n\n The real problem may therefore be the SQL execution plan rather than the storage itself.<\/p>\n\n\n\n Sometimes the database is not actually processing slowly.<\/p>\n\n\n\n Sessions may simply be waiting for another session to release a lock.<\/p>\n\n\n\n For example:<\/p>\n\n\n\n This can result in:<\/p>\n\n\n\n Before killing a session, understand which session is blocking whom and what transaction is involved.<\/p>\n\n\n\n One SQL statement can sometimes consume a significant amount of database resources.<\/p>\n\n\n\n A SQL statement may consume large amounts of:<\/p>\n\n\n\n Finding the SQL responsible is often one of the most important steps in Oracle performance troubleshooting.<\/p>\n\n\n\n When an application team reports:<\/p>\n\n\n\n “The Oracle database is slow.”<\/p>\n<\/blockquote>\n\n\n\n A practical DBA workflow is:<\/p>\n\n\n\n This approach is much safer than randomly changing database parameters.<\/p>\n\n\n\n AWR stands for Automatic Workload Repository.<\/strong><\/p>\n\n\n\n AWR collects and stores database performance information that can be used to analyze workload over time.<\/p>\n\n\n\n AWR data can include information about:<\/p>\n\n\n\n AWR is especially useful when the performance problem happened in the past and is no longer occurring.<\/p>\n\n\n\n For example, suppose users reported that the application was slow between 10:00 AM and 12:00 PM.<\/p>\n\n\n\n You can compare AWR snapshots covering that period and investigate what happened.<\/p>\n\n\n\n AWR and other Diagnostic Pack features are subject to Oracle licensing requirements. Always verify the applicable Oracle licensing terms for your environment before using licensed functionality.<\/p>\n\n\n\n You can check available AWR snapshots using:<\/p>\n\n\n\n You can then generate an AWR report using Oracle’s supplied script:<\/p>\n\n\n\n Oracle will ask you for information such as:<\/p>\n\n\n\n For example:<\/p>\n\n\n\n This allows you to analyze the workload between those snapshots.<\/p>\n\n\n\n An AWR report contains a lot of information.<\/p>\n\n\n\n You do not need to read every section from top to bottom.<\/p>\n\n\n\n Start with the sections that answer one question:<\/p>\n\n\n\n Where is the database spending its time?<\/strong><\/p>\n\n\n\n The Load Profile provides a quick overview of database workload.<\/p>\n\n\n\n Important metrics include:<\/p>\n\n\n\n Look for unusual values and compare them with a normal period whenever possible.<\/p>\n\n\n\n The wait-event section helps you understand where foreground sessions are spending time.<\/p>\n\n\n\n For example:<\/p>\n\n\n\n These numbers are only an example.<\/p>\n\n\n\n The important point is that a wait event should not automatically be treated as the root cause.<\/p>\n\n\n\n A wait is often a symptom of another problem.<\/p>\n\n\n\n For example:<\/p>\n\n\n\n The DBA should follow the chain back to the root cause.<\/p>\n\n\n\n ASH stands for Active Session History.<\/strong><\/p>\n\n\n\n ASH provides sampled information about active database sessions.<\/p>\n\n\n\n It is particularly useful when the performance problem:<\/p>\n\n\n\n For example, suppose an application team reports:<\/p>\n\n\n\n “The application was extremely slow between 10:32 AM and 10:37 AM.”<\/p>\n<\/blockquote>\n\n\n\n Instead of looking at an entire day’s workload, ASH can help you investigate that specific period.<\/p>\n\n\n\n Important ASH dimensions include:<\/p>\n\n\n\n For example:<\/p>\n\n\n\n Now you have a useful starting point.<\/p>\n\n\n\n You can investigate SQL ID ADDM stands for Automatic Database Diagnostic Monitor.<\/strong><\/p>\n\n\n\n ADDM analyzes AWR data and identifies significant database performance problems.<\/p>\n\n\n\n Depending on the environment and workload, ADDM can identify issues involving areas such as:<\/p>\n\n\n\n ADDM can also provide recommendations.<\/p>\n\n\n\n However, an ADDM recommendation should not automatically be implemented in production.<\/p>\n\n\n\n A DBA should validate the recommendation against the actual environment and business workload before making changes.<\/p>\n\n\n\n This is also a common Oracle DBA interview question.<\/p>\n\n\n\n An easy way to remember:<\/p>\n\n\n\n AWR \u2192 What happened?<\/strong><\/p>\n\n\n\n ASH \u2192 What was happening during a specific period?<\/strong><\/p>\n\n\n\n ADDM \u2192 What performance problems did Oracle identify?<\/strong><\/p>\n\n\n\n Top SQL \u2192 Which SQL consumed the resources?<\/strong><\/p>\n\n\n\n Execution Plan \u2192 How was that SQL executed?<\/strong><\/p>\n\n\n\n Once you know that SQL is responsible for the performance problem, identify the SQL ID.<\/p>\n\n\n\n For example:<\/p>\n\n\n\n This provides a starting point for identifying SQL statements with high total elapsed time.<\/p>\n\n\n\n However, do not automatically assume that the SQL with the highest total elapsed time is always the statement that needs immediate attention.<\/p>\n\n\n\n Consider:<\/p>\n\n\n\n For example:<\/p>\n\n\n\n SQL B may deserve significant investigation because it runs a very large number of times.<\/p>\n\n\n\n Always interpret SQL statistics in context.<\/p>\n\n\n\n After identifying a problematic SQL statement, examine its execution plan.<\/p>\n\n\n\n A useful command is:<\/p>\n\n\n\n Replace Look for:<\/p>\n\n\n\n But remember:<\/p>\n\n\n\n A full table scan is not automatically a problem.<\/strong><\/p>\n\n\n\n If Oracle needs to read a large percentage of a table, a full table scan may be the appropriate access method.<\/p>\n\n\n\n The goal is not to eliminate every full table scan.<\/p>\n\n\n\n The goal is to determine whether the execution plan is appropriate for the workload.<\/p>\n\n\n\n For example:<\/p>\n\n\n\n High CPU<\/p>\n\n\n\n does not automatically mean:<\/p>\n\n\n\n Increase CPU<\/p>\n\n\n\n Similarly:<\/p>\n\n\n\n High physical reads<\/p>\n\n\n\n does not automatically mean:<\/p>\n\n\n\n Increase buffer cache<\/p>\n\n\n\n And:<\/p>\n\n\n\n High waits<\/p>\n\n\n\n does not automatically mean:<\/p>\n\n\n\n Change a database parameter<\/p>\n\n\n\n Instead, follow this approach:<\/p>\n\n\n\n This mindset is one of the most important skills for an Oracle DBA.<\/p>\n\n\n\n Suppose an application report normally takes 2 minutes but suddenly takes 20 minutes.<\/p>\n\n\n\n First determine exactly when the problem occurred.<\/p>\n\n\n\n For example:<\/p>\n\n\n\n Problem window: Look for significant findings reported during the affected period.<\/p>\n\n\n\n Review:<\/p>\n\n\n\n Use ASH to identify active sessions and SQL IDs during the exact problem window.<\/p>\n\n\n\n Suppose you identify:<\/p>\n\n\n\n SQL_ID = 4m7abc123<\/p>\n\n\n\n Run:<\/p>\n\n\n\n Suppose you find:<\/p>\n\n\n\n Estimated rows: 100 That difference is an important clue.<\/p>\n\n\n\n You can then investigate:<\/p>\n\n\n\n Only after identifying the root cause should you make a production change.<\/p>\n\n\n\n The appropriate fix depends on what the investigation shows.<\/p>\n\n\n\n After implementing the fix, measure the performance again.<\/p>\n\n\n\n For example:<\/p>\n\n\n\n Before: Performance tuning is not complete until the improvement has been measured and validated.<\/p>\n\n\n\n Do not change memory parameters simply because the database is slow.<\/p>\n\n\n\n First establish whether memory is actually the bottleneck.<\/p>\n\n\n\n A session may be blocking other sessions, but killing it can cause:<\/p>\n\n\n\n Identify the blocker and understand the transaction before taking action.<\/p>\n\n\n\n Performance issues can exist at multiple layers:<\/p>\n\n\n\n The DBA should identify the affected layer instead of automatically assuming the database is responsible.<\/p>\n\n\n\n Changing SQL or adding indexes without understanding the execution plan can make performance worse.<\/p>\n\n\n\n Always investigate before making changes.<\/p>\n\n\n\n A database may look healthy over an entire day while experiencing a severe five-minute performance incident.<\/p>\n\n\n\n This is one reason ASH and targeted time-window analysis are valuable.<\/p>\n\n\n\n In an Oracle RAC environment, always consider whether the problem affects one instance or the entire cluster.<\/p>\n\n\n\n For example:<\/p>\n\n\n\n Instance 1 \u2192 Normal A problem may therefore be isolated to a particular instance, service, SQL workload, or resource.<\/p>\n\n\n\n RAC troubleshooting may require investigation of:<\/p>\n\n\n\n A RAC performance problem should not automatically be treated as a database-wide problem.<\/p>\n\n\n\n Oracle AI Database 26ai is the current long-term-support release of Oracle Database.<\/p>\n\n\n\n While 26ai is well known for its AI and vector capabilities, Oracle has also introduced improvements across database administration and performance management.<\/p>\n\n\n\n Oracle continues to enhance capabilities around workload analysis and performance monitoring.<\/p>\n\n\n\n For DBAs, this makes traditional skills such as:<\/p>\n\n\n\n still highly relevant in modern Oracle environments.<\/p>\n\n\n\n When someone says:<\/p>\n\n\n\n “Oracle Database is slow.”<\/strong><\/p>\n\n\n\n Work through this checklist.<\/p>\n\n\n\n A simple way to remember the complete process is:<\/p>\n\n\n\n Oracle performance tuning is not about memorizing hundreds of initialization parameters.<\/p>\n\n\n\n It is about knowing how to investigate a problem systematically<\/strong>.<\/p>\n\n\n\n When a production database becomes slow, do not immediately change:<\/p>\n\n\n\n Start with evidence.<\/p>\n\n\n\n Use ADDM<\/strong> to understand diagnosed performance problems.<\/p>\n\n\n\n Use AWR<\/strong> to analyze historical workload.<\/p>\n\n\n\n Use ASH<\/strong> to investigate active sessions and specific time periods.<\/p>\n\n\n\n Use Top SQL<\/strong> to identify resource-intensive SQL.<\/p>\n\n\n\n Use execution plans<\/strong> to understand how SQL is being executed.<\/p>\n\n\n\n Then make a targeted change and measure the result.<\/p>\n\n\n\n The most important rule for an Oracle DBA is simple:<\/p>\n\n\n\n Find the evidence first. Fix the root cause second.<\/strong><\/p>\n<\/blockquote>\n\n\n\n If you follow this approach consistently, you can troubleshoot many Oracle performance problems without relying on guesswork.<\/p>\n","protected":false},"excerpt":{"rendered":" Learn Oracle Database performance tuning using AWR, ASH, ADDM, Top SQL and execution plans. A practical guide to troubleshooting CPU, I\/O, locks and slow SQL.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"googlesitekit_rrm_CAowu461DA:productID":"","footnotes":""},"categories":[1225],"tags":[],"class_list":["post-5858","post","type-post","status-publish","format-standard","hentry","category-database"],"_links":{"self":[{"href":"https:\/\/w3buddy.com\/blog\/wp-json\/wp\/v2\/posts\/5858","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/w3buddy.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/w3buddy.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/w3buddy.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/w3buddy.com\/blog\/wp-json\/wp\/v2\/comments?post=5858"}],"version-history":[{"count":2,"href":"https:\/\/w3buddy.com\/blog\/wp-json\/wp\/v2\/posts\/5858\/revisions"}],"predecessor-version":[{"id":5861,"href":"https:\/\/w3buddy.com\/blog\/wp-json\/wp\/v2\/posts\/5858\/revisions\/5861"}],"wp:attachment":[{"href":"https:\/\/w3buddy.com\/blog\/wp-json\/wp\/v2\/media?parent=5858"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/w3buddy.com\/blog\/wp-json\/wp\/v2\/categories?post=5858"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/w3buddy.com\/blog\/wp-json\/wp\/v2\/tags?post=5858"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
Is it I\/O?
Is it a bad SQL query?
Is another session blocking the application?
Is there memory pressure?
Or is the problem somewhere outside the database?<\/p>\n\n\n\n
\n\n\n\nWhat Is Oracle Database Performance Tuning?<\/h2>\n\n\n\n
\n\n\n\nCommon Oracle Database Performance Problems<\/h1>\n\n\n\n
1. High CPU Usage<\/h2>\n\n\n\n
\n
\n\n\n\n2. I\/O Bottleneck<\/h2>\n\n\n\n
\n
\n\n\n\n3. Blocking and Lock Contention<\/h2>\n\n\n\n
Session A\n |\n | Holds lock\n \u2193\nTable \/ Row\n \u2191\n | Waiting\nSession B\n<\/code><\/pre>\n\n\n\n\n
\n\n\n\n4. High-Load SQL<\/h2>\n\n\n\n
\n
\n\n\n\nOracle Database Performance Troubleshooting Workflow<\/h1>\n\n\n\n
\n
Application reports slowness\n \u2193\nIdentify the exact time period\n \u2193\nCheck database health\n \u2193\nCheck CPU \/ Memory \/ I\/O\n \u2193\nReview ADDM\n \u2193\nReview AWR\n \u2193\nUse ASH for the specific time window\n \u2193\nIdentify Top SQL\n \u2193\nCheck the SQL execution plan\n \u2193\nFind the root cause\n \u2193\nApply a targeted fix\n \u2193\nValidate the result\n<\/code><\/pre>\n\n\n\n
\n\n\n\nWhat Is AWR in Oracle?<\/h1>\n\n\n\n
\n
Important licensing note<\/h3>\n\n\n\n
\n\n\n\nHow to Check AWR Snapshots<\/h1>\n\n\n\n
SELECT snap_id,\n begin_interval_time,\n end_interval_time\nFROM dba_hist_snapshot\nORDER BY snap_id DESC;\n<\/code><\/pre>\n\n\n\n@?\/rdbms\/admin\/awrrpt.sql\n<\/code><\/pre>\n\n\n\n\n
Begin Snapshot: 1000\nEnd Snapshot: 1002\n<\/code><\/pre>\n\n\n\n
\n\n\n\nHow to Read an AWR Report<\/h1>\n\n\n\n
1. Load Profile<\/h2>\n\n\n\n
\n
\n\n\n\n2. Top Foreground Events<\/h2>\n\n\n\n
Event % DB Time\n------------------------------------------------\ndb file sequential read 35%\nCPU + Wait for CPU 28%\nlog file sync 15%\nenq: TX - row lock contention 10%\nOther 12%\n<\/code><\/pre>\n\n\n\nHigh physical reads\n \u2193\nHigh I\/O waits\n \u2193\nWhy are reads high?\n \u2193\nInefficient SQL\n \u2193\nPoor execution plan\n<\/code><\/pre>\n\n\n\n
\n\n\n\nWhat Is ASH in Oracle?<\/h1>\n\n\n\n
\n
\n
\n\n\n\nWhat Should You Look for in ASH?<\/h1>\n\n\n\n
\n
Time SQL_ID Event\n-----------------------------------------\n10:32 8f3abc db file sequential read\n10:33 8f3abc db file sequential read\n10:34 8f3abc CPU\n10:35 8f3abc CPU\n<\/code><\/pre>\n\n\n\n8f3abc<\/code> and determine why it was consuming resources.<\/p>\n\n\n\n
\n\n\n\nWhat Is ADDM?<\/h1>\n\n\n\n
\n
\n\n\n\nAWR vs ASH vs ADDM<\/h1>\n\n\n\n
Tool<\/th> Main Purpose<\/th><\/tr><\/thead> AWR<\/td> Historical database performance information<\/td><\/tr> ASH<\/td> Active session activity and specific time-window analysis<\/td><\/tr> ADDM<\/td> Automated analysis of AWR data<\/td><\/tr> Top SQL<\/td> Identify SQL consuming significant resources<\/td><\/tr> Execution Plan<\/td> Understand how SQL is being executed<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\nFinding Top SQL in Oracle<\/h1>\n\n\n\n
SELECT *\nFROM (\n SELECT sql_id,\n executions,\n ROUND(elapsed_time \/ 1000000, 2) AS elapsed_seconds,\n ROUND(cpu_time \/ 1000000, 2) AS cpu_seconds,\n buffer_gets,\n disk_reads\n FROM v$sql\n ORDER BY elapsed_time DESC\n)\nWHERE ROWNUM <= 20;\n<\/code><\/pre>\n\n\n\n\n
SQL A\nExecutions: 1\nElapsed time: 30 minutes\n\nSQL B\nExecutions: 500,000\nElapsed time: 20 minutes\n<\/code><\/pre>\n\n\n\n
\n\n\n\nCheck the SQL Execution Plan<\/h1>\n\n\n\n
SELECT *\nFROM TABLE(\n DBMS_XPLAN.DISPLAY_CURSOR(\n 'YOUR_SQL_ID',\n NULL,\n 'ALLSTATS LAST'\n )\n);\n<\/code><\/pre>\n\n\n\nYOUR_SQL_ID<\/code> with the actual SQL ID.<\/p>\n\n\n\n\n
\n\n\n\nOne of the Most Important Oracle DBA Rules<\/h1>\n\n\n\n
Never tune based on a single symptom.<\/h2>\n\n\n\n
Symptom\n \u2193\nCollect evidence\n \u2193\nAnalyze the workload\n \u2193\nIdentify root cause\n \u2193\nApply targeted fix\n \u2193\nValidate\n<\/code><\/pre>\n\n\n\n
\n\n\n\nExample: Troubleshooting a Slow SQL Query<\/h1>\n\n\n\n
Step 1: Identify the Time Period<\/h2>\n\n\n\n
10:00 AM \u2013 10:20 AM
<\/p>\n\n\n\n
\n\n\n\nStep 2: Check ADDM<\/h2>\n\n\n\n
\n\n\n\nStep 3: Check AWR<\/h2>\n\n\n\n
\n
\n\n\n\nStep 4: Check ASH<\/h2>\n\n\n\n
\n\n\n\nStep 5: Check the Execution Plan<\/h2>\n\n\n\n
SELECT *\nFROM TABLE(\n DBMS_XPLAN.DISPLAY_CURSOR(\n '4m7abc123',\n NULL,\n 'ALLSTATS LAST'\n )\n);\n<\/code><\/pre>\n\n\n\n
Actual rows: 5,000,000
<\/p>\n\n\n\n\n
\n\n\n\nStep 6: Apply a Targeted Fix<\/h2>\n\n\n\n
\n\n\n\nStep 7: Validate the Result<\/h2>\n\n\n\n
Elapsed time = 20 minutes
After:
Elapsed time = 2 minutes
<\/p>\n\n\n\n
\n\n\n\nUseful Oracle Performance SQL Queries<\/h1>\n\n\n\n
1. Check Database Time Model<\/h2>\n\n\n\n
SELECT stat_name,\n ROUND(value \/ 1000000, 2) AS seconds\nFROM v$sys_time_model\nWHERE stat_name IN (\n 'DB CPU',\n 'DB time'\n);\n<\/code><\/pre>\n\n\n\n
\n\n\n\n2. Find SQL With High Elapsed Time<\/h2>\n\n\n\n
SELECT *\nFROM (\n SELECT sql_id,\n executions,\n ROUND(elapsed_time \/ 1000000, 2) AS elapsed_seconds,\n ROUND(cpu_time \/ 1000000, 2) AS cpu_seconds,\n buffer_gets,\n disk_reads\n FROM v$sql\n ORDER BY elapsed_time DESC\n)\nWHERE ROWNUM <= 20;\n<\/code><\/pre>\n\n\n\n
\n\n\n\n3. Find SQL With High CPU Usage<\/h2>\n\n\n\n
SELECT *\nFROM (\n SELECT sql_id,\n executions,\n ROUND(cpu_time \/ 1000000, 2) AS cpu_seconds,\n buffer_gets,\n disk_reads\n FROM v$sql\n ORDER BY cpu_time DESC\n)\nWHERE ROWNUM <= 20;\n<\/code><\/pre>\n\n\n\n
\n\n\n\n4. Check Active Sessions<\/h2>\n\n\n\n
SELECT sid,\n serial#,\n username,\n status,\n event,\n wait_class,\n sql_id\nFROM v$session\nWHERE status = 'ACTIVE'\nORDER BY sid;\n<\/code><\/pre>\n\n\n\n
\n\n\n\nCommon Oracle DBA Performance Tuning Mistakes<\/h1>\n\n\n\n
Mistake 1: Immediately Changing SGA or PGA<\/h2>\n\n\n\n
\n\n\n\nMistake 2: Killing Sessions Without Investigation<\/h2>\n\n\n\n
\n
\n\n\n\nMistake 3: Assuming Every Problem Is a Database Problem<\/h2>\n\n\n\n
Application\n \u2193\nSQL\n \u2193\nDatabase\n \u2193\nStorage\n \u2193\nNetwork\n<\/code><\/pre>\n\n\n\n
\n\n\n\nMistake 4: Tuning SQL Without Checking the Execution Plan<\/h2>\n\n\n\n
\n\n\n\nMistake 5: Looking Only at Averages<\/h2>\n\n\n\n
\n\n\n\nOracle RAC Performance Troubleshooting<\/h1>\n\n\n\n
Instance 2 \u2192 High CPU
Instance 3 \u2192 Normal
<\/p>\n\n\n\n\n
\n\n\n\nOracle Database 26ai and Performance Troubleshooting<\/h1>\n\n\n\n
\n
\n\n\n\nOracle DBA Performance Tuning Checklist<\/h1>\n\n\n\n
Database Health<\/h3>\n\n\n\n
\n
CPU<\/h3>\n\n\n\n
\n
Memory<\/h3>\n\n\n\n
\n
I\/O<\/h3>\n\n\n\n
\n
Sessions<\/h3>\n\n\n\n
\n
SQL<\/h3>\n\n\n\n
\n
AWR<\/h3>\n\n\n\n
\n
ASH<\/h3>\n\n\n\n
\n
ADDM<\/h3>\n\n\n\n
\n
Validation<\/h3>\n\n\n\n
\n
\n\n\n\nThe Oracle Performance Tuning Formula<\/h1>\n\n\n\n
Don't Guess\n \u2193\nCollect Data\n \u2193\nFind DB Time\n \u2193\nIdentify Waits\n \u2193\nFind Top SQL\n \u2193\nCheck Execution Plan\n \u2193\nFind Root Cause\n \u2193\nApply Targeted Fix\n \u2193\nValidate\n<\/code><\/pre>\n\n\n\n
\n\n\n\nFinal Thoughts<\/h1>\n\n\n\n
\n
\n