SQL Gone Wild: Taming Bad SQL the Easy Way (or the Hard Way) Sergey Koltakov Product Manager, Database Manageability

Oracle Enterprise Manager Top-Down, Integrated Application Management Complete, Open, Integrated Management for Oracle Technologies Deep, Optimized, Best of Breed Database, Middleware, Packaged Applications, Physical and Virtual Infrastructure Business Centric, Top Down Application Management Complete Lifecycle Management Scalable Grid and Cloud Management Manage many as one

Complete, Open and Integrated Management Event Connectors Microsoft, HP, IBM Service Desk Connectors Remedy, HP, Siebel, PeopleSoft Plug-Ins Complete, Best of Breed Management for Oracle Rich Set of Plug-Ins to Monitor Non-Oracle Products Bi-Directional Connectors to Exchange Alerts, Events

Agenda What makes SQL go bad? What should you do about these problems? Identifying Fixing Preventing

What makes SQL go bad? Root Causes of Poor SQL Performance 1. Optimizer statistics issues a. Stale/Missing statistics b. Incomplete statistics c. Improper optimizer configuration d. Upgraded database: new optimizer e. Changing statistics f. Rapidly changing data 2. Missing access structures 3. Poorly written SQL statements 4. Cursor sharing issues a. Bind-sensitive SQL with bind peeking b. Literal usage 5. Resource and contention issues a. Hardware resource crunch b. Contention (row lock contention, block update contention) 6. Parallelism issues a. Not parallelized (no scaling to large data) b. Improperly parallelized (partially parallelized, skews)

Oracle Optimizer Statistics Inaccurate statistics Suboptimal Plans Optimizer Statistics Table Statistics CBO Column Statistics Index Statistics System Statistics

What makes SQL go bad? Missing Access Structures Indexes: B-tree indexes, B-tree cluster indexes, Hash cluster indexes, Global and local indexes, Reverse key indexes, Bitmap indexes, Function-based indexes, Domain indexes Materialized Views: Primary Key materialized views, Object materialized views ROWID materialized views Complex materialized views Partitioned Tables: Range partitioning, Hash partitioning, List partitioning, Composite partitioning, Interval Partitioning, REF partitioning, Virtual Column Based partitioning B-tree index

What makes SQL go bad? Poorly Written SQL Statements SELECT * FROM employees WHERE to_char(salary) = :sal SELECT * FROM employees WHERE salary = TO_NUMBER(:sal) Convert literal once and not the whole column, index range scan vs. full table scan SELECT * FROM parts_old UNION SELECT * FROM parts_new SELECT * FROM parts_old UNION ALL SELECT * FROM parts_new If you know there are no rows in common

What makes SQL go bad? a. Literal Usage Issue SELECT * FROM jobs WHERE min_salary > 12000; SELECT * FROM jobs WHERE min_salary > 15000; SELECT * FROM jobs WHERE min_salary > 10000; SELECT * FROM SELECT * FROM SELECT * FROM cursor_sharing ={exact, force, similar} Sharing Cursors is good! Library Cache

What makes SQL go bad? b. Bind Peeking Issue Processed_Flag Y Y Y Y CBO 10g FTS Full Table Scan 99 Two different optimal plans for different bind values Index Range Scan 1 N Problem: Binds will affect optimality in any subsequent uses of the stored plan IRS

What makes SQL go bad? Resource and Contention Issues Hardware Resource Contention CPU Memory I/O Network Logical Contention Row lock contention Block update contention

What makes SQL go bad? Root Causes of Poor SQL Performance 1. Optimizer statistics issues a. Stale/Missing statistics b. Incomplete statistics c. Improper optimizer configuration d. Upgraded database: new optimizer e. Changing statistics f. Rapidly changing data 2. Missing access structures 3. Poorly written SQL statements 4. Cursor sharing issues a. Bind-sensitive SQL with bind peeking b. Literal usage 5. Resource and contention Issues a. Hardware resource crunch b. Contention (row lock contention, block update contention) 6. Parallelism issues a. Not parallelized (no scaling to large data) b. Improperly parallelized (partially parallelized, skews)

