Oracle Database 11 : Server Manageabilitydbmanagement.info/.../MIX/Oracle_Database_11g_Server_Manageability.pdfOracle Database 11g: Server Manageability Table of Contents ... Automatic

Oracle Database 11 g: Server Manageability

Student Guide

D52366GC10

Edition 1.0

October 2007

PRODUCTION

Copyright © 2007, Oracle. All rights reserved.

This documentation contains proprietary information of Oracle Corporation. It is provided under a license agreement containing restrictions on use and disclosure and is also protected by copyright law. Reverse engineering of the software is prohibited. If this documentation is delivered to a U.S. Government Agency of the Department of Defense, then it is delivered with Restricted Rights and the following legend is applicable:

Restricted Rights Legend

Use, duplication or disclosure by the Government is subject to restrictions for commercial computer software and shall be deemed to be Restricted Rights software under Federal law, as set forth in subparagraph (c)(1)(ii) of DFARS 252.227-7013, Rights in Technical Data and Computer Software (October 1988).

This material or any portion of it may not be copied in any form or by any means without the express prior written permission of the Education Products group of Oracle Corporation. Any other copying is a violation of copyright law and may result in civil and/or criminal penalties.

If this documentation is delivered to a U.S. Government Agency not within the Department of Defense, then it is delivered with “Restricted Rights,” as defined in FAR 52.227-14, Rights in Data-General, including Alternate III (June 1987).

The information in this document is subject to change without notice. If you find any problems in the documentation, please report them in writing to Worldwide Education Services, Oracle Corporation, 500 Oracle Parkway, Box SB-6, Redwood Shores, CA 94065. Oracle Corporation does not warrant that this document is error-free.

Oracle, JD Edwards, PeopleSoft, and Siebel are registered trademarks of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.

Author

Christine Jeal, Jean-Francois Verrier

Technical Contributors and Reviewers

Uri Shaft, John Beresniewicz, Prabhaker Gongloor, Bharat Baddepudi, Leonidas Galanis, Khalad Yogoub, Graham Wood, Jonathan Soule

This book was published using: oracle tutor


Oracle Database 11g: Server Manageability Table of Contents i

Table of Contents

Automatic SQL Tuning...................................................................................................................................1-2 Chapter 1Automatic SQL Tuning .................................................................................................................1-2 Objectives......................................................................................................................................................1-3 SQL Tuning in Oracle Database 10g.............................................................................................................1-4 Automatic SQL Tuning in Oracle Database 11g...........................................................................................1-5 Summary of Automation in Oracle Database 11g........................................................................................1-6 Selecting Potential SQL Statements for Tuning............................................................................................1-7 Maintenance Window Timeline ....................................................................................................................1-8 Automatic Tuning Process ............................................................................................................................1-9 DBA Controls................................................................................................................................................1-11 Automatic SQL Tuning Task ........................................................................................................................1-12 Configuring Automatic SQL Tuning.............................................................................................................1-13 Automatic SQL Tuning: Result Summary ....................................................................................................1-14 Automatic SQL Tuning: Result Details.........................................................................................................1-15 Automatic SQL Tuning Result Details: Drilldown .......................................................................................1-16 Automatic SQL Tuning: Fine Tuning ...........................................................................................................1-17 Using the PL/SQL Interface to Generate Reports .........................................................................................1-19 Automatic SQL Tuning Considerations ........................................................................................................1-20 Summary .......................................................................................................................................................1-21

Automatic Storage Management....................................................................................................................2-2 Chapter 2Automatic Storage Management....................................................................................................2-2 Objectives......................................................................................................................................................2-3 Without ASM Fast Mirror Resync ................................................................................................................2-4 ASM Fast Mirror Resync: Overview ............................................................................................................2-5 Using EM to Perform Fast Mirror Resync ....................................................................................................2-6 Setting Up ASM Fast Mirror Resync ............................................................................................................2-8 ASM Preferred Mirror Read: Overview........................................................................................................2-10 ASM Preferred Mirror Read Setup................................................................................................................2-11 Enterprise Manager ASM Configuration Page..............................................................................................2-12 ASM Preferred Mirror Read: Best Practice...................................................................................................2-13 ASM Scalability and Performance Enhancements ........................................................................................2-14 ASM Scalability In Oracle Database 11g......................................................................................................2-16 SYSASM Role ..............................................................................................................................................2-17 Using EM to Manage ASM Users.................................................................................................................2-18 ASM Disk Group Compatibility ...................................................................................................................2-19 ASM Disk Group Attributes..........................................................................................................................2-21 Using EM to Edit Disk Group Attributes ......................................................................................................2-22 Enhanced Disk Group Checks.......................................................................................................................2-23 Restricted Mount Disk Group for Fast Rebalance.........................................................................................2-24 Mount Force Disk Group ..............................................................................................................................2-25 Forcing Disk Group Drop..............................................................................................................................2-27 ASMCMD Extensions...................................................................................................................................2-28 ASMCMD Extension: Examples ..................................................................................................................2-30 Summary .......................................................................................................................................................2-31

Realistic Testing: Using Database Replay .....................................................................................................3-2 Chapter 3Realistic Testing: Using Database Replay .....................................................................................3-2 Objectives......................................................................................................................................................3-3 Managing Change in Oracle Database 11g ...................................................................................................3-4 Managing Change Effectively.......................................................................................................................3-5 Why Use Database Replay? ..........................................................................................................................3-6 Database Replay............................................................................................................................................3-7 System Architecture: Capture .......................................................................................................................3-8 System Architecture: Processing the Workload ............................................................................................3-9 System Architecture: Replay.........................................................................................................................3-10 The Big Picture..............................................................................................................................................3-11


Oracle Database 11g: Server Manageability Table of Contents ii

Prechange Production System.......................................................................................................................3-12 Supported Workloads....................................................................................................................................3-13 Capture Considerations .................................................................................................................................3-14 Replay Considerations...................................................................................................................................3-15 Replay Analysis.............................................................................................................................................3-17 Replay Data Divergence................................................................................................................................3-18 Workload Capture Process ............................................................................................................................3-19 Using Enterprise Manager for Workload Capture.........................................................................................3-20 Workload Replay Process .............................................................................................................................3-24 Using Enterprise Manager for Workload Replay ..........................................................................................3-25 Database Replay: PL/SQL Example .............................................................................................................3-37 Calibrating Replay Clients ............................................................................................................................3-39 Packages and Procedures...............................................................................................................................3-40 Data Dictionary Views: Database Replay .....................................................................................................3-41 Summary .......................................................................................................................................................3-42

Using SQL Performance Analyzer.................................................................................................................4-2 Chapter 4Using SQL Performance Analyzer ................................................................................................4-2 Objectives......................................................................................................................................................4-3 SQL Performance Analyzer: Overview.........................................................................................................4-4 SQL Performance Analyzer: Use Cases........................................................................................................4-5 Capture SQL Workload.................................................................................................................................4-6 Transport to a Test System............................................................................................................................4-7 Build Before-Change Performance ...............................................................................................................4-8 Build After-Change Performance..................................................................................................................4-9 Compare and Analyze Performance..............................................................................................................4-10 SQL Performance Analyzer: Summary.........................................................................................................4-11 Enterprise Manager: Capturing the SQL Workload ......................................................................................4-13 Creating a SQL Tuning Set ...........................................................................................................................4-15 Exporting the SQL Workload........................................................................................................................4-16 Creating a SQL Performance Analyzer Task ................................................................................................4-17 Optimizer Upgrade Simulation .....................................................................................................................4-18 SQL Performance Analyzer: Task Page........................................................................................................4-19 Comparison Report .......................................................................................................................................4-20 Guided Workflow..........................................................................................................................................4-21 Viewing Analysis Results .............................................................................................................................4-22 Viewing Tuning Results................................................................................................................................4-23 SQL Performance Analyzer: PL/SQL Example............................................................................................4-24 SQL Performance Analyzer: Data Dictionary Views...................................................................................4-25 Summary .......................................................................................................................................................4-26

SQL Access Advisor Enhancements ..............................................................................................................5-2 Chapter 5SQL Access Advisor Enhancements .............................................................................................5-2 Objectives......................................................................................................................................................5-3 SQL Access Advisor: Overview ...................................................................................................................5-4 SQL Access Advisor: Usage Model..............................................................................................................5-5 Possible Recommendations...........................................................................................................................5-6 SQL Access Advisor Session: Initial Options...............................................................................................5-7 SQL Access Advisor: Workload Source .......................................................................................................5-9 SQL Access Advisor: Recommendation Options .........................................................................................5-10 SQL Access Advisor: Schedule and Review.................................................................................................5-12 SQL Access Advisor: Results .......................................................................................................................5-13 SQL Access Advisor: PL/SQL Procedure Flow............................................................................................5-18 SQL Access Advisor: PL/SQL Example.......................................................................................................5-19 Summary .......................................................................................................................................................5-20

Automatic Memory Management ..................................................................................................................6-2 Chapter 6 Automatic Memory Management ........................................................................................6-2 Objectives......................................................................................................................................................6-3 Oracle Database 10g SGA Parameters ..........................................................................................................6-4 Oracle Database 10g PGA Parameters ..........................................................................................................6-5 Oracle Database 10g Memory Advisors........................................................................................................6-7


Oracle Database 11g: Server Manageability Table of Contents iii

Automatic Memory Management Overview.................................................................................................6-9 Oracle Database 11g Memory Parameters ....................................................................................................6-11 Automatic Memory Parameter Dependency .................................................................................................6-12 Enabling Automatic Memory Management ..................................................................................................6-14 Monitoring Automatic Memory Management ..............................................................................................6-15 DBCA and Automatic Memory Management...............................................................................................6-17 Summary .......................................................................................................................................................6-18

Intelligent Infrastructure................................................................................................................................7-2 Chapter 7Intelligent Infrastructure ................................................................................................................7-2 Objectives......................................................................................................................................................7-3 Automatic Workload Repository Baselines ..................................................................................................7-4 Comparative Performance Analysis with AWR Baselines............................................................................7-5 Moving Window Baseline.............................................................................................................................7-6 Baselines in Performance Page Settings........................................................................................................7-7 Baseline Templates .......................................................................................................................................7-8 Creating AWR Baselines...............................................................................................................................7-9 Single AWR Baseline....................................................................................................................................7-10 Creating a Repeating Baseline Template......................................................................................................7-11 Generate a Baseline Template for a Single Time Period..............................................................................7-12 Creating a Repeating Baseline Template.......................................................................................................7-13 Changes to Procedures and Views ................................................................................................................7-14 Performance Monitoring and Baselines ........................................................................................................7-15 Defining Alert Thresholds Using Static Baseline..........................................................................................7-17 Using EM to Configure Adaptive Thresholds...............................................................................................7-18 Using EM to Quickly Configure Adaptive Thresholds .................................................................................7-19 Changing Adaptive Threshold Settings.........................................................................................................7-20 Automated Maintenance Tasks .....................................................................................................................7-21 Default Maintenance Plan .............................................................................................................................7-22 Automated Maintenance Task Priorities .......................................................................................................7-23 Controlling Automated Maintenance Tasks ..................................................................................................7-24 Important I/O Metrics for Oracle Databases .................................................................................................7-25 I/O Calibration and Enterprise Manager .......................................................................................................7-27 I/O Calibration and the PL/SQL Interface.....................................................................................................7-28 I/O Statistics: Overview ................................................................................................................................7-30 I/O Statistics and Enterprise Manager ...........................................................................................................7-31 ADDM Enhancements in Oracle Database 11g ............................................................................................7-33 Automatic Database Diagnostic Monitor (ADDM) in Oracle Database 10g ................................................7-34 Automatic Database Diagnostic Monitor for Oracle RAC...........................................................................7-35 ADDM for RAC............................................................................................................................................7-36 EM Support for ADDM for RAC..................................................................................................................7-38 DBMS_ADDM Package ...............................................................................................................................7-39 Advisor-Named Findings and Directives ......................................................................................................7-40 Using the DBMS_ADDM Package...............................................................................................................7-41 New ADDM Views.......................................................................................................................................7-42 Resource Manager: New EM Interface .........................................................................................................7-43 Resource Plans Created by Default ...............................................................................................................7-44 Default Plan...................................................................................................................................................7-45 I/O Resource Limit Thresholds .....................................................................................................................7-46 Resource Manager Statistics .........................................................................................................................7-47 New Scheduler Feature: Lightweight Jobs....................................................................................................7-48 Choosing the Right Job .................................................................................................................................7-49 Creating a Single Lightweight Job ................................................................................................................7-50 Creating an Array of Lightweight Jobs .........................................................................................................7-52 Viewing Lightweight Jobs in the Dictionary.................................................................................................7-55 Easier Recovery from Loss of SPFILE .........................................................................................................7-56 Summary .......................................................................................................................................................7-57

SQL Plan Management...................................................................................................................................8-2 Chapter 8SQL Plan Management..................................................................................................................8-2 Objectives......................................................................................................................................................8-3


Oracle Database 11g: Server Manageability Table of Contents iv

SQL Plan Management: Overview................................................................................................................8-4 SQL Plan Baseline Architecture....................................................................................................................8-5 Loading SQL Plan Baselines.........................................................................................................................8-7 Important SQL Plan Baseline Attributes .......................................................................................................8-8 SQL Plan Selection .......................................................................................................................................8-10 Possible SQL Plan Manageability Scenarios.................................................................................................8-12 SQL Performance Analyzer and SQL Plan Baseline Scenario.....................................................................8-13 Automatic SQL Plan: Baseline Scenario.......................................................................................................8-14 SQL Management Base: Purging Policy.......................................................................................................8-15 Summary .......................................................................................................................................................8-16


Automatic SQL Tuning Chapter 0 - Page 1

Automatic SQL Tuning



Chapter 1Automatic SQL Tuning

Automatic SQL Tuning



Objectives

Objectives

After completing this lesson, you should be able to :• Set up and modify Automatic SQL Tuning• Use the PL/SQL interface to perform fine tuning• View and interpret reports generated by Automatic S QL

Tuning



SQL Tuning in Oracle Database 10g

SQL Tuning in Oracle Database 10 g

SQL Tuning AdvisorHigh load

ADDM

Workload

DBA

Run SQL Tuning Advisor.

Accep

t pro

files.

GenerateSQL profiles.

Automatic

1

2

3

4

Oracle Database 10g introduced SQL Tuning Advisor to help database administrators and application developers improve the performance of SQL statements. The advisor targets the poorly written SQL, in which SQL statements have not been designed in the most efficient fashion. It also targets a SQL statement that is performing poorly (more common), because the optimizer generated a poor execution plan due to a lack of accurate and relevant data statistics. In all cases, the advisor makes specific suggestions for speeding up SQL performance, but it leaves the responsibility of implementing the recommendations to the user. In addition to SQL Tuning Advisor, Oracle Database 10g has an automated process to identify high-load SQL statements in your system. This is done by the Automatic Database Diagnostic Monitor (ADDM), which automatically identifies the high-load SQL statements that are good candidates for tuning. However, some issues still remained. Although ADDM identifies some SQL that should be tuned, you must manually examine the ADDM reports and run the SQL Tuning Advisor on those reports to perform the actual tuning.



Automatic SQL Tuning in Oracle Database 11g

Automatic SQL Tuning in Oracle Database 11 g

AWR

Auto matic

SQL Tuning

WorkloadReports

1

3

4

DBA

Top SQL

2

Oracle Database 11g further automates the SQL Tuning process by identifying problematic SQL statements, running SQL Tuning Advisor on them, and implementing the resulting SQL profile recommendations to tune the statement without requiring user intervention. Automatic SQL Tuning uses the AUTOTASK framework through a new task called “Automatic SQL Tuning” that runs every night by default. Here is a brief description of the automated SQL tuning process in Oracle Database 11g:

Step 1: Based on the Automatic Workload Repository (AWR) Top SQL identification (SQLs that topped in four different time periods: the past week, any day in the past week, any hour in the past week, or single response time), Automatic SQL Tuning identifies targets for automatic tuning. Steps 2 and 3: While the Automatic SQL Tuning task is executing during the maintenance window, the previously identified SQL statements are automatically tuned by invoking SQL Tuning Advisor. As a result, SQL profiles are created for them if needed. However, before making any decision, the new profile is carefully tested. Step 4: At any point in time, you can request a report about these automatic tuning activities. You can check the tuned SQL statements to validate or remove the automatic SQL profiles that were generated.



Summary of Automation in Oracle Database 11g

Summary of Automation in Oracle Database 11 g

• Task runs automatically (AUTOTASK framework).• Workload is automatically chosen (no SQL Tuning Set ).• SQL profiles are automatically tested and implement ed.• SQLs are automatically retuned if they regress.• Reporting is available over any time period.



Selecting Potential SQL Statements for Tuning

Selecting Potential SQL Statements for Tuning

AWRAvg executionHourly

1. Pull the top queries from the past week into four b uckets:� Top for the past week� Top for any day in the past week� Top in any single hour� Top by average single execution

2. Combine four buckets into one (assigning weights).3. Cap at 150 queries per bucket.

Candidate list

DailyWeekly

Oracle Database 11g analyzes the statistics in the AWR and generates a list of potential SQL statements that are eligible for tuning. These statements include repeating high-load statements that have a significant impact on the system. Only SQL statements that have an execution plan with a high potential for improvement are tuned. Recursive SQL and statements that have been tuned recently (in the last month) are ignored, as are parallel queries, data manipulation languages (DMLs), data definition languages (DDLs), and SQL statements with performance problems caused by concurrency issues. The SQL statements selected as candidates are then ordered based on their performance impact. The performance impact of a SQL statement is calculated by summing the CPU time and the I/O times captured in the AWR for that SQL statement in the past week.



Maintenance Window Timeline

Maintenance Window Timeline

Maintenancewindow

Pickcandidate

SQL

TuneS1

TestP1

AcceptP1

TuneS2

… …

Automatic SQL Tuning task

One hour maximum (by default)

The Automatic SQL Tuning process takes place during the maintenance window. Further, it runs as part of a single AUTOTASK job on a single instance to avoid concurrency issues. This is portrayed in the example above for one scenario. In this scenario, at some time after the beginning of the maintenance window, AUTOTASK starts the Automatic SQL Tuning job (SYS_AUTO_SQL_TUNING_TASK). The first thing that the job does is to generate a list of candidate SQL for tuning, according to the AWR source. When the list is complete, the job tunes each statement in order of importance, one after another, considering only one statement at a time. In this scenario, it first tunes S1, which has a SQL profile recommendation (P1) generated for it by SQL Tuning Advisor. After P1 has been successfully tested, it is accepted and the job moves on to the next statement, S2. By default, Automatic SQL Tuning runs for at most one hour during a maintenance window. You can change this setting by using a call similar to the following:

dbms_sqltune.set_tuning_task_parameter('SYS_AUTO_SQ L_TUNING_TASK', 'TIME_LIMIT', 7200);

Note: The widths of boxes above do not indicate relative execution times. Tuning and test execution should be the most expensive processes by far, with all the others completing relatively quickly.



Automatic Tuning Process

Automatic Tuning Process

Existingprofile?

Replace profile.

Y

N 3Xbenefit?

3Xbenefit?

Y

Accept profile.Y

Ignore new profile.N

N

New SQL profile

GATHER_STATS_JOB

Indexes

Not considered forauto implementation

Stalestats

RestructureSQL

Considered forauto implementation

With the list of candidate SQL built and ordered, the statements are then tuned using SQL Tuning Advisor. During the tuning process, all the recommendation types are considered and reported, but only SQL profiles can be implemented automatically (when the ACCEPT_SQL_PROFILES task parameter is set to TRUE). Otherwise, only the recommendation to create a SQL profile is reported in the automatic SQL tuning reports. In Oracle Database 11g, the performance improvement factor has to be at least three before a SQL profile is implemented. As mentioned earlier, the Automatic SQL Tuning process implements only SQL profile recommendations automatically. Other recommendations (to create new indexes, refresh stale statistics, or restructure SQL statements) are generated as part of the SQL tuning process but are not implemented. These are left for the DBA to review and implement manually, as appropriate. The following is a description of the general tuning process:

Tuning is performed on a per-statement basis. Because only SQL profiles are implemented, there is no need to consider the effect of recommendations on the workload as a whole. For each statement (in order of importance), the tuning process carries out the following steps:

1. Tunes the statement by using SQL Tuning Advisor. Looks for a SQL profile and, if it is found, verifies that the base optimizer statistics are current for it.

2. If a SQL profile is recommended, perform the following:

- Test the new SQL profile by executing the statement with and without the SQL profile.



- When a SQL profile is generated and it causes the optimizer to pick a different execution plan for the statement, the advisor must decide whether to implement the SQL profile. It makes its decision according to the flowchart shown the previous graphic. Although the benefit thresholds here apply to the sum of the CPU and I/O time, SQL profiles are not accepted when there is degradation in either statistic. So the requirement is that there is a three-times improvement in the sum of the CPU and I/O time, with neither statistic becoming worse. Thus, the statement runs faster than it would without the profile, even with contention in CPU or I/O.

3. If stale or missing statistics are found, make this information available to GATHER_STATS_JOB.

Automatic implementation of tuning recommendations is limited to SQL profiles, because they have fewer risks. It is easy for a database administrator (DBA) to revert the implementation. Note: All SQL profiles are created in the standard EXACT mode. They are matched and tracked according to the current value of the CURSOR_SHARING parameter. DBAs are responsible for setting CURSOR_SHARING appropriately for their workload.



DBA Controls

DBA Controls

• AUTOTASK configuration:– On/off switch– Maintenance windows running tuning task– CPU resource consumption of tuning task

• Task parameters:– SQL profile implementation automatic/manual switch– Global time limit for tuning task– Per-SQL time limit for tuning task– Test-execute mode disabled to save time– Maximum number of SQL profiles automatically

implemented per execution as well as overall– Task execution expiration period

The following is a PL/SQL control example for the Automatic SQL Tuning task: BEGIN dbms_sqltune.set_tuning_task_parameter('SYS_AUTO_SQ L_TUNING_TASK', 'LOCAL_TIME_LIMIT', 1400); dbms_sqltune.set_tuning_task_parameter('SYS_AUTO_SQ L_TUNING_TASK', 'ACCEPT_SQL_PROFILES', 'TRUE'); dbms_sqltune.set_tuning_task_parameter('SYS_AUTO_SQ L_TUNING_TASK', 'MAX_SQL_PROFILES_PER_EXEC', 50); dbms_sqltune.set_tuning_task_parameter('SYS_AUTO_SQ L_TUNING_TASK', 'MAX_AUTO_SQL_PROFILES', 10002); END; The last three parameters in this example are supported only for the Automatic SQL Tuning task. You can also use valid parameters, such as LOCAL_TIME_LIMIT , or TIME_LIMIT for the traditional SQL tuning tasks. One important example is to disable the test-execute mode (to save time) and to use only the execution plan costs to decide about the performance by using the TEST_EXECUTE parameter. In addition, you can control when the Automatic SQL Tuning task runs and the CPU resources it is allowed to use.



Automatic SQL Tuning Task

Automatic SQL Tuning Task

Automatic SQL Tuning is implemented as an automated maintenance task that is itself called Automatic SQL Tuning. You can see some high-level information about the last runs of the Automatic SQL Tuning task by navigating to the Automated Maintenance Tasks page:

• On the Database Control Home page, click the Server tab.

• On the Server page, click the Automated Maintenance Tasks link in the Tasks section.

• On the Automated Maintenance Tasks page, you see the predefined tasks. You can access each task by clicking the corresponding link to get more information about the task itself (illustrated above).

• When you click the Automatic SQL Tuning link or the latest execution icon (the green area on the timeline), the Automatic SQL Tuning Result Summary page appears.



Configuring Automatic SQL Tuning

Configuring Automatic SQL Tuning

You can configure various Automatic SQL Tuning parameters by using the Automatic SQL Tuning Settings page. To open that page, click the Configure button on the Automated Maintenance Tasks page. This takes you to the Automated Maintenance Tasks Configuration page, where you see the various maintenance windows delivered with Oracle Database 11g. By default, Automatic SQL Tuning executes on all predefined maintenance windows in the MAINTENANCE_WINDOW_GROUP. However, you can disable it for specific days in the week. On this page, you can also edit each window to change its characteristics. You can do so by clicking Edit Window Group. To get to the Automatic SQL Tuning Settings page, click the Configure button on the line corresponding to Automatic SQL Tuning in the Task Settings section. On the Automatic SQL Tuning Settings page, you can specify the parameters shown in the example above. By default, “Automatic Implementation of SQL Profiles” is deactivated. Note: If you set STATISTICS_LEVEL to BASIC, turn off the AWR snapshots by using DBMS_WORKLOAD_REPOSITORY, or if AWR retention is less than seven days, you also stop Automatic SQL Tuning.



Automatic SQL Tuning: Result Summary

Automatic SQL Tuning: Result Summary

In addition, the Automatic SQL Tuning Result Summary page contains various summary graphs so that you can control the Automatic SQL Tuning task. An example is given above. The first chart in the Overall Task Statistics section shows the breakdown by finding types for the designated period of time. You can control the period of time for which you want the report to be generated by selecting a value from the Time Period list. In the example, Customize is used; it shows you the latest run. You can choose All to cover all executions of the task so far. Users can request it for any time period over the past month, because that is the amount of time for which the advisor persists its tuning history. You then generate the report by clicking View Report. On the “Breakdown by Finding Type” chart, you can clearly see that only SQL profiles are implemented. Though many more profiles were recommended, not all were automatically implemented for the reasons already explained. Similarly, recommendations for index creation and other types are not implemented. However, the advisor keeps historical information about all the recommendations if you want to implement them later. In the Profile Effect Statistics section, you can see the Tuned SQL DB Time Benefit chart, which shows you the before-and-after DB Time for implemented profiles and other recommendations.



Automatic SQL Tuning: Result Details

Automatic SQL Tuning: Result Details

