SQL Performance Analyzer: Eliminating the Guesswork from SQL Performance Prabhaker Gongloor (GP) Khaled Yagoub Pete Belknap Database Manageability

Transcription

1

2 SQL Performance Analyzer: Eliminating the Guesswork from SQL Performance Prabhaker Gongloor (GP) Khaled Yagoub Pete Belknap Database Manageability Group Oracle Corporation

3 Outline Motivation SQL Performance Analyzer (SPA) Overview SPA for Pre-11g Database Releases Usage Scenarios Upgrade testing: 9i R2, 10g R1, 10g R2 10g R2 OR 11g Any change that impacts SQL performance Real-world Deployments Conclusion New! Please visit us at the OOW Demogrounds Booth Moscone West: L52/L51 : Database Replay/SPA

4 Why SQL Performance Analyzer (SPA)? Businesses want systems that are performant and meet SLA s SQL performance regressions are #1 cause of poor system performance Solution for proactively detecting all SQL regressions resulting from changes not available DBA s use ineffective and time-consuming manual scripts to identify problems SPA identifies all changes in SQL performance before impacting users

5 Real Application Testing Real Application Testing = SPA + Database Replay SPA + Database Replay are complementary Together, provide comprehensive & flexible testing solution SQL Performance Analyzer Predicts impact of of change on on SQL response time Assess change by by executing query part of of SQL in in isolation without concurrency Unit testing of of SQL, e.g., optimizer stats/config, drop index, etc. Can use for for upgrades from 9.2/ or or 11g or or 11g Database Replay Predicts impact of of change on workload throughput Assess change by replaying workload with concurrency Comprehensive testing of of DB stack, e.g, memory, RAC, concurrency related Can use for upgrades from 9.2 or g

6 SQL Performance Analyzer (SPA)

7 SPA : Common Usage Scenarios Database upgrades and patch-set releases 9.2/ or 11.1 releases x y or 11.1 releases Database parameter changes Schema changes Optimizer statistics refresh Implementation of tuning recommendations I/O subsystem changes SPA can be used for any change that affects SQL execution plan and performance

8 SQL Performance Analyzer: Overview Helps users predict the impact of system changes on SQL workload response time Builds different trials (experiment) of SQL workload performance (i.e., SQL execution plans and statistics) Analyzes performance differences Offers fine-grained performance analysis on individual SQL SQL plans + stats Pre-change Trial Compare SQL Performance SQL Workload SQL plans + stats Post-change Trial Integrated with SQL tuning set, SQL plan baselines, and SQL tuning advisor to form an End-toend solution Analysis Report

9 SQL Performance Analyzer Generic Workflow Production Database Test Database SQL Tuning Set Fetch Next SQL Test Execute Cursor Cache Ftp Export/Import Execution Plan & Statistics Incremental Capture* Before Change Trial After Change Trial SQL Tuning Set Compare SQL Performance *Negligible Overhead, < 1-2%

10 SPA Report

11 SPA Report Regressed SQL Statements

12 SPA Enterprise Manager Interface Rich GUI through Enterprise Manager DBMS_SQLPA package PL/SQL API

13 SPA Usage Scenarios

14 Database Upgrade: 9.2/10.1* 10.2 Scenario 1: I have heard premier DB support for 9.2 has ended, I want to upgrade 10.2 database release. How can I use 11g SPA functionality to accomplish the upgrade? Goal: Assess impact of upgrade on SQL workload performance on a test system using SPA so that there are no surprises after upgrade. * For 10.1, the solution is similar to 9.2

15 Scenario 1: Database Upgrade: 9.2/ System Setup Production Database Test Database Upgrade Prod DB (9.2/10.1) Test DB (10.2) No patches needed Clone of Production 10.2 system + Test Exec patch installed 11g SPA System 11g Test System: No application schema/data, stores SPA results or patch Metalink Note:

16 Scenario 1: Database Upgrade: 9.2/ SPA Enhancements Production Database Test Database Upgrade Prod DB (9.2/10.1) Test DB (10.2) 1. Consume 9i SQL Trace files and generate STS 2. Remote Test Execute Workload over DB Link 11g SPA System

17 Scenario 1: Database Upgrade: 9.2/ Production Database Test Database Prod DB (9.2/10.1) Upgrade Test DB (10.2) 1. Capture SQL workload using SQL*Trace Move trace file to 11g SPA system Send SQL for Remote Execution 11g SPA System Collect execution stats 2. Generate STS from trace file 3. Generate Pre-Change Trial 4. Send SQL to 10.2 DB to execute 5. Compare performance and generate SPA report

18 Scenario 1: Database Upgrade: 9.2/ Production Database Test Database Prod DB (9.2/10.1) Upgrade Test DB (10.2) 1. Capture SQL workload using SQL*Trace Send SQL for Remote Execution Collect execution stats Move trace file to 11g SPA system 11g SPA System 2. Generate STS from trace file 3. Send SQL to 10.2 DB to execute 4. Compare performance and generate SPA report

19 Scenario 1: Database Upgrade: 9.2/ Step 1: Capture SQL workload using SQL Trace Identify all interesting workloads such as month-end, daily peak, etc. Capture SQL trace for the workload, few sessions at a time Use dbms_support/dbms_monitor package, these support bind value capture tracing other running sessions SQL trace considerations time_statistics=true: Important for performance data user_dump_dest max_dump_file_size trace_file_identifier Performance overhead: 10-15% for traced sessions

20 Scenario 1: Database Upgrade: 9.2/ Step 1: Capture SQL workload using SQL Trace (contd.) SQL Trace files only have object identifiers Create mapping table to map object identifiers in trace files to schema names Id Owner Name 123 SCOTT EMP 124 SCOTT DEPT SQL trace files * SQL in Note pages/otn

21 Scenario 1: Database Upgrade: 9.2/ Step 2: Transport Workload and Create STS Production Database 11g SPA System Id SQL trace files Owner Name SCOTT EMP SCOTT DEPT Ftp Export/Import SQL trace files Id Owner Name 123 SCOTT EMP 124 SCOTT DEPT Mapping Table Mapping Table SQL Tuning Set Transport SQL trace files, mapping table using ftp/expdp/impdp.., etc. Create STS from trace files using dbms_sqltune API (SQL in Notes page/otn) Specify directory object containing trace files, mapping table, STS name as input

22 Scenario 1: Database Upgrade: 9.2/ Step 3a: Create SPA Task Create SPA task on 11g SPA System

23 Scenario 1: Database Upgrade: 9.2/ Step 3a: Create SPA Task

24 Scenario 1: Database Upgrade: 9.2/ Step 3b: Establish Before Change Trial Trial Creation Method: Select Build From SQL Tuning Set option to use plans and statistics from 9i

25 Scenario 1: Database Upgrade: 9.2/ Step 4: Establish After Change Trial

26 Scenario 1: Database Upgrade: 9.2/ Production Database Test Database Prod DB (9.2/10.1) Upgrade Test DB (10.2) 1. Capture SQL workload using SQL*Trace Send SQL for Remote Execution Collect execution stats Move trace file to 11g SPA system 11g SPA System 2. Generate STS from trace file 3. Send SQL to 10.2 DB to execute 4. Compare performance and generate SPA report

27 Scenario 1: Database Upgrade: 9.2/ Step 5: Compare and Generate Report Compare Pre-Change and After-Change Trials based on a performance metric Oracle recommends using CPU_TIME and BUFFER_GETS metrics Use multiple metrics that provide repeatable and comprehensive statistics