What makes SQL go bad? Parallelism Issues Not parallelized (no scaling to large data) Improperly parallelized (partially parallelized, skews) CTAS Large Table Select Insert Serial Table Scan Parallel Servers Serial Insert

Agenda What makes SQL go bad? How should you go about solving these problems? Identifying: Top Activity ADDM SQL Monitoring

Identify High Load SQL Using Top Activity Performance Page Top Activity Identify Top SQL by DB Time: CPU I/O Non-idle waits Different Levels of Analysis Historical analysis AWR data Performance Page Real-time analysis ASH data More granular analysis Enables identification of transient problem SQL Top Activity Page

Identifying Problems with Top SQL Page Problems Stale/Missing statistics Overly general statistics Improper optimizer configuration Upgraded database: new optimizer Changing statistics Changing data (plans do not scale with data) Not parallelized (no scaling to large data) Improperly parallelized (partially parallel, skews) Missing access structures Poorly written SQL statements Hardware resource crunch Symptom High Load SQL Contention (row lock contention) Bind-sensitive SQL with bind peeking Literal usage

Identify performance problems using ADDM Automatic Database Diagnostic Monitor 11g Provides database and cluster-wide performance diagnostic Throughput centric - Focus on reducing time DB time Identifies top SQL: Shows SQL impact Frequency of occurrence Pinpoints root cause: SQL stmts waiting for Row Lock waits SQL stmts not shared

Identifying and Solving Problems With ADDM Problems Stale/Missing statistics Incomplete statistics Improper optimizer configuration Upgraded database: new optimizer Changing statistics Rapidly Changing data Not parallelized (no scaling to large data) Improperly parallelized (skews, RAC, etc) Missing access structures Poorly written SQL statements Hardware resource crunch Contention (row lock contention) Bind-sensitive SQL with bind peeking Symptoms & Solutions ADDM (Add CPU recommendation) ADDM (Blocking Sessions recommendation) ADDM (Cursor Sharing recommendation) Literal usage

Real-time SQL Monitoring Problem: Managing High Response-Time SQLs Shows what is happening inside SQL execution Automatically monitors long running SQL > 5 secs of CPU or I/O All parallel statements Enabled out-of-the-box with no performance impact Monitors each SQL execution Exposes monitoring statistics Global execution level Plan operation level Parallel Execution level Guides tuning efforts

SQL Monitoring Use Cases Big Plans

SQL Monitoring Use Cases Expensive Hash Join

SQL Monitoring Use Cases Poor Indexing

SQL Monitoring Use Cases FORCE PARALLEL QUERY PARALLEL 4

SQL Monitoring Enhancements in Oracle Database 11gR2 New save Active Reports for later analysis track PL/SQL cursors track recursive SQL statements executed by the monitored statement SQL monitoring information persists after the SQL cursor is aged out track specific Exadata statistics: cell offload efficiency interconnect bytes exchanged capture error code and error message, if SQL statement fails track when and how long parallel SQL is queued capture binds values used by the monitored SQL execution track detailed session information: user, module, actions, service name, client id and info

Identifying Problems With SQL Monitoring Problems Stale/Missing statistics Incomplete statistics Improper optimizer configuration Upgraded database: new optimizer Changing statistics Rapidly changing data Not parallelized (no scaling to large data) Improperly parallelized(partially parallel,skews) Missing access structures Poorly written SQL statements Hardware resource crunch Contention (row lock contention) Bind-sensitive SQL with bind peeking Literal usage Symptoms Serial Long Running SQL Parallel Skews Wrong Cardinalities, Poor Index Selectivity I/O, CPU, Memory, Network Waits TX enqueue waits, Row Lock Contention Significantly Different Runtimes with Different Binds

