dba’s new best friend: oracle database 10g and 11g ??s new best friend: oracle database 10g and...

Download DBA’s New Best Friend: Oracle Database 10g and 11g  ??s New Best Friend: Oracle Database 10g and 11g SQL Performance Analyzer Prabhaker Gongloor ... • Use for 9i/10.1 upgrade to higher releases

Post on 12-Apr-2018

213 views

Category:

Documents

1 download

Embed Size (px)

TRANSCRIPT

  • DBAs New Best Friend: Oracle Database 10g and 11g SQL Performance AnalyzerPrabhaker Gongloor (GP)Khaled YagoubPete BelknapDatabase Manageability Group

  • Outline

    SQL Performance Analyzer (SPA) Introduction Recommended Testing Methodology Usage Scenarios

    Evaluating Changes on Production System 10.2 11g DB Upgrade

    SPA Exadata Simulation SPA Enhancements in Oracle Database 11g Release 2 Conclusion

    * Please visit us at the OOW Demogrounds Moscone West D61/62

  • SPA Motivation

    Businesses need to adapt to changes to stay competitive, compliant and evolve DB upgrades, schema, optimizer statistics refresh

    SQL performance regressions: #1 cause of poor system perf.

    Current testing landscape and limitations Expensive capture, partial workload, non-production optimizer context,

    binds Large workloads (100Ks SQL stmts are common) Manual and time consuming testing and regression tuning

    No end-to-end testing solution Test In Production is not too uncommon

    SQL Performance Analyzer (SPA) Proactively detects ALL SQL regressions, BEFORE actual change is deployed Integrated comprehensive solution for end-to-end SQL workload testing

  • SPA Overview

    Helps users predict the impact of system changes on SQL workload response time

    Low overhead capture of SQL workload to SQL Tuning Set (STS) on production system

    Build different SQL trials (experiments) of SQL statements performance by test execution

    Analyzes performance differences

    Offers fine-grained performance analysis on individual SQL

    Integrated with STS, SQL Plan Baselines, & SQL Tuning Advisor to form an end-to-end solution

    Analysis Report

    Compare

    SQL Performance

    SQL plans + stats SQL plans + stats

    Pre-change Trial Post-change Trial

    SQL Workload STS

  • SQL Trials

    SQL Trials capture execution performance (plans and statistics) of the STS under a given environment

    SPA Trials handle the SELECTS and query part of DML, DDL is skipped

    There are 3 methods to build SQL Trials:

    Execute SQL Locally or Remotely Test execute statements in actual environment For remote execution, database link needs to be specified

    Generate Plans Locally or Remotely Generated execution plans have bind visibility, so better than vanilla

    explain Quick way to check if wide-spread changes to SQL plans

    Build from STS Convert STS to SQL Trial Use for SQL centric analysis with DB Replay or other testing tools Use for 9i/10.1 upgrade to higher releases

  • SPA: Common Usage Scenarios

    Database upgrades and patch-set releases 9.2/10.1 10.2 or 11g releases 10.2.0.x 10.2.0.y or 11g releases

    Optimizer statistics refresh Database parameter changes Database schema changes (e.g., add/drop indexes) Implementation of tuning recommendations I/O subsystem changes (e.g., ASM, Exadata)

    SPA can be used for: any change that affects SQL execution plan & performance in production as well as test environments

    Information for use cases on OTN/ML Note: 560977.1

  • SPA: Enterprise Manager Interface

    Rich GUI through Enterprise Manager New workflows added!

    DBMS_SQLPA package PL/SQL API

    New Workflows !

  • Recommended Testing Methodology

  • Real Application Testing: Recommended Methodology

    2. USE DB REPLAY FOR LOAD / CONCURRENCY TESTING

    DONE?

    No

    DEPLOY CHANGE & TUNING

    Yes

    Yes

    No

    DONE?

    1. USE SPA FOR SQL RESPONSE TIME / UNIT TESTING

  • Recommended Testing Methodology with SPA

    1. CAPTURE REPRESENTATIVE SQL WORKLOAD TO STS

    3. MAKE CHANGE, ESTABLISH SQL TRIAL-N

    2. ESTABLISH BASELINE (SQL TRIAL-1) WITHOUT CHANGE

    4. COMPARE TRIALS & REVIEW SPA REPORT, REMEDIATE

    Reports show deviations from production

    NoYes

    5. Deploy Change & Tuning to PROD OR

    further testing thru DB Replay

    Compare Baseline to Trial-N in the sameenvironment

    For incremental tuning: Compare Trial N-1 to Trial-N

    Test one change at a time to understand causality

    DONE?

    Use Production or identical Test System

  • Usage Scenario: Evaluating Changes On Production

  • +Parameter

    Change

    1. Fix Regression thru SPM

    +Add

    indexes

    Using SPA For Changes in Production: Example

    Fix Regression SQL Profile

    Prod

    +SQL

    Profile

    +New Stats

    Change

    +Partitioning

    +Validate

    Tuning

    Parameter change was bad in this case

    And so on

    +Index

    Unusable

    Bubble following the arrow indicates the delta change on Production

    SPA is used for testing every change

  • How to Minimize Impact on Production?

    Generate Plan Vs Test Execute Use Generate Plan Trial Method to subset SQL with plan changes Only test execute SQL with plan changes

    Limit testing scope to private session or schema where possible Use alter session set = ; (Vs system) Example usage for SQL Profiles:

    alter session set sqltune_category= TEST; Implement SQL Profiles and test Only sessions with TEST sqltune_category

    see these Profiles - private scope!!

    alter session set sqltune_category= DEFAULT; -- Now SQL Profiles visible globally to all sessions

    Similarly for Invisible Indexes, Pending Stats

    Use SPA time limit to control resource usage

    Test during maintenance window or non-peak activity when spare resources are available

  • Using SPA on Production: Evaluating Optimizer Statistics Refresh and other changes

    Scenario:Can I use SPA to check if any SQL statements

    regressed due to optimizer statistics refresh on my 10.2/11g production databases? If so, how?

    Goal:Assess impact of optimizer statistics gathering

    on SQL workload performance on production system using SPA & make sure are no negative effects of the change

  • Evaluating Optimizer Statistics Refresh

    Assumptions Statistics refreshed periodically through custom jobs No test system available, so evaluation is done on production Should impact end-users minimally Test using optimizer pending statistics feature

    Use SPA remote trials capability (generate plan and test execute) to evaluate statistics refresh on 10.2/11g production database

    Analyze SPA report and take appropriate action Overall improvement but few SQL regressions

    Solution: Use SQL Profiles or Plan Management No improvement and many regressions

    Solution: Revert to old statistics: Use optimizer statistics retention/history feature. Alternatively, configure optimizer statistics appropriately*

    For Oracle Database 11g, publish pending statistics after evaluation of statistics

    OBE Tutorial on OTN: Gathering and Publishing Stats Independently

  • Using SPA on Production: Evaluating Optimizer Statistics Refresh

    Production Database (10.2/11g)

    11g SPA System

    1. Capture SQL workload to STS

    Prod: Before Stats

    Prod: Stats Refreshed

    Evaluate Opt Statistics Refresh

    5. Publish Pending Stats and Remediate Regressions

    Remotely Build SQL Trials

    No Test Database Used!!

    3. Gather Pending Stats

    2. Import STS

    4.Use SPA to detect performance changes

    No app schema/data necessary

    Not Mandatory for 11g db

    Repository for many tests!

  • Evaluating Optimizer Statistics Refresh

    Tips!

    On production, first use SPA to generate execution plans only, then test-execute SQLs with changed plans

    If youre creating remote trials, you will need a logon trigger to set optimizer_use_pending_statistics = TRUE private to the second trial (SPA establishes the connection itself, over db link, so you cannot run alter session yourself)

    To test-execute only those SQLs with changed plans, subset your STS after doing trial 2, then do a new SPA experiment on that STS

    Script to subset STS is on Notes slide

  • Usage Scenario: End-to-End Case Study for 10.2 11g

    Upgrade

  • 10.2 11g DB Upgrade Using Enterprise Manager Grid Control (EMGC) 10.2.0.5

    Scenario:I want to upgrade from 10.2 to 11g database release to

    benefit from 11g functionality. How can I best accomplish the upgrade?

    Goal:Assess impact of upgrade on SQL workload performance

    using SPA so that there are no surprises after upgrade. Once migrated to 11g new features can be enabled one at a time. Use EMGC 10.2.0.5 for this purpose

  • 10.2 11g DB Upgrade

    Production Database

    11g SPA System

    1. Capture SQL workload to STS

    Upgrade

    Test Database

    Test DB (11g)

    Upgrade

    Test DB (10.2)

    Collect execution stats

    3. Establish 10.2 and 11g Trials

    4. Compare performance and generate SPA report

    Send SQL for Remote Execution

    Prod DB (10.2)

    2. Transport STS

    5. Deploy Tuning and Change to Prod

  • 10.2 11g DB Upgrade(1) Capture Workload to STS

    Steps 1: Capture workload into STS through Incremental Capture Workload into STS: Preferred method Other sources for STS also possible: Top SQL in AWR / AWR Baseline

  • 10.2 11g DB Upgrade(1) Capture Workload to STS

  • 10.2 11g Upgrade

    1. Capture SQL workload to STS

    3. Establish 10.2 and 11g Trials

    2. Transport STS

    4. Compare performance and Generate SPA report

    5. Deploy Tuning and Change to Prod

  • Step 2: Copy STS to SPA system Setup Test DB (Copy of Prod) 10.2 Upgrade Test DB from 10.2 to 11g

    10.2 11g DB Upgrade (2) Transport STS

  • 10.2 11g DB Upgrade

Recommended

View more >