Oracle Database 11g: Performance Tuning 11-1

Transcription

1 Oracle Database 11g: Performance Tuning 11-1

3 Real Application Testing: Overview SQL Performance Analyzer (SPA) SPA is the tool of choice when you trying to identify SQL statements that will perform differently, when a change is made at the database or OS level. SPA captures SQL statements into a SQL tuning set from various sources, including the cursor cache, Automatic Workload Repository (AWR), and existing SQL tuning sets (STS). The STS is analyzed by executing each SQL statement in isolation. The order of execution depends on the order of the statement in the tuning set. The STS includes bind variable, execution plan, and execution context information. With SPA, you will execute the STS and capture performance statistics, make the change to the system and execute the STS again, and then compare. SPA does not consider the impact that SQL statements can have on each other. Database Replay When there are extensive changes such as OS, or database version, or when overall system performance must tested, Database Replay is the preferred tool. Database Replay captures the actual workload over a period of time, along with performance statistics. This workload is processed for the target system and then replayed. The replay has options for speed of replay, think time, maintaining the transaction order (synchronization) and others. After the workload has been replayed, the performance statistics, data divergence, and errors can be compared to the original capture or another replay session. AWR and Replay reports are available. Oracle Database 11g: Performance Tuning 11-3

4 Real Application Testing: Use Cases The Real Application Testing option allows you to test the impact of database and OS change including (but are not limited to) any of the following: Database upgrades Implementation of tuning recommendations Schema changes Statistics gathering Database parameter changes OS and hardware changes SQL Performance Analyzer can be used to predict and prevent potential performance problems for any database environment change that affects the structure of the SQL execution plans. DBAs can use SQL Performance Analyzer to foresee SQL performance changes that result from the preceding changes for even the most complex environments. As applications evolve through the development life cycle, database application developers can test, for example, changes to schemas, database objects, and rewritten applications to mitigate any potential performance impact. SPA enables the comparison of SQL performance statistics. Database Replay can be used for the same change scenarios but tests the entire workload, honoring transaction dependencies. Database Replay executes all statements including DML. The entire workload is tested, including interactions and dependencies. Oracle Database 11g: Performance Tuning 11-4

5 SQL Performance Analyzer: Process 1. Gather SQL: In this phase, you collect the set of SQL statements that represent your SQL workload on the production system. You can use SQL tuning sets or Automatic Workload Repository (AWR) to capture the information to transport. Because AWR essentially captures high-load SQLs, you should consider modifying the default AWR snapshot settings and captured Top SQL to ensure that AWR captures the maximum number of SQL statements. This ensures more complete SQL workload capture. You can also use the filtering and ranking capabilities of the STS to change the SQL statements that are included. 2. Transport: Here you transport the resultant workload to the test system. The STS is exported from the production system and the STS is imported into the test system. 3. Compute before-version performance: Before any changes take place, you execute the SQL statements, collecting baseline information that is needed to assess the impact that a future change might have on the performance of the workload. The information collected in this stage represents a snapshot of the current state of the system workload and includes performance data. In this phase you may test the SQL by executing the STS or you can have the SPA task only generate the execution plans, without executing the statements. 4. Make a change: After you have the before-version data, you can implement your planned change and start viewing the impact on performance. Oracle Database 11g: Performance Tuning 11-5

6 SQL Performance Analyzer: Process (continued) 5. Compute after-version performance: This step takes place after the change is made in the database environment. Each statement of the SQL workload executes again, collecting the same information as captured in step Compare and analyze SQL Performance: After you have both versions of the SQL workload performance data, you can carry out the performance analysis by comparing the after-version data with the before-version data. The comparison is based on the execution statistics, such as elapsed time, CPU time, and buffer gets. 7. Tune regressed SQL: At this stage, you have identified exactly which SQL statements may cause performance problems when the database change is made. Here, you can use any of the database tools to tune the system. For example, you can use SQL Tuning Advisor or Access Advisor against the identified statements and then implement those recommendations. Alternatively, you can seed SQL Plan Management (SPM) with plans captured in step 3 to guarantee that the plans remain the same. After implementing any tuning action, you should repeat the process to create a new after-version and analyze the performance differences to ensure that the new performance is acceptable. Oracle Database 11g: Performance Tuning 11-6

