11.07.2015 Views

Oracle Database 11 g - Online Public Access Catalog

Oracle Database 11 g - Online Public Access Catalog

Oracle Database 11 g - Online Public Access Catalog

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

48 CHAPTER 1 ■ INSTALLING, UPGRADING, AND MANAGING CHANGEIn this example, we’ll show you how to use the SQL Performance Analyzer to help predictSQL performance changes following the upgrade of a database from the <strong>Oracle</strong> 10.2 release tothe <strong>Oracle</strong> <strong>11</strong>.1 release. We assume you’re using a test database to run the analysis instead ofrunning it on the production system. You must configure the test database as similarly aspossible to the production system to get the most out of the SQL Performance Analyzer. <strong>Oracle</strong>recommends you use <strong>Oracle</strong> Enterprise Manager to run the SQL Performance Analyzer. However,we show you how to run the tool using the PL/SQL procedures in the new package DBMS_SQLPA,which provides the interface for the SQL Performance Analyzer. When you use this package to runthe SQL Performance Analyzer, you create a SQL Performance Analyzer task to contain the resultsof the SQL replay trials you perform. You also use several new procedures in the DBMS_SQLTUNEpackage to conduct your performance analysis with the SQL Performance Analyzer.■Note You can run the SQL Performance Analyzer on the production database from which you collect theSQL workload or on a similarly configured test database. Running the job on the production database entailssome additional resource usage but gives you the most representative results. If performance is a big concern,then use a test database to run the analysis.You can store the SQL workload that you capture in a SQL tuning set (STS). An STS is adatabase object that includes the SQL text of one or more SQL statements along with informationpertaining to their execution environment, the execution plan, and the execution statistics.You can also specify that the STS include the execution plans and row source statistics for theSQL statements in the STS. Using an STS lets you collect and store the SQL information in apersistent database object, which you can modify and select from later on, just as you woulddata from a database table. An STS also makes it easy for you to export the SQL workload from theproduction system to the test system and provide the workload as input to the SQL PerformanceAnalyzer.You can use any of the following sources to load statements into an STS:• The automatic workload repository (AWR)• A cursor cache• Another STSOnce you capture the SQL statements that comprise the SQL workload on the productionsystem in a SQL tuning set, you follow these steps to perform a SQL Performance Analyzer task:1. Measure the pre-change SQL workload performance: The SQL Performance Analyzerexecutes the SQL statements that are part of the STS that you create and generatesthe execution plan and execution statistics for those statements. The SPA stores theexecution information in the STS.2. Make the system changes: After the first run of the SQL Performance Analyzer, you makethe changes that you want to test on the testing system. For example, you may want totest the migration to a different release of the database by installing the new release andchanging the initialization parameter optimizer_features_enable to the new version.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!