On the Automatic SQL Tuning Result Details page, you can also see a variety of important information for each automatically tuned SQL statement, including its SQL text and SQL ID, the type of recommendation that was done by SQL Tuning Advisor, the verified benefit percentage, whether a particular recommendation was automatically implemented, and the date of the recommendation. From this page, you can drill down to the SQL statement itself by clicking its corresponding SQL ID link, or you can select one SQL statement and click the View Recommendations button to have more details about the recommendation for that statement. Note: The benefit percentage shown for each recommendation is calculated using the bnf% = (time_old - time_new)/(time_old) formula. With this formula, you can see that a three-time benefit (for example, time_old = 100, time_new = 33) corresponds to 66%. So the system implements any profiles with benefits over 66%. According to this formula, 98% is a 50 times benefit.



Automatic SQL Tuning Result Details: Drilldown

Automatic SQL Tuning Result Details: Drilldown

On the “Recommendations for SQL ID” page, you can see the corresponding recommendations and implement them manually. By clicking the SQL Test link, you access the SQL Details page, where you see the tuning history and the plan control associated with your SQL statement. In the example above, you see that the statement was tuned by Automatic SQL Tuning and that the associated profile was automatically implemented.



Automatic SQL Tuning: Fine Tuning

Automatic SQL Tuning: Fine Tuning

• Use DBMS_SQLTUNE:– SET_TUNING_TASK_PARAMETER

– EXECUTE_TUNING_TASK

– REPORT_AUTO_TUNING_TASK

• Use DBMS_AUTO_TASK_ADMIN:– ENABLE

– DISABLE

• Dictionary views:– DBA_ADVISOR_EXECUTIONS

– DBA_ADVISOR_SQLSTATS

– DBA_ADVISOR_SQLPLANS

You can use the DBMS_SQLTUNE PL/SQL package to control various aspects of SYS_AUTO_SQL_TUNING_TASK.

1. SET_TUNING_TASK_PARAMETERS: The following parameters are supported only for the automatic tuning task:

– ACCEPT_SQL_PROFILES: TRUE/FALSE—whether the system should accept SQL profiles automatically

– REPLACE_USER_SQL_PROFILES: TRUE/FALSE—whether the task should replace SQL profiles created by the user

– MAX_SQL_PROFILES_PER_EXEC: Maximum number of SQL profiles to create for each run

– MAX_AUTO_SQL_PROFILES: Maximum number of automatic SQL profiles allowed on the system in total

– EXECUTION_DAYS_TO_EXPIRE: Specifies the number of days to save the task history in the advisor framework schema. By default, the task history is saved for 30 days before it expires.

2. EXECUTE_TUNING_TASK function: Used to manually run a new execution of the task in the foreground (runs in the same way as in the background)

3. REPORT_AUTO_TUNING_TASK: Get a text report covering a range of task executions



You can enable and disable SYS_AUTO_SQL_TUNING_TASK by using the DBMS_AUTO_TASK_ADMIN PL/SQL package.

You can also access Automatic SQL Tuning information through the dictionary views listed earlier:

• DBA_ADVISOR_EXECUTIONS: Get data about each execution of the task

• DBA_ADVISOR_SQLSTATS: See the test-execute statistics generated while testing the SQL profiles

• DBA_ADVISOR_SQLPLANS: See the plans encountered during test-execute



Using the PL/SQL Interface to Generate Reports

Using the PL/SQL Interface to Generate Reports

SQL> variable my_rept CLOB;SQL> BEGIN

2 :my_rept :=DBMS_SQLTUNE.REPORT_AUTO_TUNING_TASK (begin_exec=>NULL,3 end_exec=>NULL, type=>'TEXT', lev el=>'TYPICAL', section=>'ALL',4 object_id=>NULL, result_limit=>NU LL);

END;/…SQL> print :my_rept

MY_REPT--------------------------------------------------- -----------------------------GENERAL INFORMATION SECTIONTuning Task Name : SYS_AUTO_ SQL_TUNING_TASKTuning Task Owner : SYSWorkload Type : Automatic High-Load SQL WorkloadScope : COMPREHEN SIVEGlobal Time Limit(seconds) : 3600Per-SQL Time Limit(seconds) : 1200…Number of SQLs with Statistic Findings : 1Number of SQLs with SQL profiles recommended : 2Number of SQLs with SQL profiles implemented : 2Number of SQLs with Index Findings : 1Number of SQLs with Errors : 1…

The example above shows how to generate a text report to display all SQL statements that were analyzed in the most recent execution, including recommendations that were not implemented. You can view information about the automatic SQL tuning task in the following sections of the report:

• The general information section provides a high-level description of the automatic SQL tuning task, including information about the inputs given for the report, the number of SQL statements tuned during maintenance, and the number of SQL profiles created.

• The summary section lists the SQL statements (by their SQL identifiers) that were tuned during the maintenance window and the estimated benefit of each SQL profile, or their actual execution statistics after test-executing the SQL statement with the SQL profile.

• The Tuning findings section gives you all findings and statistics associated with each SQL statement, whether the profiles were accepted, and why.

• The Explain plans section shows the old and new explain plans used by each SQL statement analyzed by SQL Tuning Advisor.

• The Errors section lists all errors encountered by the Automatic SQL Tuning task.

Note: Obtain the execution list by using the following command: select execution_name,status,execution_start,execut ion_end

from dba_advisor_executions where task_name='SYS_AUTO_SQL_TUNING_TASK';



Automatic SQL Tuning Considerations

Automatic SQL Tuning Considerations

• SQL not considered for Automatic SQL Tuning:– Ad hoc or rarely repeated SQL– Parallel queries– Long-running queries after profiling– Recursive SQL statements– DML and DDL

• These statements can still be manually tuned by usi ng SQL Tuning Advisor.

Automatic SQL Tuning does not seek to resolve every SQL performance issue occurring in a system. It does not consider the following types of SQL.

• Ad hoc or rarely repeated SQL: If a SQL statement is not executed multiple times in the same form, the advisor ignores it. SQL statements that do not repeat within a week are also not considered.

• Parallel queries

• Long-running queries (post-profile): If a query takes too long to run after being SQL profiled, it is not practical to test-execute and, therefore, is ignored by the advisor. Note that this does not mean that the advisor ignores all long-running queries. If the advisor finds a SQL profile that causes a query that once took hours to run in minutes, it could be accepted because test-execution is still possible. The advisor executes the old plan just long enough to determine that it is worse than the new one, and then terminates test-execution without waiting for the old plan to finish, thereby switching the order of execution.

• Recursive SQL statements

• Data Manipulation Language, such as INSERT… SELECT statements, or data definition language, such as CREATE TABLE AS SELECT

With the exception of truly ad hoc SQL, these limitations apply only to Automatic SQL Tuning. Such statements can still be tuned by manually running SQL Tuning Advisor.



Summary

Summary

In this lesson, you should have learned how to:• Set up and modify Automatic SQL Tuning• Use the PL/SQL interface to perform fine tuning• View and interpret reports generated by Automatic

SQL Tuning




Automatic Storage Management Chapter 0 - Page 1

Automatic Storage Management



Chapter 2Automatic Storage Management

Automatic Storage Management



Objectives

Objectives

After completing this lesson, you should be able to :• Set up Automatic Storage Management (ASM) fast disk

resync• Use ASM preferred read failure groups• Set up ASM disk group attributes• Use the SYSASMrole• Use various manageability options for CHECK, MOUNT,

and DROPcommands• Use the mb_backup , md_restore , and repair ASMCMD

extensions

Note: In this lesson, the term ASM data extent is shortened to extent.



Without ASM Fast Mirror Resync

Without ASM Fast Mirror Resync

Disk access failure2

Disk added back:Extents rebalanced

4 Disk automatically dropped:All dropped extents re-created

3

ASM redundancy is used1

Prim

ary

exte

n t

Oracle Database 10 g&11g

Sec

onda

rye x

tent

Automatic Storage Management (ASM) offlines a disk whenever it is unable to complete a write to an extent allocated to the disk. At the same time, it writes at least one mirror copy of the same extent on another disk if the corresponding disk group uses ASM redundancy. With Oracle Database 10g, ASM assumes that an offline disk contains only stale data and, therefore, it does not read from such disks anymore. Shortly after a disk is offlined, ASM drops it from the disk group by re-creating the extents allocated to the disk on the remaining disks in the disk group using redundant extent copies. This process is a relatively costly operation, and may take hours to complete. If the disk failure is only a transient failure, such as failure of cables, host bus adapters, or controllers, or disk power supply interruptions, you have to add the disk back again after the transient failure is fixed. However, adding the dropped disk back to the disk group incurs an additional cost of migrating extents back onto the disk.



ASM Fast Mirror Resync: Overview

ASM Fast Mirror Resync: Overview

Disk access failure

Failure time < DISK_REPAIR_TIME

ASM redundancy used1 2

3

Oracle Database 11 g

Prim

ary

Se c

ond a

ry

Disk again accessible: Only need

to resync modified ASM data extent

4

Oracle Database 11g introduces the ASM Fast Mirror Resync feature to significantly reduce the time required to resynchronize a transient disk failure. When a disk goes offline following a transient failure, ASM tracks the ASM data extents that are modified during the outage. After the transient failure is repaired, ASM quickly resynchronizes only those extents that were affected during the outage. This feature assumes that the content of the affected ASM disks has not been damaged or modified. When an ASM disk path fails, the ASM disk is taken offline but not dropped if you have the DISK_REPAIR_TIME attribute set for the corresponding disk group. The setting for this attribute determines the duration of disk outage that ASM tolerates while still being able to resynchronize after you complete the repair. The DISK_REPAIR_TIME time elapses only when the disk group is mounted. Changing this value, however, does not affect the disks previously offlined. The default setting (3.6 hours) should be adequate for most environments. Note: The tracking mechanism uses one bit for each modified ASM data extent, ensuring that the tracking mechanism is highly efficient.



Using EM to Perform Fast Mirror Resync


When you take an ASM disk offline in Oracle Enterprise Manager (EM), you are asked to confirm the operation. On the Confirmation page, you can override the default disk repair time. Similarly, you can view by failure group and choose a particular failure group to go offline.





You can also bring disks online by using Enterprise Manager.



Setting Up ASM Fast Mirror Resync

Setting Up ASM Fast Mirror Resync

ALTER DISKGROUP dgroupA SET ATTRIBUTE 'DISK_REPAIR_ TIME'='3H';

ALTER DISKGROUP dgroupA

OFFLINE DISKS IN FALUREGROUP controller2 DROP AFTER 5H;

ALTER DISKGROUP dgroupA

ONLINE DISKS IN FALUREGROUP controller2 POWER 2 WAI T;

ALTER DISKGROUP dgroupA DROP DISKS IN FALUREGROUP c ontroller2 FORCE;

You set up this feature on a per disk group basis after disk group creation by using the ALTER DISKGROUP command. You use the following commands to enable ASM fast mirror resync:

ALTER DISKGROUP SET ATTRIBUTE DISK_REPAIR_TIME="2D4H30M"

After you repair the disk, run the ALTER DISK GROUP DISK ONLINE SQL statement. This statement brings a repaired disk group back online to enable writes so that no new writes are missed. This statement also starts a procedure to copy all extents that are marked as stale on their redundant copies. You cannot apply the ONLINE statement to already dropped disks. You can view the current attribute values by querying the V$ASM_ATTRIBUTE view. You can determine the time left before ASM drops an offlined disk by querying the REPAIR_TIMER column of either V$ASM_DISK or V$ASM_DISK_IOSTAT. In addition, a row corresponding to a disk resync operation appears in V$ASM_OPERATION with the OPERATION column set to SYNC.

You can also use the ALTER DISK GROUP DISK OFFLINE SQL statement to manually bring ASM disks offline for preventative maintenance. With this command, you can specify a timer to override the one defined at the disk group level. After you complete maintenance, use the ALTER DISK GROUP DISK ONLINE statement to bring the disk online. If you cannot repair a failure group that is in the offline state, you can use the ALTER DISKGROUP DROP DISKS IN FAILUREGROUP command with the FORCE option. This ensures that data originally stored on these disks is reconstructed from redundant copies of the data and stored on other disks in the same disk group.



Note: The time elapses only when the disk group is mounted. Also, changing the value of DISK_REPAIR_TIME does not affect disks previously offlined. The default setting of 3.6 hours for DISK_REPAIR_TIME should be adequate for most environments.



ASM Preferred Mirror Read: Overview

ASM Preferred Mirror Read: Overview

Site BSite A

P S

Site BSite A

P S

When you configure ASM failure groups, ASM in Oracle Database 10g always reads the primary copy of a mirrored extent. It may be more efficient for a node to read from a failure group extent that is closest to the node, even if it is a secondary extent. This is especially true in extended cluster configurations where reading from a local copy of an extent provides improved performance. With Oracle Database 11g, you do this by configuring the preferred mirror read using the new initialization parameter, ASM_PREFERRED_READ_FAILURE_GROUPS, to specify a list of preferred mirror read names. The disks in those failure groups become the preferred read disks. Thus, every node can read from its local disks. This results in greater efficiency and performance and reduced network traffic. The setting for this parameter is instance specific.



ASM Preferred Mirror Read Setup

Setup

ASM Preferred Mirror Read Setup

ASM_PREFERRED_READ_FAILURE_GROUPS=DATA.SITEA

ASM_PREFERRED_READ_FAILURE_GROUPS=DATA.SITEB

On first instance

On second instance

SELECT preferred_read FROM v$asm_disk;

SELECT * FROM v$asm_disk_iostat;

Monitor

You configure this feature by setting the ASM_PREFERRED_READ_FAILURE_GROUPS initialization parameter. This is a multivalued parameter and should contain a comma-delimited string of failure group names. The failure group names specified should be prefixed with its disk group name and a “.” character. The ASM_PREFERRED_READ_FAILURE_GROUPS parameter is dynamic and can be modified using the ALTER SYSTEM command at any time. The ASM_PREFERRED_READ_FAILURE_GROUPS parameter is valid only for ASM instances. When nodes are spread across several sites (an extended cluster), the failure groups specified in this parameter should contain only the disks that are local to the corresponding instance. A new column, PREFERRED_READ, has been added to the V$ASM_DISK view. If the disk group pertains to a preferred read failure group, the value of this column is Y. You can use the V$ASM_DISK_IOSTAT view to identify any performance issues with ASM preferred read failure groups. The V$ASM_DISK_IOSTAT view displays disk input/output (I/O) statistics for each ASM client. If this view is queried from a database instance, only the rows for this instance are shown.



Enterprise Manager ASM Configuration Page

Enterprise Manager ASM Configuration Page

You can specify a set of disks as preferred disks for each ASM instance by using Enterprise Manager. The preferred read attributes are instance specific. In Oracle Database 11g, the Preferred Read Failure Groups field (asm_preferred_read_failure_group ) is added to the EM Configuration page. This setting takes effect only before the disk group is mounted or when the disk group is created and applies only to newly opened files or to a newly loaded ASM data extent map for a file.



ASM Preferred Mirror Read: Best Practice

ASM Preferred Mirror Read: Best Practice

Two sites / Normal redundancy

Only two failure groups: one for each instance

Two sites / High redundancy

Max four failure groups: two for each instance

P S P S S PSS

Three sites / High redundancy

Only three failure groups: one for each instance

P S S

In practice, there are only a limited number of good disk group configurations in an extended cluster. A good configuration takes into account both performance and availability of a disk group in an extended cluster. Here are some possible examples:

For a two-site extended cluster, a normal redundancy disk group should have only two failure groups and all disks local to one site should belong to the same failure group. Also, at most one failure group should be specified as a preferred read failure group by each instance. If there are more than two failure groups, ASM may not mirror a virtual extent across both sites. Furthermore, if the site with more than two failure groups were to go down, it would take the disk group down as well. If the disk group to be created is a high redundancy disk group, at most two failure groups should be created on each site with its local disks, having both local failure groups specified as preferred read failure groups for the local instance. For a three-site extended cluster, a high redundancy disk group with three failure groups must be used. This is for ASM to guarantee that each virtual extent has a mirror copy local to each site, and the disk group is protected against a catastrophic disaster on any of the three sites.



ASM Scalability and Performance Enhancements

ASM Scalability and Performance Enhancements

• The ASM Data Extent size grows automatically according to file size.

• ASM supports variable extents size to:– Raise maximum possible file size– Reduce memory utilization in shared pool

• There are no administration needs other than manual rebalance in case of important fragmentation.

In Oracle Database 11g, ASM supports variable sizes for ASM data extents of 1, 8, and 64 allocation units (AU). This is an automated feature that enables ASM to support larger sized ASM data extents while improving memory usage efficiency. ASM uses a predetermined number of ASM data extents of each size. When a file crosses a certain threshold, the next ASM data extent size is used. An ASM file can begin with 1 AU; as the file’s size increases, the ASM data extent size also increases to 8 or 64 AUs based on predefined file size thresholds. As fewer ASM data extent pointers are needed to describe the files, less memory is required to manage the ASM data extent maps in the shared pool, which would have been prohibitive in large file configurations. The ASM data extent size can vary across files and within files. Use of variable-size ASM data extents enables you to deploy Oracle databases by using ASM that are several hundred terabytes (TB), even several petabytes (PB) in size. The management of variable-size ASM data extents is completely automated. As ASM data extent sizes grow and smaller noncontiguous ASM data extents are freed, any rebalance operation also performs a defragmentation operation. ASM also automatically defragments during allocation if the desired size is unavailable, thereby potentially affecting allocation times but offering much faster file opens, given the reduction in memory required to store file ASM data extents.

However, external fragmentation may occur when a large number of noncontiguous small data extents have been allocated and freed, and no additional contiguous large extents are available. A defragmentation operation is integrated as a part of any rebalance operation. So, as a DBA, you can defragment your disk group by executing a rebalance operation.



Nevertheless, this should happen only rarely, because ASM also automatically performs defragmentation during extents allocation if the desired size is unavailable. This can potentially render some allocation operations longer. Note: This feature also enables much faster file opens, because of the significant reduction in the amount of memory that is required to store file extents.



ASM Scalability In Oracle Database 11g

ASM Scalability In Oracle Database 11 g

ASM imposes the following limits:• 63 disk groups• 10,000 ASM disks• 4 petabyte per ASM disk• 40 exabyte of storage• 1 million files per disk group• Maximum file size:

– External redundancy: 140 PB– Normal redundancy: 42 PB– High redundancy: 15 PB

ASM imposes the following limits:

• 63 disk groups in a storage system

• 10,000 ASM disks in a storage system

• 4 petabyte maximum storage for each ASM disk

• 40 exabyte maximum storage for each storage system

• 1 million files for each disk group

• Maximum file sizes depending on the redundancy type of the disk groups used: 140 PB for external redundancy (value currently greater than possible database file size), 42 PB for normal redundancy, and 15 PB for high redundancy.

Note: In Oracle Database 10g, maximum ASM file size for external redundancy was 35 TB.



SYSASM Role

SYSASMRole

• You can use the SYSASMrole to manage ASM instances and avoid overlap between DBAs and storage administrators.

• SYSDBA will be deprecated:– Oracle Database 11 g, Release 1 behaves as in 10 g.– In future releases SYSDBA privileges are restricted in

ASM instances.

SQL> CONNECT / AS SYSASM

SQL> CREATE USER username IDENTIFIED by passwd;

SQL> GRANT SYSASM TO username;

SQL> DROP USER username;

SQL> CONNECT username / passwd AS SYSASM;

This feature introduces a new SYSASM role that is specifically intended for performing ASM administration tasks. Using the SYSASM role instead of the SYSDBA role improves security by separating ASM administration from database administration. As of Oracle Database 11g, Release 1, the OS group for SYSASM and SYSDBA is the same, and the default installation group for SYSASM is dba . In a future release, separate groups will have to be created, and SYSDBA users will be restricted in ASM instances. As a member of the dba group, you can currently connect to an ASM instance by using the first statement shown above. You can use the combination of CREATE USER and GRANT SYSASM SQL statements from an ASM instance to create a SYSASM user. This is useful for remote ASM administration. These commands update the password file of each ASM instance, and do not need the instance to be running. Similarly, you can revoke the SYSASM privilege from a user by using the REVOKE command, and you can drop a user from the password file using the DROP USER command. Note: With Oracle Database 11g, Release 1, if you log in to an ASM instance as SYSDBA, warnings are written in the corresponding alert.log file.



Using EM to Manage ASM Users

Using EM to Manage ASM Users

Oracle Enterprise Manager 11g enables you to manage users who access the ASM instance through remote connection (using password file authentication). These users are used exclusively for the ASM instance. However, you have this functionality only when connected as the SYSASM user. It is hidden when you connect as the SYSDBA or SYSOPER user. When you click the Create button, the Create User page is displayed. When you click the Edit button, the Edit User page is displayed. By clicking the Delete button, you can delete the created users. Note: Oracle Database 11g adds the SYSASM role to the ASM instance login page.



ASM Disk Group Compatibility

ASM Disk Group Compatibility

• Compatibility of each disk group can be controlled separately:– ASM compatibility controls ASM metadata on disk

structure.– RDBMS compatibility controls minimum client level.– This feature is useful with heterogeneous environme nts.

• Setting disk group compatibility is irreversible.

DB instance

COMPATIBLE.RDBMSCOMPATIBLE

ASM DiskGroup

>=<=

COMPATIBLE.ASM

ASM instance

<= COMPATIBLE

There are two kinds of compatibility applicable to ASM disk groups:

• ASM compatibility: Dealing with the persistent data structures that describe a disk group

• RDBMS compatibility: Dealing with the capabilities of the clients (consumers of disk groups)

The compatibility of each disk group is independently controllable. This is required to enable heterogeneous environments with disk groups from both Oracle Database 10g and Oracle Database 11g. These two compatibility settings are attributes of each ASM disk group:

• RDBMS compatibility refers to the minimum compatible version of the RDBMS instance that would allow the instance to mount the disk group. This compatibility dictates the format of messages that are exchanged between the ASM and database (RDBMS) instances. An ASM instance has the capability to support different RDBMS clients running at different compatibility settings. The database COMPATIBLE version setting of each instance must be greater than or equal to the COMPATIBLE.RDBMS version of all disk groups used by that database. Database instances are typically run from a different Oracle home than the ASM instance. This implies that the database instance may be running a different software version than the ASM instance. When a database instance first connects to an ASM instance, it negotiates the highest version that they both can support. The compatibility parameter setting of the database, software version of the database, and the RDBMS compatibility setting of a disk group determine whether a database instance can mount a given disk group.



• ASM compatibility refers to the persistent compatibility setting controlling the format of data structures for ASM metadata on disk. The ASM compatibility level of a disk group must always be greater than or equal to the RDBMS compatibility level of the same disk group. ASM compatibility is only concerned with the format of the ASM metadata. The format of the file contents is up to the database instance. For example, the ASM compatibility of a disk group can be set to 11.0 while its RDBMS compatibility could be 10.1. This implies that a disk group can be managed only by the ASM software whose software version is 11.0 or higher while any database client whose software version is higher than or equal to 10.1 can use that disk group.

The compatibility of a disk group needs to be advanced only when there is a change to either persistent disk structures or protocol messaging. However, advancing disk group compatibility is an irreversible operation. You can set the disk group compatibility by using either the CREATE DISKGROUP or ALTER DISKGROUP commands. Note: In addition to disk group compatibilities, the compatible parameter (database compatible version) determines the features that are enabled; it applies to the database or ASM instance depending on the instance_type parameter. For example, setting it to 10.1 would preclude use of any new features introduced in Oracle Database 11g (disk online/offline, variable extents, for example).



ASM Disk Group Attributes

ASM Disk Group Attributes

Striping attribute of specified templateCOARSE|FINEAtemplate. tname.stripe

Redundancy of specified templateUNPROTECT|MIRROR|HIGHAtemplate. tname.redundancy

Length of time before removing a disk when offline

0 M to 2 32 D ACdisk_repair_time

Format of ASM metadata structures on diskValid ASM instance version

ACcompatible.asm

Format of messages exchanged between DB and ASM

Valid database versionACcompatible.rdbms

Size of allocation units in the disk group1|2|4|8|16 |32 |64MBCau_size

DescriptionValuesPropertyName

CREATE DISKGROUP DATA NORMAL REDUNDANCY

DISK '/dev/raw/raw1','/dev/raw/raw2'

ATTRIBUTE 'compatible.asm'='11.1';

A: ALTERcommand C: CREATEcommand

You can change an ASM disk group’s attributes by using the new ATTRIBUTE clause of the CREATE DISKGROUP and ALTER DISKGROUP commands.

• ASM enables the use of different AU sizes that you specify when you create a disk group. The AU size can be 1 MB, 2 MB, 4 MB, 8 MB, 16 MB, 32 MB, or 64 MB.

• RDBMS compatibility: See the slide titled “ASM Disk Group Compatibility” for more information.

• ASM compatibility: See the slide titled “ASM Disk Group Compatibility” for more information.

• You can specify the DISK_REPAIR_TIME in units of minutes (M), hours (H), or days (D). If you omit the unit, the default is H. If you omit this attribute, then the default is 3.6H. You can override this attribute with an ALTER DISKGROUP statement.

• You can specify the redundancy attribute of the specified template.

• You can specify the striping attribute of the specified template.

For each defined disk group, you can look at all the defined attributes by using the V$ASM_ATTRIBUTE fixed view. Note: For pre-11g ASM instances, the default ASM compatibility and client compatibility is 10.1. For 11g ASM instances, the default ASM compatibility is 11.1 and database compatibility is 10.1.



Using EM to Edit Disk Group Attributes

Using EM to Edit Disk Group Attributes

EM provides a simple way to store and retrieve environment settings related to disk groups. You can now set the compatible attributes from both the Create Disk Group page and the Edit Advanced Attributes for Disk Group page. The disk_repair_time attribute is added only to the Edit Advanced Attributes for Disk Group page. Note: For 11g ASM instances, the default ASM and database compatibility values are 10.1.



Enhanced Disk Group Checks

Enhanced Disk Group Checks

• Disk group check syntax is simplified.– FILE and DISK options do the same as ALL.

