This presentation is for informational purposes only and may not be incorporated into a contract or agreement.

Transcription

1 This presentation is for informational purposes only and may not be incorporated into a contract or agreement.

2 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 decision. The development, release, and timing of any features or functionality described for Oracle s products remains at the sole discretion of Oracle.

3

4 Optimizing the Optimizer: Essential SQL Tuning Tips and Techniques

5 Mughees A. Minhas Group Product Manager Benoit Dageville Consulting Member of Technical Staff Khaled Yagoub Senior Member of Technical Staff Pete Belknap Member of Technical Staff

6 Outline SQL Tuning Overview SQL Tuning Best Practices Production system Live Tuning Remote Tuning Development system Techniques for Avoiding Plan Regressions After Database Upgrades Q & A

7 SQL Tuning Overview

8 Common Causes of Poor SQL Performance Stale optimizer statistics CBO requires representative statistics to optimize SQL execution Not easy to determine when statistics are really stale Not easy to determine when stale statistics are actually impacting plan selection Missing access structures Identifying useful indexes and MVs non-trivial Difficult to ascertain performance impact of new structures on DMLs

9 Common Causes of Poor SQL Performance Poor plan selection due to incorrect optimizer estimates Manually hinting SQL a solution, but Requires significant expertise Is time consuming trial and error method Does not work for packaged applications Bad SQL design Only real remedy is to restructure SQL Requires expertise, time, application knowledge

10 Tuning Using SQL Advisors SQL Tuning/Access Advisor Comprehensive Analysis Recommendation SQL Statistics Analysis Gather Missing or Stale Statistics Access Structure Analysis Add Missing Indexes SQL Design Analysis Modify SQL Constructs Plan Tuning (SQL Profiling) Create a SQL Profile

11 SQL Tuning & Access Advisor Feature Comparison Mode Analysis: Statistics SQL Profile SQL Structure Feature Access Path: Indexes Access Path: Materialized Views Access Path: Materialized View Logs * STA: SQL Tuning Advisor ** SAA: SQL Access Advisor *** B-tree indexes only STA* SQL Yes Yes Yes Yes*** No No SAA** Workload No No No Yes Yes Yes

12 SQL Tuning Best Practices

13 Identifying Problem SQL Two key sources for identifying problem SQL Automatic Database Diagnostic Monitor (ADDM) Shows high-load SQL with impact % Based on analysis of SQL, recommends SQL advisors as needed Not all high-load SQL are good candidates for advisors E.g., SQL with HWM enqueue wait problem cannot be tuned by SQL advisors but requires space reconfiguration Top Activity Enterprise Manager (EM) screens Real Time Mode: Source: v$active_session_history (ASH) Period: Last one hour Historical Mode: Source: Automatic Workload Repository (AWR) Period: Last 7 days (default)

14 Using ADDM to Identify High-load SQL

15 Top Activity EM Screens: ASH

16 Top Activity EM Screens: AWR

17 SQL Tuning of Production System

18 SQL Tuning of Production System Tuning Considerations Resource consumption Running SQL advisors consumes CPU, I/O, memory and can affect system performance Potential negative impact of recommendation Implementing recommendations may impact system negatively, e.g., optimizer stats refresh Before initiating tuning, answer the following questions How much system resources will be consumed by tuning activity? Can the system spare resources needed for tuning? How can the production system be shielded from possible negative impact of tuning actions?

19 Resource Consumption of SQL Advisors SQL Tuning Advisor Limited mode: Resource consumption minimal Stats, index and SQL restructure analysis is cheap Average is less than 1 second per SQL statement Comprehensive mode: Resource consumption may be significant SQL Profiling can potentially consume non-trivial resources Roughly comparable to amount of resources/time consumed when executing SQL statement(s) SQL Access Advisor Resource consumption depends on size of SQL workload For small number of SQL, resource consumption not very high