Agenda What makes SQL go bad? What should you do about these problems? Identifying: Top Activity ADDM SQL Monitoring Fixing: SQL Tuning Advisor + Automatic SQL Tuning SQL Access Advisor Optimizer Statistics

SQL Tuning Advisor Categories of Recommendations Automatic Tuning Optimizer Statistics Analysis SQL Profiling Access Path Analysis SQL Tuning Advisor SQL Tuning Recommendations Gather Missing or Stale Statistics Create a SQL Profile Add Missing Access Structures SQL Restructure Analysis Modify SQL Constructs DBA 11gR2 Alternative Plan Analysis Adopt Alternative Execution Plan 11gR2 11gR2 Parallel Execution Analysis Use Parallel Execution for SQL 11gR2

SQL Tuning Advisor Two New Categories of Recommendations 11gR2 Parallel Execution Analysis Alternative Plan Analysis

Automatic SQL Tuning Further automation of SQL Tuning Advisor Nightly Automatic implement Packaged Apps Custom Apps SQL Tuning Advisor SQL Profiles Well-tuned SQL Auto Capture High-Load SQL SQL Analysis Report Manually implement Automatically captures high-load SQL Automatically tunes SQL without changing application by creating SQL Profiles Automatically validates SQL Profiles by test executing them Automatically implements (optional) greatly improved SQL plans Automatically reports analysis Automatically runs during maintenance window

Fixing Problems With SQL Tuning Advisor Problems Stale/Missing statistics Incomplete statistics Improper optimizer configuration Upgraded database: new optimizer Changing statistics Rapidly changing data Not parallelized (no scaling to large data) Improperly parallelized(partially parallel,skews) Missing access structures Poorly written SQL statements Hardware resource crunch Contention (row lock contention) Solutions Stats recommendation Profile recommendation Profile recommendation Profile recommendation using O_F_E Profile recommendation Profile recommendation PQ recommendation Index recommendation partially Restructure recommendation Bind-sensitive SQL with bind peeking Literal usage

SQL Access Advisor: Partition Advisor Indexes Representative Workload SQL Access Advisor Materialized views Automatic Tuning Optimizer Access Path Analysis Materialized views logs Partitioned objects 11g

Fixing Problems With SQL Access Advisor Problems Stale/Missing statistics Incomplete statistics Improper optimizer configuration Upgraded database: new optimizer Changing statistics Rapidly changing data Not parallelized (no scaling to large data) Improperly parallelized (partially parallel,skews) Missing access structures Poorly written SQL statements Hardware resource crunch Solution SQL Access Advisor Contention (row lock contention) Bind-sensitive SQL with bind peeking Literal usage

Oracle Optimizer Statistics Preventing SQL Regressions Automatic Statistics Collection Job (stale or missing) Out-of-the box, runs in maintenance window Configuration can be changed (at table level) Gathers statistics on user and dictionary objects Uses new collection algorithm with accuracy of compute and speed faster than sampling of 10% Incrementally maintains statistics for partitioned tables very efficient Set DBMS_STATS.SET_GLOBAL_PREFS Nightly

Oracle Optimizer Statistics Preventing SQL Regressions: Tips Gather statistics for all objects User Objects Non-volatile Volatile Gathers statistics when object at MAX size and then lock table Delete all statistics and lock table dynamic sampling will be used Dictionary Tables Fixed Tables Restoring old optimizer statistics Used when new stats result in poor execution plan selection Scope: table, schema and database History maintained for 30 days API: DBMS_STATS.RESTORE_TABLE_STATS Best Practice: Use DBMS_STATS instead of the ANALYZE command Officially obsolete for optimizer statistics

Oracle Optimizer Statistics Preventing SQL Regressions Extended Statistics Extended Optimizer Statistics provides a mechanism to collect statistics on a group of related columns: Function-Based Statistics Multi-Column Statistics Full integration into existing statistics framework Automatically maintained with column statistics DBMS_STATS.CREATE_EXTENDED_STATS Pending Statistics Allows validation of statistics before publishing Disabled by default To enable, set table/schema PUBLISH setting to FALSE DBMS_STATS.SET_TABLE_PREFS('SH','CUSTOMERS','PUBLISH','false') To use for validation ALTER SESSION SET optimizer_pending_statistics = TRUE; Publish after successful verification