• Additional checks performed:– Alias– Directories

ALTER DISKGROUP DATA CHECK;

The CHECK disk group command is simplified to check all the metadata directories by default. You can verify the internal consistency of the ASM disk group metadata using CHECK command. ASM displays summary errors and writes the details of the detected errors in the alert log. In earlier releases, you could specify this clause for ALL, DISK, DISKS IN FAILGROUP, and FILE . Those clauses have been deprecated because they are no longer needed. In the current release, the CHECK keyword performs the following operations:

• Checks the consistency of the disk (equivalent to CHECK DISK and CHECK DISK IN FAILGROUP in previous releases)

• Crosschecks all the file extent maps and allocation tables for consistency (equivalent to CHECK FILE in previous releases)

• Checks that the alias metadata directory and the file directory are linked correctly

• Checks that the alias directory tree is linked correctly

• Checks that ASM metadata directories do not have unreachable allocated blocks

You can tell the ASM whether or not to attempt to repair the errors found during consistency check using the REPAIR | NOREPAIR clause. The default is REPAIR. The NOREPAIR setting is useful when you want to be alerted to any inconsistencies but do not want ASM to take any automatic action to resolve them. Note: Introducing extra checks as part of check disk group slows down the entire check disk group operation.



Restricted Mount Disk Group for Fast Rebalance

Restricted Mount Disk Group for Fast Rebalance

• A disk group can be mounted only on a single instan ce.• No database client or other ASM instance can obtain

access.• Rebalance can proceed without locking overhead.

ALTER DISKGROUP data DISMOUNT;

ALTER DISKGROUP data MOUNT RESTRICT;

ALTER DISKGROUP data DISMOUNT;

ALTER DISKGROUP data MOUNT;

1

2

4

5

3 Maintenance task: Add/Remove disks …

A new mount mode to mount a disk group in Oracle Database 11g is called RESTRICTED. When a disk group is mounted in RESTRICTED mode, clients cannot access the files in a disk group. When ASM instance knows that there are no clients, it improves the performance of the rebalance operation by not attempting to message clients for locking/unlocking extent maps. A disk group mounted in RESTRICTED mode is mounted exclusively on only one node and clients of ASM on that node cannot use that disk group. The RESTRICTED mode allows you to perform all maintenance tasks on a disk group in the ASM instance without any external interaction. At the end of the maintenance cycle you have to explicitly dismount the disk group and remount it in the normal mode. The ALTER DISKROUP diskgroupname MOUNT command is extended to allow ASM to mount the diskgroup in RESTRICTED mode. An example is shown above. When you use the RESTRICTED option to start an ASM instance, all the disk groups defined in the ASM_DISKGROUPS parameter are mounted in the RESTRICTED mode. Note: The restricted mode is not allowed if the cluster is in rolling migration.



Mount Force Disk Group

Mount Force Disk Group

• By default, MOUNTis NOFORCE:– All disks must be available.

• MOUNT FORCE:– Offlines unavailable disks if quorum exists– Fails if all disks are available

ALTER DISKGROUP data MOUNT [ FORCE| NOFORCE];

This feature alters the behavior of ASM when mounting an incomplete disk group. With Oracle Database 10g, as long as there are enough failure groups to mount a disk group, the mount operation succeeds, even when there are missing or damaged failure groups. This behavior has the potential to automatically drop ASM disks, requiring their addition again later after repair, and thus incurring a long rebalance operation. With Oracle Database 11g, such an operation fails unless you specify the new FORCE option when mounting the damaged disk group. This allows you to correct configuration errors (such as ASM_DISKSTRING set incorrectly) or connectivity issues before trying the mount again. However, disk groups mounted with the FORCE option could potentially have one or more disks offline if they were not available at the time of mount. You must take corrective action before DISK_REPAIR_TIME expires to restore these devices. Failing to bring these devices online results in the disks being expelled from the disk group and costly rebalancing being required to restore redundancy for all the files in the disk group. Also, if one or more devices are offlined as a result of MOUNT FORCE, some or all files will not be properly protected until the redundancy is restored in the disk group via rebalance. Therefore, MOUNT with FORCE is useful when you know that some of the disks belonging to a disk group are unavailable. The disk group mount succeeds if ASM finds enough disks to form a quorum.

Mount with NOFORCE is the default option of mount when none is specified. In the NOFORCE mode, all disks that belong to a disk group must be accessible for the mount to succeed.



Note: Specifying the FORCE option when it is not necessary results in an error. There is one special case in a cluster: if an ASM instance is not the first to mount the disk group, then MOUNT FORCE fails with an error if disks are determined to be inaccessible locally but accessible by another instance.



Forcing Disk Group Drop

Forcing Disk Group Drop

• Allows users to drop disk groups that cannot be mounted

• Fails if disk group is mounted anywhere

DROP DISKGROUP data FORCE INCLUDING CONTENTS;

The DROP DISK GROUP… FORCE command marks the headers of disks belonging to a disk group that cannot be mounted by the ASM instance as FORMER. However, the ASM instance first determines whether the disk group is being used by another ASM instance using the same storage subsystem. If it is being used, and if the disk group is in the same cluster or on the same node, the statement fails. If the disk group is in a different cluster, the system checks further to determine whether the disk group is mounted by an instance in the other cluster. If the disk group is mounted elsewhere, the statement fails. However, this latter check is not as definitive as the checks for disk groups in the same cluster. You should, therefore, use this clause with caution. Note: When executing the DROP DISKGROUP command with the FORCE option, you must also specify the INCLUDING CONTENTS clause.



ASMCMD Extensions

ASMCMDExtensions

$ asmcmd help

md_backup

md_restorecp

lsdsk

full

nodg

newdg

User-created directoriesTemplatesDisk group compatibilityDisk group nameDisk names and failure groups

ASMCMD is extended to include ASM metadata backup and to restore functionality. This provides the ability to re-create an existing ASM disk group with the exact template and alias directory structure. Currently, if an ASM disk group is lost, it is possible to restore the lost files by using Recovery Manager (RMAN)—but you must manually re-create the ASM disk group and any required user directories or templates. ASM metadata backup and restore (AMBR) works in two modes:

• In backup mode, AMBR parses ASM-fixed tables and views to gather information about existing disks and failure group configurations, templates, and alias directory structures. It then dumps this metadata information to a text file.

• In restore mode, AMBR reads the previously generated file to reconstruct the disk group and its metadata. You have the ability to control AMBR behavior in restore mode to do a full , nodg , or newdg restore. The difference among the three submodes is in whether you want to include the disk group creation and change its characteristics.

The lsdsk command lists ASM disk information. This command can run in two modes:

• In connected mode, ASMCMD uses the V$ and GV$ views to retrieve disk information.

• In nonconnected mode, ASMCMD scans disk headers to retrieve disk information, using an ASM disk string to restrict the discovery set. The connected mode is always attempted first.

The cp command enables you to copy files between ASM disk groups on local instances and remote instances. Here is a possible usage example: cp +DATA/ORCL/DATAFILE/TBSJFV.256.629730771 +DATA/O RCL/tbsjfv.bak



In the above example, you copy an existing file locally. However, you can specify a connect string to copy the file to a remote ASM disk group. The format of copied files is portable between Little-Endian and Big-Endian systems. You can also use the cp command to copy an ASM file to your operating system:

cp +DATA/ORCL/DATAFILE/TBSJFV.256.629730771 /home/oracle/tbsjfv.dbf

Similarly, you can use the cp command to copy a file from your operating system to an ASM directory:

cp /home/oracle/tbsjfv.dbf +data/jfv

If you want to copy an ASM file from your local ASM instance to a remote ASM instance, you could use the following syntax:

cp +DATA/orcl/datafile/tbsjfv.256.629989893 \sys@edcdr12p1.+ASM2:+D2/jfv/tbsjfv.dbf

Note: For more information about the syntax for each of these commands, see the Oracle Database Storage Administrator’s Guide.



ASMCMD Extension: Examples

ASMCMDExtension: Examples

ASMCMD> md_backup –b jfv_backup_file -g data

Disk group to be backed up: DATA#

Current alias directory path: jfv

ASMCMD>

ASMCMD> md_restore -b jfv_backup_file -t full -g da ta

Disk group to be restored: DATA#

ASMCMDAMBR-09358, Option -t newdg specified without any override options.

Current Diskgroup being restored: DATA

Diskgroup DATA created!

User Alias directory +DATA/jfv

created!

ASMCMD>

Unintentional disk group drop

Restore disk group files using RMAN

1

2

4

3

This example describes how to backup ASM metadata using the md_backup command, and how to restore them using the md_restore command. The first statement specifies the –b option and the –g option of the command. This is to define the name of the generated file containing the backup information, the disk group that must be backed up: jfv_backup_file , and the data respectively in the above example. In step two, it is assumed that there is a problem on the DATA disk group, and as a result it gets dropped. But before you restore the database files it contained, you have to restore the disk group itself. In step three, you initiate the disk group re-creation and restoring of its metadata by using the md_restore command. Here, you specify the name of the backup file generated in step one, the name of the disk group you want to restore, and also the type of restore you want to perform. Here a full restore of the disk group is done, because it no longer exists. After the disk group is re-created, you can restore its database files using RMAN, for example.



Summary

Summary

In this lesson, you should have learned how to:• Set up ASM fast disk resync• Use ASM preferred read failure groups• Set up ASM disk group attributes• Use SYSASMrole• Use various manageability options for CHECK, MOUNT,

and DROPcommands• Use the mb_backup , md_restore , and repair ASMCMD

extensions




Realistic Testing: Using Database Replay Chapter 0 - Page 1

Realistic Testing: Using Database Replay



Chapter 3Realistic Testing: Using Database Replay

Realistic Testing: Using Database Replay



Objectives

Objectives

After completing this lesson, you should be able to :• Identify the benefits of using Database Replay• List the steps involved in Database Replay• Use Enterprise Manager to record and replay

workloads



Managing Change in Oracle Database 11g

Managing Change in Oracle Database 11 g

Oracle Database 11 g dramatically reduces the cost of system changes by providing:• Database Replay:

– Captures actual database workload on the production system

– Replays the captured workload (with the same concurrency) on a test system

– Identifies performance changes and errors

• SQL Performance Analyzer:– Identifies SQL regressions and fixes them

Database Replay enables you to test the impact of a system change by replaying real-world workload on the test system before it is exposed to a production system. The production workload (including transaction concurrency and dependency) of the database server is recorded over an illustrative period of time (for example, a peak period). This recorded data is used to replay the workload on a test system that has been appropriately configured. You gain a high degree of confidence in the overall success of the database change by subjecting the database server in a test system to a workload that is practically indistinguishable from a production workload. SQL Performance Analyzer makes quantitative estimates of the system’s performance in the new environment and makes suggestions for avoiding potential SQL performance degradation.



Managing Change Effectively

Managing Change Effectively

• Confidence in the success of a system change in minimizing system disruption

• Ease of upgrade to a different RDBMS release or ser ver configuration

• Capacity planning• Recording and replaying of sessions when debugging

issues• Development of autonomic features on real-life

workloads• Prevention of degradations that are potentially cau sed

by a change in the production environment

By using the Oracle Database 11g functionality, your business can be confident in the success of its change-management goals. The record and replay functionality offers confidence in the ease of upgrade during a database server upgrade. A useful application of Database Replay is to test the performance of a new server configuration. Consider a customer who is using a single instance database and wants to move to a Real Application Clusters (RAC) setup. The customer records the workload of an interesting period and then sets up a RAC test system for replay. During replay, the customer is able to monitor the performance benefit of the new configuration by comparing the performance to the recorded system. This can also help convince customers to move to a RAC configuration after being shown the benefits of using the database replay functionality. Another application is debugging. You can record and replay sessions emulating an environment to make bugs more reproducible. Manageability feature testing is another benefit. Self-managing and self-healing systems must implement this advice automatically. Multiple replay iterations allow testing and fine-tuning of the control strategies’ effectiveness and stability.



Why Use Database Replay?

Why Use Database Replay?

• System changes, such as hardware and software upgrades, occur often.

• Customers want to identify the full impact of a cha nge before going live.

• Extensive testing and validation can be expensive i n terms of time and money.

• Despite expensive testing, success rates can be low :– Many issues may go undetected.– Changes can impact system availability and performa nce

negatively.

Database Replay makes it possible to test with real-world production workloads.

Large business-critical applications are complex and experience highly varying load and usage patterns. At the same time, these business systems are expected to provide certain service-level guarantees in terms of response time, throughput, up time, and availability. Any change to a system, such as upgrading the database or modifying the configuration, often necessitates extensive testing and validation before the changes can make it to the production system. To be confident before moving to a production system, the DBA must expose a test system to a workload very similar to the workload to be experienced in a production environment. It is also beneficial for the DBA to have an effective means of analyzing the impact of system-level changes on the overall SQL performance so that any tuning changes required can be performed before production.



Database Replay

Database Replay

• Re-create the actual production database workload i n a test environment.

• Identify, analyze, and fix potential instabilities before makingchanges to the production.

• Capture the workload in production:– Capture full production workload with real load and concurrency.– Move the captured workload to the test system.

• Replay the workload in test:– Make the desired changes in the test system.– Replay the workload with the production load and co ncurrency.– Honor commit ordering.

• Analyze and report:– Errors– Data divergence – Performance divergence

Oracle Database 11g provides specific solutions to the challenges of managing change.



System Architecture: Capture

System Architecture: Capture

Database stack

Productiondatabase

Databasebackup

Capture directory

Recording infrastructure

Shadow Shadow Shadow ShadowShadow capture file

Shadow capture file

Shadow capture file

Shadow capture fileBackground Background

In the example above, you see an illustration of a system that is being recorded. You should always record a workload that spans an “interesting” period in a production system. Typically, the replay of the recording is used to determine whether it is safe to upgrade to a new version of the RDBMS server. During recording, a special recording infrastructure built into the RDBMS records data about all external client requests while the production workload is running on the system. External requests are any SQL queries, PL/SQL blocks, PL/SQL remote procedure calls, data manipulation language (DML) statements, data definition language (DDL) statements, Object Navigation requests, or Oracle Call Interface (OCI) calls. Background jobs and, in general, all internal clients continue their work during the recording without being recorded. The end product is the workload recording that contains all necessary information for replaying the workload as seen by the RDBMS in the form of external requests. The recording infrastructure imposes minimal performance overhead (extra CPU, memory, and I/O) on the recording system. You should, however, plan to accommodate the additional disk space that is needed for the actual workload recording. RAC Note: Instances in a RAC environment have access to common database files. However, they do not need to share a common general-purpose file system. In such an environment, the workload recording is written on each instance’s file system during recording. For processing and replay, all parts of the workload recording must be manually copied into a single directory.



System Architecture: Processing the Workload

System Architecture: Processing the Workload

Database stack

Productiondatabase

Databasebackup

Capture directory

Shadow capture file

Shadow capture file

Shadow capture file

Shadow capture filePro

cess

cap

ture

file

s

Background Background

Processcapture

The workload capture data is processed, and new workload replay–specific metadata files are created that are required to replay the given workload capture. Only new files are created; no files are modified that were created during the workload capture. Because of this, you can run the preprocess multiple times on the same capture directory (for example, when the procedure encounters unexpected errors or is canceled). External client connections are remapped at this stage, and replay parameters that affect the replay outcome can be modified. Note: Because processing a workload capture can be relatively expensive, the best practice is to carry out this operation on a system other than the production database system.



System Architecture: Replay

System Architecture: Replay

Database stack

Testdatabase

Databasebackup

Capture directory

Shadow capture file

Shadow capture file

Shadow capture file

Shadow capture filePro

cess

cap

ture

file

s

Replayclient

Replayclient

Shadow … ShadowShadow … Shadow

Background Background

Test systemwith changes.

Replaysystem

Before replaying the workload on the replay system, be sure to perform the following:

1. Restore the replay database on a test system to match the capture database at the start of the workload capture.

2. Make changes (such as performing an upgrade) to the test system as needed.

3. Copy the workload to the test system.

The workload recording is consumed by a special application called the replay driver, which sends requests to the RDBMS on which the workload is replayed; this RDBMS is usually a test system. It is assumed that the database of the replay system is suitable for the replay of the workload that was recorded. The internal RDBMS clients are not replayed. The replay driver is a special client that consumes the workload recording and sends appropriate requests to the test system to make it behave as though the external requests were sent by the clients used during the recording of the workload (see previous example). The use of a special driver that acts as the sole external client to the RDBMS enables the recording and replay infrastructure to be client agnostic. The replay driver consists of one or more clients that connect to the replay system and that send requests based on the workload capture. The replay driver distributes the workload capture streams equally among all the replay clients based on the network bandwidth, CPU, and memory capability.



The Big Picture

The Big Picture

Productiondatabase

Databasebackup

Capture directory

Shadow capture file

Shadow capture file

Shadow capture file

Shadow capture file

Pro

cess

cap

ture

file

s.

Databaserestore

Prechange production system Postchange test system

Replaysystem

Can use snapshot standby as test system

Testsystem

withchanges.

Productionsystem

Clients/application servers

The significant benefit with Oracle Database 11g is the added confidence to the business in the success of performing a change. Many Oracle customers have expressed interest in this change-management functionality. The database administrator, or a user with special privileges granted by the DBA, initiates the record and replay cycle, and has full control over the entire procedure.



Prechange Production System

Prechange Production System

Supported changes:• Database upgrades, patches• Schema, parameters• RAC nodes, interconnect• OS platforms, OS upgrades• CPU, memory• Storage

Changes not supported

Productionsystem

Clients/application servers

Productiondatabase

Database Replay focuses on recording and replaying workload that is directed to the RDBMS only. Recording at the RDBMS in the software stack makes it possible to exchange anything below this level and test the new setup using the record and replay functionality. While replaying the workload, the RDBMS performs the actions observed during recording. That is, during the replay phase, the RDBMS code is exercised very much like it was exercised during the recording phase. This is achieved by re-creating all external client requests to the RDBMS. External client requests include all the requests by all possible external clients of the RDBMS.



Supported Workloads

Supported Workloads

• Supported:– All SQL (DML, DDL, PL/SQL) with practically all typ es of binds– Full large objects (LOB) functionality (cursor-base d and direct

OCI)– Local transactions– Logins/logoffs– Session switching– Limited PLSQL calls (database interaction)

• Limitations:– Direct path load, import/export– OCI-based object navigation (abstract data types) a nd

REF binds– Streams, non-PL/SQL based advanced queuing (AQ)– Distributed transactions, remote describe, or commi t

operations

The workload initiated by a database user, and reaching the server through a connection from the user, is supported. All nonrecursive SQL calls are recorded and replayed, and falls into the categories listed above. Recursive SQL calls (calls that are regenerated when the user calls are replayed) and SQL calls from parallel query slaves are not recorded. Parallel query slave calls are replayed as part of the top-level call that spawned them. User logins and logoffs are supported; however, passwords are not recorded and replayed. Remote procedure calls from PL/SQL, distributed transactions, debug calls, remote commits, remote describes, bundled PL/SQL, and session migrations are not supported. The replay user must correctly configure external interactions, such as database links, external tables, directory objects, and URLs during replay. Workload from Oracle utilities or features (such as Enterprise Manager (EM), SQL*Loader, Data Pump, Replication) is supported. As EM is likely to be used to monitor and administer the database during recording, you are recommended to filter the EM workload. Data Pump, Export, and Import calls are SQL calls and, as such, are captured. System background workload—for example workload from PMON, SMON, LGWR, and other processes—is not recorded.



Capture Considerations

Capture Considerations

The goal of capture planning is to ensure that:• The database can be restored to the system change

number (SCN) when capture starts ( StartSCN )

• The system has enough resources for the capture• You find a suitable period for restarting the datab ase

before capture starts (if selected)• You can specify filters to capture a subset of the

workload• Users have SYSDBAor SYSOPERprivileges and

appropriate OS privileges

You perform the following tasks in the planning phase of the workload recording:

• Check the database backup strategy: You should ensure that the database could be restored to StartSCN when the recording starts.

• Plan the capture period: You select the capture period based on the application and the peak periods. You can use the existing manageability features, such as Automatic Workload Repository (AWR) and Active Session History (ASH), to select an appropriate period based on the workload history. The starting time for the capture should be carefully planned because it is recommended that you shut down and restart the database before starting the capture.

• Specify the location of the workload capture data: You must set up a directory that is to be used to store the workload capture data. You should provide ample disk space because the recording will stop if there is insufficient disk space. However, everything captured up to that point could be used for replay.

• Define capture filters for user sessions that are not to be captured: You can specify a recording filter to skip sessions that should not be captured.

No new privileges or user roles are introduced with the Database Replay functionality. The recording user and replay user must have the SYSDBA or SYSOPER privilege. This is because only a user with the SYSOPER or SYSDBA privilege can start or shut down the database to start the recording. Correct operating system privileges should also be assigned so that the user is able to access the recording, replay directories, and manipulate the files in those directories.



Replay Considerations


• Preprocess the captured workload:– Is a one-time action– Must be on the same DB version as the replay– Can be performed anywhere (production, test system, or

other system) if versions match

• Restore the database, and then perform the followin g:– Upgrade the database.– Make Schema changes.– Change the operating system.– Make hardware changes.– Add an instance

The preprocess phase is required only once for the specified database version. After the necessary metadata has been created, you can replay the workload as many times as required. You must restore the replay database to match the capture database at the start of the workload capture. A successful replay depends on the application transactions accessing the application data that is identical to that on the capture system. You can choose to restore the application data by using point-in-time recovery, flashback, and import/export functionalities.





• Manage external interactions:– Remap the connection strings to be used for the

workload.— One-to-one: Allows simple instance-to-instance rema pping— Many-to-one: Allows the use of load balancer (singl e node

to RAC)

– Modify external references (such as database links and directory objects) that point to production systems .

• Set up one or more replay clients:– Each multithreaded client can drive multiple worklo ad

sessions.

A captured workload may contain references to external systems that are meaningful only in the capture environment. Replaying a workload with unresolved references to external systems may cause unexpected problems in the production environment. A replay should be performed in a completely isolated test. You must ensure that all references to external systems have been resolved in the replay environment so that replaying a workload will cause no harm to your production environment. You can make one-to-one or many-to-one remappings. For example, database links in a captured production environment may reference external production databases that should not be referenced during replay. Therefore, you should modify any external references that could jeopardize the production environment during replay. The replay client (an executable named wrc ) submits a captured session’s workload. You should install one or more replay clients, preferably on systems other than the database host. Each replay client must be able to access the directory that holds the preprocessed workload. You can also modify the replay parameters to change the behavior of the replay.



Replay Analysis

Replay Analysis

• Data divergence:– Number of rows compared for each call (queries, DML s)

• Error divergence:– New errors– Mutated errors– Disappearance of errors

• Performance:– Capture and replay report– Automatic Database Diagnostic Monitor (ADDM) report– Active Session History (ASH) report for skew analys is– AWR report

There may be some divergence of the replay compared to what was recorded. For example, when replaying on a newer version of the RDBMS, a new algorithm may cause specific requests to be faster, and thus divergence appears as faster execution. This is considered a desirable divergence. Another example of divergence is when a SQL statement returns fewer rows during replay than during recording. This is clearly not desirable; its root cause may be a new index look-up algorithm. The replay identifies this fact. For data divergence, the result of an action can be considered as:

• The result set of a SQL query

• An update to the persistent database state

• A return code or an error code

Performance divergence is useful to determine how new algorithms introduced in the replay system may affect overall performance. There are numerous factors that can cause replay divergence. Though some of them cannot be controlled, others can be mitigated. It is the task of the DBA to understand the workload run-time operations and take the necessary actions to reduce the level of record and replay divergence. Online divergence should aid the decision to stop a replay that has diverged significantly. The results of the replay before the divergence may still be useful, but further replay does not produce reliable conclusions. Offline divergence reporting is used to determine how successful the replay was after it has finished.



Replay Data Divergence

Replay Data Divergence

Workload characteristics that increase data or erro r divergence:• Implicit session dependencies by the application (f or

example, the use of dbms_pipe )

• Extensive use of multiple commits in PL/SQL• User locks• Use of nonrepeatable functions or system-dependent

data• External interactions via URLs or database links

Data divergence of the replay encompasses the results of both queries and errors. That is, errors that occurred during recording are considered proper results and any change during replay is reported. You can use existing tools such as Automatic Database Diagnostic Monitor (ADDM) to measure performance differences between the recording and the replay systems. Additionally, error comparison reports during the replay report on the following:

• Errors that did not happen during recording

• Errors that were not reproduced during replay

• Differences in error type



Workload Capture Process

Workload Capture Process

Start

Raw captureddata

Workload recording

Plan

Shutdown/Startup restricted

Capture

. . .

You see the workflow for Database Replay above. As shown, the workload capture and preprocessing need to be done only once. The data produced can be used for workload replay multiple times. The workload recording has three main steps:

1. Planning for capture

2. Preparing for capture

3. Capturing the workload

These steps are discussed in detail in the following slides.



Using Enterprise Manager for Workload Capture


Enterprise Manager (EM) provides you with a user interface to manage each component in the Database Replay process. The workflow and user interface apply to both EM Database Control and EM Grid Control. You access Database Replay on the “Software and Support” tab of Database Control. You are then directed to the page to create the necessary tasks to perform the following:

• Manage the workload capture operations.

• View any previously captured workload.

• Manage the workload replay operations.

• Stop the active capture or replay: This option is available only during an active capture or replay session.

You can view previously captured workloads by clicking the View Workload Capture History link to see graphical and statistical details about the captured workload.





The EM Wizard walks you through the prechecks before beginning the database workload capture. On this page, you are asked to acknowledge the conditions that ensure a successful replay of the workload. It is recommended that you restart the database to reduce the potential for data divergence, confirm that you have sufficient disk space for the capture data, and ensure that you can effectively restore the database as of the time of capture. You should select the capture period based on the application and the peak periods. You can use existing manageability features such as Automatic Workload Repository (AWR) and ASH to select an appropriate period based on the workload history.