20 Production System Tuning Options Options Direct tuning of live system Remote tuning Live system tuning Run SQL Tuning Advisor in Comprehensive mode Run SQL Tuning Advisor in Limited mode only if System does not have spare resources to tune SQL Run SQL Access Advisor for few SQL at a time Perform remote tuning, if Cumulative resources/time consumed by all SQL statements being tuned significant System cannot spare resources

21 Live System Tuning Techniques 1. Ensure tables referenced in SQL have representative optimizer stats 2. Run SQL Access Advisor For individual SQL, set Recommendation Type to indexes MV not suitable for tuning individual statements 3. Run SQL Tuning Advisor Test profile before making it PUBLIC DBMS_SQLTUNE.ACCEPT_SQL_PROFILE ( task_name => <tuning task name>, category => MY_CATEGORY ); ALTER SESSION SET SQLTUNE_CATEGORY= MY_CATEGORY ; Once satisfied with results set category to DEFAULT DBMS_SQLTUNE.ALTER_SQL_PROFILE( name => <SQL Profile Name>, attribute_name => category, value => DEFAULT );

22 Remote SQL Tuning Techniques Performed to shield production system from performance impact of running SQL advisors Production System Test System 1. Move SQL to Test 3. Apply recomm. on production 2. Tune SQL

23 Remote Tuning Method Test system setup Test system should be identical to production system in Schema Data distribution Volume If system smaller than production system, ensure data distribution is similar

24 Remote Tuning Method 1. Move SQL to test system Create STS of high-load SQL on production system STS is a new object in Oracle 10g for managing SQL workloads STS stores SQL statements along with Execution context: parsing user, bind values, etc. Execution statistics: buffer gets, CPU time, elapse time, number of executions, etc. Use EM screen Period SQL to locate high-load SQL Select Create SQL Tuning Set option to create STS Export STS to test

25 Creating STS of High-load SQL

26 Remote Tuning Method Export STS to test i. Create staging table DBMS_SQLTUNE.CREATE_STGTAB_SQLSET( table_name => 'staging_table' ); ii. Move STS to staging table DBMS_SQLTUNE.PACK_STGTAB_SQLSET( sqlset_name => 'my_sts', staging_table_name => 'staging_table'); iii. iv. Export staging table to test system Export/import, DataPump, DB Links, etc., can be used Unload STS from staging table into dictionary on test system DBMS_SQLTUNE.UNPACK_STGTAB_SQLSET( sqlset_name => my_sts, replace => TRUE, staging_table_name => 'staging_table');

27 Remote Tuning Method 2. Tune SQL Run SQL Tuning Advisor in comprehensive mode to tune STS Implement/verify recommendations If SQL Profile recommended, set profile category to nondefault value before moving profile to production system DBMS_SQLTUNE.ALTER_SQL_PROFILE( name => <SQL Profile Name>, attribute_name => category, value => MY_CATEGORY );

28 Remote Tuning Method 3. Apply recommendation to production Move profile from test to production system i. Create staging table ii. iii. iv. DBMS_SQLTUNE.CREATE_STGTAB_SQLPROF( table_name => 'PROFILE_STGTAB'); Move SQL Profile to staging table DBMS_SQLTUNE.PACK_STGTAB_SQLPROF ( profile_name => 'MY_PROFILE', staging_table_name => 'PROFILE_STGTAB'); Export staging table to production system Export/import, Data Pump, DB Links, etc., can be used Unload data from staging table to create SQL Profile on target DBMS_SQLTUNE.UNPACK_STGTAB_SQLPROF( replace => FALSE, staging_table_name => 'PROFILE_STGTAB');

29 Remote Tuning Method 3. Apply recommendation on production (Contd.) Test profile in private session to verify performance on production system ALTER SESSION SET SQLTUNE_CATEGORY= MY_CATEGORY ; If execution performance okay, set category to DEFAULT DBMS_SQLTUNE.ALTER_SQL_PROFILE( name => <SQL Profile Name>, attribute_name => category, value => DEFAULT );