Fixing Problems With Good Statistics Problems Stale/Missing statistics Incomplete statistics Improper optimizer configuration Upgraded database: new optimizer Changing statistics Rapidly changing data Solution Good Optimizer Statistics Not parallelized (no scaling to large data) Improperly parallelized(partially parallel,skews) Missing access structures Poorly written SQL statements Hardware resource crunch Contention (row lock contention) Bind-sensitive SQL with bind peeking Literal usage

Fixing problems with Adaptive Cursor Sharing Adaptive Cursor Sharing compromise between cursor sharing & optimization SELECT * FROM emp WHERE wage := wage_value Selectivity Ranges: 1 20 25 2 3 22 24 Same Plan Different Plan 4 30 35 34 43 Same Plan, Expand Interval

Fixing Problems With Adaptive Cursor Sharing Problems Stale/Missing statistics Overly general statistics Improper optimizer configuration Upgraded database: new optimizer Changing statistics Changing data (plans do not scale with data) Not parallelized (no scaling to large data) Solution Adaptive Cursor Sharing Improperly parallelized (partially parallel,skews) Missing access structures Poorly written SQL statements Hardware resource crunch Contention (row lock contention) Bind-sensitive SQL with bind peeking Literal usage

Preventing problems with SQL Plan Management Problem: changes in the environment cause plans to change Parse GB NL Plan baseline is established NL SQL statement is parsed again and a different plan is generated New plan is not executed but marked for verification GB NL Statement log Plan history Plan baseline NL GB HJ HJ

SQL Performance Analyzer (SPA) Validate statistics refresh with SPA Steps: 1. Capture SQL workload in STS using automatic cursor cache capture capability 2. Execute SPA pre-change trial 3. Refresh statistics using PENDING option 4. Execute SPA post-change trial 5. Run SPA report comparing SQL execution statistics Before PUBLISHing stats: Remediate individual few SQL for plan regressions: SPM, STA Revert to old statistics if too many regressions observed Validating SQL Workload upgrade with SPA SQL plans + stats SQL plans + stats Pre-change Trial Post-change Trial Compare SQL Performance Analysis Report

Preventing Problems With SPA and SPM Problems Stale/Missing statistics Overly general statistics Improper optimizer configuration Upgraded database: new optimizer Changing statistics Changing data (plans do not scale with data) Not parallelized (no scaling to large data) Improperly parallelized(partially parallel,skews) Missing access structures Poorly written SQL statements Hardware resource crunch Contention (row lock contention) Preventive Solutions SPA + SQL Tune/SPM (on regressed plans) SPM (evolve old plans), SPA (test statistics) Bind-sensitive SQL with bind peeking Literal usage

Conclusion Identify, Resolve, Prevent Prevent SPA SPM Resolve ADDM, Top Activity, SQL Monitoring Identify Top Activity, ADDM, SQL Monitoring Tuning Advisor, Access Advisor, Auto Stat Collection

Oracle Helps You Maximize Customer Value Deploys SOA infrastructure 92% faster Saves 80% time and effort for managing Databases Avoids online revenue losses up to 25% Improves IT productivity by 25% Drives asset utilization up by 70% Cuts configuration management effort by 90% Saves $1.9 million with Oracle Enterprise Manager Saves $170,000 per year with Oracle Enterprise Manager Replaces manual tools with automation; saves time by 50% Reduces Database testing time by 90% Reduces provisioning effort by 75% Saves weeks on application testing time Cuts application testing from weeks to hours Reduces critical patching time by 80% Delivers 24/7 uptime with Oracle Enterprise Manager

The preceding is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle s products remains at the sole discretion of Oracle.

For More Information search.oracle.com or oracle.com