As an option, you can restart the database before beginning the capture process. If you know your workload well, you can choose not to restart the database. Not restarting the database allows in-flight transactions to be present during the capture phase, thus affecting the potential for data divergence in the replay phase. Oracle recommends that you restart the database to minimize data divergence in the replay phase. You are then asked to set up any required capture filters to customize the data that is captured (or filtered out of the captured data). Because EM is used to monitor and administer the recording and replaying sessions (essentially duplicating its workload during replay), it provides a default filter to filter itself out. You can add additional filtering components. You must specify the location for the workload capture data. You can specify an existing database directory or create a directory from this page. You are then prompted for a directory object name and an OS path that will be validated. You should ensure that ample disk space exists to hold the captured workload because the recording stops if there is insufficient disk space. However, everything captured up to that point could be used for replay. You can (optionally) choose to export the AWR data at the same time as the capture process ensuring in-depth capture and replay analysis. Alternatively, the export can be performed at a later stage on the View Workload Capture History page. RAC Note: For RAC, the DBA should define the directory for captured data at a storage location accessible by all instances. Otherwise, the workload capture data must be copied from all locations to a single location before starting the processing of the workload recording.





You complete the schedule information to submit a capture job (IMMEDIATELY, LATER), specifying whether the capture is manually terminated or timebound (DURATION), and then review the job information before submitting the job. Monitoring of the capture shows you the progress and resource usage. Because workload capture is typically done on a production system with a heavy workload, monitoring during the capture phase is lightweight and adds only minimal overhead to the production workload. The monitor data is accessible through V$ views.



Workload Replay Process

Workload Replay Process

End

Raw captured data (from production

system)

Workload replay

Process capture

Prepare

Replay

Analyze

Initialize replay

Replay report

Replay files& metadata

The workload replay has four steps:

1. Initializing replay data

2. Preparing for replay

3. Replaying

4. Analyzing replay

These steps are discussed in detail in the following slides.



Using Enterprise Manager for Workload Replay


You begin the replay workflow by specifying the directory object where you stored the captured data. When specified, the page as shown above is displayed with the Capture Summary of the selected workflow. Select Preprocess Workload to commence the prepare phase. In the preprocess phase, you are asked to validate the database version of the replayed workload and requests you to schedule the preprocess phase (IMMEDIATELY, LATER). After the database has restarted in restricted mode, you begin the capture phase by calling the DBMS_WORKLOAD_CAPTURE package with the following arguments:

• Name for the capture (This allows reference of the historical captured data on the capture system.)

• Directory object pointing to the directory that exists to store the captured workload data

• Time duration T for capture (This stops recording approximately after time T.)

• Filtering mode

• Restart mode

When you execute the FINISH_CAPTURE procedure, the capture stops and the database system flushes the capture buffers and closes all the open workload data files. After finishing the recording, you can request a report on the capture. This is used for comparison with the report generated through the replay phases. RAC Note: On instance failure during a RAC system capture, the capture continues and is not aborted. Any sessions that died as a result of the failure are replayed up to the point at which the



instance died. When a dead instance is repaired and comes up again during capture, all new sessions are recorded normally. During replay, the death of instances is not replayed.





In this phase, the recorded data is transformed into a more suitable format. This transformation is done offline and preferably on a system different from the production system (because it is resource intensive). The capture-processing output can be used for multiple replays as a one-time activity when you use it on the same RDBMS version that is to be used for the replay. If the captured data has already been processed for a given RDBMS version (for example, A), you must perform the process capture phase again if it is required to perform replay on an RDBMS version that is newer than A. The following actions are performed in this phase:

• Transforming workload capture data files into suitable replay streams (the replay files)

• Producing all necessary metadata

This phase is equivalent to the functionality in the DBMS_WORKLOAD_REPLAY.PROCESS_CAPTURE procedure. RAC Note: In a RAC setup, one database instance of the replay system is selected for processing the workload recording. If the recorded data was written to a local file system for nodes in the RAC, the recorded data files from all the nodes in the RAC should first be copied to the directory for the instance on which the preprocessing is to be done. If the captured data is stored in a shared file system, copying is not necessary.





Select the required captured data from the replay history table (if one exists), and then click Set Up Replay to begin the replay process.





The Set Up Replay phase can be done multiple times on the processed capture data. The above screen is displayed, reminding you to complete the following necessary steps:

Restore Database: You need to restore the database objects used during capture to an equivalent state as of StartSCN (the system SCN at which the recording actually started).

Perform System Changes: The intent is to test your workload under a different environment, so you make the necessary environment changes here.

Resolve References to External Systems: A captured workload may contain references to external interaction that may be meaningful only in the capture environment. You should fix all the references before replay to ensure that replaying a workload will not cause harm to your production environment. Replaying a workload with unresolved references to an external interaction may affect your production environment.

Set Up Replay Clients: Workload is replayed using replay clients connected to the replay database. You should install these replay clients on systems other than the database host. In Addition, each replay client must be able to access the replay directory.





References to resolve:

A replay should be performed in a completely isolated test environment (for example, hosts, networks, email servers, or storage systems). The captured workload may have database activities that refer or connect to systems or devices that are meaningful only in the capture environment. The three links direct you to other EM pages to see whether the database links, directory objects, and streams on the replay database (as restored from the capture database) refer to production-only systems or devices. You should modify these by using the test environment values. You should ensure that all references to external interactions are resolved in the replay environment so that replaying a workload causes no harm to your production environment. RAC Note: In a RAC system, the replay data files should be stored in the shared storage or copied to the appropriate local directories so that all database instances in the RAC and all replay clients can access them. The remapping of external interactions should include the remapping of instances. In particular, every captured connection string probably needs to be remapped to a connection string in the replay system. If the capture system is a single-instance database and the replay system is also a single-instance database, remapping of the connection string is straightforward and involves adding the appropriate entry to the configuration file. The same is valid when the capture and replay systems are both RAC databases with the same number of nodes. That is, there is a one-to-one mapping of the connection strings of the capture system to the connection strings of the replay system. Remapping becomes more complicated if the capture and replay systems have different numbers of nodes.





You use either the default options or the options from a previous replay. The next step enables you to further customize the chosen configuration.





You use the Connection Mappings page to conveniently use a single descriptor for all connections, either as a prepopulated string or as an alias name that maps to the descriptor string. You can also select a separate connect descriptor option that enables you to specify a unique descriptor for each connection. If you select the “Use replay options from a previous replay” option in the Choose Initial Options step, the “Use a separate connect descriptor” option is selected and the previous replay system values then appear. The Replay Parameters page provides advanced parameters that control some aspects of the replay. These replay parameters are documented in the Oracle Database Performance Tuning Guide (Oracle 11g, Release 1).





The Replay Parameters page provides advanced parameters that control aspects of the replay. SYNCHRONIZATION: You can disable SCN-based synchronization of the replay if your workload consists of transactions that do not heavily depend on each other, thereby accepting any divergence during replay. CONNECT_TIME_SCALE: This scales the time elapsed between the instant the workload capture was started and the session connects with the given value. The input is interpreted as a percentage value. It can potentially be used to increase or decrease the number of concurrent users during the workload replay. THINK_TIME_SCALE: This scales the time elapsed between two successive user calls from the same session. The input is interpreted as a percentage value. Setting this value to 0 sends requests to the database as fast as possible. THINK_TIME_AUTO_CORRECT: This appropriately autocorrects the think time between calls when a user call takes longer to complete during replay than during the original capture. The input is interpreted as a percentage value. Note that THINK_TIME_AUTO_CORRECT corrects the think time that is calculated based on THINK_TIME_SCALE. If TRUE, it reduces (or increases) the think time when the replay is slower (or faster) than capture. If FALSE, it does nothing. Note: These replay parameters are documented in the Oracle Database Performance Tuning Guide (Oracle 11g, Release 1).





The workload is replayed using replay clients connected to the database. You should be ready to start the replay clients at this point. When you are ready to start the replay clients, click Next, and then start the clients.





%> wrc userid=<user id> password=<password> server=<server connection string> replaydir=<replay directory>workdir=<client work directory>

$ wrc REPLAYDIR=/home/oracle/solutions/dbreplay USE RID=system PASSWORD=oracle

Workload Replay Client: Release 11.1.0.6.0 - Product ion on Tue …

Copyright (c) 1982, 2007, Oracle. All rights reser ved.

Wait for the replay to start (21:47:01)

Replay started (21:48:14)

The Workload Replay Wizard waits for you to start the replay clients. You open a separate terminal window to start the replay clients. You can start multiple replay clients depending on the workload replay size. Each client initiates one or more replay threads with the RDBMS, with each replay thread corresponding to a stream from the workload capture. The replay clients are started after the database server has entered the replay PREPARE mode from the wizard, using the syntax illustrated in the example above. The userid and password parameters are the user ID and password of the replay user for the client. The server parameter is a connection string that connects to the instance of the replay system. The replaydir parameter points to the directory that contains the processed replay files. The workdir parameter defines the client’s working directory. When left unspecified, it defaults to the current directory. Before starting the replay clients, be sure that:

• The replay client software is installed on the hosts

• The client has access to the replay directory

• The replay directory has the replay files that have been preprocessed

• The userid and password for the replay user are correct (Furthermore, the replay user should be able to use the workload replay package and have the user SWITCH privilege.)

The Client Connections table is populated when at least one replay client is connected.





After starting the replay clients, you review the replay setup and submit the job. A progress window is displayed, providing comparison statistics as the replay progresses. You can terminate the replay at any stage with the Stop Replay button. On successful completion of the replay, your terminal window that started the replay clients displays an information message (“Replay Finished”) followed by a time stamp. The replayed workload is now complete, and you can use existing manageability tools such as AWR and ASH for additional system performance information. The Elapsed Time Comparison chart shows how much time the replayed workload has taken to accomplish the same amount of work as the captured workload. The divergence table gives information about the data and error discrepancies between the replay and capture environments that can be used as a measure of the replay quality. You can click the View Workload Replay Report button (or Report tab after replay has completed) for a browser window that displays a report containing detailed information about the replay. RAC Note: If a specific captured instance is mapped to a new instance in the replay system, all captured calls for the captured instances are sent to the new one. If the replay system is also RAC and a captured instance is mapped to the run-time load balancing of the replay system, all captured calls for that recorded instance are dynamically distributed to instances in the replay RAC system by using run-time load balancing.



Database Replay: PL/SQL Example


exec DBMS_WORKLOAD_CAPTURE.ADD_FILTER(fname => 'sessfilt',-fattribute => USER ,-fvalue => 'KING');

exec DBMS_WORKLOAD_CAPTURE.START_CAPTURE(name => 'june_peak',-dir => 'jun07');

Execute your workload

exec DBMS_WORKLOAD_CAPTURE.FINISH_CAPTURE();

exec DBMS_WORKLOAD_REPLAY.PROCESS_CAPTURE(capture_dir => 'jun07');

wrc userid=system password=oracle replaydir=/dbrepl ay

exec DBMS_WORKLOAD_REPLAY.INITIALIZE_REPLAY(replay_ name => 'j_r' ,-replay_dir => 'jun07');

In this example, the ADD_FILTER procedure adds a filter named sessfilt that filters out all sessions belonging to the username KING. You use the START_CAPTURE procedure to start the workload capture. In the example above, a capture named june_peak is captured and stored in a directory named jun07 . Because the duration parameter is not specified, the workload capture continues until the FINISH_CAPTURE procedure is called. You can now run your workload. You stop the workload capture with the FINISH_CAPTURE procedure that finalizes the workload capture and returns the database to a normal state. At this point, you can generate a capture report by using the REPORT function. To preprocess a captured workload, use the PROCESS_CAPTURE procedure. In this example, the captured workload stored in the jun07 directory is preprocessed. When you are finished, start your replay clients. To initialize replay data, use the INITIALIZE_REPLAY procedure. Initializing replay data loads the necessary metadata into tables required by workload replay. For example, captured connection strings are loaded into a table where they can be remapped for replay. In this example, the INITIALIZE_REPLAY procedure loads preprocessed workload data from the jun07 directory into the database.





exec DBMS_WORKLOAD_REPLAY.REMAP_CONNECTION(connection_id => 101,-replay_connection => 'edlin44:3434/bjava21');

exec DBMS_WORKLOAD_REPLAY.PREPARE_REPLAY(synchronization => TRUE,-think_time_scale=> 2);

exec DBMS_WORKLOAD_REPLAY.START_REPLAY ();

DECLAREcap_id NUMBER;rep_id NUMBER;rep_rpt CLOB;

BEGINcap_id := DBMS_WORKLOAD_REPLAY.GET_REPLAY_INFO(dir => 'jun07');/* Get the latest replay for that capture */SELECT max(id) INTO rep_id FROM dba_workload_replaysWHERE capture_id = cap_id;rep_rpt := DBMS_WORKLOAD_REPLAY.REPORT(replay_id => rep_id,

format => DBMS_WORKLOAD_REPLAY.TYPE_TEXT);END;

To remap connections, use the REMAP_CONNECTION procedure. In the example above, the connection that corresponds to the connection ID 101 uses the new connection string defined by the replay_connection parameter. You then use the PREPARE_REPLAY procedure to prepare the workload replay on the replay system. In this example, the PREPARE_REPLAY procedure prepares the j_r replay to preserve the COMMIT order in the workload capture. Use the START_REPLAY procedure to start a workload replay. To stop a workload replay, use the REPLAY_CANCEL procedure. In the example above, the REPORT function is used to generate a workload replay report. Note: You require the EXECUTE privilege on the capture and replay packages to execute these packages. These privileges are usually assigned by the DBA. For further details about the DBMS_WORKLOAD packages, see the Oracle Database PL/SQL Packages and Types Reference 11g, Release 1.



Calibrating Replay Clients

Calibrating Replay Clients

$ wrc system/oracle@orcl mode= calibrate replaydir=/dbreplay

Workload Replay Client: Release 11.1.0.5.0 - Beta on Tue …Copyright (c) 1982, 2007, Oracle. All rights reser ved.

Report for Workload in: /dbreplay

-----------------------

Recommendation:

Consider using at least 1 clients divided among 1 C PU(s).

Workload Characteristics:

- max concurrency: 4 sessions

- total number of sessions: 11

Assumptions:

- 1 client process per 50 concurrent sessions

- 4 client process per CPU

- think time scale = 100

- connect time scale = 100

- synchronization = TRUE

$

Because one replay client can initiate multiple sessions with the database, it is not necessary to start a replay client for each session that was captured. The number of replay clients that need to be started depends on the number of workload streams, the number of hosts, and the number of replay clients for each host. Run the wrc executable in calibrate mode to estimate the number of replay clients and hosts that are required to replay a particular workload. In calibration mode, the wrc executable accepts the following parameters:

• replaydir specifies the directory that contains the preprocessed workload capture that you want to replay. If unspecified, it defaults to the current directory.

• process_per_cpu specifies the maximum number of client processes that can run on each CPU. The default value is 4.

• threads_per_process specifies the maximum number of threads that can run within a client process. The default value is 50 .

The example above shows how to run the wrc executable in calibrate mode. In this example, the wrc executable is executed to estimate the number of replay clients and hosts that are required to replay the workload capture stored in the directory named replay . Note: Use list_hosts mode to list hosts that participated in the capture.



Packages and Procedures

Packages and Procedures

• DBMS_WORKLOAD_CAPTURE

– START_CAPTURE

– FINISH_CAPTURE

– ADD_FILTER

– DELETE_FILTER

– DELETE_CAPTURE_INFO

– GET_CAPTURE_INFO()

– EXPORT_AWR

– IMPORT_AWR()

– REPORT()

• DBMS_WORKLOAD_REPLAY

– PROCESS_CAPTURE

– INITIALIZE_REPLAY

– PREPARE_REPLAY

– START_REPLAY

– CANCEL_REPLAY

– DELETE_REPLAY_INFO

– REMAP_CONNECTION

– EXPORT_AWR

– IMPORT_AWR

– GET_REPLAY_INFO

– REPORT

You need the EXECUTE privilege on the capture and replay packages to execute these packages. These privileges are usually assigned by the DBA. Note: For further details about the DBMS_WORKLOAD packages, see the Oracle Database PL/SQL Packages and Types Reference 11g, Release 1.



Data Dictionary Views: Database Replay

Data Dictionary Views: Database Replay

• DBA_WORKLOAD_CAPTURES: Lists all workload captures performed in the database

• DBA_WORKLOAD_FILTERS: Lists all workload filters defined in the database

• DBA_WORKLOAD_REPLAYS: Lists all workload replays that have been performed in the database

• DBA_WORKLOAD_REPLAY_DIVERGENCE:Is used to monitor workload divergence

• DBA_WORKLOAD_CONNECTION_MAP: Is used to review all connection strings used by workload replays

• V$WORKLOAD_REPLAY_THREAD: Monitors the status of external replay clients

For further details about the data dictionary views, see the Oracle Database Reference 11g, Release 1 (11.1).



Summary

Summary

In this lesson, you should have learned how to:• Identify the benefits of using Database Replay• List the steps involved in Database Replay• Use Enterprise Manager to record and replay

workloads


Using SQL Performance Analyzer Chapter 0 - Page 1

Using SQL Performance Analyzer



Chapter 4Using SQL Performance Analyzer

Using SQL Performance Analyzer



Objectives

Objectives

After completing this lesson, you should be able to :• Identify the benefits of using SQL Performance

Analyzer• Describe the SQL Performance Analyzer workflow

phases• Use SQL Performance Analyzer to evaluate

performance gains following a database change



SQL Performance Analyzer: Overview

SQL Performance Analyzer: Overview

• Helps predict the impact of system changes on SQL workload response times

• Builds different versions of SQL workload performan ce– SQL execution plans and execution statistics

• Executes SQL serially; concurrency not respected• Analyzes performance differences• Offers finegrained performance analysis on

individual SQL• Is integrated with SQL Tuning Advisor to tune

regressions

Targeted users: DBAs, QA testers, and application d evelopers

Oracle Database 11g introduces SQL Performance Analyzer that gives you an exact and accurate assessment of the impact of change on the SQL statements in the workload. SQL Performance Analyzer helps forecast the impact of a potential change on the performance of a SQL query workload. This capability provides DBAs with detailed information about the performance of SQL statements, such as before and after execution statistics, statements with performance improvement or degradation. This enables you to make changes in a test environment to determine, for example, whether the workload performance will be improved through a database upgrade.



SQL Performance Analyzer: Use Cases

SQL Performance Analyzer: Use Cases

SQL Performance Analyzer is beneficial in the follo wing situations:• 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 SQL execution plans. The changes can include any of the following (but are not limited to these):

• Database upgrades

• Implementation of tuning recommendations

• Schema changes

• Statistics gathering

• Database parameter changes

• OS and hardware changes

DBAs can use SQL Performance Analyzer to foresee SQL performance changes induced through the above changes, for even the most complex environments. As applications evolve through the development life cycle, database application developers can test changes to schemas, database objects, and rewritten applications (for example) to mitigate any potential performance impact. SQL Performance Analyzer also allows the comparison of SQL performance statistics.



Capture SQL Workload

Capture SQL Workload

• SQL Tuning Set (STS) stores SQL workload. Includes:

– SQL text– Bind variables– Execution plans– Execution statistics

• Incremental capture populates STS from cursor cache over a time period.

• STS’s filtering and ranking capabilities filter out undesirable SQL.

Database instance

Cursor cache

Incrementalcapture

Productiondatabase

The first step in using SQL Performance Analyzer is to capture the SQL statements that represent your workload. This step is done by using the SQL Tuning Set technology or by using the high-load SQL statements captured in the Automatic Workload Repository (AWR).



Transport to a Test System

Transport to a Test System

a. Copy STS to staging table (“pack”).b. Transport staging table to test system (Data Pump, database link,

for example).c. Copy STS from staging table (“unpack”).

Database instance

Cursor cache

Database instance

Productiondatabase

Testdatabase

The next step is to transport these SQL statements to a similar system that is being tested. Here, the STS can be exported from production and then imported into a test system.



Build Before-Change Performance

Build Before-Change Performance

• Before change, the SQL performance version is the SQL workload performance baseline.

• SQL performance = execution plans + execution statistics

• Test-execute SQL in the STS:– Produce execution plans and

statistics.– Execute SQL serially

(no concurrency).– Every SQL is executed only

once.– Skip DDL/DML effects.

• Explain plan the SQL in the STS to generate only SQL plans.

050

100

1stQtr

3rdQtr

EastWestNorth

Testdatabase

Database instance

Beforechanges

Test/execute

The third step is to capture a baseline of the test system performance comprising the execution plan and execution statistics.



Build After-Change Performance

Build After-Change Performance

• Manually implement the planned change:

– Database upgrade– Implementation of tuning

recommendations– Schema changes– Statistics gathering– Database parameter changes– OS/hardware changes, etc

• Reexecute SQL after change:– Test-execute SQL in SQL

Tuning Set to generate SQL execution plans and statistics.

– Explain plan SQL in SQL Tuning Set to generate SQL plans.

Database instance

After changes implemented

Afterchanges

Testdatabase

The fourth step is to make the change to the test system and rerun the SQL statements to assess the impact of the change on SQL performance.



Compare and Analyze Performance

Compare and Analyze Performance

• Rely on user-specified metric to compare SQL performance:

– Elapsed_time , Buffer_gets ,Disk_reads

• Calculate change impact on individual SQL and SQL workload:

– Overall impact on workload – SQL net impact on workload

• Use SQL execution frequency to define the weight of importance.

• Detect improvements, regressions, and unchanged performance.

• Detect changes in execution plans.• Recommend running SQL Tuning

Advisor to tune regressed SQLs.• Analysis results can be used to

seed SQL plan management baselines.

Testdatabase

Database instance

Compareanalysis

Regressionimprovement

SQL Tuning Advisor

Enterprise Manager (EM) provides the tools to make a full comparison of performance data, including execution statistics, such as elapsed time, CPU time, and buffer gets. If the SQL performance has regressed in some of the cases, the DBA must run SQL Tuning Advisor to tune the SQL statements immediately or at a scheduled time. As with any tuning strategy, it is recommended that only one change be implemented at a time and retested before making further changes.



SQL Performance Analyzer: Summary

SQL Performance Analyzer: Summary

1. Capture SQL workload on production.2. Transport the SQL workload to a test system.3. Build “before-change” performance data.4. Make the changes.5. Build “after-change” performance data.6. Compare results from steps 3 and 5.7. Tune regressed SQL.

1. Capture 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 the AWR to capture the information to transport. As the AWR essentially captures high-load SQLs, you should consider modifying the default AWR snapshot settings and captured Top SQL to ensure that the AWR captures the maximum number of SQL statements. This would ensure a more complete SQL workload capture.

2. Transport: In this phase, you transport the resultant workload to the test system. The STS is exported from the production system and imported into the test system.

3. Compute “before version” performance: Before any changes take place, you execute the SQL statements, collecting the baseline information needed to assess the impact that a future change may have on the performance of the workload. The information collected at this stage represents a snapshot of the current state of the system workload. The performance data includes:

- Execution plans: Execution plans (for example, those generated by an explain plan)

- Execution statistics: For example, elapsed time, buffer gets, disk reads, and rows processed

4. Make a change: After you have the “before version” data, you can implement your planned change and start viewing the impact on performance.



5. Compute “after version” performance: This step takes place after the change is made in the database environment. Each statement of the SQL workload runs under a mock execution—collecting statistics only—collecting the same information as in step 3.

6. 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 the SQL statements that may cause performance problems when the database change is made. From here, you can use any of the database tools to tune the system. For example, you could use SQL Tuning Advisor or Access Advisor against the identified statements, and implement those recommendations. Alternatively, you can seed the SQL Plan Management (SPM) with plans captured in step 3 to guarantee that the plans remain the same. After you implement 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.



Enterprise Manager: Capturing the SQL Workload


1. Create SQL Tuning Set (STS) on original system.2. Create a staging table and upload STS in staging ta ble.3. Export staging table to test system.4. Unpack staging table to STS on test system.

Capturing SQL workload is done using SQL Tuning Sets (STS). This concept is not new in Oracle Database 11g, and it follows the same workflow as with the previous releases of the database. This workflow is briefly described above. You can use Enterprise Manager (EM) wizards or the DBMS_SQLTUNE PL/SQL package. You access the STS page from the Performance tab in Database Control. The workload you capture should reflect a representative period of time (in captured SQL statements) that you wish to test under a 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 that 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. 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.





You can do either of the following:• Incrementally collect SQL workload over a period of

time• Collect SQL statements on a one-time-only basis fro m

the following sources:– Cursor cache– AWR snapshots– AWR baselines– User-defined workload

You can choose either to incrementally collect SQL workload over a period of time, or to collect SQL statements one time only from the sources shown above. A user-defined workload is a user-defined table that stores SQL statements and must include sql_text and parsing_schema_name columns. Ideally, it should also have columns that contain SQL statistics. EM provides the following support for SQL Performance Analyzer:

• Viewing previously captured workloads and their details

• Capturing the SQL

• Exporting a workload

• Importing a workload

• Computing SQL performance

• Managing SQL performance data

• Reporting analysis result

• Running SQL Advisor to tune regressed SQL statements

• Viewing previously executed SQL Performance Analyzer tasks and their results



Creating a SQL Tuning Set

Creating a SQL Tuning Set

You can create filters against the type of SQL conditions for capture. In the example above, the schema APPS, SELECT SQL statements, and APPS_DEMO module are selected for capture from the cursor cache. The actual filter options depend on the selected load methods. The final stage in the Wizard enables you to select a job schedule time (IMMEDIATELY, LATER), review your job options, and submit the job.



Exporting the SQL Workload

Exporting the SQL Workload

• DBMS_SQLTUNEpackages:– CREATE_STGTAB_SQLSET

– PACK_STGTAB_SQLSET

SQL> exec DBMS_SQLTUNE.CREATE_STGTAB_SQLSET('STS_APPS_STG','APPS');