7 Capturing the SQL Workload Capturing SQL workload is done by using SQL tuning sets (STS) and transporting it to the target system. This workflow is briefly described in the slide. You can use either Enterprise Manager wizards or the DBMS_SQLTUNE PL/SQL package. With Oracle Database 11g, you access the SQL tuning sets page from the Performance tab in Database Control. The workload that you capture should reflect a representative period of time (in captured SQL statements) that you wish to test under some changed condition. The following information is captured in this process: The SQL text The execution context (including bind values, parsing schema, and compilation environment), which contains a set of initialization parameters under which the statement is executed The execution frequency, which tells how many times the SQL statement has been executed during the time interval of the workload Normally the capture SQL happens on the production system to capture the workload running on it. The performance data is computed later on the test system by the compute SQL performance processes. SQL Performance Analyzer tracks the SQL performance of the same STS before and after a change is made to the database. Oracle Database 11g: Performance Tuning 11-7

8 Creating a SQL Performance Analyzer Task EM helps you manage each component in the SQL Performance Analyzer process and reports the analysis result. EM Database Control and EM Grid Control have the same pages. There are multiple paths to access the SQL Performance Analyzer page: from the Software and Support tab of Database Control, from the Related Links section on any tab, select Advisor Central > Advisors > SQL Performance Analyzer, or from the Performance tab in the Additional Monitoring Links section SQL Performance Analyzer offers three workflows for you to test different scenarios: Optimizer Upgrade Simulation: Test the effects of specified optimizer version changes on SQL tuning set performance. A SQL Performance Analyzer task is created and an initial trial run is performed with the optimizer_features_enable parameter set to an initial value. A second trial run is performed with the optimizer_features_enable parameter set to the targeted version. A replay trial comparison report is then run for the two trials. Parameter Change: Test and compare an initialization parameter change on SQL tuning set performance. A SQL Performance Analyzer task is created and an initial trial run is performed with the parameter set to the base value. A second trial run is performed with the parameter set to the changed value. A replay trial comparison report is then run for the two trials. Guided Workflow: Create a SQL Performance Analyzer task and execute custom experiments by using manually created replay trials. Oracle Database 11g: Performance Tuning 11-8

9 SQL Performance Analyzer: Tasks After you create your SQL Performance Analyzer task, it might take a long time for it to finish depending on the number of statements that are contained in your SQL tuning set. While your task is executing, you can click Refresh on the SQL Performance Analyzer page to update the Last Run Status field. When you see a green tick in the Last Run Status column for your task, the task is complete. After execution, you can click the link corresponding to the name of your task in the SQL Performance Analyzer Tasks table. This directs you to the corresponding SQL Performance Analyzer Task page. Oracle Database 11g: Performance Tuning 11-9

10 Optimizer Upgrade Simulation This page enables you to create a task that measures the performance impact on a SQL tuning set when the database is upgraded from one version to another. In the example in the slide, the simulated upgrade is done from to by setting the COMPATIBLE initialization parameter. (You set COMPATIBLE as low as ) To create an analysis task, you must specify the following details: Enter the name of the task and (optionally) a description. Specify the STS to use for this analysis. It must already be created. Select a time limit from the Per-SQL Time Limit drop-down list to specify the time limit for the execution of each SQL statement: - UNLIMITED: There is no time limit for the execution of each SQL statement. - EXPLAIN ONLY: The test plan is generated but not executed. - CUSTOMIZE: You can customize the execution time limit. Select the optimizer versions to indicate the original version of the database and the new version to which the database is being upgraded. Two replay trials are created. The first captures STS performance with the original optimizer version, and the second uses the targeted version. Select the comparison metric to be used by SPA to evaluate the performance impact due to the database upgrade. Specify a schedule for the task. Click Submit to start the analysis. Oracle Database 11g: Performance Tuning 11-10