28 Fixing Regressed SQL Systematic problems Check un-analyzed tables, PGA memory, statistics collection, system statistics Refer Upgrading from Oracle 9i to 10g: What to expect from the Optimizer on OTN For statements suffering from isolated problems use one of the following fixes SQL Profiles: Implement Profiles recommended by SQL Tuning Advisor (STA) Stored Outlines**: If no profile was recommended by STA, then capture Stored Outlines in 9i for the targeted SQL statements. Import stored outline into 10g.

29 Database Upgrade: x y Scenario 2: One of the database I m managing is on How can I use 11g SPA functionality to accomplish an patchset upgrade? Goal: Assess impact of upgrade on SQL workload performance using SPA so that there are no surprises after upgrade.

30 Scenario 2: Database Upgrade: x y System Setup Production Database Test Database Prod DB ( x) No patches needed Upgrade Test DB ( y) Test DB ( x) Upgrade x: Clone of Prod 10.2 systems + Test Exec patch installed 11g Test System: No application schema/data, stores SPA results 11g SPA System or patch Metalink Note:

31 Scenario 1: Database Upgrade: x y Workflow Production Database Test Database Prod DB ( x) Upgrade Test DB ( y) Upgrade Test DB ( x) 1. Capture SQL workload to STS using Increment Cursor Cache Capture Move STS dmp file to 11g SPA system Send SQL for Remote Execution 11g SPA System 2. Import STS Collect execution stats 3. Send SQL for test execution on 10.2 before and after upgrade 4. Compare performance and generate SPA report

32 Scenario 3: Using SPA Functionality for 9i/10g 11g Upgrades Similar workflow as Scenario 2 Use 11g SPA system and test execute on 10g/11g source and destination target databases Stores results of experiments separately Allows use of latest releases for 11g SPA system

33 Schema Changes Scenario 4: A few months after upgrade, the database engineering team wants to add few indexes on the production system. They want my input on how it will impact the database and application Goal: Assess impact of schema changes on SQL workload on test system performance & make sure are no negative effects of the change

34 Schema Changes

35 Schema Changes Change Accepted 1

36 Evaluating Optimizer Statistics Refresh Scenario 5: Can I use SPA to check if any SQL statements regressed due to optimizer statistics refresh on my 10.2 production databases. If so, how can I evaluate the refreshed optimizer statistics? Goal: Assess impact of optimizer statistics gathering on SQL workload performance on production system & make sure are no negative effects of the change

37 Evaluating Optimizer Statistics Refresh Assumptions Optimizer has already gathered statistics on the database Statistics refreshed periodically No prod copy is available on test Use 11g SPA system to evaluate optimizer statistics on 10.2 production database Remote test execute before/after statistics refresh Analyze SPA report and take appropriate action Overall improvement but few SQL regressions Solution: Use SQL Profiles for regressed SQL No improvement and many regressions Solution: Revert to old statistics: Use optimizer statistics retention/history feature For Oracle Database 11g, use publish pending statistics feature to publish statistics after evaluation of statistics

38 Evaluating Optimizer Statistics Refresh for 10.2 Production Database Prod DB (10.2) 11g SPA System Opt Statistics Refresh Prod DB (10.2) 1. Capture SQL workload to STS 2. Import STS 3. Use SPA to detect plan changes 4. Compare performance and generate SPA report 5. Retain new statistics or revert to old statistics or use SQL Profiles for regression tuning

39 SPA Real-World Case Studies

40 Case Study 1: Large Hotel Chain Challenge Upgrade critical customer-facing application providing rates for room reservations from Oracle Database to 11.1 Highly volatile data where plan stability is critical Unsuccessfully used synthetic queries to test previous upgrades Solution Approach SQL Performance Analyzer to identify SQL regressions SQL Profiles to tune SQL transparently SQL Plan Baselines for plan stability Benefit Very successful upgrade. No surprises! Predictable performance and SLAs Reduced testing time from 5 months to 10 days