From this page, you can choose to export the selected STS for transport to the test system. You can also drill down and see the SQL statements contained within the selected STS. You also use this page to import an STS from a previously exported file. This is how you would load an STS on the test system for comparison purposes. In a common scenario, you would be exporting from an Oracle Database 10g environment, in which case you would need to create and pack a staging table by using the DBMS_SQLTUNE procedures through which STS are imported and exported. These packages are shown above. After you package the STS in Oracle Database 10g, use Data Pump to export the schema to the Oracle Database 11g test system on which you will replay the workload after some environment changes. This allows you to access the new environment before upgrading your production system.



Creating a SQL Performance Analyzer Task

Creating a SQL Performance Analyzer Task

EM helps manage each component in the SQL Performance Analyzer process and reports the analysis result. The workflow and user interface applies to both EM Database Control and EM Grid Control. You access SQL Performance Analyzer from the “Software and Support” tab of Database Control, or by selecting Database Instance > Advisor Central > Advisors > SQL Performance Analyzer. SQL Performance Analyzer offers three workflows that enable you to test different scenarios.

• Optimizer Upgrade Simulation: To test the effects of specified optimizer version changes on STS performance

• Parameter Change: To test and compare an initialization parameter change on the STS 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 : To create a SQL Performance Analyzer Task and execute custom experiments by using manually created replay trials



Optimizer Upgrade Simulation

Optimizer Upgrade Simulation

The Optimizer Upgrade Simulation page allows you to create a task that measures the performance impact on an STS when the database version is upgraded from 10g to 11g. You can test the performance impact after a database is upgraded and then tune the database if a degradation occurs. To create a task, you must specify the following details:

• Enter the name of the task and a description.

• Click the Select icon and select an STS from the list.

• Select the Per-SQL Time Limit from the list to specify the time limit for the execution of each SQL statement. This can be:

- Unlimited : There is no time limit for the execution of each SQL statement.

- Explain Only : If you select this option, the test plan is generated but not executed.

- Customize: Select this option if you want to customize the execution time limit.

• Select the Optimizer Versions to indicate the current version of the database and the new version to which the database is being upgraded. Two replay trials will be created: the first captures STS performance with the optimizer simulating the 10g optimizer, and the second uses the native 11g optimizer.

• Select the Comparison Metric to be used to evaluate the performance impact due to the database upgrade.

• Specify the Schedule for the task (IMMEDIATELY, LATER).



SQL Performance Analyzer: Task Page

SQL Performance Analyzer: Task Page

A SQL Performance Analyzer Task allows you to execute a specific STS under changed environmental conditions. After you execute the task, you can assess the impact of the changes on the performance of the STS. The comparison report is useful in assessing the impact of the changed environmental conditions on the performance of the specified STS. From this page you can also:

• Create a replay trial to test the performance of an STS under a specific environment. Click “Create Replay Trial.” Refer to the Guided Workflow page for details on creating a Replay Trial.

• Run a replay trial comparison to compare the differences between the replay trials that have been created. A comparison report is generated for each replay trial run. Click “Run Replay Trial Comparison.” Refer to the Guided Workflow page for details on running a replay trial comparison.

• Click the icon in the Comparison Report column to view the Replay Trial Comparison report.



Comparison Report

Comparison Report

The Projected Workload chart shows the projected workload for each replay trial based on the comparison metric (Execute Elapsed Time) along with the improvement and regression impact. Use the links to drill down to the Details page, where you can click the associated Improvement, Regression, and Overall Impact links to view the SQL statements in each category. You can click the SQL ID to drill down to the SQL Details page. On the SQL Details page, you can view the SQL text, a line-by-line comparison of the execution statistics, and the explain plan comparison. The SQL Statement Count chart shows the number of SQL statements that have improved, regressed, or that remain unchanged in performance based on the comparison metric. The color of the bar indicates whether the plan changed between the two trial runs. Use the links or the data buckets to access the SQL Statement Count Details page. On this page, you can see a list of SQL statements and click the SQL ID to access the SQL Details page. The Report page also provides a summary of the 10 statements (by SQL ID) that have had the most significant impact on performance. Use the SQL ID link to access the SQL details.



Guided Workflow

Guided Workflow

The trial environment must be set manually from a separate terminal session before the replay trials are captured.

You can use the Guided Workflow to define a sequence of steps to execute a two-trial SQL Performance Analyzer test. The steps are as follows:

• Create a SQL Performance Analyzer Task based on an STS.

• Replay the STS 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.

• Create a replay trial using changed environment: You can now create the second replay trial using the changed environment and specifying the necessary information. Performance differences between the trials are attributed to the environmental differences between the trials.

• Create a 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.

• 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.



Viewing Analysis Results

Viewing Analysis Results

When you click the SQL ID associated with the statement, you see a more detailed illustration of the SQL. The arrows give you a symbolic reference of the overall improvement expectation.

The detailed page gives you SQL text, execution statistics for the selected SQL statement, and overall information findings. Using the scrollable windows, you can view the plan table of the SQL statement before and after the proposed change. The trial comparison allows you to assess the impact on the STS performance of any changes made between two trials. You should know the difference between Trial 1 and Trial 2 execution environments to understand the impact of the changes between trials. Tracking environmental changes between trials is currently a DBA responsibility. The selected comparison metric is used as the basis for comparison, and defaults to EXECUTE ELAPSED TIME when both trials contain test execution statistics. You can enact SQL Tuning Advisor at the statement level or at the task level. Task-level activation will affect changes for all statements within the task. From the SQL Performance Analyzer Task Result page, you can directly tune all regressed statements by invoking SQL Tuning Advisor by clicking the Run SQL Tuning Advisor button, completing the job name and optional job details, and then submitting the job. You can also prevent regressions by using SQL plan baselines by clicking the Create SQL Plan Baselines button.



Viewing Tuning Results

Viewing Tuning Results

After successful job submission, go to the Advisor Central page and drill down to view the recommendations of the run. You can view the detail of the suggested statement improvements by selecting a specific type. The improvement identified by SQL Tuning Advisor as having the highest benefit (percentage) is presented at the top of the list. It is recommended that you implement only one change at a time and repeat the analysis process, capturing “after tuning” performance data and re-analyzing the recommendations against the “after change” performance data.



SQL Performance Analyzer: PL/SQL Example

SQL Performance Analyzer: PL/SQL Example

Make changes

exec :tname:=dbms_sqlpa.create_analysis_task( -sqlset_name=>':mysts', task_type => 'sqlpia');

exec dbms_sqlpa.execute_analysis_task(:tname, -execution_type=>'test execute');

select dbms_sqlpa.report_analysis_task(task_name=>: tname,type=>'text', section=>'summary') FROM dual;

exec dbms_sqlpa.execute_analysis_task(:tname, -execution_type=>'test execute');


exec dbms_sqlpa.execute_analysis_task(:tname, execution_type=>'analyze performance');


You can easily adapt the example above to run your own DBMS_SQLPA analysis.

1. Create the tuning task to run SQL Performance Analyzer.

2. Execute the task once to build the before-change performance data and produce the before-change report. You can specify various parameters, some of which are:

- Set the execution_type parameter to EXPLAIN PLAN (generates explain plans for all SQL statements) or TEST EXECUTE (executes all SQL statements in the SQL workload).

- Specify execution parameters by using the execution_params parameter specified as name-value pairs. The time_limit parameter specifies the global time limit to process all SQL statements in an STS before timing out. The local_time_limit parameter specifies the time limit to process each SQL statement in an STS before timing out.

3. Make your changes.

4. Execute the task again after making the changes, and then get the after-changes report.

5. Compare the two executions, and then get the analysis report.



SQL Performance Analyzer: Data Dictionary Views

SQL Performance Analyzer: Data Dictionary Views

• Modified views in Oracle Database 11 g:– DBA{USER}_ADVISOR_TASKS: Displays details about the

advisor task– DBA{USER}_ADVISOR_FINDINGS: Displays analysis

findings

• New views in Oracle Database 11 g:– DBA{USER}_ADVISOR_EXECUTIONS: Lists metadata

information for execution of a task– DBA{USER}_ADVISOR_SQLPLANS: Displays the list of SQL

execution plans– DBA{USER}_ADVISOR_SQLSTATS: Displays the list of SQL

compilation and execution statistics

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)

DBA{USER}_ADVISOR_TASKS: Displays details about the advisor task created to perform an impact analysis of a system environment change

DBA{USER}_ADVISOR_EXECUTIONS: Lists metadata information for execution of a task. SQL Performance Analyzer creates a minimum of three executions to perform a change impact analysis on a SQL workload: one execution that collects performance data for the before-change version of the workload, a second execution of the after-change version of the workload, and a final execution to perform the actual analysis. DBA{USER}_ADVISOR_FINDINGS: Displays analysis findings. The advisor generates four types of findings: performance regression, symptoms, errors, and informative messages.



Summary

Summary

In this lesson, you should have learned how to:• Identify the benefits of using SQL Performance

Analyzer• Describe the SQL Performance Analyzer workflow

phases• Use SQL Performance Analyzer to evaluate

performance gains following a database change


SQL Access Advisor Enhancements Chapter 0 - Page 1

SQL Access Advisor Enhancements



Chapter 5SQL Access Advisor Enhancements

SQL Access Advisor Enhancements



Objectives

Objectives

After completing this lesson you should be able to:• Create SQL Access Advisor analysis sessions using

Enterprise Manager• Create SQL Access Advisor analysis sessions using

PL/SQL



SQL Access Advisor: Overview

SQL Access Advisor: Overview

Workload

SQL Access Advisor

Solution

Component of CBO

Provides implementation

script

No expertiserequired

DBA

Whatpartitions , indexes, and MVs do I need

to optimizemy entire

workload?

Defining appropriate access structures to optimize SQL queries has always been a concern for an Oracle DBA. As a result, there have been many papers and scripts written, and high-end tools developed to address the matter. In addition, with the development of partitioning and materialized view technology, deciding on access structures has become even more complex. As part of the manageability improvements in Oracle Database 10g and 11g, SQL Access Advisor has been introduced to address this very critical need. SQL Access Advisor identifies and helps resolve performance problems relating to the execution of SQL statements by recommending which indexes, materialized views, materialized view logs, or partitions to create, drop, or retain. It can be run from Database Control or from the command line by using PL/SQL procedures. SQL Access Advisor takes an actual workload as input, or it can derive a hypothetical workload from the schema. It then recommends the access structures for a faster execution path. It provides the following advantages:

• Does not require you to have expert knowledge

• Bases decision making on rules that actually reside in the cost-based optimizer

• Is synchronized with the optimizer and Oracle database enhancements

• Is a single advisor covering all aspects of SQL access methods

• Provides simple, user-friendly graphical user interface (GUI) wizards

• Generates scripts for implementation of recommendations



SQL Access Advisor: Usage Model

SQL Access Advisor: Usage Model

Indexes Materializedviews

Materializedview log

SQL Access Advisor

Hypothetical

SQL cache

Filter Options

STS

Workload

Partitionedobjects

SQL Access Advisor takes as input a workload that can be derived from multiple sources:

• SQL cache, to take the current content of V$SQL

• Hypothetical, to generate a likely workload from your dimensional model. This option is interesting when your system is being initially designed.

• SQL Tuning Sets, from the workload repository

SQL Access Advisor also provides powerful workload filters that you can use to target the tuning. For example, a user can specify that the advisor should look at only the 30 most resource-intensive statements in the workload, based on optimizer cost. For the given workload, the advisor then does the following:

• Simultaneously considers index solutions, materialized view solutions, partition solutions, or combinations of all three

• Considers storage for creation and maintenance costs

• Does not generate drop recommendations for partial workloads

• Optimizes materialized views for maximum query rewrite usage and fast refresh

• Recommends materialized view logs for fast refresh

• Recommends partitioning for tables, indexes, and materialized views

• Combines similar indexes into a single index

• Generates recommendations that support multiple workload queries



Possible Recommendations

Possible Recommendations

YESYESModify an existing materialized view log to add new columns or clauses.

YESYESPartition an existing unpartitioned table or index.

YESYESAdd a new materialized view log.

NOYESDrop an unused materialized view (log).

YESYESAdd a new ( partitioned ) materialized view.

YESYESModify an existing index by adding columns at the e nd.

NOYESModify an existing index by changing the index type .

NOYESDrop an unused index.

YESYESAdd new ( partitioned ) index on table or materialized view.

LimitedComprehensiveRecommendation

SQL Access Advisor carefully considers the overall impact of recommendations and makes recommendations by using only the known workload and supplied information. Two workload analysis methods are available:

• Comprehensive: With this approach, SQL Access Advisor addresses all aspects of tuning partitions, materialized views, indexes, and materialized view logs. It assumes that the workload contains a complete and representative set of application SQL statements.

• Limited : Unlike the comprehensive workload approach, a limited workload approach assumes that the workload contains only problematic SQL statements. Thus, advice is sought for improving the performance of a portion of an application environment.

When comprehensive workload analysis is chosen, SQL Access Advisor forms a better set of global tuning adjustments, but the effect may be a longer analysis time. As shown in the table, the chosen workload approach determines the type of recommendations made by the advisor. Note: Partition recommendations can work only on those tables that have at least 10,000 rows, and workloads that have some predicates and joins on columns of NUMBER or DATE type. Partitioning advices can be generated only on these types of columns. Also, partitioning advice can be generated only for single-column interval and hash partitions. Interval partitioning recommendations can be output as range syntax but interval is the default. Hash partitioning is done to leverage only partitionwise joins.



SQL Access Advisor Session: Initial Options


The next few slides describe a typical SQL Access Advisor session. You can access the SQL Access Advisor Wizard through the Advisor Central link on the Database Home page, through individual alerts, or performance pages that may include a link to facilitate solving a performance problem. The SQL Access Advisor Wizard comprises several steps during which you supply the SQL statements to tune and the types of access methods you want to use. Use the SQL Access Advisor: Initial Options page to select a template or task from which to populate default options before starting the Wizard. You can click Continue to start the Wizard or Cancel to go back to the Advisor Central page. Note: The SQL Access Advisor may be interrupted while generating recommendations, thereby allowing the results to be reviewed. For general information about using SQL Access Advisor, see the “Overview of the SQL Access Advisor” section in the “SQL Access Advisor” lesson of the Oracle Data Warehousing Guide.





If you choose the “Inherit Options from a Task or Template” option on the Initial Options page, you can select an existing task, or an existing template to inherit SQL Access Advisor’s options. By default, the SQLACCESS_EMTASK template is used. You can view the various options defined by a task or a template by selecting the corresponding object and clicking View Options.



SQL Access Advisor: Workload Source

SQL Access Advisor: Workload Source

You can choose your workload source from three different sources:

• Current and Recent SQL Activity: This source corresponds to SQL statements that are still cached in your System Global Area (SGA).

• Use an existing SQL Tuning Set: You also have the possibility to create and use a SQL Tuning Set that holds your statements.

• Hypothetical Workload: This option provides a schema that allows the advisor to search for dimension tables and produce a workload. This is very useful to initially design your schema.

You can further filter your workload source by using the Filter Options section. Filter options are:

• Resource Consumption: Number of statements ordered by Optimizer Cost, Buffer Gets, CPU Time, Disk Reads, Elapsed Time, Executions

• Users

• Tables

• SQL Text

• Module IDs

• Actions



SQL Access Advisor: Recommendation Options


You use the Recommendation Options page to choose whether to limit SQL Access Advisor to recommendations based on a single access method. You can choose the type of structures to be recommended by the advisor. If none of the three possible ones are chosen, the advisor evaluates existing structures instead of trying to recommend new ones. You can use the Advisor Mode section to run the advisor in one of two modes. These modes affect the quality of recommendations and the length of time required for processing. In Comprehensive mode, the advisor searches a large pool of candidates resulting in recommendations of the highest quality. In Limited mode, the advisor performs quickly, limiting the candidate recommendations by working only on the highest-cost statements.





You can choose Advanced Options to show or hide options that allow you to set space restrictions, tuning options, and default storage locations. Use the Workload Categorization section to set options for workload volatility and scope. For workload volatility, you can choose to favor read-only operations or you can consider the volatility of referenced objects when forming recommendations. For workload scope, you can select Partial Workload, which does not include recommendations to drop unused access structures, or Complete Workload, which includes recommendations to drop unused access structures. You use the Space Restrictions section to specify a hard space limit, which forces the advisor to produce only recommendations with total space requirements that do not exceed the specified limit. The Tuning Options section allows you to specify options that customize the recommendations made by the advisor. The “Prioritize Tuning of SQL Statements by” drop-down list allows you to prioritize by Optimizer Cost, Buffer Gets, CPU Time, Disk Reads, Elapsed Time, and Execution Count. The Default Storage Locations section allows you to override the defaults defined for schema and tablespace locations. By default, indexes are placed in the schema and tablespace of the table they reference. Materialized views are placed in the schema and tablespace of the user who executed one of the queries that contributed to the materialized view recommendation. Note: Oracle highly recommends that you specify the default schema and tablespaces for materialized views.



SQL Access Advisor: Schedule and Review

SQL Access Advisor: Schedule and Review

You can then schedule and submit your new analysis by specifying various parameters to the scheduler. The possible options are shown in the screenshots above.



SQL Access Advisor: Results


From the Advisor Central page, you can retrieve the task details for your analysis. By selecting the task name in the Results section of the Advisor Central page, you can access the Results for Task Summary page where you can see an overview of the Access Advisor findings. The page displays charts and statistics that provide overall workload performance and potential for improving query execution time for the recommendations. You can use the page to show statement counts and recommendation action counts.





To see other aspects of the results for the Access Advisor task, choose one of the three other tabs on the page: Recommendations, SQL Statements, or Details. On the Recommendation page, you can drill down to each of the recommendations. For each of them, you can see important information in the Select Recommendations for Implementation table. You can then select one or more recommendations and schedule their implementation. If you click the ID for a particular recommendation, you are taken to the Recommendation page that displays all actions for the specified recommendation and, optionally, to modify the tablespace name of the statement. When you complete any changes, choose OK to apply the changes. From that page, you can view the full text of an action by choosing the link in the Action field for the specified action. You can view the SQL for all actions in the recommendation by clicking Show SQL.





Most of these recommendations can be executed on a production system by using simple SQL data definition language (DDL) statements. For these simple SQL DDL statement cases, SQL Access Advisor produces executable SQL statements. In some instances, for example, repartitioning partitioned tables or dependent indexes, simple SQL is not sufficient. The SQL Access Advisor then generates a script calling external packages such as DBMS_REDEFINITION to enable the user to implement the recommended change. In the example above, the SQL Access Advisor recommends the partition of SH.CUSTOMERS table on the CUST_CREDIT_LIMIT column. The recommendation uses the INTERVAL partitioning scheme, and defines the first range of values as being less than 1,600. Interval partitions are partitions based on a numeric range or date-time interval. They extend range partitioning by instructing the database to create partitions of specified interval automatically when data inserted into the table exceeds all the range partitions.





The SQL Statements page displays a chart and a corresponding table that lists SQL statements initially ordered by the largest cost improvement. The top SQL statement is improved the most by implementing its associated recommendation.





The Details page displays the workload and task options that were used when the task was created. This page also gives all journal entries that were logged during task execution.



SQL Access Advisor: PL/SQL Procedure Flow

SQL Access Advisor: PL/SQL Procedure Flow

SQLAccess Advisor

task

CREATE_TASKUPDATE_TASK_ATTRIBUTESDELETE_TASKQUICK_TUNE

SET_TASK_PARAMETERRESET_TASK

ADD_STS_REFDELETE_STS_REFEXECUTE_TASKINTERRUPT/CANCEL_TASKMARK_RECOMMENDATIONUPDATE_REC_ATTRIBUTES GET_TASK_REPORTGET_TASK_SCRIPT

Step 1

Step 2

Step 3

Report/Scripts

Task-dependent

Advisor-dependent

The graphic shows the typical operational flow of SQL Access Advisor procedures from the DBMS_ADVISOR package. You can find a complete description of each of these procedures in the Oracle Database PL/SQL Packages and Types Reference Guide.

• Step 1: Create and manage tasks and data. This step uses a SQL Access Advisor task.

• Step 2: Prepare tasks for various operations. This step uses SQL Access Advisor parameters.

• Step 3: Prepare and analyze data. This step uses STS and SQL Access Advisor tasks. With Oracle Database 11g, R1, GET_TASK_REPORT can report back using HTML or Extensible Markup Language (XML) in addition to just text.

Note: The DBMS_ADVISOR.QUICK_TUNE procedure is a shortcut that performs all the necessary operations to analyze a single SQL statement. The operation creates a task for which all parameters are defaulted. The workload is constituted by the specified statement only. Finally, the task is executed and the results are saved in the repository. You can also instruct the procedure to implement the final recommendations.



SQL Access Advisor: PL/SQL Example

SQL Access Advisor: PL/SQL Example

BEGINdbms_advisor.create_task(dbms_advisor.sqlaccess_adv isor,'MYTASK');

END;

BEGIN

dbms_advisor.add_sts_ref('MYTASK','SH','MYSTS');dbms_advisor.execute_task('MYTASK');

dbms_output.put_line(dbms_advisor.get_task_script(' MYTASK'));END;

1

3

BEGINdbms_advisor.set_task_parameter('MYTASK','ANALYSIS_ SCOPE','ALL'); dbms_advisor.set_task_parameter('MYTASK','MODE','CO MPREHENSIVE'); END;

2

Matching the order shown in the previous slide, the examples in this slide show a possible SQL Access Advisor tuning session using PL/SQL code. The first PL/SQL block creates a tuning task called MYTASK. This task uses SQL Access Advisor. The second PL/SQL block sets SQL Access Advisor parameters for MYTASK. In the example, you set ANALYSIS_SCOPE to ALL, which means that you generate recommendations for indexes, materialized views, and partitions. Then, you set MODE to COMPREHENSIVE to include all SQL statements that are part of the STS associated to a future task. The third PL/SQL block associates a workload to MYTASK. Here, you use an existing STS called MYSTS. You can now execute the tuning task. After its execution completes, you can generate corresponding recommendation scripts as shown in the third example above. Note: For a complete list of SQL Access Advisor parameters (around 50), refer to the Oracle Database PL/SQL Packages and Types Reference Guide.



Summary

Summary

In this lesson you should have learned how to:• Create SQL Access Advisor analysis sessions using

Enterprise Manager• Create SQL Access Advisor analysis sessions using

PL/SQL


Automatic Memory Management Chapter 0 - Page 1

Automatic Memory Management



Chapter 6 Automatic Memory Management

Automatic Memory Management



Objectives

Objectives

After completing this lesson, you should be able to :• Set up SGA sizing initialization parameters• Set up Automatic Memory Management• Use memory advisors



Oracle Database 10g SGA Parameters

Oracle Database 10 g SGA Parameters

Automatic Shared Memory Management (ASMM)• With ASMM, five important System Global Area (SGA)

components can be automatically tuned.• Special buffer pools are not autotuned.• Log buffer is a static component but has a good def ault.

DB_KEEP_CACHE_SIZE

DB_RECYCLE_CACHE_SIZE

DB_nK_CACHE_SIZE

LOG_BUFFERSHARED_POOL_SIZEDB_CACHE_SIZELARGE_POOL_SIZEJAVA_POOL_SIZESTREAMS_POOL_SIZE

Autotunedparameters

Manualdynamic parameters

Manualstatic parameters

SGA_TARGET

SGA_MAX_SIZE

As shown above, five most important pools are automatically tuned when Automatic Shared Memory Management (ASMM) is activated. These parameters are called autotuned parameters. The second category, manual dynamic parameters, are parameters that can be manually resized without having to shutdown the instance, but that are not automatically tuned by the system. The last category, manual static parameters, includes parameters that are fixed in size and cannot be resized without first shutting down the instance.



Oracle Database 10g PGA Parameters

Oracle Database 10 g PGA Parameters

• PGA_AGGREGATE_TARGET:– Specifies the target aggregate amount of Program Gl obal

Area (PGA) memory available to the instance– Can be dynamically modified at the instance level– Examples: 100,000 KB, 2,500 MB, 50 GB– Default: 10 MB or 20% of SGA size (whichever is gre ater)

• WORKAREA_SIZE_POLICY:– Optional– Can be dynamically modified at the instance or sess ion

level– Enables fallback to static SQL memory management fo r a

particular session

PGA_AGGREGATE_TARGET specifies the target aggregate PGA memory that is available to all server processes attached to the instance. Setting PGA_AGGREGATE_TARGET to a nonzero value automatically sets the WORKAREA_SIZE_POLICY parameter to AUTO, meaning that the SQL work areas used by memory-intensive SQL operators are automatically sized. A nonzero value for this parameter is the default because, unless you specify otherwise, Oracle sets it to 20% of the SGA or 10 MB, whichever is greater. Setting PGA_AGGREGATE_TARGET to 0 automatically sets the WORKAREA_SIZE_POLICY parameter to MANUAL, meaning that the SQL work areas are sized using the *_AREA_SIZE parameters. The PGA_AGGREGATE_TARGET is not a fixed value. It is used to help the system better manage PGA memory, but the system will exceed this setting as necessary. WORK_AREA_SIZE_POLICY can be altered per database session, allowing manual memory management on a per-session basis if needed. Suppose that a session loads a large import file and a rather large sort_area_size is needed. A logon trigger could be used to set WORK_AREA_SIZE_POLICY for the account doing the import. If WORK_AREA_SIZE_POLICY is AUTO and PGA_AGGREGATE_TARGET is set to 0, an external error ORA-04032 is thrown at startup. Note: Until Oracle 9i Database, Release 2, PGA_AGGREGATE_TARGET controlled the sizing of work areas for all dedicated server connections. But it had no effect on the shared server connections, and the *_AREA_SIZE parameters took precedence in this case. In Oracle



Database 10g, PGA_AGGREGATE_TARGET controls work areas allocated by dedicated and shared connections.



Oracle Database 10g Memory Advisors

Oracle Database 10 g Memory Advisors

