- \n
- The Automatic Workload Repository (AWR)<\/strong>\u00a0provides historical snapshots for system-wide trend analysis, while\u00a0the\u00a0<\/span>Active Session History (ASH)<\/strong> delivers real-time session data to diagnose immediate wait events.<\/li>\n\n\n\n
- The SQL Tuning Advisor<\/strong> automates remediation by analyzing high-load queries identified in AWR reports and recommending specific actions such as creating indexes, gathering statistics, or rewriting SQL code.<\/li>\n\n\n\n
- SQL Plan Management (SPM)<\/strong> ensures long-term stability by capturing and persisting optimal execution plan baselines, which prevents performance regression even after database restarts or upgrades.<\/li>\n\n\n\n
- Effective tuning requires a disciplined workflow that moves from identifying top timed events to manually loading verified plans into the cursor cache, provided the environment meets Enterprise Edition<\/strong> licensing requirements.<\/li>\n<\/ul>\n\n\n\n
By integrating these utilities into a routine maintenance checklist, IT teams can shift from reactive troubleshooting to proactive performance management, ensuring critical systems remain fast and predictable.<\/p>\n\n\n\n
Table of contents<\/h2>
- SUMMARY:<\/a><\/li>
- Introduction<\/a><\/li>
- Understanding the Key Components<\/a><\/li>
- Diagnosing Performance Bottlenecks with AWR and ASH<\/a>
- Automatic Workload Repository (AWR)<\/a><\/li>
- Key Metrics to Check<\/a><\/li><\/ul><\/li>
- Active Session History (ASH)<\/a>
- Ways Of Gathering ASH<\/a><\/li><\/ul><\/li>
- SQL Tuning Advisor: Automating SQL Optimization<\/a><\/li>
- Managing Execution Plans with SQL Plan Management (SPM)<\/a><\/li>
- DBA Performance Tuning Checklist<\/a><\/li>
- Conclusion<\/a><\/li><\/ul><\/div>\n\n\n\n
Introduction<\/h2>\n\n\n\n
Oracle Database 19c offers a mature, stable platform with advanced tools for optimizing performance. As a DBA, mastering these built-in utilities \u2014 AWR, ASH, and SPM \u2014 is key to keeping your systems fast and efficient. In this blog, we’ll go step-by-step from analyzing top wait events to managing SQL baselines, supported by real commands and actionable DBA insights.<\/p>\n\n\n\n
Understanding the Key Components<\/h2>\n\n\n\n
Tool<\/strong><\/td> Purpose<\/strong><\/td><\/tr> AWR (Automatic Workload Repository)<\/td> Captures performance statistics over time (snapshots).<\/td><\/tr> ASH (Active Session History)<\/td> Provides session-level performance data in real time.<\/td><\/tr> SQL Tuning Advisor (STA)<\/td> Recommends improvements for poorly performing SQLs.<\/td><\/tr> SQL Plan Management (SPM)<\/td> Ensures plan stability using baselines.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Diagnosing Performance Bottlenecks with AWR and ASH<\/h2>\n\n\n\n
Tip: <\/strong>Use AWR for system-wide analysis and ASH for real-time, session-level insights.<\/p>\n\n\n\n
Automatic Workload Repository (AWR)<\/h3>\n\n\n\n
AWR captures snapshots of database activity at regular intervals, giving insight into CPU usage, I\/O waits, and SQL performance over time. It’s ideal for historical analysis and identifying system-wide issues.<\/p>\n\n\n\n
Example: Identifying Top Wait Events with AWR<\/em><\/strong><\/p>\n\n\n\n
If your database slows during peak hours, generate an AWR report to pinpoint the cause.<\/p>\n\n\n\n
sqlplus \/ as sysdba\n@$ORACLE_HOME\/rdbms\/admin\/awrrpt.sql<\/code><\/pre>\n\n\n\nYou’ll be prompted to:<\/p>\n\n\n\n
- \n
- Choose report type (HTML or TEXT)<\/li>\n\n\n\n
- Specify snapshot range<\/li>\n\n\n\n
- Enter a report name<\/li>\n<\/ul>\n\n\n\n
Key Metrics to Check<\/h3>\n\n\n\n
Top 5 Timed Events<\/strong><\/p>\n\n\n\n
In Oracle Database Administration, the Top 5 Timed Events are the most significant wait events that consume database time, as reported by the Automatic Workload Repository (AWR). These events highlight where the database spends most of its time, helping DBAs identify performance bottlenecks.<\/p>\n\n\n\n
![\"Performance](\"https:\/\/virtual-dba.com\/wp-content\/uploads\/Performance-Tuning-in-Oracle-19c-From-AWR-to-SQL-Plan-Management-Top-5-Timed-Events.png\")
<\/figure>\n\n\n\nSQL Ordered by Elapsed Time<\/strong><\/p>\n\n\n\n
SQL Ordered by Elapsed Time is a key section in the Automatic Workload Repository (AWR) report or similar performance tools (e.g., Statspack). It lists SQL statements consuming the most elapsed time during execution, helping DBAs identify resource-intensive queries that may cause performance bottlenecks.<\/p>\n\n\n\n
Instance Efficiency<\/strong><\/p>\n\n\n\n
Instance Efficiency is a section in the Automatic Workload Repository (AWR) report that provides key performance metrics indicating how efficiently the database instance uses its resources. These metrics help DBAs assess the database’s health and identify areas for optimization.<\/p>\n\n\n\n
Instance Efficiency metrics are a snapshot of how well an Oracle database utilizes its resources. High ratios indicate an efficient system, while low ratios signal areas for improvement, such as memory configuration or query optimization. Regularly reviewing these metrics alongside other AWR sections (e.g., Top 5 Timed Events, SQL Ordered by Elapsed Time) ensures a proactive approach to maintaining optimal database performance.<\/p>\n\n\n\n
![\"Performance](\"https:\/\/virtual-dba.com\/wp-content\/uploads\/Performance-Tuning-in-Oracle-19c-From-AWR-to-SQL-Plan-Management-Instant-Efficiency-Metrics.png\")
<\/figure>\n\n\n\nIO Stats<\/strong><\/p>\n\n\n\n
In Oracle Database Administration, I\/O Stats (Input\/Output Statistics) in the Automatic Workload Repository (AWR) report provide insights into the database’s disk I\/O performance. These statistics help DBAs identify I\/O bottlenecks, optimize storage configurations, and improve overall database performance. By analyzing these metrics, DBAs can optimize query performance, balance I\/O workloads, and ensure efficient storage usage. Combine I\/O Stats analysis with other AWR sections.<\/p>\n\n\n\n
![\"Performance](\"https:\/\/virtual-dba.com\/wp-content\/uploads\/Performance-Tuning-in-Oracle-19c-From-AWR-to-SQL-Plan-Management-Tablespace-IO-Stats.png\")
<\/figure>\n\n\n\nActive Session History (ASH)<\/h2>\n\n\n\n
Using the Active Session History, you can examine and perform a detailed analysis on the current data in the
V$ACTIVE_SESSION_HISTORY<\/code> and the past data in theDBA_HIST_ACTIVE_SESS_HISTORY<\/code> view. The ASH report is smaller than the AWR report and will provide db\/instance details for a short period of time. An ASH report covers a much shorter period of time (e.g., 5 min) than an AWR report (e.g., 30 min or 1 hour).<\/p>\n\n\n\nMajor ASH report sections are:<\/strong><\/p>\n\n\n\n
- \n
- Top User Events<\/li>\n\n\n\n
- Top Background Events<\/li>\n\n\n\n
- Top Cluster Events<\/li>\n\n\n\n
- Top SQL with Top Events<\/li>\n<\/ul>\n\n\n\n
Ways Of Gathering ASH<\/h3>\n\n\n\n
Note:<\/strong> For RAC environments, collect ASH data from all instances simultaneously for better correlation.<\/p>\n\n\n\n
Using ORADEBUG<\/strong><\/p>\n\n\n\n
ASHDUMP needs to be collected DURING the time of the issue<\/p>\n\n\n\n
In case of collecting from RAC, Gather ASH Dumps from ALL database instances at approximately the same time.<\/p>\n\n\n\n
SQL> oradebug setmypid;\nSQL> oradebug unlimit;\nSQL> oradebug dump ashdump 5;\nSQL> oradebug tracefile_name;<\/code><\/pre>\n\n\n\nUsing ashrpt.sql or Enterprise Manager<\/strong><\/strong><\/p>\n\n\n\n
SQL> @?\/rdbms\/admin\/ashrpt\n\tEnter value for report_type: HTML or TEXT [ HTML is default ]\n\tEnter value for begin_time: \n\t\tDefaults to -15 mins\n\t\tTo specify absolute begin time: [MM\/DD[\/YY]] HH24:MI[:SS]\n\t\tTo specify relative begin time: (start with '-' sign) -[HH24:]MI\n\tEnter value for duration: Default is till current time\n\tEnter value for report_name:<\/code><\/pre>\n\n\n\nUsing v$active_session_history<\/strong><\/p>\n\n\n\n
SELECT event, COUNT(*) AS wait_count\nFROM v$active_session_history\nWHERE sample_time > SYSDATE - (5\/1440)\nGROUP BY event\nORDER BY wait_count DESC;<\/code><\/pre>\n\n\n\nIdentify Top SQL IDs by Waits<\/strong><\/p>\n\n\n\n
SELECT sql_id, event, COUNT(*) AS samples\nFROM v$active_session_history\nWHERE session_state = 'WAITING'\nGROUP BY sql_id, event\nORDER BY samples DESC FETCH FIRST 10 ROWS ONLY;<\/code><\/pre>\n\n\n\nTip:<\/strong> Combine ASH data with AWR for both macro<\/strong> (system-wide) and micro<\/strong> (session-level) tuning insights.<\/p>\n\n\n\n
SQL Tuning Advisor: Automating SQL Optimization<\/h2>\n\n\n\n
Once you’ve identified a problematic SQL ID from AWR or ASH, use the SQL Tuning Advisor to generate actionable recommendations.<\/p>\n\n\n\n
DECLARE\n tname VARCHAR2(30);\n tid NUMBER;\nBEGIN\n tname := DBMS_SQLTUNE.CREATE_TUNING_TASK(\n sql_id => 'b9p45hkcx0pwh',\n scope => 'COMPREHENSIVE',\n time_limit => 60,\n task_name => 'sql_tune_task1');\n DBMS_SQLTUNE.EXECUTE_TUNING_TASK(task_name => 'sql_tune_task1');\nEND;\n\/<\/code><\/pre>\n\n\n\nTip: <\/strong>The SQL Tuning Advisor may suggest index creation, SQL rewriting, or gathering optimizer statistics.<\/p>\n\n\n\n
Check the status:<\/strong><\/p>\n\n\n\n
SELECT task_name, STATUS FROM dba_advisor_log WHERE task_name LIKE 'sql_tune_task1';<\/code><\/pre>\n\n\n\nExecute Tuning task:<\/strong><\/p>\n\n\n\n
EXEC DBMS_SQLTUNE.execute_tuning_task(task_name => 'sql_tune_task1');<\/code><\/pre>\n\n\n\nGet the Tuning Advisor report:<\/strong><\/p>\n\n\n\n
set long 65536\nset longchunksize 65536\nset linesize 100\nSELECT DBMS_SQLTUNE.REPORT_TUNING_TASK('sql_tune_task1') FROM dual;<\/code><\/pre>\n\n\n\nInterpreting SQL Tuning Advisor Output:<\/strong><\/p>\n\n\n\n
The output typically includes:<\/p>\n\n\n\n
Recommendation<\/th> Description<\/th> Action<\/th><\/tr><\/thead> Statistics<\/td> Suggests gathering optimizer statistics for stale or missing objects.<\/td> Use DBMS_STATS.GATHER_TABLE_STATS.<\/td><\/tr> Indexing<\/td> Recommends new indexes that can reduce I\/O.<\/td> Create only after cost-benefit analysis.<\/td><\/tr> SQL Profile<\/td> Proposes creating a SQL Profile to improve optimizer estimates.<\/td> Accept using DBMS_SQLTUNE.ACCEPT_SQL_PROFILE.<\/td><\/tr> Rewriting<\/td> Suggests modifying SQL text for better performance.<\/td> Apply manually in code.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Tip:<\/strong> Always validate SQL Profile or Index recommendations in a test environment before implementing in production.<\/p>\n\n\n\n
Managing Execution Plans with SQL Plan Management (SPM)<\/h2>\n\n\n\n
How SQL Plan Baselines Work:<\/strong><\/p>\n\n\n\n
When a SQL statement is executed, the optimizer generates an execution plan. If a plan is captured as a baseline, subsequent executions of that statement will try to use the same plan. If a new, better plan is found, it can be evolved into the baseline.<\/p>\n\n\n\n
SQL Plan Management (SPM) Persistence<\/strong>:<\/p>\n\n\n\n
SQL Plan Baselines are persistent across database restarts. Once captured, they remain stored in the data dictionary under SYS.SYS_SQL_PLAN_BASELINES, ensuring the same plan is used consistently even after shutdowns or instance failures.<\/p>\n\n\n\n
Enable Automatic SQL Plan Capture:<\/strong><\/p>\n\n\n\n
ALTER SYSTEM SET \"optimizer_capture_sql_plan_baselines\" = TRUE SCOPE=BOTH;<\/code><\/pre>\n\n\n\nThis automatically captures frequently executing and resource-intensive SQL plans.<\/p>\n\n\n\n
Manually Load a Good Plan:<\/strong><\/p>\n\n\n\n
DECLARE\n plans_loaded PLS_INTEGER;\nBEGIN\n plans_loaded := DBMS_SPM.load_plans_from_cursor_cache(\n sql_id => 'b9p45hkcx0pwh',\n plan_hash_value => 1234567890,\n fixed => 'YES',\n enabled => 'YES');\nEND;\n\/<\/code><\/pre>\n\n\n\nNote:<\/strong> Manually loading a good plan is helpful when you’ve verified a stable execution plan and want to make it permanent.<\/p>\n\n\n\n
DBA Performance Tuning Checklist<\/h2>\n\n\n\n
- SQL Tuning Advisor: Automating SQL Optimization<\/a><\/li>
- Key Metrics to Check<\/a><\/li><\/ul><\/li>
- Introduction<\/a><\/li>
- The SQL Tuning Advisor<\/strong> automates remediation by analyzing high-load queries identified in AWR reports and recommending specific actions such as creating indexes, gathering statistics, or rewriting SQL code.<\/li>\n\n\n\n