30 SQL Tuning on Development System

31 SQL Tuning on Development System Performance impact of tuning overhead not an issue Tuning Method Capture SQL Workload Redesign poorly written SQL Identify appropriate access structures

32 Development System Tuning Steps Capture SQL Workload Easiest way is to use cursor cache capture capability of STS Run workload Capture workload in STS simultaneously DBMS_SQLTUNE.CAPTURE_CURSOR_CACHE_SQLSET( sqlset_name => MY_STS, time_limit => 3600, repeat_interval => 60, sqlset_owner => own);

33 Development System Tuning Steps Use SQL Tuning Advisor to redesign poorly written SQL Types of problems identified include: Semantic changes of SQL operators Syntactic changes to predicates on indexed columns SQL design issues Use SQL Access Advisor to optimize schema design Identifies appropriate access structures % improvement in performance of entire workload for each structure recommended is provided

34 Techniques for Avoiding Plan Regressions After Database Upgrades

35 Avoiding Plan Regressions After Upgrades Database Upgrade from 10.1 to 10.2 SQL execution plan regression major concern for upgrades Plan regressions can systematically be detected and remedied New Oracle 10g infrastructure makes this possible

36 Methodology for Avoiding Plan Regressions Step 1 Step 2 Step DB Capture 10.1 Workload & Execution Plans Upgrade to 10.2 Capture 10.2 Workload & Execution Plans Step 4 Compare 10.1 and 10.2 Execution Plans Step 5 Tune SQL with Performance Regressions

37 Methodology for Avoiding Plan Regressions 10.1 DB Step 1 Step 2 Step 3 Capture 10.1 Workload & Execution Plans Upgrade to 10.2 Capture 10.2 Workload & Execution Plans Step 4 Step 5 Compare 10.1 and 10.2 Execution Plans Tune SQL with Performance Regressions

38 Upgrade Steps for Avoiding Plan Regressions 1. Capture 10.1 workload and executions plans Increase AWR retention on 10.1 production system Motivation: Capture top SQL of entire workload cycle If system upgraded is test system Ideally should replica of actual system to be upgraded (using RMAN backup) Ensure configuration of AWR, optimizer parameters, etc., same as actual system If data distribution/volume on test system different than production, import optimizer stats from production Allow normal production workload to run on system before starting upgrade testing

39 Methodology for Avoiding Plan Regressions 10.1 DB Step 1 Step 2 Step 3 Capture 10.1 Workload & Execution Plans Upgrade to 10.2 Capture 10.2 Workload & Execution Plans Step 4 Step 5 Compare 10.1 and 10.2 Execution Plans Tune SQL with Performance Regressions

40 Upgrade Steps for Avoiding Plan Regressions 2. Upgrade test system to 10.2 Use standard upgrade method Create baseline STS Baseline STS created in 10.2 not STS also contains execution plans Capture all SQL from AWR in production system Use EM or PL/SQL API s to create STS

41 Example 1: Capturing All AWR SQL in STS Inputs: Snapshot range: begin and end snapshot Owner: STS owner declare own VARCHAR2(30) := '&owner'; bid NUMBER := '&begin_snap'; eid NUMBER := '&end_snap'; sts_cur dbms_sqltune.sqlset_cursor; begin dbms_sqltune.create_sqlset(sqlset_name => '10.1 sts', sqlset_owner => own); open sts_cur for select value(p) from table(dbms_sqltune.select_workload_repository(bid, eid, null, null, null, null, null, 1, null, 'ALL')) P; dbms_sqltune.load_sqlset(sqlset_name => '10.1 sts', populate_cursor => sts_cur, load_option => 'MERGE'); end; /