• Buffer Cache Advice (introduced in 9 i R1):– V$DB_CACHE_ADVICE

– Predicts physical read times for different cache si zes

• Shared Pool Advice (in 9 i R2):– V$SHARED_POOL_ADVICE

– Predicts parse times for different sizes of shared pool

• Java Pool Advice (in 9 i R2):– V$JAVA_POOL_ADVICE

– Predicts Java class load time for Java pool sizes

• Streams Pool Advice (10 g R2)– V$STREAMS_POOL_ADVICE

– Predicts spill and unspill activity time for variou s sizes

To help you size the most important SGA components, a number of advisories have been introduced in Oracle database.

• V$DB_CACHE_ADVICE contains rows that predict the number of physical reads and time for the cache size corresponding to each row.

• V$SHARED_POOL_ADVICE displays information about the estimated parse time in the shared pool for different pool sizes.

• V$JAVA_POOL_ADVICE displays information about the estimated class load time into the Java pool for different pool sizes.

• V$STREAMS_POOL_ADVICE displays information about the estimated count of spilled or unspilled messages, and the associated time spent in the spill or unspill activity for different streams pool sizes.

Note: For more information about these views, see the Oracle Database Reference.



Oracle Database 10g Memory Advisors

Oracle Database 10 g Memory Advisors

• SGA Target Advice (introduced in 10 g R2):– V$SGA_TARGET_ADVICEview

– Estimates the DB time for different SGA target size s based on current size

• PGA Target Advice (introduced in 9 i R1):– V$PGA_TARGET_ADVICEview

– Predicts the PGA cache hit ratio for different PGA sizes– ESTD_TIMEtime column added in 11 g R1

• For all advisors, STATISTICS_LEVEL must be set to at least TYPICAL.

• In Oracle Database 10g, the SGA advisor shows the improvement in DB time that can be

achieved for a particular setting of the total SGA size. This advisor allows you to reduce trial and error in setting the SGA size. The advisor data is stored in the V$SGA_TARGET_ADVICE view.

• V$PGA_TARGET_ADVICE predicts how the PGA cache hit percentage displayed by the V$PGASTAT performance view is impacted when the value of the PGA_AGGREGATE_TARGET parameter is changed. The prediction is performed for various values of the PGA_AGGREGATE_TARGET parameter, selected around its current value. The advice statistic is generated by simulating the past workload run by the instance. In 11g, a new column (ESTD_TIME) is added corresponding to the CPU and I/O time required to process the bytes.



Automatic Memory Management Overview


UntunablePGA

Free

Buffer cache

Large pool

Shared pool

Java poolStreams pool

SQL Areas

Other SGA

SGA Target

PGA Target

10g&11g

OLTP

PG

A m

e mo

ryS

GA

mem

ory

BATCH

Buffer cache

Large pool

Shared pool


SQL Areas

Other SGA

UntunablePGA

Free

BATCH

Buffer cache

Large pool

Shared pool


Other SGA

SQL Areas

UntunablePGA

11g

Memory Target

PGA Target

SGA Target

With Automatic Memory Management, the system causes an indirect transfer of memory from SGA to PGA, and vice versa. It automates the sizing of PGA and SGA according to your workload. This indirect memory transfer relies on the OS mechanism of freeing shared memory. After memory is released to the operating system, the other components can allocate memory by requesting memory from the operating system. Currently, this is implemented on Linux, Solaris, HP-UX, AIX, and Windows. Set your memory target for the database instance and the system then tunes to the target memory size, redistributing memory as needed between the SGA and the aggregate PGA. The illustration above shows the differences between the Oracle Database 10g mechanism and the new Automatic Memory Management with Oracle Database 11g.





11g

Memory Target

MemoryMax Target

250M

350M

ALTER SYSTEM SET MEMORY_TARGET=300M;

11g

Memory Target

MemoryMax Target

300M

350M

The simplest way to manage memory is to allow the database to automatically manage and tune it for you. To do so (on most platforms), you set only a target memory size initialization parameter (MEMORY_TARGET) and a maximum memory size initialization parameter (MEMORY_MAX_TARGET). Because the target memory initialization parameter is dynamic, you can change the target memory size at any time without restarting the database. Maximum memory size serves as an upper limit so that you do not accidentally set the target memory size too high. Because certain SGA components cannot easily shrink or must remain at a minimum size, the database also prevents you from setting the target memory size too low.



Oracle Database 11g Memory Parameters

Oracle Database 11 g Memory Parameters

DB_KEEP_CACHE_SIZEDB_RECYCLE_CACHE_SIZE

DB_nK_CACHE_SIZE

LOG_BUFFERRESULT_CACHE_SIZE

SHARED_POOL_SIZEDB_CACHE_SIZELARGE_POOL_SIZEJAVA_POOL_SIZESTREAMS_POOL_SIZE

SGA_TARGET

SGA_MAX_SIZEMEMORY_MAX_TARGET

MEMORY_TARGET

Others

PGA_AGGREGATE_TARGET

The above graphic shows you the memory initialization parameters hierarchy. Although you only have to set MEMORY_TARGET to trigger Automatic Memory Management, you can still set lower-bound values for various caches. So if the child parameters are user set, they will be the minimum values below which the database will not autotune that component.



Automatic Memory Parameter Dependency

Automatic Memory Parameter Dependency

ST+PAT<=MT<=MMT

MT>0

ST>0 & PAT>0

ST>0 & PAT=0 PAT=MT-ST

ST=0 & PAT>0 ST=min(MT-PAT,SMS)

ST=60%MTPAT=40%MT

MMT>0MT=0

MMT=MTMMT=0

MT=0

Y YN

N

Y

Both SGA and PGA can grow and shrink automatically.

ST>0SGA & PGA

are separatelyautotuned.

Y

Only PGAis autotuned

N

MT can be dynamically

changed later.

SGA and PGA cannotgrow and shrink automatically.

Minimum possible valuesN

N

N

Y

Y

Y

N

The above flowchart describes the relationship between the various memory sizing parameters. If MEMORY_TARGET is set to a nonzero value:

• If SGA_TARGET and PGA_AGGREGATE_TARGET are set, they will be considered to be minimum values for the sizes of SGA and PGA, respectively. MEMORY_TARGET can take values from SGA_TARGET + PGA_AGGREGATE_TARGET to MEMORY_MAX_SIZE.

• If SGA_TARGET is set and PGA_AGGREGATE_TARGET is not, you still autotune both the parameters. PGA_AGGREGATE_TARGET is initialized to a value of (MEMORY_TARGET - SGA_TARGET).

• If PGA_AGGREGATE_TARGET is set and SGA_TARGET is not, you still autotune both the parameters. SGA_TARGET is initialized to a value of min (MEMORY_TARGET -PGA_AGGREGATE_TARGET, SGA_MAX_SIZE (if set by the user)) and will autotune subcomponents.

• If neither is set, they are autotuned without minimum or default values. There is a policy of distributing the total server memory in a fixed ratio to the SGA and PGA during initialization. The policy is to distribute 60% to SGA and 40% to PGA at startup.

If MEMORY_TARGET is not set, or if it is explicitly set to 0 (default value is 0 for 11g):

• If SGA_TARGET is set, the system autotunes only the sizes of the subcomponents of the SGA. PGA is autotuned independently of whether it is explicitly set or not. However, the



whole SGA (SGA_TARGET) and PGA (PGA_AGGREGATE_TARGET) are not autotuned (do not grow or shrink automatically). If neither SGA_TARGET nor PGA_AGGREGATE_TARGET is set, the same policy is followed as present now: PGA is autotuned and the SGA is not autotuned, and parameters for some of the subcomponents must be set explicitly (for SGA_TARGET).

• If only MEMORY_MAX_TARGET is set, MEMORY_TARGET defaults to 0 in manual setup using the text initialization file. Autotuning defaults to 10g R2 behavior for SGA and PGA.

• If SGA_MAX_SIZE is not user set, it is set internally to MEMORY_MAX_TARGET if user sets MEMORY_MAX_TARGET (independent of SGA_TARGET being user set).

In a text initialization parameter file, if you omit the line for MEMORY_MAX_TARGET and include a value for MEMORY_TARGET, the database automatically sets MEMORY_MAX_TARGET to the value of MEMORY_TARGET. If you omit the line for MEMORY_TARGET and include a value for MEMORY_MAX_TARGET, the MEMORY_TARGET parameter defaults to zero. After startup, you can then dynamically change MEMORY_TARGET to a nonzero value if it does not exceed the value of MEMORY_MAX_TARGET. Legend: In the earlier diagram, use the following list to translate abbreviations to parameter names:

• MT = MEMORY_TARGET

• MMT = MEMORY_MAX_TARGET

• ST = SGA_TARGET

• PAT = PGA_AGGREGATE_TARGET

• SMS = SGA_MAX_SIZE



Enabling Automatic Memory Management

Enabling Automatic Memory Management

You can enable Automatic Memory Management by using Enterprise Manager, as shown above:

• On the Database Home page, click the Server tab.

• On the Server page, click the Memory Advisors link in the Database Configuration section.

• On the Memory Advisors page, click Enable to enable Automatic Memory Management. The value in the “Total Memory Size for Automatic Memory Management” field is set by default to the current SGA + PGA size. You can set it to anything more than this but less than the value in Maximum Memory Size.

Note: On the Memory Advisors page, you can also specify the Maximum Memory Size. If you change this field, the database must be automatically restarted for your change to take effect.



Monitoring Automatic Memory Management


When Automatic Memory Management is enabled, you see a graphical representation of the history of your memory size components in the Allocation History section of the Memory Parameters page. The green part in the first graphic represents the PGA and the brownish orange part is all of the SGA. The dark blue below in the lower histogram is the Shared Pool size; light blue corresponds to Buffer Cache. The change in the example displays the possible repartition of memory after the execution of the various demanding queries. Both SGA and PGA might, therefore, shrink. Note that with SGA shrink, its subcomponents also shrink. On this page, you can also access the memory target advisor by clicking the Advice button. This advisor gives you the possible DB time improvement for various total memory sizes. Note: V$MEMORY_TARGET_ADVICE displays the tuning advice for the MEMORY_TARGET initialization parameter.





If you want to monitor the decisions made by Automa tic Memory Management from the command line:• V$MEMORY_DYNAMIC_COMPONENTShas the current

status of all memory components.• V$MEMORY_RESIZE_OPShas a circular history buffer of

the last 800 completed memory resize requests.• V$MEMORY_CURRENT_RESIZE_OPShas current memory

resize operations.• All SGA and PGA equivalents are still in place for

backward compatibility.

The following views provide information about dynamic resize operations:

• V$MEMORY_DYNAMIC_COMPONENTS displays information about the current sizes of all dynamically tuned memory components, including the total sizes of SGA and PGA.

• V$MEMORY_RESIZE_OPS displays information about the last 800 completed memory resize operations (both automatic and manual). This does not include in-progress operations.

• V$MEMORY_CURRENT_RESIZE_OPS displays information about the memory resize operations (both automatic and manual) that are currently in progress.

• V$SGA_CURRENT_RESIZE_OPS displays information about SGA resize operations that are currently in progress. An operation can be a grow or a shrink of a dynamic SGA component.

• V$SGA_RESIZE_OPS displays information about the last 800 completed SGA resize operations. This does not include operations currently in progress.

• V$SGA_DYNAMIC_COMPONENTS displays information about the dynamic components in SGA. This view summarizes information based on all completed SGA resize operations since startup.

• V$SGA_DYNAMIC_FREE_MEMORY displays information about the amount of SGA memory that is available for future dynamic SGA resize operations.



DBCA and Automatic Memory Management

DBCA and Automatic Memory Management

With Oracle Database 11g, Database Configuration Assistant (DBCA) has new options to accommodate AMM. Use the Memory tab of the Initialization Parameters page to set the initialization parameters that control how the database manages its memory usage. You can choose from two basic approaches to memory management:

• Typical: Requires very little configuration and allows the database to manage how it uses a percentage of your overall system memory. Select Typical to create a database with minimal configuration or user input. This option is sufficient for most environments and for DBAs who are inexperienced with advanced database creation procedures. Enter a value in megabytes in the Memory Size field. To use AMM, select the corresponding option in the Typical section of the page. Click Show Memory Distribution to see how much memory the DBCA assigns to SGA and PGA when you do not select the AMM option.

• Custom (uses ASMM or not): Requires more configuration but provides you with more control over how the database uses available system memory. To allocate specific amounts of memory to the SGA and PGA, select Automatic. To customize how the SGA memory is distributed among the SGA memory structures (buffer cache, shared pool, and so on), select Manual and enter specific values for each SGA subcomponent. Review and modify these initialization parameters later in the DBCA.

Note: When you use Database Upgrade Assistant (DBUA) or manual DB creation, the MEMORY_TARGET parameter defaults to 0.



Summary

Summary

In this lesson, you should have learned how to:• Set up SGA sizing initialization parameters• Set up Automatic Memory Management• Use memory advisors


Intelligent Infrastructure Chapter 0 - Page 1

Intelligent Infrastructure



Chapter 7Intelligent Infrastructure

Intelligent Infrastructure



Objectives

Objectives

After completing this lesson, you should be able to :• Create AWR baselines for future time periods• Control automated maintenance tasks• Perform clusterwide analysis of performance by

using Oracle RAC-aware ADDM• Use Resource Manager I/O calibration• Use lightweight jobs with the Scheduler• Improve file accessibility of the SPFILE file



Automatic Workload Repository Baselines

Automatic Workload Repository Baselines

Oracle Database 11 g further enhances the Automatic Workload Repository (AWR) baselines by enabling:• Specification of adaptive thresholds through the ou t-of-

the-box moving window baseline• Scheduling of the creation of a baseline using base line

templates• Renaming of baselines• Setting of expiration dates for baselines

Oracle Database 11g consolidates the various concepts of baselines in Oracle (specifically in Enterprise Manager and RDBMS) into the single concept of the Automatic Workload Repository (AWR) baseline. Oracle Database 11g AWR baselines provide powerful capabilities for defining dynamic and future baselines, and considerably simplify the process of creating and managing performance data for comparison purposes. Oracle Database 11g introduces the concept of moving window baseline. By default, a system-defined moving window baseline is created that corresponds to all the AWR data within the AWR retention period. Oracle Database 11g provides the ability to collect two kinds of baselines: moving window and static baselines. Static baselines can be single or repeating. A single AWR baseline is collected over a single time period. A repeating baseline is collected over a repeating time period (for example, every Monday in June). In Oracle Database 11g, baselines are enabled by default if STATISTICS_LEVEL =TYPICAL or ALL.



Comparative Performance Analysis with AWR Baselines

Comparative Performance Analysiswith AWR Baselines

• AWR baseline contains a set of AWR snapshots for an “interesting or reference” period of time.

• Baseline is key for performance tuning to:– Guide setting of alert thresholds– Monitor performance– Compare advisor reports

time

Performance

Actual

AWR Baseline Normal

What is the proper threshold to set on a performance metric? What is it that you want to detect? If you want to know whether the performance metric value indicates that the server is nearing capacity, an absolute value is correct. But if you want to know whether the performance is different today than it was at this time last week, or last month, the current performance must be compared to a baseline. A baseline is a set of snapshots taken over a period of time. These snapshots are grouped statistically to yield a set of baseline values that vary over time. For example, the number of transactions per second in a certain database varies depending on the time of the day. The values for transactions per second are higher during working hours and lower during nonworking hours. The baseline records this variation and can be set to alert you if the current number of transactions per second is significantly different from the baseline values. Oracle Database 11g baselines provide the data required to calculate time-varying thresholds based on the baseline data. The baseline allows a real-time comparison of performance metrics with baseline data, and can be used to produce AWR reports that compare two periods.



Moving Window Baseline

Moving Window Baseline

There is one moving window baseline:• SYSTEM_MOVING_WINDOW: A moving window baseline

that corresponds to the last eight days of AWR data• Created out-of-the-box in Oracle 11 g

By default, the adaptive thresholds functionality c omputes statistics on this baseline.

Oracle Database automatically maintains a system-defined moving window baseline. The default window size for the system-defined moving window baseline is the current AWR retention period, which by default is eight days. If you are planning to use adaptive thresholds, consider using a larger moving window (such as 30 days) to accurately compute threshold values. You can resize the moving window baseline by changing the number of days in the moving window to a value that is equal to or less than the number of days in the AWR retention period. Therefore, to increase the size of a moving window, you first need to increase the AWR retention period accordingly. The system-defined baseline provides a default out-of-the-box baseline for Enterprise Manager (EM) performance screens to compare the performance with the current database performance. Note: The default retention period for snapshot data has been changed from seven days to eight days in Oracle Database 11g to ensure the capture of an entire week of performance data.



Baselines in Performance Page Settings

Baselines in Performance Page Settings

The data for any baseline defined in the past is available in Oracle Database 11g. The baseline data may be displayed on the Performance page of EM. You have three display options:

• Do not show baseline information.

• Show the information from a specified static baseline.

• Show the information from the system moving window baseline.

Note: The system moving window baseline becomes valid after sufficient data has been collected and the statistics calculation occurs. By default, the statistics calculation is scheduled for every Sunday at midnight.



Baseline Templates

Baseline Templates

• Templates enable you to schedule the creation of baselines for any time period(s) of interest in the future:– Single time period in the future– Repeating schedule

• Examples:– A known holiday weekend– Every Monday morning from 10 AM to 2 PM

• When the end time for a baseline template changes from future to past, MMONdetects the change and creates the baseline.

By creating baselines for future time periods, you can mark time periods that you know will be interesting. For example, you may want the system to automatically generate a baseline for every Monday morning for the whole year, or you can ask the system to generate a baseline for an upcoming holiday weekend if you suspect that it is a high-volume weekend. Previously, you could create baselines only on snapshots that existed. With Oracle Database 11g, a nightly MMON task goes through all the templates for baseline generation and checks to see if any time ranges have changed from the future to the past within the last day. For the relevant time periods, the MMON task then creates a baseline.



Creating AWR Baselines

Creating AWR Baselines

You can create two types of AWR baselines: single and repeating. The “Create Baseline: Baseline Interval Type” page gives the following explanations. The single baseline has a single and fixed time interval: for example, from Jan 1, 2007, at 10:00 AM, to Jan 1, 2007, at 12:00 PM. The repeating type of baseline has a time interval that repeats over a time period: for example, every Monday from 10:00 AM to 12:00 PM for the year 2007. To view the AWR Baseline page, click the AWR Baselines link on the Server tab of the Database Instance page. On the Baseline page, click Create and follow the Wizard to create your baseline. Note: Before you can set up AWR baseline metric thresholds for a particular baseline, you must compute the baseline statistics. Select Schedule Statistics Computation from the actions menu to compute the baseline statistics. There are several other actions available.



Single AWR Baseline

Single AWR Baseline

If you selected the Single option in the previous step, you access the page shown in this slide. Select the time period corresponding to your interest in one of two ways:

• Select the Snapshot Range option, and then set the Period Start Time and Period End Time by following the directions on the page. If the icon that you want to select is not shown, you can change the chart time period.

• Specify the Time Range, with a date and time for start and end times. With Time Range, you can choose times in the future.

When you are finished, click Finish to create the static baseline. Note: If the End Time of the baseline is in the future, a baseline template with the same name as the baseline is created.



Creating a Repeating Baseline Template


You can define repeating baselines by using EM. In the Wizard, after selecting Repeating in step 1, you can specify the repeat interval as shown above. You specify the start time and the duration of the baseline. Then specify when the baseline statistics will be collected (daily or weekly; if weekly, for which days). Specify the range of dates for which the baseline template will collect statistics. Retention Time sets an expiration value for the baseline; a value of NULL indicates that the baseline never expires.



Generate a Baseline Template for a Single Time Period

Generate a Baseline Template for a Single Time Period

BEGIN

DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE_TEMPLATE(

start_time => to_date('21-JUN-2008','DD-MON-YYYY'),

end_time => to_date('21-SEP-2008','DD-MON-YYYY'),

baseline_name => 'FALL08',

template_name => 'FALL08',

expiration => NULL ) ;

END;

Interesting time period

T4 T5 T6 ….. Tx Ty Tz…..

You can now create a template for how baselines are to be created for different time periods in the future, for predictable schedules. If any part of the period is in the future, use the CREATE_BASELINE_TEMPLATE procedure. For the baseline template, when the end time becomes a time in the past, a task automatically creates a baseline for the specified time period. The example creates a baseline template that automatically creates a baseline when 0:0:0 21-Sep-2008 is in the past. You no longer need the start-snapshot and end-snapshot identifiers when using time-based definitions in baseline creation in Oracle Database 11g. For the CREATE_BASELINE_TEMPLATE procedure, you can also now specify expiration duration for the baseline that is created from the template. The expiration duration, specified in days, represents the number of days you want the baselines to be maintained. A value of NULL means that the baselines never expire. To create a baseline over a period in the past, use the CREATE_BASELINE procedure (as in Oracle Database 10g). The CREATE_BASELINE procedure has one new parameter: expiration duration. Expiration duration has the same meaning as it does for CREATE_BASELINE_TEMPLATE.




Creating a RepeatingBaseline Template

BEGINDBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE_TEMPLATE( day_of_week => 'SATURDAY',

hour_in_day => 6, duration => 20,start_time => to_date('21-JUN-2007','DD-MON-YYYY'),end_time => to_date('21-JUN-2008','DD-MON-YYYY'),baseline_name_prefix => 'SAT_MAINT_WIN'template_name => 'SAT_MAINT_WIN', expiration => 90,dbid => NULL );

END;

Use the CREATE_BASELINE_TEMPLATE procedure to generate baseline templates that automatically create baselines for a contiguous time period based on a repeating time schedule. You can also specify whether you want the baseline to be automatically removed after a specified expiration interval (expiration ). The example above generates a template that creates a baseline for a period corresponding to each SATURDAY_MAINTENANCE_WINDOW for a year. The baseline is created over a 20-hour period (duration ) that starts at 6:00 AM (hour_in_day ) each Saturday (day_of_week ). The baseline is named ‘SAT_MAINT_WIN’ with time information appended to make the name unique. The template is named ‘SAT_MAINT_WIN’, and each baseline will be kept for 90 days (expiration ). This template is created for the local database ( dbid => NULL ). Use this baseline to compare the resources that are used each Saturday during the maintenance window.



Changes to Procedures and Views

Changes to Procedures and Views

CREATE_BASELINE_TEMPLATE

SELECT_BASELINE_METRICFunctions

MODIFY_BASELINE_WINDOW_SIZE

RENAME_BASELINE

Procedures

DBMS_WORKLOAD_REPOSITORYPackageNew

ModifiedNew

DBA_HIST_BASELINE_TEMPLATE

DBA_HIST_BASELINEDBA_HIST_BASELINE_DETAILSViews

The first table above shows the set of PL/SQL interfaces offered by Oracle Database 11g in the DBMS_WORKLOAD_REPOSITORY package for administration and filtering. MODIFY_BASELINE_WINDOW_SIZE enables you to modify the size of the SYSTEM_MOVING_WINDOW. The data dictionary views shown in the second table support AWR baselines.

• DBA_HIST_BASELINE: Has been modified to support the SYSTEM_MOVING_WINDOW baseline and the baselines generated from templates. Additional information includes the date created, time of last statistics calculation, and type of baseline.

• DBA_HIST_BASELINE_DETAILS: Displays information that enables you to determine the validity of a given baseline, such as whether there was a shutdown during the baseline period and the percentage of the baseline period that is covered by the snapshot data.

• DBA_HIST_BASELINE_TEMPLATE: Holds the baseline templates. This view provides the information needed by MMON to determine when a baseline will be created from a template and when the baseline should be removed.

For additional details, see the Oracle Database Reference.



Performance Monitoring and Baselines


• Performance alert thresholds are difficult to determine:– Expected metric values vary by workload type.– Expected metric values vary by system load.

• Baselines can capture metric value statistics:– Automatically computed over the

SYSTEM_MOVING_WINDOW

– Manually computed over static baselines

When properly set, alert thresholds provide a valuable service—an alert—by indicating a performance metric that is at an unexpected value. Unfortunately, in many cases the expected value varies with the workload type, system load, time of day, or day of the week. Baselines associated with certain workload types or days of the week capture the metric values of that period. The baseline can then be used to set the threshold values when similar conditions exist. Baselines capture metric values. The statistics for baselines are computed to place a minimal load on the system; statistics for static baselines are manually computed. You can schedule statistics computation on the AWR Baselines page. Statistics for SYSTEM_MOVING_WINDOW are automatically computed according to the BSLN_MAINTAIN_STATS_SCHED schedule. By default, this schedule starts the job every week at noon on Saturday.





• Baseline metric statistics determine alert threshol ds:– Unusual values compared with baseline data =

significance level thresholds– Close or exceeding peak value compared with baselin e

data = percentage of maximum thresholds

Metric statistics computed over a baseline enable you to set thresholds that compare the baseline statistics to the current activity. There are three methods of comparison: significance level, percentage of maximum, and fixed values. Thresholds based on significance level use statistical relevance to determine the current values that are unusual. In simple terms, if the significance level is set to .99 for a critical threshold, the threshold is set where 1% of the baseline values fall outside this value and any current values that exceed this value trigger an alert. A higher significance level of .999 or .9999 causes fewer alerts to be triggered. Thresholds based on percentage of maximum are calculated based on the maximum value captured by the baseline. Threshold values based on fixed values are set by the DBA. No baseline is required.



Defining Alert Thresholds Using Static Baseline

Defining Alert Thresholds Using Static Baseline

After AWR baseline statistics are computed for a particular baseline, you can set metric thresholds specific to your baseline. Compute baseline statistics directly from the Baselines page (as previously discussed).

• Then open the AWR Baseline Metric Thresholds page and select the type of metrics that you want to set.

• When finished, select a metric and click Edit Thresholds.

• On the corresponding Edit AWR Baseline Metric Thresholds page, specify your thresholds in the Thresholds Settings section, and then click Apply Thresholds.