11 SQL Performance Analyzer Task Page A SQL Performance Analyzer task allows you to execute a specific SQL tuning set under changed environmental conditions. After you execute the task, you can assess the impact of these changes on the performance of the SQL tuning set. The Comparison Report is useful in assessing the impact of the changed environmental conditions on the performance of the specified SQL tuning set. From this page, you can also: Create a replay trial to test the performance of a SQL tuning set under a specific environment. Click Create Replay Trial. Refer to the Guided Workflow page for detailed information about creating a replay trial. Run a replay trial comparison to compare the differences between the replay trials that have been created so far. A comparison report is generated for each replay trial run. Click Run Replay Trial Comparison. Refer to the Guided Workflow page for detailed information about running a replay trial comparison. Click the eyeglass icon in the Comparison Report column to view the replay trial comparison report for your task. Oracle Database 11g: Performance Tuning 11-11

12 Comparison Report Use the SQL Performance Analyzer Task Result page to see the replay trial comparison report. The following general details are displayed: Task details such as name, owner, and description of the task Name and owner of the SQL tuning set Total number of SQL statements and any SQL statements with errors. Click the SQL Statements With Errors link to access the Errors table. The replay trials being compared and the comparison metric being used In addition to these details, you can view the following: Projected Workload [Comparison Metric]: This chart shows the projected workload for each replay trial based on the comparison metric along with the improvement, regression, and overall impact. Click the impact links to drill down to the complete list of SQL statements in each category. SQL Statement Count: This chart shows the number of SQL statements that have improved, regressed, or not changed performance based on the comparison metric. The colors of the bars indicate whether the plan changed between the two trial runs. Click the links or the data buckets to access the SQL Statement Count Details page, where you can see a list of SQL statements, and then click a SQL ID to access the SQL details. Top 10 SQL Statements Based on Impact on Workload table: This table allows you to click a specific SQL ID to drill down to the corresponding SQL Details page. Oracle Database 11g: Performance Tuning 11-12

13 Comparison Report (continued) On the SQL Details page, you can view the SQL statements and a line-by-line comparison between each replay trial run for each statistic. You can also find the execution plan for each trial. Oracle Database 11g: Performance Tuning 11-13

14 Tuning Regressing Statements From the SQL Performance Analyzer Task Result page, you can directly tune all regressing statements by invoking SQL Tuning Advisor. To do so, click the Run SQL Tuning Advisor button to access the Schedule SQL Tuning Task page, where you can specify the tuning task name and a schedule. When you are finished, click OK. This creates a new tuning task that analyzes all regressing statements found by SQL Performance Analyzer. Oracle Database 11g: Performance Tuning 11-14

15 Tuning Regressing Statements (continued) After the SQL tuning task is created, you return to the SQL Performance Analyzer Task Results page, where you can see that you now have a SQL Tune report associated with your performance analysis in the Recommendations Section. You can also access the SQL Tuning Results page directly from the SQL Performance Analyzer Task page by clicking the eyeglass icon in the SQL Tune Report column of the Replay Trial Comparisons section for your trial comparison The SQL Tune Report shows you the Recommendations table that lists all recommendations for regressing statements. Oracle Database 11g: Performance Tuning 11-15

16 Preventing Regressions Instead of using SQL Tuning Advisor to tune your regressing statements, you can also prevent regressions by using the SQL plan baselines. You can do so from the SQL Performance Analyzer Task Result page by clicking the Create SQL Plan Baselines button. Note: For more information about SQL plan baselines, refer to the SQL Plan Management lesson. Oracle Database 11g: Performance Tuning 11-16

17 Parameter Change Analysis Use the Parameter Change page to create a task that allows you to test the performance impact on a SQL tuning set when the value of the initialization parameter is changed. This option is very useful because it is difficult to forecast whether changing the parameter value will have a positive or negative impact. To create a task, do the following: 1. Enter the name of the task and a description. 2. Click the Select icon and select a SQL tuning set from the list. 3. Select the Per-SQL Time Limit from the list to specify the time limit for the execution of each SQL statement. 4. Click the Select icon to select an initialization parameter from the list. 5. Specify the current value (Base Value) and the new value (Changed Value) for the initialization parameter. 6. Select the comparison metric that will be used to evaluate the performance impact due to the change. 7. Specify the schedule for the task. After the task has been created, an initial trial run is performed with the initialization parameter set to the base value. A second trial run is performed with the initialization parameter set to the changed value. Finally, a replay trial comparison report is generated for the two trials with the specified comparison metric. Oracle Database 11g: Performance Tuning 11-17