42 Methodology for Avoiding Plan Regressions 10.1 DB Step 1 Step 2 Step 3 Capture 10.1 Workload & Execution Plans Upgrade to 10.2 Capture 10.2 Workload & Execution Plans Step 4 Step 5 Compare 10.1 and 10.2 Execution Plans Tune SQL with Performance Regressions

43 Upgrade Steps for Avoiding Plan Regressions 3. Capture 10.2 workload and execution plans Run workload on 10.2 and capture in new STS simultaneously Use dbms_sqltune.capture_cursor_cache_sqlset procedure

44 Example 2: Capturing SQL from Cursor Cache in STS Inputs: Time Limit: Workload execution time Owner: STS owner declare own VARCHAR2(30) := '&owner'; time_lim NUMBER := &time; begin dbms_sqltune.create_sqlset(sqlset_name => '10.2 sts', sqlset_owner => own); end; / dbms_sqltune.capture_cursor_cache_sqlset (sqlset_name => '10.2 sts', time_limit => time_lim, repeat_interval => 60, sqlset_owner => own);

45 Methodology for Avoiding Plan Regressions 10.1 DB Step 1 Step 2 Step 3 Capture 10.1 Workload & Execution Plans Upgrade to 10.2 Capture 10.2 Workload & Execution Plans Step 4 Step 5 Compare 10.1 and 10.2 Execution Plans Tune SQL with Performance Regressions

46 Upgrade Steps for Avoiding Plan Regressions 4. Compare 10.1 and 10.2 SQL executions plans Query contents of 10.1 sts and 10.2 sts via DBA_SQLSET_STATEMENTS to see if: Top 100 SQL in 10.2 sts were also found in 10.1 sts Any SQL in top 100 have had plan changes

47 Example 3: Query for Comparing STS select * from ( select r2_sts.sql_id, r1_sts.plan_hash_value old_plan_hash, r2_sts.plan_hash_value new_plan_hash, r2_sts.elapsed_time/r2_sts.executions elap_time, nvl2(r1_sts.plan_hash_value, 0, 1) new_plan, r2_sts.sql_text from dba_sqlset_statements r1_sts, dba_sqlset_statements r2_sts where r1_sts.sqlset_name (+) = '10.1 sts' and r1_sts.sqlset_owner (+) = '&own' and r1_sts.sql_id (+) = r2_sts.sql_id and r1_sts.plan_hash_value (+) = r2_sts.plan_hash_value and r2_sts.sqlset_name = '10.2 sts' and r2_sts.sqlset_owner = '&own' order by elap_time desc) where rownum < 100 ;

48 Example 4: Query Output Comparing Contents of STS Sample query output Output shows top 100 SQL in 10.2 ordered by elapsed time. Old and new plan hash values shown NEW_PLAN column indicates if plan was not captured in SQL_ID OLD_PLAN_HASH NEW_PLAN_HASH ELAP_TIME NEW_PLAN SQL_TEXT fyrbzparfb4gb select * from scott.dept

49 Methodology for Avoiding Plan Regressions 10.1 DB Step 1 Step 2 Step 3 Capture 10.1 Workload & Execution Plans Upgrade to 10.2 Capture 10.2 Workload & Execution Plans Step 4 Step 5 Compare 10.1 and 10.2 Execution Plans Tune SQL with Performance Regressions

50 Upgrade Steps for Avoiding Plan Regressions 5. Tune SQL with performance regressions Examine plan changes to identify regressions Use dbms_xplan.display_sqlset to examine execution plans in STS select * from table(dbms_xplan.display_sqlset( &sqlset_name, &sql_id, &plan_hash_value, 'TYPICAL', &sqlset_owner)); Tune SQL with plan regressions using techniques discussed in remote tuning section

51 Summary Tuning techniques for production and development systems vary Production system considerations Tuning activity performance overhead Risk management of tuning actions Development system considerations SQL design improvement Optimization of access structure design Oracle Database 10g has powerful capabilities to minimize upgrade performance regressions Reduce risk by fully utilizing new capabilities

52

53