You can specify thresholds based on the statistics computed for your baseline. This is illustrated in the example above. In addition to “Significance Level,” the other possibilities are “Percentage of Maximum” and “Fixed Values.” Note: After a threshold is set using Baseline Metric Thresholds, the previous threshold values are forgotten forever and the statistics from the associated baseline are used to determine the threshold values until they are cleared (by using the Baseline Metric Threshold UI or the PL/SQL interface).



Using EM to Configure Adaptive Thresholds

Using EM to Configure Adaptive Thresholds

Oracle Database 11g EM provides significant usability improvements in the selection of adaptive thresholds for database performance metrics, with full integration with AWR baselines as the source for the metric statistics. EM offers a quick configuration option in a one-click starter set of thresholds based on online transaction processing (OLTP) or Data Warehouse workload profiles. Select the appropriate workload profiles from the subsequent pop-up window. With this simple selection, the system automatically configures and evolves adaptive thresholds based on the SYSTEM_MOVING_WINDOW baseline for the groups of metrics that best correspond to the chosen workload.



Using EM to Quickly Configure Adaptive Thresholds

Using EM to Quickly ConfigureAdaptive Thresholds

On the OLTP Threshold settings page, configure the desired workload baselines. When it is configured, you can edit the threshold levels by using the Edit Threshold button. The Warning Level and Critical Level columns indicate the type of alert generated. Significance Level indicates whether the level of observation is at or above a certain value. The following significance level thresholds are supported:

• High: Significant at 0.95 level (5 in 100)

• Very High : Significant at 0.99 level (1 in 100)

• Severe: Significant at 0.999 level (1 in 1,000)

• Extreme: Significant at 0.9999 level (1 in 10,000)

Tip : When editing threshold levels, set the significance level thresholds conservatively and experimentally at first, and then observe the number and significance of alerts. Higher significance levels reduce the number of alerts. The threshold values are determined by examining the statistics for the metric values observed over the baseline time period. The system sets the thresholds based on prior data from the system itself and some metadata provided by you. This is significantly easier in the multitarget case, because you no longer need to know the system-specific metric. The statistics to monitor are the maximum value and the significance levels. The significance levels let you set the threshold to a value that is statistically significant at the stated level (for example, 1 in 1,000).



Changing Adaptive Threshold Settings

Changing Adaptive Threshold Settings

Thresholdadapts

automatically

Baselinecalculation

Observedvalue

After the adaptive thresholds are set, you can change their values (if necessary). On the Edit AWR Baseline Metric Thresholds page corresponding to the metric that you want to modify, you see the graphical history of the observed value for the metric, the materialization of the computed baseline value, and the corresponding adaptive threshold.



Automated Maintenance Tasks

Automated Maintenance Tasks

10 pm – 2 am Mon to Fri 6 am – 2 am Sat to Sun

Maintenance Windows

Oracle Database 10g introduced the execution of automated maintenance tasks during a maintenance window. The automated tasks are statistics collection, segment advisor, and Automatic SQL Tuning. With Oracle Database 11g, the Automated Maintenance Tasks feature relies on the Resource Manager being enabled during the maintenance windows. Thus, the resource plan associated with the window is automatically enabled when the window opens. The goal is to prevent maintenance work from consuming excessive amounts of system resources. Each maintenance window is associated with a resource plan that specifies how the resources will be allocated during the window duration. In Oracle Database 11g, WEEKNIGHT_WINDOW and WEEKEND_WINDOW (defined in Oracle Database 10g) are replaced with daily maintenance windows. Automated tasks are assigned to specific windows. All daily windows belong to MAINTENANCE_WINDOW_GROUP by default. However, you are still free to define other maintenance windows and change the start times and durations for the daily maintenance windows. Likewise, maintenance windows that are deemed unnecessary can be disabled or removed. The operations can be done using EM or Scheduler interfaces.



Default Maintenance Plan

Default Maintenance Plan

SQL> SELECT name FROM V$RSRC_PLAN2 WHERE is_top_plan = 'TRUE';

NAME--------------------------------DEFAULT_MAINTENANCE_PLAN

When a maintenance window opens, DEFAULT_MAINTENANCE_PLAN in the Resource Manager is automatically set to control the amount of CPU used by the automated maintenance tasks. To be able to give different priorities to each possible task during a maintenance window, various consumer groups are assigned to DEFAULT_MAINTENANCE_PLAN. The hierarchy between groups and plans is shown above. For high-priority tasks:

• Optimizer Statistics Gathering automatic task is assigned to the ORA$AUTOTASK_STATS_GROUP consumer group

• Segment Advisor automatic task is assigned to the ORA$AUTOTASK_SPACE_GROUP consumer group

• Automatic SQL Tuning automatic task is assigned to the ORA$AUTOTASK_SQL_GROUP consumer group

Note: If necessary, you can manually change the percentage of CPU resources allocated to the various automated maintenance task consumer groups inside ORA$AUTOTASK_HIGH_SUB_PLAN.



Automated Maintenance Task Priorities

Automated Maintenance Task Priorities

Maintenancewindow

Run Job1with

urgentpriority.

Run Job2with

urgentpriority.

Run Job3withhigh

priority.

… …

MMON

ABP

Job nJob 1 …

DBA_AUTOTASK_TASK

Stats

Space

SQL

urgent

high

medium

Run Job3with

mediumpriority.

Run Job4with

mediumpriority.

The Automated Maintenance Tasks feature is implemented by Autotask Background Process (ABP). ABP functions as an intermediary between automated tasks and the Scheduler. Its main purpose is to translate automated tasks into AUTOTASK jobs for execution by the Scheduler. Just as important, ABP maintains a history of execution of all tasks. ABP stores its private repository in the SYSAUX tablespace; you view the repository through DBA_AUTOTASK_TASK. ABP is started by MMON at the start of a maintenance window. Only one ABP is required for all instances. The MMON process monitors ABP and restarts it if necessary. ABP determines the list of jobs that must be created for each maintenance task. This list is ordered by priority: urgent, high, and medium. Within each priority group, jobs are arranged in the preferred order of execution. ABP creates jobs in the following manner: all urgent-priority jobs are created first, all high-priority jobs are created next, and all medium-priority jobs are created last. ABP assigns jobs to various Scheduler job classes. These job classes map the job to a consumer group based on priority. Note: With Oracle Database 11g, there is no job that is permanently associated with a specific automated task. Therefore, it is not possible to use DBMS_SCHEDULER procedures to control the behavior of automated tasks. Use the DBMS_AUTO_TASK_ADMIN procedures instead.



Controlling Automated Maintenance Tasks

Controlling Automated Maintenance Tasks

The Automated Maintenance Tasks feature determines when—and in what order—tasks are performed. As a DBA, you can control the following:

• If the maintenance window turns out to be inadequate for the maintenance workload, adjust the duration and start time of the maintenance window.

• Control the resource plan that allocates resources to the automated maintenance tasks during each window.

• Enable or disable individual tasks in some or all maintenance windows.

• In an Oracle RAC environment, shift maintenance work to one or more instances by mapping maintenance work to a service. Enabling the service on a subset of instances shifts maintenance work to these instances.

As shown above, using EM is the preferred way to control Automated Maintenance Tasks. However, you can also use the DBMS_AUTO_TASK_ADMIN package.



Important I/O Metrics for Oracle Databases

Metric = MBPS

Important I/O Metrics for Oracle Databases

OLTP(Small random I/O)

DW/OLAP(Large sequential I/O)

Need high RPM andfast seek time

Need largeI/O channel

Metric = IOPSand latency

Disk bandwidth Channel bandwidth

The illustration above briefly summarizes the types of I/Os issued by the Oracle Database processes. The database I/O workload typically consists of small random I/O and large sequential I/O. Small random I/O is more prevalent in an OLTP application environment in which each foreground reads a data block into the buffer cache for updates and the changed blocks are written in batches by the dbwr process. Large sequential I/O is common in an online analytical processing (OLAP) application environment. The performance of an OLTP application depends on how fast a small I/O is serviced, which, in turn, depends on how fast the disk spins and finds the data. Large I/O performance depends on the capacity of the I/O channel that connects the server to the storage array; large I/O throughput is better when the channel capacity is larger. IOPS (I/O per second): This metric represents the number of small random I/O that can be serviced in a second. The IOPS rate mainly depends on how fast the disk media can spin. The IOPS rate from a storage array can be increased either by adding more disk drives or by using disk drives with a higher rotations per minute (RPM) rate. MBPS (megabytes per second): The rate at which data can be transferred between the computing server node and the storage array depends on the capacity of the I/O channel that is used to transfer data. More data can be transferred through a wider pipe.

The throughput of a streaming data application depends on how fast this data can be transferred. Throughput is measured by using the MBPS metric. Even though the disks themselves have an upper limit on the amount of sequential data they can transfer, it is often channel capacity that limits the overall throughput of the system. For example,



a host connected to a Network-attached storage (NAS) server through a GigE switch is limited by a transfer capacity of 128 MBPS. However, there are usually multiple disks in the NAS that can, together, provide more than 128 MBPS. The channel resource, therefore, becomes the limiting resource in this case. I/O latency: Latency is another important metric that is used to measure the performance of an I/O subsystem. Traditionally, latency is simply the time for the disk to access a particular sector on the disk. But from the database point of view, latency represents all the time it takes for a submitted I/O request to be serviced by the storage. In other words, it represents the overhead before the first byte of a transfer arrives after an I/O request has been submitted. Latency values are more commonly used for small random I/O when tuning a system. If there are too many I/O requests queued up against a disk, the latency increases as the wait time in the queue increases. To improve the latency of I/O requests, data is usually striped across multiple spindles so that all I/O requests to a file do not go to the same disk. Higher latency usually indicates an overloaded system. Other than the main resources mentioned above, there are storage array components that can affect I/O performance. Array vendors provide caching mechanisms to improve read throughput, but their real benefit is questionable in a database environment, because Oracle Database uses caches and read-ahead mechanisms so that data is available directly from RAM rather than from the disks.



I/O Calibration and Enterprise Manager

I/O Calibration and Enterprise Manager

To determine the previously discussed I/O metrics, you can use the I/O Calibration tool from the Enterprise Manager Performance page or PL/SQL interface. I/O Calibration is a modified version of the ORION tool and is based on the asynchronous I/O library. Because calibration requires issuing enough I/O to saturate the storage system, any performance-critical sessions will be negatively impacted. Thus, you should run I/O Calibration only when there is little activity on your system. I/O Calibration takes approximately 10 minutes to run. You can launch an I/O Calibration task directly from EM (as shown above):

• Click Performance tab. On the Performance page, click the I/O tab > I/O Calibration button.

• On the I/O Calibration page, specify the approximate number of physical disks attached to your database storage system and the maximum tolerable latency for a single-block I/O request.

• Then, in the Schedule section of the I/O Calibration page, specify when to execute the calibration operation. Click the Submit button to create a corresponding Scheduler job.

• On the Scheduler Jobs page, you can see the amount of time it takes for the calibration task to run.

• When finished, view the following results of the calibration operation on the I/O Calibration page: maximum I/O per second, maximum megabytes per second, and average actual latency metrics.



I/O Calibration and the PL/SQL Interface

I/O Calibration and the PL/SQL Interface

SQL> exec dbms_resource_manager.calibrate_io( -num_disks=>1, -max_latency=>10, -max_iops=>:max_iops, -max_mbps=>:max_mbps, -actual_latency=>:actual_latency);

PL/SQL procedure successfully completed.

SQL> SELECT max_iops, max_mbps, max_pmbps, latency2 FROM DBA_RSRC_IO_CALIBRATE;

MAX_IOPS MAX_MBPS MAX_PMBPS LATENCY---------- ---------- ---------- ----------

137 12 6 64

You can run the I/O Calibration task by using the PL/SQL interface. Execute the CALIBRATE_IO procedure from the DBMS_RESOURCE_MANAGER package. This procedure calibrates the I/O capabilities of the storage. The calibration status and results are available from the V$IO_CALIBRATION_STATUS and DBA_RSRC_IO_CALIBRATE views. Here is a brief description of the parameters that you can specify for the CALIBRATE_IO procedure:

• num_disks : Approximate number of physical disks in the database storage

• max_latency : Maximum tolerable latency (in milliseconds) for database-block-sized I/O requests

• max_iops : Maximum number of I/O requests per second that can be sustained. The I/O requests are randomly distributed, database-block-sized reads.

• max_bps : Maximum throughput of I/O that can be sustained (in megabytes per second). The I/O requests are randomly distributed 1 MB reads.

• actual_latency : Average latency of database-block-sized I/O requests at max_iops rate (in milliseconds)

Usage notes:

• Only users with the SYSDBA privilege can run this procedure.

• Only one calibration can run at a time. If another calibration is initiated at the same time, it fails.



• For an Oracle RAC database, the workload is simultaneously generated from all instances.

• The latency time is computed only when the TIMED_STATISTICS initialization parameter is set to TRUE (which is set when STATISTICS_LEVEL is set to TYPICAL or ALL).



I/O Statistics: Overview

I/O Statistics: Overview

V$IOSTAT_FUNCTION

V$IOSTAT_FILE

V$IOSTAT_CONSUMER_GROUP

AWR and EM

.

To give a consistent set of statistics for all I/O issued from an Oracle instance, Oracle Database 11g introduces a set of virtual views that collect I/O statistics in three dimensions:

• RDBMS components: Components are grouped by their functionality into 12 categories (shown above).

• When Resource Management is enabled, I/O statistics are collected for all consumer groups that are part of the currently enabled resource plan.

• I/O statistics are also collected for the individual files that have been opened.

Each dimension has statistics for read and write operations. Because read/write can occur in single-block or multiblock operations, they are separated into four operations (as shown above). For each operation type, the number of corresponding requests and the amount of megabytes are cumulated. In addition to these, the total I/O wait time in milliseconds and the number of total waits are also cumulated for both component and consumer group statistics. For file statistics, total service time in microseconds is accumulated, in addition to statistics for single-block reads. Virtual views show cumulative values for statistics. Component and consumer group statistics are transformed into AWR metrics that are sampled regularly and stored in the AWR repository. You can retrieve those metrics across a timeline directly on the Performance page of EM. Note: V$IOSTAT_NETWORK collects network I/O statistics that are related to accessing files on a remote database instance.



I/O Statistics and Enterprise Manager


You can retrieve I/O statistics directly on the Performance page in EM:

• On the Performance page, click I/O subtab located under Average Active Session graph.

• On the I/O subpage, you see a breakdown of I/O statistics on three possible dimensions: I/O Function, I/O Type, and Consumer Group.

• Select one of the options to look at the corresponding dimension graphs.

The slide shows the two graphs corresponding to the I/O Function dimension:

• I/O Megabytes per Second (by RDBMS component)

• I/O Requests per Second (by RDBMS component)

Note: The “Others” RDBMS component category corresponds to everything that is not directly issued from SQL (for example, PL/SQL and Java).





From the I/O Function statistic graphs, you can drill down to a specific component by clicking that component. In the example above, you drill down to the Buffer Cache Reads component. This takes you to the “I/O Rates by I/O Function” page, where you can see three important graphs for that particular component: MBPS, IOPS, and wait time.



ADDM Enhancements in Oracle Database 11g

ADDM Enhancements in Oracle Database 11 g

• ADDM for Oracle Real Application Clusters (RAC)• Directives (finding suppression)• DBMS_ADDMpackage



Automatic Database Diagnostic Monitor (ADDM) in Oracle Database 10g

Automatic Database Diagnostic Monitor (ADDM) in Oracle Database 10 g

Intelligent infrastructure

Spacemanagement

Backup and recoverymanagement

Storagemanagement

Database management

Application and SQLmanagement

System Resourcemanagement

Oracle Database 10g introduced the Automatic Database Diagnostic Monitor (ADDM), a self-diagnostic engine built directly into the Oracle Database. ADDM is automatically invoked by the Oracle Database and performs analysis to determine the major issues on the system on a proactive basis. In many cases, ADDM recommends solutions and quantifies expected benefits.



Automatic Database Diagnostic Monitor for Oracle RAC

Automatic Database Diagnostic Monitor for Oracle RAC

Database ADDM

AWR

Instance ADDM

Self-diagnostic engine

Inst1 Inst n

…

Oracle Database 11g further extends database management functionality by offering clusterwide analysis of performance. A special mode of ADDM analyzes an Oracle RAC database cluster and reports on issues that are affecting the entire cluster, and those that are affecting individual instances. When the advisor runs in this mode, it is called the database ADDM. You can run the advisor for a single instance, which is equivalent to the Oracle Database 10g ADDM and is now called the instance ADDM. The database ADDM for RAC is not just a report of reports. It has independent analysis appropriate for RAC.



ADDM for RAC

• Identifies the most critical performance problems f or the entire RAC cluster database

• Runs automatically when taking AWR snapshots (the default)

• Performs databasewide analysis of:– Global resources—for example, I/O and global locks– High-load SQL, hot blocks– Global cache interconnect traffic– Network latency issues– Skew in instance response times

• Is used by DBAs to analyze cluster performance

ADDM for RAC

The database ADDM has access to AWR data generated by all instances, making the analysis of global resources more accurate. The database ADDM and instance ADDM run on continuous time periods that can contain instance startup and shutdown. In the case of the database ADDM, there may be several instances that are shut down or started during the analysis period. You must, however, maintain the same database version throughout the analysis period. The database ADDM runs automatically after each snapshot is taken. The automatic instance ADDM runs are the same as in Oracle Database 10g. You can also perform analysis on a subset of instances in the cluster. This is called partial analysis ADDM. I/O capacity finding (The I/O system is overused.) is a global finding, because it concerns a global resource affecting multiple instances. A local finding concerns a local resource or issue that affects a single instance. For example, a CPU-bound instance results in a local finding about the CPU. Though ADDM can be used during application development to test changes to the application, the database system, or the hosting machines, the database ADDM is targeted at DBAs.



ADDM for RAC

ADDM for RAC

Specified in the DBMS_ADVISOR.SET_DEFAULT_TASK_PARAMETERprocedure:

Any value

Comma-separated list of instance numbers (1,2,5..)

“UNUSED” (default)

Value of INSTANCES

Instance ADDM. The instance specified in the INSTANCEparameter is analyzed.

A positive integer (For example: “1”)

Partial analysis ADDM. Only instances specified in the INSTANCESparameter are analyzed.

“0” or “UNUSED”(default)

Database ADDM (all instances) “0” or “UNUSED”(default)

ADDM Analysis ModeValue of INSTANCE

The distinction between the database ADDM and instance ADDM is based on the value of the advisor INSTANCE parameter. When the value is 0 or UNUSED, the task is a database ADDM. When the value is numeric, it is the instance ID for an instance ADDM task. The results of an ADDM analysis are stored in the advisor framework and accessed like any ADDM task in Oracle Database 10g. You select to run the database ADDM, instance ADDM, or partial analysis by setting the INSTANCE and INSTANCES parameters in the DBMS_ADVISOR.SET_DEFAULT_TASK_PARAMETER procedure. Note: Partial ADDM is not currently exposed through EM, but command-line PL/SQL APIs exist to perform partial analysis. It is recommended that you use the DBMS_ADDM package instead.



EM Support for ADDM for RAC

EM Support for ADDM for RAC

Finding History page:

Oracle Database 11g EM displays the ADDM analysis on the Cluster Database Home page. The Findings Table is displayed in the Performance Analysis section. For each finding, the Affected Instances column displays the number (n of n) of instances affected. The display also indicates the percentage impact for each instance. Further drilldown on the findings takes you to the ADDM Finding Details page. The ADDM Finding Details Page enables you to see Finding History. When you click the Finding History button, you see a page with a chart on the top plotting the impact in active sessions for the finding over time. The default display period is 24 hours. The drop-down list also supports viewing for seven days. At the bottom of the display, a table similar to the Results section is shown, displaying all findings for this named finding. From this page, you can set filters on the findings results. Different types of findings (for example, CPU, Logins, and SQL) have different kinds of criteria for filtering. Note: Only automatic runs of ADDM are considered for Finding History. These results reflect the unfiltered results only.



DBMS_ADDM Package

DBMS_ADDMPackage

The DBMS_ADDMpackage eases ADDM management. It consists of the following procedures and functions:

Create an ADDM task for analyzing a subset of instances.

ANALYZE_PARTIAL

Delete a created ADDM task (of any kind).DELETE

Get the default text report of an executed ADDM task.

GET_REPORT

Create an ADDM task for analyzing a local instance.

ANALYZE_INST

ANALYZE_DB Create an ADDM task for analyzing the database globally.

The following example illustrates the creation and execution of a database ADDM task:

SQL> var tname varchar2(60);

SQL> BEGIN

SQL> :tname := 'my database ADDM task';

SQL> dbms_addm.analyze_db(:tname, 1, 2);

SQL> END;

Here, parameters 1 and 2 are the start and end snapshots, respectively. You can then use the GET_REPORT procedure to view the result:

SQL> SELECT dbms_addm.get_report(:tname) FROM DUAL;



Advisor-Named Findings and Directives

Advisor-Named Findings and Directives

SQL> select finding_name from dba_advisor_finding_names ;FINDING_NAME----------------------------------------Top Segments by I/OTop SQL by "Cluster" Wait. . .Undersized Redo Log BufferUndersized SGAUndersized Shared PoolUndersized Streams Pool

• The DBA_ADVISOR_FINDING_NAMESview lists all possible findings.

• Advisor results are now classified and named, andexist in the DBA{USER}_ADVISOR_FINDINGSview.

Oracle Database 10g introduced the advisor framework and various advisors to help DBAs manage databases efficiently. These advisors provide feedback in the form of findings. Oracle Database 11g now classifies these findings, so that you can query the advisor views to understand how often a given type of finding recurs in the database. A FINDING_NAME column has been added to the following advisor views:

• DBA_ADVISOR_FINDINGS

• USER_ADVISOR_FINDINGS



Using the DBMS_ADDM Package

Using the DBMS_ADDMPackage

• Create an ADDM directive, which filters “Undersized SGA” findings:

• Possible findings are found in DBA_ADVISOR_FINDING_NAMES.

SQL> var tname varchar2(60);SQL> BEGIN

2 dbms_addm.insert_finding_directive (NULL,3 'My undersized SGA directive',4 'Undersized SGA', 5 2, 6 10); 7 :tname := 'my instance ADDM task';8 dbms_addm.analyze_inst (:tname, 1, 2); 9 END;

10 /SQL> SELECT dbms_addm.get_report (:tname) from dual;

You can use possible finding names to query the findings repository to get all occurrences of that specific finding. In the example above, you see the creation of an instance ADDM task with a finding directive called My undersized SGA directive . When the task name is NULL, it applies to all subsequent ADDM tasks. The finding name (“Undersized SGA”) must exist in the DBA_ADVISOR_FINDING_NAMES view (which lists all the findings) and is case-sensitive. The result of DBMS_ADDM.GET_REPORT shows an “Undersized SGA” finding only if the finding is responsible for at least two (min_active_sessions ) average active sessions during the analysis period, and this constitutes at least 10% (min_perc_impact ) of the total database time during that period. The following are some of the procedures to use directives:

• INSERT_FINDING_DIRECTIVE

• INSERT_SQL_DIRECTIVE

• INSERT_PARAMETER_DIRECTIVE

• DELETE_FINDING_DIRECTIVE

• DELETE_SQL_DIRECTIVE

• DELETE_SEGMENT_DIRECTIVE

Note: For a complete description of available procedures, see the Oracle Database 11g PL/SQL References and Types documentation.



New ADDM Views

New ADDM Views

• DBA{USER}_ADDM_TASKS: Displays every executed ADDM task. Is an extension of the corresponding advisor views.

• DBA{USER}_ADDM_INSTANCES: Displays instance-level information for ADDM tasks that are completed

• DBA{USER}_ADDM_FINDINGS: Displays extensions of the corresponding advisor views

• DBA{USER}_ADDM_FDG_BREAKDOWN: Displays the contribution for each finding from the different in stances for database and partial ADDM

• DBA_ADDM_SYSTEM_DIRECTIVES: Displays the directives in the system that affect all tasks

• DBA_ADDM_TASK_DIRECTIVES: Displays the directives in the system affecting a specific task. Use TASK_ID or TASK_NAME

to limit to a specified task.

Note: For a complete description of available procedures, see the Oracle Database Reference.



Resource Manager: New EM Interface

Resource Manager: New EM Interface

Using EM, you can access the Resource Manager section from the Server page. The Resource Manager section is organized in the same way as the Database Resource Manager. Clicking the Getting Started link takes you to the “Getting Started with Database Resource Manager” page, which provides a brief description of each step and the links to the corresponding pages. Note: The DBMS_RESOURCE_MANAGER PL/SQL interface has some deprecated and new parameters. For example, you should no longer use CPU_Pn parameters of the CREATE_PLAN_DIRECTIVE procedure, but replace them by MGMT_Pn parameters. Another example is to use the new SWITCH_FOR_CALL parameter instead of SWITCH_TIME_IN_CALL parameter of the CREATE_PLAN_DIRECTIVE procedure. For more information refer to the Oracle Database Administrator’s Guide.



Resource Plans Created by Default

Resource Plans Created by Default

When you create an Oracle 11g Database, the Resource Plans (shown above) are created by default.



Default Plan

Default Plan

With the exception of the DEFAULT_PLAN resource plan, none of these default plans are active. However, DEFAULT_PLAN has no limits set for its thresholds. As you can see, Oracle Database 11g introduces two I/O limits that you can define as thresholds in a resource plan:

• I/O Limit (MB)

• I/O Request Limit (Requests)



I/O Resource Limit Thresholds

I/O Resource Limit Thresholds

When you create a Resource Plan directive, you can specify the I/O resource limits. The example above shows you how to do this in EM and PL/SQL. You can specify the following arguments:

• switch_io_megabytes : Specifies the amount of I/O (in MB) that a session can issue before an action is taken. Default is NULL, which means unlimited.

• switch_io_reqs : Specifies the number of I/O requests that a session can issue before an action is taken. Default is NULL, which means unlimited.



Resource Manager Statistics