18 Guided Workflow Analysis You can use the Guided Workflow page to define a sequence of steps to execute a two-trial SQL Performance Analyzer test. The steps are as follows: 1. Create a SQL Performance Analyzer task based on a SQL tuning set. 2. Replay the SQL tuning set in the initial environment: Any changes to the trial environment that affect the STS must be made manually before the replay trial is executed. These trials may include changing initialization parameters, gathering optimizer statistics, and creating indexes. 3. Create the replay trial using the changed environment: You can now create the second replay trial using the changed environment by specifying all the necessary information. Performance differences between the trials are attributed to the environmental differences. 4. Create the replay trial comparison using trials from previous steps: This allows you to assess the performance impact on the STS when each replay trial is executed. 5. View the trial comparison report: You can now generate the replay trial comparison report. Note: Before submitting a replay trial, you must select the Trial environment established option on the corresponding task page. However, you must manually make the necessary changes. Oracle Database 11g: Performance Tuning 11-18

19 SQL Performance Analyzer: PL/SQL Example The general example in the slide shows you how to use the DBMS_SQLPA package to invoke SQL Performance Analyzer to access the SQL performance impact of some changes. You could easily adapt this example to run your own analysis. 1. Create the tuning task to run SQL Performance Analyzer. 2. Execute the task once to build the before-change performance data. With this call, you can specify various parameters, some of which are: - Set the execution_type parameter in either of the following ways: Set to EXPLAIN PLAN to generate explain plans for all SQL statements in the SQL workload. Set to TEST EXECUTE to execute all SQL statements in the SQL workload. The procedure executes only the query part of the DML statements to prevent side effects to the database or user data. When TEST EXECUTE is specified, the procedure generates execution plans and execution statistics. - Specify execution parameters by using the execution_params parameter that needs to be specified as dbms_advisor.arglist(name,value, ). The time_limit parameter specifies the global time limit to process all SQL statements in a SQL tuning set before timing out. The local_time_limit parameter specifies the time limit to process each SQL statement in a SQL tuning set before timing out. 3. Produce the before-change report (special settings for report: set long , longchunksize , and linesize 90). Oracle Database 11g: Performance Tuning 11-19

20 SQL Performance Analyzer: PL/SQL Example (continued) After you make the change to your test instance. 4. Execute the task again after making the changes 5. Generate the after-changes report. 6. Compare the two executions 7. Generate the analysis report. Using the following command as a pattern and substituting parameters to suit your needs: BEGIN DBMS_SQLTUNE.EXECUTE_TUNING_TASK( task_name => :tname, execution_type => 'compare performance', execution_params => dbms_advisor.arglist( 'execution_name1', 'before', 'execution_name2', 'after', 'comparison_metric', 'buffer_gets')); END; Note: For more information about the DBMS_SQLPA package, see the Oracle Database PL/SQL Packages and Types Reference Guide. Oracle Database 11g: Performance Tuning 11-20

21 SQL Performance Analyzer: Data Dictionary Views DBA{USER}_ADVISOR_TASKS: Displays details about the advisor task created to perform an impact analysis of a system environment change DBA{USER}_ADVISOR_FINDINGS: Displays analysis findings. The advisor generates four types of findings: performance regression, symptoms, errors, and informative messages. DBA{USER}_ADVISOR_EXECUTIONS: Lists metadata information for a task execution. SQL Performance Analyzer creates a minimum of three executions to perform a change impact analysis on a SQL workload: one execution to collect performance data for the before-change version of the workload, the second execution to collect data for the after-change version of the workload, and a final execution to perform the actual analysis. DBA{USER}_ADVISOR_SQLPLANS: Displays the list of all SQL execution plans (or those owned by the current user) DBA{USER}_ADVISOR_SQLSTATS: Displays the list of SQL compilation and execution statistics (or those owned by the current user) Oracle Database 11g: Performance Tuning 11-21

24