SPA百科

广告

有没有纯英文的SPA介绍?

2011-12-14 13:50:56 本文行家:施洗约翰

TheconceptofSQLtuningsets,alongwiththeDBMS_SQLTUNEpackagetomanipulatethem,wasintroducedinOracle10gaspartoftheAutomaticSQLTuningfunctionality.Oracle11gmakesfurtheruseofSQLtuningsetswiththeSQLPerformanc


The concept of SQL tuning sets, along with the DBMS_SQLTUNE package to manipulate them, was introduced in Oracle 10g as part of the Automatic SQL Tuning functionality. Oracle 11g makes further use of SQL tuning sets with the SQL Performance Analyzer, which compares the performance of the statements in a tuning set before and after a database change. The database change can be as major or minor as you like, such as:


Database, operating system, or hardware upgrades.
Database, operating system, or hardware configuration changes.
Database initialization parameter changes.
Schema changes, such as adding indexes or materialized views.
Refreshing optimizer statistics.
Creating or changing SQL profiles.
Unlike Database Replay, the SQL Performance Analyzer does not try and replicate the workload on the system. It just plugs through each statement gathering performance statistics.

The SQL Performance Analyzer can be run manually using the DBMS_SQLPA package or using Enterprise Manager. This article gives an overview of both methods.

· 

· Setting Up the Test

· Creating SQL Tuning Sets using the DBMS_SQLTUNE Package

· Running the SQL Performance Analyzer using the DBMS_SQLPA Package

· Creating SQL Tuning Sets using Enterprise Manager

· Running the SQL Performance Analyzer using Enterprise Manager

· Optimizer Upgrade Simulation

· Parameter Change

· Transferring SQL Tuning Sets

Setting Up the Test


The SQL performance analyzer requires SQL tuning sets, and SQL tuning sets are pointless unless they contain SQL, so the first task should be to issue some SQL statements. We are only trying to demonstrate the technology, so the example can be really simple. The following code creates a test user called SPA_TEST_USER.

CONN sys/password@prod AS SYSDBA

CREATE USER spa_test_user IDENTIFIED BY spa_test_user

  QUOTA UNLIMITED ON users;

GRANT CONNECT, CREATE TABLE TO spa_test_user;


Next, connect to the test user and create a test table called MY_OBJECTS using a query from the ALL_OBJECTS view.

CONN spa_test_user/spa_test_user@prod

CREATE TABLE my_objects AS

  SELECT * FROM all_objects;

EXEC DBMS_STATS.gather_table_stats(USER, 'MY_OBJECTS', cascade => TRUE);


This schema represents our "before" state. Still logged in as the test user, issue the following statements.

SELECT COUNT(*) FROM my_objects WHERE object_id <= 100;

SELECT object_name FROM my_objects WHERE object_id = 100;

SELECT COUNT(*) FROM my_objects WHERE object_id <= 1000;

SELECT object_name FROM my_objects WHERE object_id = 1000;

SELECT COUNT(*) FROM my_objects WHERE object_id BETWEEN 100 AND 1000;


Notice, all statements make reference to the currently unindexed OBJECT_ID column. Later we will be indexing this column to create our changed "after" state.

The select statements are now in the shared pool, so we can start creating an SQL tuning set.

Creating SQL Tuning Sets using the DBMS_SQLTUNE Package


The DBMS_SQLTUNE package contains procedures and functions that allow us to create, manipulate and drop SQL tuning sets. The first step is to create an SQL tuning set called spa_test_sqlset using the CREATE_SQLSET procedure.

CONN sys/password@prod AS SYSDBA

EXEC DBMS_SQLTUNE.create_sqlset(sqlset_name => 'spa_test_sqlset');


Next, the SELECT_CURSOR_CACHE table function is used to retrieve a cursor containing all SQL statements that were parsed by the SPA_TEST_USER schema and contain the word "my_objects". The resulting cursor is loaded into the tuning set using the LOAD_SQLSET procedure.

DECLARE

  l_cursor  DBMS_SQLTUNE.sqlset_cursor;