Resource Manager Statistics

You can also look at the Resource Manager Statistics page, which displays statistics for only the current active plan.



New Scheduler Feature: Lightweight Jobs

New Scheduler Feature: Lightweight Jobs

Persistent lightweight jobs:• Created from a job template• Recoverable• JOB_STYLE => LIGHTWEIGHT

Some customers need to create hundreds of jobs each second. With regular jobs, each job creates a database object describing the job, modifying several tables, and creating redo in the process. In Oracle Database 11g Scheduler, there is a persistent lightweight job. The goal of a lightweight job is to reduce the overhead and the time required to start a job. A minimal amount of metadata is created for the job. This reduces the time required and the redo created when the job starts. To achieve these goals, the lightweight job has a small footprint on disk for the job metadata and for storing run-time data. The footprint on disk also makes recovery and load balancing possible in Oracle RAC environments. The lightweight job is always created from a job template, which can be a stored procedure or a program. The stored procedure holds all the information needed for the job. A few job attributes may be set (such as job arguments). Job templates are created by using the DBMS_SCHEDULER.CREATE_PROGRAM procedures. Oracle Database 11g continues to support the database object-based jobs that have existed since Oracle Scheduler was first introduced in Oracle 10g. Lightweight jobs are not intended to replace these jobs because each job type has its own advantage and gives you the flexibility to choose a job based on your needs.



Choosing the Right Job

Choosing the Right Job

• Regular job:– Highest overhead– Best recovery– Most flexible

• Persistent lightweight job:– Less overhead– Some recovery– Limited change to attributes

The advantages and disadvantages of the types of jobs are as follows:

• A regular job offers maximum flexibility but entails a significant overhead in create/drop performance. A job can be created with a single command. Users have finegrained control of privileges on the job and can also use programs or stored procedures owned by the other users. A regular job requires the job database object to be created and dropped. This action updates several tables and the associated redo. Users who are creating a relatively small number of jobs that run relatively infrequently should choose regular jobs.

• A persistent lightweight job has a significant improvement in create/drop time, because it does not have the overhead of creating a database object. Every lightweight job is created from a job template, which is stored as a program. Because persistent lightweight jobs write state information to disk at run time, only a small improvement is expected in execution. There are several limitations to persistent lightweight jobs:

- Users cannot set privileges on these jobs. Instead, they inherit their privileges from the parent job template.

- The use of a template is mandatory. It is not possible to create a fully self-contained persistent lightweight job.

- Only certain job attributes are available to be set, such as JOB_ARGUMENTS.

Lightweight jobs are most useful when the user needs to create a large number of jobs in a very short time (from 10 to 100 jobs a second) and has a library of programs (job templates) available for use.



Creating a Single Lightweight Job

Creating a Single Lightweight Job

• Specify time and frequency.

• Use predefined schedule.

DBMS_SCHEDULER.CREATE_JOB (job_name => 'my_lightweight_job1',program_name => 'MY_PROG',repeat_interval=> 'FREQ=DAILY;BY_HOUR=9',end_time => '30-APR-07 04.00.00 AM CST',job_style => 'LIGHTWEIGHT');

DBMS_SCHEDULER.CREATE_JOB (job_name => 'my_lightweight_job2', program_name => 'MY_PROG', schedule_name => 'MY_SCHED',job_style => 'LIGHTWEIGHT');

The DBMS_SCHEDULER package has overloaded a few packages to allow the lightweight jobs to be created with a minimum of new syntax. Lightweight jobs have very few parameters that can be specified: job arguments and schedule. The rest of the metadata for the job is inherited from the job template, including privileges. The template for a lightweight job must be a PL/SQL block or a stored procedure. Lightweight jobs must be created in PL/SQL by using the DBMS_SCHEDULER package. The JOB_STYLE argument is not exposed in EM. In the first example above, MY_PROG is the job template, and the schedule is created as part of the CREATE_JOB method. In the second example, the schedule is applied from a named schedule.

An example of a simple template is the following: BEGIN

DBMS_SCHEDULER.CREATE_PROGRAM(

program_name=>'"SYSTEM"."MY_PROG"',

program_action=>

'DECLARE time_now DATE;

BEGIN

SELECT SYSDATE INTO time_now FROM DUAL;

END;',

program_type=>'PLSQL_BLOCK',

enabled=>TRUE);



END;



Creating an Array of Lightweight Jobs


1. Declare variables of types sys.job and sys.job_array .

2. Initialize the job array.

3. Size the job array to hold the number of jobs neede d.

DECLAREnewjob sys.job;newjobarr sys.job_array;

BEGIN newjobarr := SYS.JOB_ARRAY();

newjobarr.EXTEND(100);

Using a job array is a more efficient way to create a set of jobs. This also applies to lightweight jobs. The job array type and the CREATE_JOBS procedure are new to the DBMS_SCEHDULER package in Oracle Database 11g. In the example above, 100 job specifications are created in a job array and submitted to the job queue in a single transaction. Notice that, for a lightweight job, a very limited amount of information is needed. In this example, the start_time parameter defaults to NULL, so the job is scheduled to start immediately. The example continues on the next two pages.

1. Declare the variable to hold a job definition and a job array variable.

2. Initialize the job array by using the SYS.JOB_ARRAY constructor. This creates a place for one job in the array.

3. Set the size of the array to the number of expected jobs.

Note: If the array is very small, performance is not significantly better than submitting a single job.





4. Place the jobs in the job array.

5. Submit the job array as one transaction.

DBMS_SCHEDULER.CREATE_JOBS(newjobarr, 'TRANSACTIONAL');

FOR i IN 1..100 LOOPnewjob := SYS.JOB(job_name => 'LWTJK'||to_char(i),

job_style => 'LIGHTWEIGHT',job_template => 'MY_PROG',enabled => TRUE );

newjobarr(i) := newjob;END LOOP;

4. Create each job and place it in the array. In this example, the only difference is the name of

the job. The start_time variable of the job is omitted and defaults to NULL, indicating that the job will run immediately.

5. Use the CREATE_JOBS procedure to submit all jobs in the array as one transaction.

The full code of this example is as follows: DECLARE

newjob sys.job;

newjobarr sys.job_array;

BEGIN

-- Create an array of JOB object types

newjobarr := sys.job_array();

-- Allocate sufficient space in the array

newjobarr.extend(100);

-- Add definitions for jobs

FOR i IN 1..100 LOOP

-- Create a JOB object type

newjob := sys.job(job_name => 'LWTJK' || to_char (i),

job_style => 'LIGHTWEIGHT',



job_template => 'PROG_1',

enabled => TRUE );

-- Add job to the array

newjobarr(i) := newjob;

END LOOP;

-- Call CREATE_JOBS to create jobs in one transact ion

DBMS_SCHEDULER.CREATE_JOBS(newjobarr, 'TRANSACTION AL');

END;

/



Viewing Lightweight Jobs in the Dictionary

Viewing Lightweight Jobs in the Dictionary

View lightweight jobs in *_SCHEDULER_JOBS:

View job arguments with *_SCHEDULER_JOB_ARGS:

SQL> SELECT job_name, job_style, program_name2 FROM USER_SCHEDULER_JOBS;

JOB_NAME JOB_STYLE PROGRAM_NAME----------------- ----------- -------------------LWTJX LIGHTWEIGHT PROG_3

SQL> select job_name, argument_name, argument_type, value2 FROM USER_SCHEDULER_JOB_ARGS;

JOB_NAME ARGUMENT_NAME ARGUMENT_TYPE VALUE---------- -------------- -------------- ----------LWTJX ARG1 VARCHAR2 TEST_VALUE

In Oracle Database 11g, changes to dictionary views to support lightweight jobs are minimal.

• No new views are added.

• Lightweight jobs are visible through the same views as regular jobs: DBA_SCHEDULER_JOBS, ALL_SCHEDULER_JOBS, and USER_SCHEDULER_JOBS

• Arguments to lightweight jobs are visible through the same views as are those of regular jobs: DBA_SCHEDULER_JOB_ARGS, ALL_SCHEDULER_JOB_ARGS, and USER_SCHEDULER_JOB_ARGS

• Because lightweight jobs are not database objects, they are not visible through the DBA_OBJECTS, ALL_OBJECTS, and USER_OBJECTS views.



Easier Recovery from Loss of SPFILE


The FROM MEMORYclause allows the creation of current systemwide parameter settings.

CREATEPFILE [= 'pfile_name' ]FROM{ { SPFILE [= 'spfile_name'] } | MEMORY} ;

CREATE SPFILE [= 'spfile_name' ]FROM{ { PFILE [= 'pfile_name' ] } | MEMORY} ;


Oracle Database 11g offers simplified parameter management through easier recovery from the loss of the SPFILE . In Oracle Database 11g, you can use the FROM MEMORY clause to create a pfile or spfile using the current systemwide parameter settings. In a RAC environment, the created file contains the parameter settings from each instance. During instance startup, all parameter settings are logged to the alert.log file. However, as of Oracle Database 11g, the alert.log parameter dump text is written in valid parameter syntax. This facilitates cutting and pasting of parameters into a separate file, and then using as a pfile for a subsequent instance. The name of the pfile or spfile is written to the alert.log at instance startup. In cases when an unknown client-side pfile is used, the alert log indicates this as well. To support the additional functionality, the COMPATIBLE initialization parameter must be set to 11.0.0.0 or higher.



Summary

Summary

In this lesson, you should have learned how to:• Create AWR baselines for future time periods• Control automated maintenance tasks• Perform clusterwide analysis of performance using

RAC-aware ADDM• Use Resource Manager I/O calibration• Use lightweight jobs with the Scheduler• Improve file accessibility of the SPFILE file




SQL Plan Management Chapter 0 - Page 1

SQL Plan Management



Chapter 8SQL Plan Management

SQL Plan Management



Objectives

Objectives

After completing this lesson, you should be able to :• Set up SQL Plan Management• Set up various SQL Plan Management scenarios



SQL Plan Management: Overview

SQL Plan Management: Overview

• SQL Plan Management is automatically controlled SQL plan evolution.

• The optimizer automatically manages SQL plan baselines:– Only known and verified plans are used.

• Plan changes are automatically verified:– Only comparable or better plans are used going forw ard.

• SQL Plan Management can pre-seed critical SQL with SQL Tuning Sets from SQL Performance Analyzer.

Potential performance risk occurs when the SQL execution plan changes for a SQL statement. A SQL plan change can occur due to a variety of reasons like optimizer version, optimizer statistics, optimizer parameters, schema definitions, system settings, and SQL profile creation. Various plan control techniques, such as stored outlines and SQL profiles, have been introduced in past Oracle versions to address performance regressions due to plan changes. However, these techniques are reactive processes that require manual intervention. SQL Plan Management is a new feature introduced with Oracle Database 11g that enables the system to automatically control SQL plan evolution by maintaining what are called SQL plan baselines. With this feature enabled, a newly generated SQL plan can integrate a SQL plan baseline only if it has been proven that doing so will not generate performance regression. So, during execution of a SQL statement, only a SQL plan that is part of the corresponding SQL plan baseline can be used. As described later in this lesson, SQL plan baselines can be automatically loaded or can be seeded by using SQL Tuning Sets. Various possible scenarios are studied later in the lesson. The main benefit of the SQL Plan Management feature is the performance stability of the system through the avoidance of plan regressions. Additionally, it saves the DBA the time spent in identifying and analyzing SQL performance regressions and finding workable solutions.



SQL Plan Baseline Architecture

SQL Plan Baseline Architecture

SQL management base

Statement log

SYSAUX

Plan history

Planbaseline

HJ

GB

HJ

HJ

GB

HJ…HJ

GB

HJ

Plan history

Planbaseline

HJ

GB

HJ

HJ

GB

HJ…HJ

GB

HJ

Plan history

Planbaseline

HJ

GB

HJ

HJ

GB

HJ…HJ

GB

HJ

Plan verificationbefore integration

to baseline

RepeatableSQL

statement

SQLprofile

AutomaticSQL Tuning

task

The SQL Plan Management (SPM) feature introduces necessary infrastructure and services in support of plan maintenance and performance verification of new plans. For this, the optimizer maintains a history of plans for individual SQL statements that are executed more than once. The optimizer recognizes a repeatable SQL statement by maintaining a statement log. A SQL statement is recognized as repeatable when it is parsed or executed again after it has been logged. After a SQL statement is recognized as repeatable, various plans generated by the optimizer are maintained as a plan history. The plan history contains relevant information used by the optimizer to reproduce an execution plan, such as SQL text, outline, bind variables, and compilation environment. As an alternative, or as a complement to the automatic recognition of repeatable SQL statements and the creation of their plan history, manual seeding of plans for a set of SQL statements is also supported. A plan history contains different plans generated by the optimizer for a SQL statement over time. However, only some of the plans in the plan history may be accepted for use. For example, a new plan generated by the optimizer will not normally be used until it has been verified not to cause a performance regression. As delivered, plan verification is done as part of Automatic SQL Tuning that is run as an automated task in a maintenance window.

Automatic SQL Tuning targets only the high-load SQL statements. For them, it automatically implements actions, such as making a successfully verified plan an accepted plan. A set of acceptable plans constitutes a SQL plan baseline. The very first plan generated for a SQL statement is obviously acceptable for use; therefore, it forms the original plan baseline. Any new



plan subsequently found by the optimizer is part of the plan history but not part of the plan baseline initially. The statement log, plan history, and plan baselines are stored in SQL Management Base (SMB), which also contains SQL profiles. The SMB is part of the database dictionary and is stored in the SYSAUX tablespace. The SMB has automatic space management, such as periodic purging of unused plans. You can configure the SMB to change plan retention policy and set a space size limit. Note: With Oracle Database 11g, if the database instance is running but the SYSAUX tablespace is OFFLINE, the optimizer is unable to access SQL management objects. This can affect the performance on some of the SQL workload.



Loading SQL Plan Baselines

Plan baseline

Loading SQL Plan Baselines

DBA

OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES=TRUE

Plan history

HJ

GB

HJ

Plan

HJ

GB

HJ

Plan history

HJ

GB

HJ

baseline1

2

3

4

Plan baseline

Plan history

HJ

GB

HJ

lo

ad

_p

la

ns

_f

ro

m_

cu

rs

or

_c

ac

he

lo

ad

_p

la

ns

_f

ro

m_

sq

ls

et

dbms_spm

Stagingtable

HJ

GB

HJ

*_stgtab_baseline

alter_sql_plan_baseline

Cursorcache

There are two ways of loading SQL plan baselines:

Automatic capture • Use automatic plan capture by setting the

OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES initialization parameter to TRUE (default: FALSE). Setting it to TRUE turns on automatic recognition of repeatable SQL statements and automatic creation of plan history for such statements. This is illustrated in the left portion of the graphic above, where you can see the first generated SQL plan automatically integrated into the original SQL plan baseline.

Bulk loading • The DBMS_SPM package enables you to manually manage SQL plan baselines. With this

package, you can load SQL plans into a SQL plan baseline directly from the cursor cache or from an existing SQL Tuning Set (STS). For a SQL statement to be loaded into a SQL plan baseline from an STS, the SQL statement needs to store its SQL plan in the STS. DBMS_SPM allows you to change the status of a baseline plan from accepted to not accepted (and vice versa). It also allows you to export baseline plans from a staging table, which can then be used to load SQL plan baselines on other databases.



Important SQL Plan Baseline Attributes

Important SQL Plan Baseline Attributes

select signature, sql_handle, sql_text, plan_name, origin, enabled, accepted, fixed, autopurge

from dba_sql_plan_baselines;

SIGNATURE SQL_HANDLE PLAN_H_V SQL_TEXT PLAN_NAME ORIGIN ENA ACC FIX AUT

--------- ------------ -------- -------- -------------- -- ------------ --- --- --- ---

8.062E+18 SYS_SQL_6fe2 8992199 select.. SYS_SQL_PL AN_1ea AUTO-CAPTURE YES NO NO YES

8.062E+18 SYS_SQL_6fe2 38034070 select.. SYS_SQL_PL AN_4be AUTO-CAPTURE YES YES NO YES

…

Plan Baseline

Plan history

HJ

GB

HJ

HJ

GB

HJ

exec :cnt := dbms_spm.alter_sql_plan_baseline(sql_h andle => 'SYS_SQL_37e0168b0…3efe', -

plan_name => 'SYS_SQL_PLAN_8dfc352f359901ea', -

attribute_name => 'ACCEPTED_STATUS', attribute_val ue => 'YES');

Enabled butnot accepted

Enabled andaccepted

When a plan enters the plan history, it is associated with a number of important attributes:

• SIGNATURE, SQL_HANDLE, SQL_TEXT, and PLAN_NAME are important identifiers for search operations.

• ORIGIN allows you to determine whether the plan was automatically captured (AUTO-CAPTURE) or manually inserted into the plan history (MANUAL).

• ENABLED and ACCEPTED: ENABLED means that the plan is enabled for use by the optimizer. If ENABLED is not set, the plan will not be considered. ACCEPTED means that the plan was validated as a good plan, either automatically by the system or by the user manually changing it to ACCEPTED. After a plan changes to ACCEPTED, it will become not ACCEPTED only if someone uses DBMS_SPM.ALTER_SQL_PLAN_BASELINE () to change its status. An ACCEPTED plan can be temporarily disabled by removing the ENABLED setting. A plan has to be ENABLED and ACCEPTED for the optimizer to consider using it.

• FIXED means that the optimizer considers only certain plans and not others. For example, if you have 10 baseline plans and three of them are marked FIXED, the optimizer uses the best plan from only these three, ignoring all the others.

You can look at each plan’s attributes by using the DBA_SQL_PLAN_BASELINES view (as shown above). You can then change some of them by using the DBMS_SPM.ALTER_SQL_PLAN_BASELINE function. You can also remove plans or the



complete plan history by using the DBMS_SPM.PURGE_SQL_PLAN_BASELINE function. The earlier example changes the ACCEPTED attribute of the SYS_SQL_PLAN_8DFC352F359901EA to YES, making it ACCEPTED and thus part of the baseline. Note: The DBA_SQL_PLAN_BASELINES view contains additional attributes that enable you to determine when each plan was last used and whether a plan should be automatically purged.



SQL Plan Selection

SQL Plan Selection

Plan partof history? No

HJ

GB

HJ

HJ

GB

HJ

HJ

GB

HJ

> HJ

GB

HJ

NoHJ

GB

HJ

Yes

Plan history

PlanBaseline

HJ

GB

HJ

HJ

GB

HJ…HJ

GB

HJ

Yes

Plan partof baseline?Yes

optimizer_use_sql_plan_baselines

=true ?Yes

HJ

GB

HJ

No

No

dbms_xplan.display

dbms_xplan.display_plan_baseline

Select baseline planwith lowest best-cost.

If you are using automatic plan capture, the first time a SQL statement is recognized as repeatable, its best-cost plan is added to the corresponding SQL plan baseline, and that plan is used to execute the statement. The optimizer uses a comparative plan selection policy when a plan baseline exists for a SQL statement and the initialization parameter OPTIMIZER_USE_SQL_PLAN_BASELINES is set to TRUE (default value). Each time a SQL statement is compiled, the optimizer first uses the traditional cost-based search method to build a best-cost plan. Then it tries to find a matching plan in the SQL plan baseline. If a match is found, the optimizer proceeds as usual. Otherwise, it first adds the new plan to the plan history and then costs each of the accepted plans in the SQL plan baseline and picks the one with the lowest cost. The accepted plans are reproduced using the outline that is stored with each of them. The effect of having a SQL plan baseline for a SQL statement is that the optimizer always selects one accepted plan in that SQL plan baseline. With SQL Plan Management, the optimizer can produce a plan that can be either a best-cost plan or a baseline plan. This information is dumped in the other_xml column of the plan_table upon EXPLAIN PLAN. You can display one or more execution plans for the specified SQL_HANDLE of a plan baseline by using the new DBMS_XPLAIN.DISPLAY_PLAN_BASELINE function. If PLAN_NAME is also specified, the corresponding execution plan is displayed. Note: To preserve backward compatibility, if a stored outline for a SQL statement is active for the user session, the statement is compiled using the stored outline. In addition, a plan generated



by the optimizer using a stored outline is not stored in the SMB even if automatic plan capture has been enabled for the session.



Possible SQL Plan Manageability Scenarios

Possible SQL Plan Manageability Scenarios

DBA

Plan Baseline

Plan History

HJ

GB

HJ

Database upgrade



HJ

GB

HJ

Well-tunedplan

No planregressions

HJ

GB

HJ

Plan Baseline

Plan History

HJ

GB

HJ

New application deploymentProduction database

No planregressions

HJ

GB

HJ

Plan BaselineHJ

GB

HJ

Development database

Well-tunedplan

HJ

GB

HJ

Baselineplans

staging table

DBA

Plan History

Database upgrade

• Bulk SQL plan loading is especially useful when the system is being upgraded from a pre–Oracle Database 11g version to Oracle Database 11g. For this, you can capture plans for a SQL workload into an STS before the upgrade, and then load these plans from the STS into the SQL plan baseline immediately after the upgrade. This strategy can minimize plan regressions resulting from the use of the new optimizer version.

New Application Deployment • The deployment of a new application module means introduction of new SQL statements

into the system. The software vendor can ship the application software along with the appropriate SQL plan baselines for the new SQL being introduced. Because of the plan baselines, the new SQL statements will initially run with the plans that are known to give good performance under a standard test configuration. However, if the customer system configuration is very different from the test configuration, the plan baselines can be changed over time to produce better performance.

In both cases, you can use automatic SQL plan capture after manual loading to make sure that only better plans will be used for your applications in the future.



SQL Performance Analyzer and SQL Plan Baseline Scenario

SQL Performance Analyzer and SQL Plan Baseline Scenario

Plan Baseline

Plan History

HJ

GB

HJ



HJ

GB

HJ Well-tunedplans

HJ

GB

HJ

HJ

GB

HJ

O_F_E=10

O_F_E=11

Regressingstatements

Beforechange

Afterchange

HJ

GB

HJ

No planregressions

optimizer_features_enable

A variation of the first method described in the previous slide is through the use of SQL Performance Analyzer. You can capture pre–Oracle Database 11g plans in an STS and import them into Oracle Database 11g. You then set the optimizer_features_enable initialization parameter to 10 to make the optimizer behave like an Oracle Database 10g database. Then, run SQL Performance Analyzer for the STS. When that finishes, set the optimizer_features_enable initialization parameter back to 11 and rerun SQL Performance Analyzer for the STS. SQL Performance Analyzer will produce a report that lists any SQL statement whose plan has regressed from Oracle Database 10g to Oracle Database 11g. For those SQL statements that are shown by SQL Performance Analyzer to incur performance regression due to the new optimizer version, you can capture their plans using an STS and then load them into the SMB. This method represents the best form of the plan-seeding process, because it helps prevent performance regressions while preserving performance improvements upon database upgrade.



Automatic SQL Plan: Baseline Scenario

Automatic SQL Plan: Baseline Scenario


Well-tunedplans


optimizer_features_enable=10.2.0.2optimizer_capture_plan_baselines=true

Plan History

PlanBaseline

HJ

GB

HJ

HJ

GB

HJ

No planregressions



Plan History

PlanBaseline

HJ

GB

HJ

HJ

GB

HJ

No planregressions

HJ

GB

HJ

New planawaiting

verification

HJ

GB

HJ

HJ

GB

HJ



Plan History

Betterplans

HJ

GB

HJ

HJ

GB

HJ

HJ

GB

HJ

Plan Baseline

Another possibility for the upgrade scenario is to use the automatic SQL plan capture mechanism. In this case, you set the OPTIMIZER_FEATURES_ENABLE (OFE) initialization parameter to the pre–Oracle Database 11g version value for an initial period of time (for example, a quarter) and you execute your workload after upgrade by using automatic SQL plan capture. During this initial time period, because of the OFE parameter setting, the optimizer is able to reproduce pre–Oracle Database 11g plans for a majority of the SQL statements. Because automatic SQL plan capture is also enabled during this period, the pre–Oracle Database 11g plans produced by the optimizer are captured as SQL plan baselines. After the initial time period, you can remove the setting of the OFE to take advantage of the new optimizer version while incurring minimal or no plan regressions due to the plan baselines.



SQL Management Base: Purging Policy

SYSAUX

20%1% 50% space

time

105

53

SQL ManagementBasez

Alert.log

10%

SQL Management Base: Purging Policy

SQL> exec dbms_spm.configure('SPACE_BUDGET_PERCENT' , 20);

SQL> exec dbms_spm.configure('PLAN_RETENTION_WEEKS' , 105);

SQL> exec :cnt := dbms_spm.purge_sql_plan_baseline( 'SYS_SQL_37e0168b04e73efe');

The space occupied by the SMB is regularly checked against a defined limit based on the percentage size of the SYSAUX tablespace. The space budget limit for the SMB is 10 percent of the SYSAUX size (by default). However, you can configure the SMB and change space budget to a value between 1 percent and 50 percent. A daily task measures the total space occupied by the SMB, and when it exceeds the defined percent limit, it generates a warning and writes it to the alert log. The alerts are generated daily until either the SMB space limit is increased, the size of SYSAUX is increased, or the size of the SMB is decreased by purging some of the SQL management objects, such as SQL plan baselines or SQL profiles. Space management of SQL plan baselines is done proactively by using a regularly scheduled purging task. The task runs as an automated task in the maintenance window. Any plan that has not been used for more than 53 weeks is purged. However, you can configure the SMB and change the unused plan retention period to a value between 5 and 523 weeks (a little more than 10 years). You can also manually purge the SMB by using the DBMS_SPM.PURGE_SQL_PLAN_BASELINE function (as shown above).



Summary

Summary

In this lesson, you should have learned how to:• Set up SQL Plan Management• Set up various SQL Plan Management scenarios

Documents

Oracle Database 11 : Server Manageabilitydbmanagement.info/.../MIX/Oracle_Database_11g_Server_Manageability.pdfOracle Database 11g: Server Manageability Table of Contents ... Automatic