41 Large Hotel Chain Problems Resolved Issues Prior to Upgrade Volatile nature of data sometimes produced inefficient queries based on stale stats. Impossible to maintain good statistics due to the nature of data load frequent and widely changing Bind variables didn't always help Outlines hurt in some cases due to nature of the data values After Oracle Database 11g Upgrade: No performance problems noticed Predictable query performance and plan stability due to Plan Baselines Provided a history of plan changes Allowed a more efficient usage of bind variables due to adaptive cursor sharing

42 SPA Case Study 2: E-Business Suite (EBS) Certification and Testing Challenge Solution Approach Certify EBS release 11i, R12 against Oracle Database 11g Complex & large workload: More than 650K unique SQL statements need to be validated Ensure application optimized for Oracle Database 11g Difficult to perform realistic and efficient testing with previous (home-grown) tools SQL Performance Analyzer to run regression tests and identify performance deviations Regressions reported to base development for fixes Benefit Reduced testing time from 21 to 2 days for each release Faster and higher quality testing Faster adoption and certification of newer features

43 SPA: E-Business Suite Certification and Testing SPA has been extensively used for Apps certification and testing R E-Business Suite w/ DB: 650K unique SQL stmts 11i E-Business Suite w/ DB: 550K unique SQL stmts Workload is complex, large Challenges before SPA deployment Manually maintain SQL repository of statements Need to maintain database hosting the SQL repository and java application SPA deployment Eliminated need to maintain SQL repository, java application, database hosting the repository Higher quality and realistic testing Fine-grain, reporting analysis possible Automatic tracking of trials and performance data

44 SPA: E-Business Suite Certification and Testing SPA is already being used in many scenarios Certification of EBS (11i and R12) with Oracle Database Impact of new features on EBS Extended Optimizer Statistics, SQL Plan Baselines, SQL Profiles Performance Testing: Vs Vs 11.2 Impact of Parameter Changes: Obsolete/new parameters Impact of HW changes

45 SPA Case Study 3: Internal Mail System Background: Internal mail system, critical application Collaboration Suite , 4000 named users, 25 Average Active Sessions, RDBMS 4-node RAC, DG Physical Standby, 4 nodes x 8 (4-dual core) CPUs, 15Gb SGA per instance, ASM 4.5 TB DB size (allocated data), Apple XServe RAID, Linux-64 bit OEL4U4 Before SPA: Used manual processes, captured SQL with no bind data for testing and checked plan regression, 80 hrs, but still not reliable SPA used for DB upgrade testing, from release to (Jan 2008) Switching to 11g optimizer statistics gathering Removing legacy, custom optimizer parameters Moving to 11g optimizer code path SPA reported about 20% overall performance improvement SQL Workload consisted of 818 statements Testing revealed most workload would be unchanged (by buffer gets/elapsed time, etc) Few statements improved, but for 5 critical statements plans regressed SQL Plan Baselines used in production successfully for remediating these 5 queries

46 Case Study 3: Internal Mail system After upgrade, SLAs were same as before, and no instabilities were noticed in the last 8 months Upgrade Testing Summary with SPA Resulted in reduced time/effort for actual testing from 80 hrs to 2 hrs More accurate and realistic testing than before SLAs being met and successful production deployment

47 Resources on OTN Real Application Testing for Earlier Releases Testing Performance Impact of an Oracle Database 9i/10g Release 1 to Oracle Database 10g Release 2 Upgrade with SQL Performance Analyzer Migration to Cost-Based Optimizer Upgrading from Oracle 9i to 10g: What to expect from the Optimizer Upgrade Companion: Metalink Note: : One-stop shop for Upgrades Real Application Testing Users Guide

48 David Mitchell Senior Vice President, OVUM Oracle Real Application Testing reduces the time required to test changes by as much as 80%, lower testing costs by as much as 70%, mitigate risks by reducing the number of unexpected outages, and improve the quality of service for their IT operations. Source: Oracle Real ApplicationTesting business agility through superior testing, Jan 2008