BEGIN

  OPEN l_cursor FOR

     SELECT VALUE(a)

     FROM   TABLE(

              DBMS_SQLTUNE.select_cursor_cache(

                basic_filter   => 'sql_text LIKE ''%my_objects%'' and parsing_schema_name = ''SPA_TEST_USER''',

                attribute_list => 'ALL')

            ) a;

                                               

 

  DBMS_SQLTUNE.load_sqlset(sqlset_name     => 'spa_test_sqlset',

                           populate_cursor => l_cursor);

END;

/


The DBA_SQLSET_STATEMENTS view allows us to see which statements have been associated with the tuning set.

SELECT sql_text

FROM   dba_sqlset_statements

WHERE  sqlset_name = 'spa_test_sqlset';

SQL_TEXT

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

SELECT object_name FROM my_objects WHERE object_id = 100

SELECT COUNT(*) FROM my_objects WHERE object_id <= 100

SELECT COUNT(*) FROM my_objects WHERE object_id BETWEEN 100 AND 1000

SELECT COUNT(*) FROM my_objects WHERE object_id <= 1000

SELECT object_name FROM my_objects WHERE object_id = 1000

5 rows selected.

SQL>


Now we have an SQL tuning set, we can start using the SQL performance analyzer.

Running the SQL Performance Analyzer using the DBMS_SQLPA Package


The DBMS_SQLPA package is the PL/SQL API used to manage the SQL performance ananlyzer. The first step is to create an analysis task using the CREATE_ANALYSIS_TASK function, passing in the SQL tuning set name and making a note of the resulting task name.

CONN sys/password@prod AS SYSDBA

VARIABLE v_task VARCHAR2(64);

EXEC :v_task :=  DBMS_SQLPA.create_analysis_task(sqlset_name => 'spa_test_sqlset');

PL/SQL procedure successfully completed.

SQL> PRINT :v_task

 

V_TASK

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

TASK_122

SQL>


Next, use the EXECUTE_ANALYSIS_TASK procedure to execute the contents of the SQL tuning set against the current state of the database to gather information about the performance before any modifications are made. This analysis run is named before_change.

BEGIN

  DBMS_SQLPA.execute_analysis_task(

    task_name       => :v_task,

    execution_type  => 'test execute',

    execution_name  => 'before_change');

END;

/


Now we have the "before" performance information, we need to make a change so we can test the "after" performance. For this example we will simply add an index to the test table on the OBJECT_ID column. In a new SQL*Plus session create the index using the following statements.

CONN spa_test_user/spa_test_user@prod

CREATE INDEX my_objects_index_01 ON my_objects(object_id);

EXEC DBMS_STATS.gather_table_stats(USER, 'MY_OBJECTS', cascade => TRUE);


Now, we can return to our original session and test the performance after the database change. Once again use the EXECUTE_ANALYSIS_TASK procedure, naming the analysis task "after_change".

BEGIN

  DBMS_SQLPA.execute_analysis_task(

    task_name       => :v_task,

    execution_type  => 'test execute',

    execution_name  => 'after_change');

END;

/


Once the before and after analysis tasks are complete, we must run a comparison analysis task. The following code explicitly names the analysis tasks to compare using name-value pairs in the EXECUTION_PARAMS parameter. If this is ommited, the latest two analysis runs are compared.

BEGIN

  DBMS_SQLPA.execute_analysis_task(

    task_name        => :v_task,

    execution_type   => 'compare performance', 

    execution_params => dbms_advisor.arglist(

                          'execution_name1', 

                          'before_change', 

                          'execution_name2', 

                          'after_change')

    );

END;

/


With this final analysis run complete, we can check out the comparison report using the REPORT_ANALYSIS_TASK function. The function returns a CLOB containing the report in text or HTML format. The script below spools the default text format report out to a file.

SET LONG 1000000

SET PAGESIZE 0

SET LINESIZE 200

SET LONGCHUNKSIZE 200

SET TRIMSPOOL ON

分享:
标签: 英文版 SPA术语 | 收藏
百科的文章(含所附图片)系由网友上传,如果涉嫌侵权,请与客服联系,我们将按照法律之相关规定及时进行处理。如需转载,请注明来源于www.baike.com