49 Conclusion SPA provides comprehensive and easy to use solution for assessing impact of changes on SQL response time Eliminates SQL performance guess work!! SPA can be used to test many changes Upgrade testing including 9i, 10g to 10.2 or 11g releases Index creation/drop, statistics gathering, etc. Helps adopt technology faster by cutting down testing time from months for days With SPA and Real Application Testing businesses can Stay competitive Improve profitability Be compliant

50 The following 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.

51 Recommended Campground Demos Complete Data Center Management Oracle Real Application Testing: Database Replay and SQL Performance Analyzer Demo Self-Managing Database: Automatic Performance Diagnostics Self-Managing Database: Automatic Application & SQL Tuning Self-Managing Database: Automatic Fault Diagnostics Change Management & Data Masking for DBAs Application Quality Management Location Moscone West Exhibit Hall Moscone West Exhibit Hall Moscone West Exhibit Hall Moscone West Exhibit Hall Moscone West Exhibit Hall Moscone West Exhibit Hall Moscone West Exhibit Hall

52 Recommended Sessions (Monday sessions) Session Title Date Time Location Optimizing Application Performance: Application Testing Suite to the Rescue Monday, Sept. 22 1:00 pm Moscone West 2001 Performance Fundamentals for Oracle Database 10g and Oracle Database 11g Monday, Sept. 22 2:30 pm Moscone South 302 First-Failure Fault Diagnosability and Diagnostics: Oracle Database 11g Features and Novel Approaches Monday, Sept. 22 2:30 pm Moscone South 304 Oracle Enterprise Manager: Oracle's Management Solution for Your Enterprise Monday, Sept. 22 4:00 pm Moscone West 2003

53 Recommended Sessions (Tuesday sessions) Session Title Date Time Location Application Upgrade Secrets: Avoid Surprises While Making Database Changes Tuesday, Sept. 23 9:00 am Moscone West 2003 Using Oracle Database 11g Real Application Testing to Simulate Production System Patching Tuesday, Sept. 23 9:00 am Moscone South 304 Advanced Performance Diagnostics: What the GUI Doesn't Tell You Tuesday, Sept :30 am Moscone West 2003 Demystifying SQL Tuning: Tips and Techniques for SQL Experts Tuesday, Sept. 23 1:00 pm Moscone South 303 Successful Upgrade Secrets: Preventing Performance Problems with Database Replay Tuesday, Sept. 23 5:00 pm Moscone South 303

54 Recommended Sessions (Wednesday sessions) Session Title Date Time Location Storage Monitoring Made Easy: Diagnosing I/O Performance Problems Wednesday, Sept. 24 9:00 am Moscone South 303 Applications Data Privacy: An Expert Panel Discussion Wednesday, Sept :30 am Moscone West 2001 SQL Tuning Roundtable with the Experts Wednesday, Sept. 24 1:00 pm Moscone West 2001 Deploying Oracle Enterprise Manager in a Secure Maximum Availability Architecture Wednesday, Sept. 24 5:00 pm Moscone West 2001

55 Create SQL Set : Filters

56 Recommended Sessions (Thursday sessions) Session Title Date Time Location The Danish Experiment: Oracle Database 11g Shock Upgrades and Massive Workload Reduction via COBS Thursday, Sept. 25 9:00 am Moscone South 301 Integrating 40 Data Centers in Three Years: How Oracle's DBAs Control the Data Center Explosion Thursday, Sept :30 am Moscone South 303 Application Testing Best Practices: Real-World Customer Testimonials Thursday, Sept :00 pm Moscone South 303 Proactive Performance Monitoring with Baselines and Adaptive Thresholds Thursday, Sept. 25 1:30 pm Moscone South 303 Managing Oracle Grid Computing: Oracle Real Application Clusters, Oracle Automatic Storage Management, Oracle Data Guard Thursday, Sept. 25 3:00 pm Moscone South 303