BACK TO THE BASICS AN OVERVIEW OF ORACLE TOOLS FOR TUNING Michael R. Ault- Burleson Consulting

Transcription

1 BACK TO THE BASICS AN OVERVIEW OF ORACLE TOOLS FOR TUNING Michael R. - Burleson Consulting Introduction Tuning of Oracle is a three-part process. In this three part tuning process the old 80/20 rule applies. This rule states that 80% of the gains will be accomplished through 20% of the work. With Oracle, this 20% corresponds to the first part of the process. The first part of the process is application design Cost Gain 20 0 Design Impl. Prod Maint Figure 1: Generalized Cost - Benefit Graph for Tuning Phase 1 80% of your performance gains will be accomplished through proper application design. By simply using proper relational concepts and then properly denormalizing a table layout immense performance gains can be realized. The proper design of any system starts with proper business, or system rules (we seem to concentrate on only business applications, what about the multitude of other applications?). The designers of a system have to be familiar with Oracle, they can t design in a vacuum. If the designers aren t aware of Oracle features and strengths how can they take advantage of them? In one project I worked on they used no functions, packages or procedures because the designers weren t aware of them. In another all of the referential integrity (RI) was done through triggers, again, the designers weren t aware how Oracle did RI. Phase 2 Once the Oracle system is designed, based on sound business rules and sound Oracle based design practice, phase two begins. The phase two of the process is when the application developers take the Oracle based design and implement it using sound, Oracle based development practices. Again, it is critical to spend the time to become experienced Oracle developers. Believe me, the time you save from having to redo code, correct mistakes and teach off-the-shelf developers Oracle will more than equate to enough dollars to have paid qualified people in the first place. Experience with the S or the I database doesn t qualify a developer to develop in Oracle. While the concepts are similar the execution in many cases is far different. Again, do you want to pay for learning curve time? Proper specification of business rules, application of the rules to a design and implementation of the design by being Oracle savvy developers will give you 80% of your database performance. Developers must be familiar with Oracle application statement tuning. Statement tuning is not a DBA responsibility, it should be the responsibility of the developers. All of your developers should be familiar with EXPLAIN PLAN, TKPROF, and the strengths and weaknesses of the cost and rule based optimizers. Provide good tools to good people and you will be amazed at the results. There are numerous tools available now that automatically analyze code and some will even suggest alternative, better performing ways to do a particular piece of code.

2 In some cases merely adding a hint, analyzing a table or changing the structure of a query will improve a statements performance by an order of magnitude. Imagine what performance gains can be made over an entire application? In one case adding a simple index changed a 4-hour process into less than 10 seconds. The mere act of analyzing a recently loaded table may translate into hours of saved processing time. Phase 3 The remaining 20% of the performance gains can be realized through tuning the structures and processes that make up the Oracle system. This tuning of the structure and processes is the DBAs job. Reducing disk, memory, and IO contention and improving sort and checkpoint speed will all improve performance. Of course, if all of these functions are really out-of-tune, database performance may show more than a 20% gain. In general, the 20% gain is a good rule of thumb. Unfortunately, DBAs are usually not hired until the programmer who got to be DBA because no one else wanted the job has made a complete mess of things. Indeed, usually by the time a true DBA is hired a project is only weeks away from production and then Oracle, and the DBA, are blamed for poor performance. Use of Standalone EXPLAIN PLAN The EXPLAIN PLAN program can be used in standalone fashion without the TKPROF application. In order to use EXPLAIN PLAN in this way, the user must create a "PLAN" table in their tablespace. This can either be done with the supplied SQL script UTLXPLAN.SQL which is located in the directory pointed at by the ORA_RDBMS logical in VMS or in the oracle/rdbms/admin directory on most UNIX systems. In later versions of 7 and all 8 versions the user can also use the SET AUTOTRACE ON EXPLAIN command in SQL*Plus to generate explain plans as the user enters and executes SQL statements, an additional SET, SET TIMING ON will generate elapsed time counts between the start and end of a transaction. The UTLXPLAN.SQL procedure creates the PLAN_TABLE. As an alternative, the user can create a table with any name they choose, but the table must have the columns and data types shown in Figure 2. CREATE TABLE plan_table (statement_id VARCHAR2(30), timestamp DATE, remarks VARCHAR2(80), operation VARCHAR2(30), options VARCHAR2(30), object_node VARCHAR2(128), object_owner VARCHAR2(30), object_name VARCHAR2(30), object_instance NUMERIC, object_type VARCHAR2(30), optimizer VARCHAR2(255), search_columns NUMERIC, id NUMERIC, parent_id NUMERIC, position NUMERIC, cost NUMERIC, cardinality NUMERIC, bytes NUMERIC, other_tag VARCHAR2(255) other LONG); Figure 2: Contents of the Explain Plan Table The PLAN_TABLE used by the EXPLAIN PLAN command contains the following columns:

3 Column STATEMENT_ID TIMESTAMP REMARKS OPERATION OPTIONS OBJECT_NODE OBJECT_OWNER OBJECT_NAME OBJECT_INSTANCE OBJECT_TYPE OPTIMIZER SEARCH_COLUMNS ID PARENT_ID POSITION OTHER OTHER_TAG PARTITION_START PARTITION_STOP PARTITION_ID COST CARDINALITY BYTES Description The value of the option STATEMENT_ID parameter specified in the EXPLAIN PLAN statement. The date and time when the EXPLAIN PLAN statement was issued. Any comment (of up to 80 bytes) you wish to associate with each step of the explained plan. If you need to add or change a remark on any row of the PLAN_TABLE, use the UPDATE statement to modify the rows of the PLAN_TABLE. The name of the internal operation performed in this step. In the first row generated for a statement, the column contains one of the following values: 'DELETE STATEMENT' 'INSERT STATEMENT' 'SELECT STATEMENT' 'UPDATE STATEMENT' A variation on the operation described in the OPERATION column. The name of the database link used to reference the object (a table name or view name). For local queries using the parallel query option, this column describes the order in which output from operations is consumed. The name of the user that owns the schema containing the table or index. The name of the table or index. A number corresponding to the ordinal position of the object as it appears in the original statement. The numbering proceeds from left to right, outer to inner with respect to the original statement text. Note that view expansion will result in unpredictable numbers. A modifier that provides descriptive information about the object; for example, NON-UNIQUE for indexes. The current mode of the optimizer. Not currently used. A number assigned to each step in the execution plan. The ID of the next execution step that operates on the output of the ID step. The order of processing for steps that all have the PARENT_ID. Other information that is specific to the execution step that a user may find useful. Describes the contents of the OTHER column. See below for more information on the possible values for this column. The start partition of a range of accessed partitions. The stop partition of a range of accessed partitions. The step that has computed the pair of values of the PARTITION_START and PARTITION_STOP columns. The cost of the operation as estimated by the optimizer's cost-based approach. For statements that use the rule-based approach, this column is null. Cost is not determined for table access operations. The value of this column does not have any particular unit of measurement, it is merely a weighted value used to compare costs of execution plans. The estimate by the cost-based approach of the number of rows accessed by the operation. The estimate by the cost-based approach of the number of bytes accessed by the operation. The next section describes the values that may appear in the OTHER_TAG column.

4 OTHER_TAG (blank) serial_from_remote serial_to_parallel parallel_to_parallel parallel_to_serial parallel_combined_with_parent parallel_combined_with_child Text Interpretation serial execution serial execution at a remote site serial execution, output of step is partitioned or broadcast to parallel query servers parallel execution, output of step is repartitioned to second set of parallel query servers parallel execution, output of step is returned to serial "query coordinator" process parallel execution, output of step goes to next step in same parallel process. No interprocess communication to parent parallel execution, input of step comes from prior step in same parallel process. No interprocess communication from child The TKPROF section lists each combination of OPERATION and OPTION values produced by the EXPLAIN PLAN command and its meaning within an execution plan. When TKPROF is run using the EXPLAIN option, the table is created and dropped automatically. If it is created for use in EXPLAIN PLAN it is permanent. The table should have the DELETE command issued against it between runs of EXPLAIN PLAN or duplicate rows will be inserted into the table and into any output generated based on the table. Once this table is generated, the user issues the EXPLAIN PLAN command from within SQLPLUS to generate output to the table. The EXPLAIN PLAN command format follows. EXPLAIN PLAN [SET STATEMENT_ID = 'descriptor'] [INTO table] FOR SQL statement; Where: Descriptor -- This is a short name to identify the SQL statement by. If not specified the entire statement will be used as the identifier. Table -- If other than the PLAN_TABLE is used, this is where it is named. SQL statement -- This is the SQL statement to analyze. An example of the use of the EXPLAIN PLAN command is shown in Figure 3. SQL> explain plan 2 set statement_id='exp PLAN EXAMPLE' 3 for 4 select t.owner,t.table_name,t.tablespace_name, 5 i.index_name,i.tablespace_name 6 from tkp_example t, tkp_example2 i 7 where 8 t.table_name=i.table_name and 9 t.owner not in ('SYS','SYSTEM') 10* Explained. Figure 3: Example use of the EXPLAIN PLAN command.

5 To get the results of the EXPLAIN PLAN command the table PLAN_TABLE, or whatever table was specified in the EXPLAIN PLAN command, must be queried. Let's look at a simple query of this table for the above SQL statement. The query and output from the query are shown in Figure 4. While this type of query will provide useful information, it leaves the logical arrangement of the information retrieved to the user. With use of the padding options and connect features available in SQL the user can generated a pseudo-execution plan comparable to the one generated in the TKPROF command. The query used for this and the output generated in place of the tabular information in Figure 4, is shown in Figure 5. This new format shown in figure 24 is easier to understand. The TKPROF output for each statement also needs to be reviewed as was shown in the first part of this chapter. Just because index rather than table scans are used it doesn't mean the query executed faster. If the index is not a bitmapped index and is not selective, use of an index can actually slow a query rather than speed it up. SQL> column position format SQL> column object_name format a12 SQL> column options format a7 SQL> column operation format a15 SQL> select operation, options, object_name, id, parent_id, 2 position 3 from plan_table 4 where statement_id='exp PLAN EXAMPLE' 5* order by id OPERATION OPTIONS OBJECT_NAME ID PARENT_ID POSITION SELECT STATEMENT 0 MERGE JOIN SORT JOIN TABLE ACCESS FULL TKP_EXAMPLE SORT JOIN TABLE ACCESS FULL TKP_EXAMPLE rows selected Figure 4: Example Query of the PLAN_TABLE SQL> column query_plan format a60 SQL> select lpad(' ',2*level) operation ' ' object_name query_plan 2 from plan_table where statement_id is not null 3 connect by prior id=parent_id 4 start with id=0; QUERY_PLAN SELECT STATEMENT MERGE JOIN SORT TABLE ACCESS TKP_EXAMPLE2 SORT TABLE ACCESS TKP_EXAMPLE 6 rows selected. Figure 5: SQL statement to generate an execution plan from the PLAN_TABLE One thing to remember is that these plans need to be read from the inside out, bottom up, for example, in the plan in Figure 5, the TKP_EXAMPLE table is accessed and all rows that don't have the OWNER SYS or SYSTEM are retrieved. Then, the TKP_EXAMPLE2 table is accessed for each row in the TKP_EXAMPLE table all rows that have matches in the TABLE_NAME column are selected. The results for both accesses are then sorted and merged to form the final output.

6 The ORACLE8 table also has columns to document if partitions are being used and this data can be added to the select if desired, as well as a number of other columns that you may find useful. Example Use of Command Line Explain Plan As was stated above, the SQL*Plus program also allows use of the explain plan facility. The use of automatic explain plan requires the user either have a plan_table in their schema or that a public plan_table be made available to all users. The automated use of the explain plan facility is accomplished through the setting of the autotrace feature. The autotrace feature in SQLPLUS has several possible settings, ON, ON EXPLAIN, and TRACEONLY. The ON setting shows both execution plan and statistics, the ON EXPLAIN shows only the explain plan, and TRACEONLY doesn t show the statement results, but the statement is still executed. Another useful setting is the TIMING feature. If TIMING is turned on, the time required to execute all statements is shown. By combining AUTOTRACE and TIMING you get complete information about SQL execution. Figure 6 shows these various settings and their resulting display. SQL> set autotrace on SQL> set timing on SQL> select a.tablespace_name, b.file_name, a.initial_extent 2 from 3 test1 a, 4 test2 b 5 where a.tablespace_name=b.tablespace_name 6* order by a.tablespace_name SQL> / statement executes 20 rows selected. Elapsed: 00:00:00.02 Execution Plan SELECT STATEMENT Optimizer=CHOOSE 1 0 MERGE JOIN 2 1 SORT (JOIN) 3 2 TABLE ACCESS (FULL) OF 'TEST2' 4 1 SORT (JOIN) 5 4 TABLE ACCESS (FULL) OF 'TEST1' Statistics recursive calls 0 db block gets 6 consistent gets 0 physical reads 0 redo size 1749 bytes sent via SQL*Net to client 510 bytes received via SQL*Net from client 3 SQL*Net roundtrips to/from client 2 sorts (memory) 0 sorts (disk) 20 rows processed SQL> set autotrace on explain SQL> select a.tablespace_name, b.file_name, a.initial_extent 2 from 3 test1 a, 4 test2 b 5 where a.tablespace_name=b.tablespace_name 6* order by a.tablespace_name SQL> / statement executes

7 20 rows selected. Elapsed: 00:00:00.01 Execution Plan SELECT STATEMENT Optimizer=CHOOSE 1 0 MERGE JOIN 2 1 SORT (JOIN) 3 2 TABLE ACCESS (FULL) OF 'TEST2' 4 1 SORT (JOIN) 5 4 TABLE ACCESS (FULL) OF 'TEST1' SQL> set autotrace traceonly SQL> select a.tablespace_name, b.file_name, a.initial_extent 2 from 3 test1 a, 4 test2 b 5 where a.tablespace_name=b.tablespace_name 6* order by a.tablespace_name SQL> / 20 rows selected. Elapsed: 00:00:00.00 Execution Plan SELECT STATEMENT Optimizer=CHOOSE 1 0 MERGE JOIN 2 1 SORT (JOIN) 3 2 TABLE ACCESS (FULL) OF 'TEST2' 4 1 SORT (JOIN) 5 4 TABLE ACCESS (FULL) OF 'TEST1' Statistics recursive calls 0 db block gets 6 consistent gets 0 physical reads 0 redo size 1749 bytes sent via SQL*Net to client 510 bytes received via SQL*Net from client 3 SQL*Net roundtrips to/from client 2 sorts (memory) 0 sorts (disk) 20 rows processed Figure 6: Results from Different Settings of AUTOTRACE The V$SQL_PLAN Table In 9i and 10g Oracle has provided the V$SQL_PLAN table. The V$SQL_PLAN table contains the execution plans for all SQL currently in the shared pool. The V$SQL_PLAN table has the structure: Name Null? Type ADDRESS RAW(4) HASH_VALUE NUMBER CHILD_NUMBER NUMBER OPERATION VARCHAR2(30) OPTIONS VARCHAR2(30) OBJECT_NODE VARCHAR2(10) OBJECT# NUMBER OBJECT_OWNER VARCHAR2(30) OBJECT_NAME VARCHAR2(64)

8 OPTIMIZER ID PARENT_ID DEPTH POSITION SEARCH_COLUMNS COST CARDINALITY BYTES OTHER_TAG PARTITION_START PARTITION_STOP PARTITION_ID OTHER DISTRIBUTION CPU_COST IO_COST TEMP_SPACE ACCESS_PREDICATES FILTER_PREDICATES VARCHAR2(20) NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER VARCHAR2(35) VARCHAR2(5) VARCHAR2(5) NUMBER VARCHAR2(4000) VARCHAR2(20) NUMBER NUMBER NUMBER VARCHAR2(4000) VARCHAR2(4000) As you can see this table looks very similar to the PLAN_TABLE we have already discussed and it can be used in a similar manner. As you change a piece of code to tune it you may find it advantageous to select all of the explain plans out of this table for the various incarnations of your code that may still be in the SGA. This selection of all versions can either be accomplished by physically looking at the ADDRESS in V$SQL_PLAN, then comparing that to the ADDRESS in the V$SQLTEXT view or by utilizing good code comments in the SQL statements then just doing a batch SELECT for the addresses which have code with the proper comment from V$SQLTEXT and then accessing those explain plans in the V$SQL_PLAN table. Use of TKPROF to Tune Statements Oracle provides two tools to tune SQL statements, TKPROF and EXPLAIN PLAN. TKPROF uses the Oracle trace facility to give statistics and query plans on all statements executed while the session is in trace mode. EXPLAIN PLAN is used on any query at any time. One thing every developer that uses embedded SQL statements in PL/SQL should do is make it a good practice to place comments in the SQL statements providing some means of tying the code back to a particular procedure or package. This makes finding the code n a long tkprof, trace or other report much easier. In addition, with the new V4sql_plan table there is additional benefit by allowing the code to be easily extracted, with its statistics, from that table. Identify SQL using Comments It can be very difficult to pull your PL/SQL procedure code out of the background code in an instance shared pool, large tkprof, trace output or from v$sql_plan. I suggest placing a comment in each SQL statement that identifies the SQL. An example of this is: CURSOR get_latch IS SELECT /* DBA_UTIL.get_latch */ a.name,100.*b.sleeps/b.gets FROM v$latchname a, v$latch b WHERE a.latch# = b.latch# and b.sleeps > 0; Now to find all SQL code in the shared pool from the DBA_UTILITIES package I can simply query the V$SQLAREA or V$SQLTEXT, or the V$SQL_PLAN VPT to find code entries with '%DBA_UTIL%' in the SQL_TEXT column.

9 Using SQL Tracing TRACE allows users to monitor execution statistics of SQL and PL/SQL and provides information about how Oracle will actually execute the plan. There are various methods for invoking the SQL Trace facility, instance wide, session level and for a specific process. Instance Wide trace The DBA can set up instance wide tracing by setting the SQL_TRACE initialization parameter to TRUE, however this is not suggested since then each session will generate a trace in the location specified by the initialization parameter USER_DUMP_DEST that is named for the user s session id. However, the DBA should set the undocumented parameter "_public_trace_files" to TRUE in the test and development environments to allow the developers to see their trace files (on UNIX/Linux/AIX, on WINDOWS this isn't required). In order to make the trace files more useful the DBA should also set the parameter TIMED_STATISTICS to TRUE. However, the DBA should verify that the release of Oracle you are using doesn't have any bugs associated with TIMED_STATISTICS and SQL_TRACE as there have been some reported against various versions. Trace in a session As long as a user has ALTER SESSION permission they can alter their own session to be traced. The following commands will turn on tracing in a user session: ALTER SESSION SET TIMED_STATISTICS=TRUE; ALTER SESSION SET SQL_TRACE=TRUE; The user should be careful to turn off tracing when it is no longer needed. Logging off of a session automatically terminates session specific tracing. Tracing Forms, Reports Tracing in forms, reports and procedures can be turned on by use of the DBMS_SESSION.SET_SQL_TRACE command, however the TIMED_STATISTICS parameter must still be set manually or via a call using EXECUTE IMMEDIATE on versions prior to Oracle8i unless the DBMS_SYSTEM package has been loaded. In Oracle9i the DBMS_SYSTEM.SET_INT_PARAM_IN_SESSION package can be used to alter the settings of session alterable parameters. Tracing another session The DBA will usually be the one turning on and off tracing for other sessions, however, this is done using the DBMS_SYSTEM. SET_SQL_TRACE_IN_SESSION package, the oradebug program or using system events. Once the trace files are generated, the TKPROF tool is utilized to make them more user friendly. Let s examine the use of TKPROF. As an example, look at the two queries in Figure 7. Query 1: SELECT C.OWNER, C.TABLE_NAME, C.CONSTRAINT_NAME, CC.COLUMN_NAME, R.TABLE_NAME REF_TABLE, RC.COLUMN_NAME REF_COLUMN FROM DBA_CONSTRAINTS C, DBA_CONSTRAINTS R, DBA_CONS_COLUMNS CC, DBA_CONS_COLUMNS RC WHERE C.R_CONSTRAINT_NAME = R.CONSTRAINT_NAME AND C.R_OWNER = R.OWNER AND C.CONSTRAINT_NAME = CC.CONSTRAINT_NAME AND C.OWNER = CC.OWNER AND R.CONSTRAINT_NAME = RC.CONSTRAINT_NAME AND R.OWNER = RC.OWNER AND CC.POSITION = RC.POSITION AND C.CONSTRAINT_TYPE = 'R' AND C.OWNER <> 'SYS' AND C.OWNER <> 'SYSTEM' ORDER BY C.OWNER, C.TABLE_NAME, C.CONSTRAINT_NAME, CC.POSITION query 2: SELECT C.OWNER, C.TABLE_NAME, C.CONSTRAINT_NAME, CC.COLUMN_NAME, R.TABLE_NAME REF_TABLE, RC.COLUMN_NAME REF_COLUMN FROM DBA_CONSTRAINTS C, DBA_CONSTRAINTS R, DBA_CONS_COLUMNS CC, DBA_CONS_COLUMNS RC WHERE C.CONSTRAINT_TYPE = 'R' AND C.OWNER NOT IN ('SYS','SYSTEM') AND C.R_OWNER = R.OWNER and C.R_CONSTRAINT_NAME = R.CONSTRAINT_NAME

10 AND C.CONSTRAINT_NAME = CC.CONSTRAINT_NAME AND C.OWNER = CC.OWNER AND R.CONSTRAINT_NAME = RC.CONSTRAINT_NAME AND R.OWNER = RC.OWNER AND CC.POSITION = RC.POSITION ORDER BY C.OWNER, C.TABLE_NAME, C.CONSTRAINT_NAME, CC.POSITION Figure 7: Example Queries First, we turn on tracing either at the instance or session level. Since we are only interested in this session, it makes more sense to just use the session level: SQL> ALTER SESSION SET SQL_TRACE=TRUE; We then execute the code that we want to trace, this generates a trace file in the USER_DUMP directory. Once we have the code executed we turn off tracing: SQL> ALTER SESSION SET SQL_TRACE=FALSE; Then, TKPROF is executed by either moving to the directory where the trace files are located (the value of the initialization parameter user_dump_destination gives this information, or moving the trace file to a work directory and executing the tkprof command against it: tkprof input output explain=user/password sort=(sort options) Both of the queries are complex queries against views. Both of the queries retrieve the same information from the database. Close examination reveals that the only difference between them is the order of the where clause columns. Figure 8 shows the results of analyzing the above queries with the TKPROF tool. As you can see, the first query performs fractionally better based on timing data. This is due to placing the most restrictive columns first, thus reducing the volume of subsequent merges and sorts. As you can see the explain plan generated is huge since this is a multi-table and multi-view join. Unfortunately a query against views that are not owned by the user running TKPROF cannot be run through the EXPLAIN PLAN option, so if the queries you analyze involve views from multiple owners an explain plan output will not be available unless you have full SELECT privileges on the underlying objects. Figure 8 shows a partial set of results from a trace of the queries in Figure 7. ********************************************************* SELECT C.OWNER, C.TABLE_NAME, C.CONSTRAINT_NAME, CC.COLUMN_NAME, R.TABLE_NAME REF_TABLE, RC.COLUMN_NAME REF_COLUMN FROM DBA_CONSTRAINTS C, DBA_CONSTRAINTS R, DBA_CONS_COLUMNS CC, DBA_CONS_COLUMNS RC WHERE C.R_CONSTRAINT_NAME = R.CONSTRAINT_NAME AND C.R_OWNER = R.OWNER AND C.CONSTRAINT_NAME = CC.CONSTRAINT_NAME AND C.OWNER = CC.OWNER AND R.CONSTRAINT_NAME = RC.CONSTRAINT_NAME AND R.OWNER = RC.OWNER AND CC.POSITION = RC.POSITION AND C.CONSTRAINT_TYPE = 'R' AND C.OWNER <> 'SYS' AND C.OWNER <> 'SYSTEM' ORDER BY C.OWNER, C.TABLE_NAME, C.CONSTRAINT_NAME, CC.POSITION call count cpu elapsed disk query current rows Parse Execute Fetch total Misses in library cache during parse: 0 Optimizer goal: CHOOSE Parsing user id: 5 (SYSTEM) Rows Row Source Operation

11 SORT ORDER BY OUTER OUTER OUTER OUTER OUTER OUTER OUTER OUTER OUTER OUTER OUTER 3907 NESTED LOOPS 3907 NESTED LOOPS 5594 NESTED LOOPS 5594 NESTED LOOPS 5594 NESTED LOOPS OUTER 5594 NESTED LOOPS 5594 NESTED LOOPS 5594 NESTED LOOPS TABLE ACCESS FULL OBJ$ 5594 TABLE ACCESS CLUSTER CCOL$ 1540 INDEX UNIQUE SCAN I_COBJ# (object id 30) 5594 TABLE ACCESS BY INDEX ROWID CDEF$ 5594 INDEX UNIQUE SCAN I_CDEF1 (object id 50) 5594 TABLE ACCESS BY INDEX ROWID COL$ 5594 INDEX UNIQUE SCAN I_COL3 (object id 47) 3 TABLE ACCESS CLUSTER ATTRCOL$ 5594 TABLE ACCESS BY INDEX ROWID CON$ 5594 INDEX UNIQUE SCAN I_CON2 (object id 49) 5594 TABLE ACCESS CLUSTER USER$ 5594 INDEX UNIQUE SCAN I_USER# (object id 11) 3907 TABLE ACCESS BY INDEX ROWID USER$ 3907 INDEX UNIQUE SCAN I_USER1 (object id 44) 3907 TABLE ACCESS BY INDEX ROWID CON$ 3907 INDEX UNIQUE SCAN I_CON1 (object id 48) 575 TABLE ACCESS BY INDEX ROWID CDEF$ 3907 INDEX UNIQUE SCAN I_CDEF1 (object id 50) 574 TABLE ACCESS BY INDEX ROWID OBJ$ 574 INDEX UNIQUE SCAN I_OBJ1 (object id 36) 575 TABLE ACCESS BY INDEX ROWID OBJ$ 575 INDEX UNIQUE SCAN I_OBJ1 (object id 36) 575 INDEX UNIQUE SCAN I_OBJ1 (object id 36) 575 TABLE ACCESS BY INDEX ROWID CON$ 575 INDEX UNIQUE SCAN I_CON2 (object id 49) 574 TABLE ACCESS CLUSTER USER$ 574 INDEX UNIQUE SCAN I_USER# (object id 11) 575 TABLE ACCESS CLUSTER USER$ 575 INDEX UNIQUE SCAN I_USER# (object id 11) 575 TABLE ACCESS BY INDEX ROWID USER$ 575 INDEX UNIQUE SCAN I_USER1 (object id 44) 575 TABLE ACCESS BY INDEX ROWID USER$ 575 INDEX UNIQUE SCAN I_USER1 (object id 44) 575 TABLE ACCESS BY INDEX ROWID CON$ 575 INDEX UNIQUE SCAN I_CON1 (object id 48) 575 TABLE ACCESS BY INDEX ROWID CON$ 575 INDEX UNIQUE SCAN I_CON1 (object id 48) 575 TABLE ACCESS BY INDEX ROWID CDEF$

12 575 INDEX UNIQUE SCAN I_CDEF1 (object id 50) 575 TABLE ACCESS BY INDEX ROWID CDEF$ 575 INDEX UNIQUE SCAN I_CDEF1 (object id 50) 575 TABLE ACCESS BY INDEX ROWID OBJ$ 575 INDEX UNIQUE SCAN I_OBJ1 (object id 36) 575 TABLE ACCESS BY INDEX ROWID OBJ$ 575 INDEX UNIQUE SCAN I_OBJ1 (object id 36) 0 INDEX UNIQUE SCAN I_OBJ1 (object id 36) 0 TABLE ACCESS BY INDEX ROWID CON$ 0 INDEX UNIQUE SCAN I_CON2 (object id 49) 575 TABLE ACCESS CLUSTER USER$ 575 INDEX UNIQUE SCAN I_USER# (object id 11) 0 TABLE ACCESS CLUSTER USER$ 0 INDEX UNIQUE SCAN I_USER# (object id 11) 575 TABLE ACCESS BY INDEX ROWID CCOL$ 1079 INDEX RANGE SCAN I_CCOL2 (object id 55) 575 INDEX UNIQUE SCAN I_OBJ1 (object id 36) 575 TABLE ACCESS BY INDEX ROWID COL$ 575 INDEX UNIQUE SCAN I_COL3 (object id 47) 0 TABLE ACCESS CLUSTER ATTRCOL$ Rows Execution Plan SELECT STATEMENT GOAL: CHOOSE 575 SORT (ORDER BY) (OUTER) (OUTER) (OUTER) (OUTER) (OUTER) (OUTER) (OUTER) (OUTER) (OUTER) (OUTER) (OUTER) 3907 NESTED LOOPS 3907 NESTED LOOPS 5594 NESTED LOOPS 5594 NESTED LOOPS 5594 NESTED LOOPS (OUTER) 5594 NESTED LOOPS 5594 NESTED LOOPS 5594 NESTED LOOPS TABLE ACCESS (FULL) OF 'OBJ$' 5594 TABLE ACCESS (CLUSTER) OF 'CCOL$' 1540 INDEX (UNIQUE SCAN) OF

13 'I_COBJ#' (NON-UNIQUE) TABLE ACCESS (BY INDEX ROWID) OF 'CDEF$' INDEX (UNIQUE SCAN) OF 'I_CDEF1' (UNIQUE) TABLE ACCESS (BY INDEX ROWID) OF 'COL$' 5594 INDEX (UNIQUE SCAN) OF 'I_COL3' (UNIQUE) 3 TABLE ACCESS (CLUSTER) OF 'ATTRCOL$' 5594 TABLE ACCESS (BY INDEX ROWID) OF 'CON$' 5594 INDEX (UNIQUE SCAN) OF 'I_CON2' (UNIQUE) 5594 TABLE ACCESS (CLUSTER) OF 'USER$' 5594 INDEX (UNIQUE SCAN) OF 'I_USER#' (NON-UNIQUE) 3907 TABLE ACCESS (BY INDEX ROWID) OF 'USER$' 3907 INDEX (UNIQUE SCAN) OF 'I_USER1' (UNIQUE) 3907 TABLE ACCESS (BY INDEX ROWID) OF 'CON$' 3907 INDEX (UNIQUE SCAN) OF 'I_CON1' (UNIQUE) 575 TABLE ACCESS (BY INDEX ROWID) OF 'CDEF$' 3907 INDEX (UNIQUE SCAN) OF 'I_CDEF1' (UNIQUE) 574 TABLE ACCESS (BY INDEX ROWID) OF 'OBJ$' 574 INDEX (UNIQUE SCAN) OF 'I_OBJ1' (UNIQUE) 575 TABLE ACCESS (BY INDEX ROWID) OF 'OBJ$' 575 INDEX (UNIQUE SCAN) OF 'I_OBJ1' (UNIQUE) 575 INDEX (UNIQUE SCAN) OF 'I_OBJ1' (UNIQUE) 575 TABLE ACCESS (BY INDEX ROWID) OF 'CON$' 575 INDEX (UNIQUE SCAN) OF 'I_CON2' (UNIQUE) 574 TABLE ACCESS (CLUSTER) OF 'USER$' 574 INDEX (UNIQUE SCAN) OF 'I_USER#' (NON-UNIQUE) 575 TABLE ACCESS (CLUSTER) OF 'USER$' 575 INDEX (UNIQUE SCAN) OF 'I_USER#' (NON-UNIQUE) 575 TABLE ACCESS (BY INDEX ROWID) OF 'USER$' 575 INDEX (UNIQUE SCAN) OF 'I_USER1' (UNIQUE) 575 TABLE ACCESS (BY INDEX ROWID) OF 'USER$' 575 INDEX (UNIQUE SCAN) OF 'I_USER1' (UNIQUE) 575 TABLE ACCESS (BY INDEX ROWID) OF 'CON$' 575 INDEX (UNIQUE SCAN) OF 'I_CON1' (UNIQUE)

14 575 TABLE ACCESS (BY INDEX ROWID) OF 'CON$' 575 INDEX (UNIQUE SCAN) OF 'I_CON1' (UNIQUE) 575 TABLE ACCESS (BY INDEX ROWID) OF 'CDEF$' 575 INDEX (UNIQUE SCAN) OF 'I_CDEF1' (UNIQUE) 575 TABLE ACCESS (BY INDEX ROWID) OF 'CDEF$' 575 INDEX (UNIQUE SCAN) OF 'I_CDEF1' (UNIQUE) 575 TABLE ACCESS (BY INDEX ROWID) OF 'OBJ$' 575 INDEX (UNIQUE SCAN) OF 'I_OBJ1' (UNIQUE) 575 TABLE ACCESS (BY INDEX ROWID) OF 'OBJ$' 575 INDEX (UNIQUE SCAN) OF 'I_OBJ1' (UNIQUE) 0 INDEX (UNIQUE SCAN) OF 'I_OBJ1' (UNIQUE) 0 TABLE ACCESS (BY INDEX ROWID) OF 'CON$' 0 INDEX (UNIQUE SCAN) OF 'I_CON2' (UNIQUE) 575 TABLE ACCESS (CLUSTER) OF 'USER$' 575 INDEX (UNIQUE SCAN) OF 'I_USER#' (NON-UNIQUE) 0 TABLE ACCESS (CLUSTER) OF 'USER$' 0 INDEX (UNIQUE SCAN) OF 'I_USER#' (NON-UNIQUE) 575 TABLE ACCESS (BY INDEX ROWID) OF 'CCOL$' 1079 INDEX (RANGE SCAN) OF 'I_CCOL2' (UNIQUE) 575 INDEX (UNIQUE SCAN) OF 'I_OBJ1' (UNIQUE) 575 TABLE ACCESS (BY INDEX ROWID) OF 'COL$' 575 INDEX (UNIQUE SCAN) OF 'I_COL3' (UNIQUE) 0 TABLE ACCESS (CLUSTER) OF 'ATTRCOL$' ******************************************************************************** SELECT C.OWNER, C.TABLE_NAME, C.CONSTRAINT_NAME, CC.COLUMN_NAME, R.TABLE_NAME REF_TABLE, RC.COLUMN_NAME REF_COLUMN FROM DBA_CONSTRAINTS C, DBA_CONSTRAINTS R, DBA_CONS_COLUMNS CC, DBA_CONS_COLUMNS RC WHERE C.CONSTRAINT_TYPE = 'R' AND C.OWNER NOT IN ('SYS','SYSTEM') AND C.R_OWNER = R.OWNER and C.R_CONSTRAINT_NAME = R.CONSTRAINT_NAME AND C.CONSTRAINT_NAME = CC.CONSTRAINT_NAME AND C.OWNER = CC.OWNER AND R.CONSTRAINT_NAME = RC.CONSTRAINT_NAME AND R.OWNER = RC.OWNER AND CC.POSITION = RC.POSITION ORDER BY C.OWNER, C.TABLE_NAME, C.CONSTRAINT_NAME, CC.POSITION call count cpu elapsed disk query current rows Parse Execute Fetch total Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 5 (SYSTEM) Rows Row Source Operation SORT ORDER BY OUTER OUTER OUTER OUTER OUTER

15 OUTER OUTER OUTER OUTER OUTER OUTER 3907 NESTED LOOPS 3907 NESTED LOOPS 5594 NESTED LOOPS 5594 NESTED LOOPS 5594 NESTED LOOPS OUTER 5594 NESTED LOOPS 5594 NESTED LOOPS 5594 NESTED LOOPS TABLE ACCESS FULL OBJ$ 5594 TABLE ACCESS CLUSTER CCOL$ 1540 INDEX UNIQUE SCAN I_COBJ# (object id 30) 5594 TABLE ACCESS BY INDEX ROWID CDEF$ 5594 INDEX UNIQUE SCAN I_CDEF1 (object id 50) 5594 TABLE ACCESS BY INDEX ROWID COL$ 5594 INDEX UNIQUE SCAN I_COL3 (object id 47) 3 TABLE ACCESS CLUSTER ATTRCOL$ 5594 TABLE ACCESS BY INDEX ROWID CON$ 5594 INDEX UNIQUE SCAN I_CON2 (object id 49) 5594 TABLE ACCESS CLUSTER USER$ 5594 INDEX UNIQUE SCAN I_USER# (object id 11) 3907 TABLE ACCESS BY INDEX ROWID USER$ 3907 INDEX UNIQUE SCAN I_USER1 (object id 44) 3907 TABLE ACCESS BY INDEX ROWID CON$ 3907 INDEX UNIQUE SCAN I_CON1 (object id 48) 575 TABLE ACCESS BY INDEX ROWID CDEF$ 3907 INDEX UNIQUE SCAN I_CDEF1 (object id 50) 574 TABLE ACCESS BY INDEX ROWID OBJ$ 574 INDEX UNIQUE SCAN I_OBJ1 (object id 36) 575 TABLE ACCESS BY INDEX ROWID OBJ$ 575 INDEX UNIQUE SCAN I_OBJ1 (object id 36) 575 INDEX UNIQUE SCAN I_OBJ1 (object id 36) 575 TABLE ACCESS BY INDEX ROWID CON$ 575 INDEX UNIQUE SCAN I_CON2 (object id 49) 574 TABLE ACCESS CLUSTER USER$ 574 INDEX UNIQUE SCAN I_USER# (object id 11) 575 TABLE ACCESS CLUSTER USER$ 575 INDEX UNIQUE SCAN I_USER# (object id 11) 575 TABLE ACCESS BY INDEX ROWID USER$ 575 INDEX UNIQUE SCAN I_USER1 (object id 44) 575 TABLE ACCESS BY INDEX ROWID USER$ 575 INDEX UNIQUE SCAN I_USER1 (object id 44) 575 TABLE ACCESS BY INDEX ROWID CON$ 575 INDEX UNIQUE SCAN I_CON1 (object id 48) 575 TABLE ACCESS BY INDEX ROWID CON$ 575 INDEX UNIQUE SCAN I_CON1 (object id 48) 575 TABLE ACCESS BY INDEX ROWID CDEF$ 575 INDEX UNIQUE SCAN I_CDEF1 (object id 50) 575 TABLE ACCESS BY INDEX ROWID CDEF$ 575 INDEX UNIQUE SCAN I_CDEF1 (object id 50) 575 TABLE ACCESS BY INDEX ROWID OBJ$ 575 INDEX UNIQUE SCAN I_OBJ1 (object id 36) 575 TABLE ACCESS BY INDEX ROWID OBJ$ 575 INDEX UNIQUE SCAN I_OBJ1 (object id 36) 0 INDEX UNIQUE SCAN I_OBJ1 (object id 36) 0 TABLE ACCESS BY INDEX ROWID CON$ 0 INDEX UNIQUE SCAN I_CON2 (object id 49)

16 575 TABLE ACCESS CLUSTER USER$ 575 INDEX UNIQUE SCAN I_USER# (object id 11) 0 TABLE ACCESS CLUSTER USER$ 0 INDEX UNIQUE SCAN I_USER# (object id 11) 575 TABLE ACCESS BY INDEX ROWID CCOL$ 1079 INDEX RANGE SCAN I_CCOL2 (object id 55) 575 INDEX UNIQUE SCAN I_OBJ1 (object id 36) 575 TABLE ACCESS BY INDEX ROWID COL$ 575 INDEX UNIQUE SCAN I_COL3 (object id 47) 0 TABLE ACCESS CLUSTER ATTRCOL$ Rows Execution Plan SELECT STATEMENT GOAL: CHOOSE 575 SORT (ORDER BY) (OUTER) (OUTER) (OUTER) (OUTER) (OUTER) (OUTER) (OUTER) (OUTER) (OUTER) (OUTER) (OUTER) 3907 NESTED LOOPS 3907 NESTED LOOPS 5594 NESTED LOOPS 5594 NESTED LOOPS 5594 NESTED LOOPS (OUTER) 5594 NESTED LOOPS 5594 NESTED LOOPS 5594 NESTED LOOPS TABLE ACCESS (FULL) OF 'OBJ$' 5594 TABLE ACCESS (CLUSTER) OF 'CCOL$' 1540 INDEX (UNIQUE SCAN) OF 'I_COBJ#' (NON-UNIQUE) 5594 TABLE ACCESS (BY INDEX ROWID) OF 'CDEF$' 5594 INDEX (UNIQUE SCAN) OF 'I_CDEF1' (UNIQUE) 5594 TABLE ACCESS (BY INDEX ROWID) OF 'COL$'

17 5594 INDEX (UNIQUE SCAN) OF 'I_COL3' (UNIQUE) 3 TABLE ACCESS (CLUSTER) OF 'ATTRCOL$' 5594 TABLE ACCESS (BY INDEX ROWID) OF 'CON$' 5594 INDEX (UNIQUE SCAN) OF 'I_CON2' (UNIQUE) 5594 TABLE ACCESS (CLUSTER) OF 'USER$' 5594 INDEX (UNIQUE SCAN) OF 'I_USER#' (NON-UNIQUE) 3907 TABLE ACCESS (BY INDEX ROWID) OF 'USER$' 3907 INDEX (UNIQUE SCAN) OF 'I_USER1' (UNIQUE) 3907 TABLE ACCESS (BY INDEX ROWID) OF 'CON$' 3907 INDEX (UNIQUE SCAN) OF 'I_CON1' (UNIQUE) 575 TABLE ACCESS (BY INDEX ROWID) OF 'CDEF$' 3907 INDEX (UNIQUE SCAN) OF 'I_CDEF1' (UNIQUE) 574 TABLE ACCESS (BY INDEX ROWID) OF 'OBJ$' 574 INDEX (UNIQUE SCAN) OF 'I_OBJ1' (UNIQUE) 575 TABLE ACCESS (BY INDEX ROWID) OF 'OBJ$' 575 INDEX (UNIQUE SCAN) OF 'I_OBJ1' (UNIQUE) 575 INDEX (UNIQUE SCAN) OF 'I_OBJ1' (UNIQUE) 575 TABLE ACCESS (BY INDEX ROWID) OF 'CON$' 575 INDEX (UNIQUE SCAN) OF 'I_CON2' (UNIQUE) 574 TABLE ACCESS (CLUSTER) OF 'USER$' 574 INDEX (UNIQUE SCAN) OF 'I_USER#' (NON-UNIQUE) 575 TABLE ACCESS (CLUSTER) OF 'USER$' 575 INDEX (UNIQUE SCAN) OF 'I_USER#' (NON-UNIQUE) 575 TABLE ACCESS (BY INDEX ROWID) OF 'USER$' 575 INDEX (UNIQUE SCAN) OF 'I_USER1' (UNIQUE) 575 TABLE ACCESS (BY INDEX ROWID) OF 'USER$' 575 INDEX (UNIQUE SCAN) OF 'I_USER1' (UNIQUE) 575 TABLE ACCESS (BY INDEX ROWID) OF 'CON$' 575 INDEX (UNIQUE SCAN) OF 'I_CON1' (UNIQUE) 575 TABLE ACCESS (BY INDEX ROWID) OF 'CON$' 575 INDEX (UNIQUE SCAN) OF 'I_CON1' (UNIQUE) 575 TABLE ACCESS (BY INDEX ROWID) OF 'CDEF$' 575 INDEX (UNIQUE SCAN) OF 'I_CDEF1' (UNIQUE) 575 TABLE ACCESS (BY INDEX ROWID) OF 'CDEF$'

18 575 INDEX (UNIQUE SCAN) OF 'I_CDEF1' (UNIQUE) 575 TABLE ACCESS (BY INDEX ROWID) OF 'OBJ$' 575 INDEX (UNIQUE SCAN) OF 'I_OBJ1' (UNIQUE) 575 TABLE ACCESS (BY INDEX ROWID) OF 'OBJ$' 575 INDEX (UNIQUE SCAN) OF 'I_OBJ1' (UNIQUE) 0 INDEX (UNIQUE SCAN) OF 'I_OBJ1' (UNIQUE) 0 TABLE ACCESS (BY INDEX ROWID) OF 'CON$' 0 INDEX (UNIQUE SCAN) OF 'I_CON2' (UNIQUE) 575 TABLE ACCESS (CLUSTER) OF 'USER$' 575 INDEX (UNIQUE SCAN) OF 'I_USER#' (NON-UNIQUE) 0 TABLE ACCESS (CLUSTER) OF 'USER$' 0 INDEX (UNIQUE SCAN) OF 'I_USER#' (NON-UNIQUE) 575 TABLE ACCESS (BY INDEX ROWID) OF 'CCOL$' 1079 INDEX (RANGE SCAN) OF 'I_CCOL2' (UNIQUE) 575 INDEX (UNIQUE SCAN) OF 'I_OBJ1' (UNIQUE) 575 TABLE ACCESS (BY INDEX ROWID) OF 'COL$' 575 INDEX (UNIQUE SCAN) OF 'I_COL3' (UNIQUE) 0 TABLE ACCESS (CLUSTER) OF 'ATTRCOL$' ******************************************************************************** Figure 8. TKPROF results from queries in Figure 7. As you can see, the re-arrangement of the where clause has reduced the CPU and elapsed statistics for both the parse phase of the query processing. You may find it difficult to really get valid results unless your datasets are large or your processor is slow. To use the TKPROF tool and get timing results the TIMED_STATISTICS parameter in the INIT.ORA file must be set to TRUE. To limit the size of the generated trace file set the INIT.ORA parameter MAX_DUMP_FILE_SIZE to the desired file size limit. If you want the files to be created in other than the ORA_INSTANCE, ORA_TRACE or the $ORACLE_HOME directory set the USER_DUMP_DEST to the desired file location. In order for these parameters to take effect, the instance has to be shutdown and restarted. Since the performance penalty is slight and the benefits derived potentially great leave the TIMED_STATISTIC parameter set to TRUE. Setting TIMED_STATISTICS to TRUE will allow individual users to set the SQL_TRACE value for their process to TRUE which will then generate a trace file in the ORA_TRACE or selected directory. The users should then execute the statements from within SQLPLUS. To use the trace facility in SQL*Plus the ALTER SESSION command is used. For example: ALTER SESSION SET SQL_TRACE TRUE; Use of TKPROF Once the SQL statements or applications have been run, exit SQLPLUS or the forms based application and look for the proper trace file that corresponds to the PID of the process that generated it. For example if the database is testb, the PID in Oracle is 5 and the program being run is SQLPLUS the trace file will be SQLPLUS_F30_TESTB_005.TRC. On your system the file naming may be different. Usually the name will contain the PID. If you try to look at this file without processing through TKPROF, you will receive little benefit. An unformatted file excerpt is shown in Figure 9. TKPROF formats the trace files into a user readable form. I suggest turning off Multi-threaded server (MTS) while tuning with TKPROF since you cannot control what sessions will be threaded into a single process stream. ===================== PARSING IN CURSOR #1 len=566 dep=0 uid=5 oct=3 lid=5 tim= hv= ad='6fe9240c' SELECT C.OWNER, C.TABLE_NAME, C.CONSTRAINT_NAME, CC.COLUMN_NAME, R.TABLE_NAME REF_TABLE, RC.COLUMN_NAME REF_COLUMN FROM DBA_CONSTRAINTS C, DBA_CONSTRAINTS R, DBA_CONS_COLUMNS CC, DBA_CONS_COLUMNS RC WHERE C.R_CONSTRAINT_NAME = R.CONSTRAINT_NAME AND C.R_OWNER = R.OWNER AND C.CONSTRAINT_NAME = CC.CONSTRAINT_NAME AND C.OWNER = CC.OWNER AND R.CONSTRAINT_NAME = RC.CONSTRAINT_NAME AND R.OWNER = RC.OWNER AND CC.POSITION = RC.POSITION

19 AND C.CONSTRAINT_TYPE = 'R' AND C.OWNER <> 'SYS' AND C.OWNER <> 'SYSTEM' ORDER BY C.OWNER, C.TABLE_NAME, C.CONSTRAINT_NAME, CC.POSITION END OF STMT PARSE #1:c=0,e=86,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim= EXEC #1:c=0,e=246,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim= FETCH #1:c=406250,e=427185,p=0,cr=138045,cu=0,mis=0,r=1,dep=0,og=4,tim= FETCH #1:c=0,e=53,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=4,tim= FETCH #1:c=0,e=53,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=4,tim= FETCH #1:c=0,e=52,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=4,tim= FETCH #1:c=0,e=51,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=4,tim= FETCH #1:c=0,e=53,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=4,tim= FETCH #1:c=0,e=51,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=4,tim= FETCH #1:c=0,e=63,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=4,tim= FETCH #1:c=0,e=52,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=4,tim= FETCH #1:c=0,e=52,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=4,tim= FETCH #1:c=0,e=54,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=4,tim= FETCH #1:c=0,e=52,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=4,tim= FETCH #1:c=0,e=53,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=4,tim= FETCH #1:c=0,e=50,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=4,tim= FETCH #1:c=0,e=51,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=4,tim= FETCH #1:c=0,e=54,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=4,tim= FETCH #1:c=0,e=52,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=4,tim= FETCH #1:c=0,e=56,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=4,tim= FETCH #1:c=0,e=54,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=4,tim= FETCH #1:c=0,e=51,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=4,tim= FETCH #1:c=0,e=49,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=4,tim= FETCH #1:c=0,e=52,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=4,tim= FETCH #1:c=0,e=51,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=4,tim= FETCH #1:c=0,e=50,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=4,tim= FETCH #1:c=0,e=51,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=4,tim= FETCH #1:c=0,e=52,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=4,tim= FETCH #1:c=0,e=52,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=4,tim= FETCH #1:c=0,e=50,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=4,tim= FETCH #1:c=0,e=51,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=4,tim= FETCH #1:c=0,e=52,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=4,tim= FETCH #1:c=0,e=49,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=4,tim= FETCH #1:c=0,e=50,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=4,tim= FETCH #1:c=0,e=52,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=4,tim= FETCH #1:c=0,e=52,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=4,tim= FETCH #1:c=0,e=49,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=4,tim= FETCH #1:c=0,e=55,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=4,tim= FETCH #1:c=0,e=52,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=4,tim= FETCH #1:c=0,e=58,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=4,tim= FETCH #1:c=0,e=51,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=4,tim= FETCH #1:c=0,e=103,p=0,cr=0,cu=0,mis=0,r=4,dep=0,og=4,tim= STAT #1 id=1 cnt=575 pid=0 pos=1 obj=0 op='sort ORDER BY ' STAT #1 id=2 cnt=575 pid=1 pos=1 obj=0 op='nested LOOPS OUTER ' STAT #1 id=3 cnt=575 pid=2 pos=1 obj=0 op='nested LOOPS ' STAT #1 id=4 cnt=575 pid=3 pos=1 obj=0 op='nested LOOPS ' STAT #1 id=5 cnt=575 pid=4 pos=1 obj=0 op='nested LOOPS ' STAT #1 id=6 cnt=575 pid=5 pos=1 obj=0 op='nested LOOPS OUTER ' STAT #1 id=7 cnt=575 pid=6 pos=1 obj=0 op='nested LOOPS OUTER ' STAT #1 id=8 cnt=575 pid=7 pos=1 obj=0 op='nested LOOPS OUTER ' STAT #1 id=9 cnt=575 pid=8 pos=1 obj=0 op='nested LOOPS OUTER ' STAT #1 id=10 cnt=575 pid=9 pos=1 obj=0 op='nested LOOPS ' STAT #1 id=11 cnt=575 pid=10 pos=1 obj=0 op='nested LOOPS OUTER ' STAT #1 id=12 cnt=575 pid=11 pos=1 obj=0 op='nested LOOPS ' STAT #1 id=13 cnt=575 pid=12 pos=1 obj=0 op='nested LOOPS ' STAT #1 id=14 cnt=575 pid=13 pos=1 obj=0 op='nested LOOPS ' STAT #1 id=15 cnt=575 pid=14 pos=1 obj=0 op='nested LOOPS ' STAT #1 id=16 cnt=575 pid=15 pos=1 obj=0 op='nested LOOPS ' STAT #1 id=17 cnt=575 pid=16 pos=1 obj=0 op='nested LOOPS ' STAT #1 id=18 cnt=575 pid=17 pos=1 obj=0 op='nested LOOPS OUTER ' STAT #1 id=19 cnt=575 pid=18 pos=1 obj=0 op='nested LOOPS OUTER ' STAT #1 id=20 cnt=575 pid=19 pos=1 obj=0 op='nested LOOPS OUTER ' STAT #1 id=21 cnt=575 pid=20 pos=1 obj=0 op='nested LOOPS OUTER ' STAT #1 id=22 cnt=575 pid=21 pos=1 obj=0 op='nested LOOPS ' STAT #1 id=23 cnt=575 pid=22 pos=1 obj=0 op='nested LOOPS OUTER ' STAT #1 id=24 cnt=575 pid=23 pos=1 obj=0 op='nested LOOPS ' STAT #1 id=25 cnt=3907 pid=24 pos=1 obj=0 op='nested LOOPS '

20 STAT #1 id=26 cnt=3907 pid=25 pos=1 obj=0 op='nested LOOPS ' STAT #1 id=27 cnt=5594 pid=26 pos=1 obj=0 op='nested LOOPS ' STAT #1 id=28 cnt=5594 pid=27 pos=1 obj=0 op='nested LOOPS ' STAT #1 id=29 cnt=5594 pid=28 pos=1 obj=0 op='nested LOOPS OUTER ' STAT #1 id=30 cnt=5594 pid=29 pos=1 obj=0 op='nested LOOPS ' STAT #1 id=31 cnt=5594 pid=30 pos=1 obj=0 op='nested LOOPS ' STAT #1 id=32 cnt=5594 pid=31 pos=1 obj=0 op='nested LOOPS ' STAT #1 id=33 cnt=34381 pid=32 pos=1 obj=18 op='table ACCESS FULL OBJ$ ' STAT #1 id=34 cnt=5594 pid=32 pos=2 obj=32 op='table ACCESS CLUSTER CCOL$ ' STAT #1 id=35 cnt=1540 pid=34 pos=1 obj=30 op='index UNIQUE SCAN I_COBJ# ' STAT #1 id=36 cnt=5594 pid=31 pos=2 obj=31 op='table ACCESS BY INDEX ROWID CDEF$ ' STAT #1 id=37 cnt=5594 pid=36 pos=1 obj=50 op='index UNIQUE SCAN I_CDEF1 ' STAT #1 id=38 cnt=5594 pid=30 pos=2 obj=21 op='table ACCESS BY INDEX ROWID COL$ ' STAT #1 id=39 cnt=5594 pid=38 pos=1 obj=47 op='index UNIQUE SCAN I_COL3 ' STAT #1 id=40 cnt=3 pid=29 pos=2 obj=288 op='table ACCESS CLUSTER ATTRCOL$ ' STAT #1 id=41 cnt=5594 pid=28 pos=2 obj=28 op='table ACCESS BY INDEX ROWID CON$ ' STAT #1 id=42 cnt=5594 pid=41 pos=1 obj=49 op='index UNIQUE SCAN I_CON2 ' STAT #1 id=43 cnt=5594 pid=27 pos=2 obj=22 op='table ACCESS CLUSTER USER$ ' STAT #1 id=44 cnt=5594 pid=43 pos=1 obj=11 op='index UNIQUE SCAN I_USER# ' STAT #1 id=45 cnt=3907 pid=26 pos=2 obj=22 op='table ACCESS BY INDEX ROWID USER$ ' STAT #1 id=46 cnt=3907 pid=45 pos=1 obj=44 op='index UNIQUE SCAN I_USER1 ' STAT #1 id=47 cnt=3907 pid=25 pos=2 obj=28 op='table ACCESS BY INDEX ROWID CON$ ' STAT #1 id=48 cnt=3907 pid=47 pos=1 obj=48 op='index UNIQUE SCAN I_CON1 ' STAT #1 id=49 cnt=575 pid=24 pos=2 obj=31 op='table ACCESS BY INDEX ROWID CDEF$ ' STAT #1 id=50 cnt=3907 pid=49 pos=1 obj=50 op='index UNIQUE SCAN I_CDEF1 ' STAT #1 id=51 cnt=574 pid=23 pos=2 obj=18 op='table ACCESS BY INDEX ROWID OBJ$ ' STAT #1 id=52 cnt=574 pid=51 pos=1 obj=36 op='index UNIQUE SCAN I_OBJ1 ' STAT #1 id=53 cnt=575 pid=22 pos=2 obj=18 op='table ACCESS BY INDEX ROWID OBJ$ ' STAT #1 id=54 cnt=575 pid=53 pos=1 obj=36 op='index UNIQUE SCAN I_OBJ1 ' STAT #1 id=55 cnt=575 pid=21 pos=2 obj=36 op='index UNIQUE SCAN I_OBJ1 ' STAT #1 id=56 cnt=575 pid=20 pos=2 obj=28 op='table ACCESS BY INDEX ROWID CON$ ' STAT #1 id=57 cnt=575 pid=56 pos=1 obj=49 op='index UNIQUE SCAN I_CON2 ' STAT #1 id=58 cnt=574 pid=19 pos=2 obj=22 op='table ACCESS CLUSTER USER$ ' STAT #1 id=59 cnt=574 pid=58 pos=1 obj=11 op='index UNIQUE SCAN I_USER# ' STAT #1 id=60 cnt=575 pid=18 pos=2 obj=22 op='table ACCESS CLUSTER USER$ ' STAT #1 id=61 cnt=575 pid=60 pos=1 obj=11 op='index UNIQUE SCAN I_USER# ' STAT #1 id=62 cnt=575 pid=17 pos=2 obj=22 op='table ACCESS BY INDEX ROWID USER$ ' STAT #1 id=63 cnt=575 pid=62 pos=1 obj=44 op='index UNIQUE SCAN I_USER1 ' STAT #1 id=64 cnt=575 pid=16 pos=2 obj=22 op='table ACCESS BY INDEX ROWID USER$ ' STAT #1 id=65 cnt=575 pid=64 pos=1 obj=44 op='index UNIQUE SCAN I_USER1 ' STAT #1 id=66 cnt=575 pid=15 pos=2 obj=28 op='table ACCESS BY INDEX ROWID CON$ ' STAT #1 id=67 cnt=575 pid=66 pos=1 obj=48 op='index UNIQUE SCAN I_CON1 ' STAT #1 id=68 cnt=575 pid=14 pos=2 obj=28 op='table ACCESS BY INDEX ROWID CON$ ' STAT #1 id=69 cnt=575 pid=68 pos=1 obj=48 op='index UNIQUE SCAN I_CON1 ' STAT #1 id=70 cnt=575 pid=13 pos=2 obj=31 op='table ACCESS BY INDEX ROWID CDEF$ ' STAT #1 id=71 cnt=575 pid=70 pos=1 obj=50 op='index UNIQUE SCAN I_CDEF1 ' STAT #1 id=72 cnt=575 pid=12 pos=2 obj=31 op='table ACCESS BY INDEX ROWID CDEF$ ' STAT #1 id=73 cnt=575 pid=72 pos=1 obj=50 op='index UNIQUE SCAN I_CDEF1 ' STAT #1 id=74 cnt=575 pid=11 pos=2 obj=18 op='table ACCESS BY INDEX ROWID OBJ$ ' STAT #1 id=75 cnt=575 pid=74 pos=1 obj=36 op='index UNIQUE SCAN I_OBJ1 ' STAT #1 id=76 cnt=575 pid=10 pos=2 obj=18 op='table ACCESS BY INDEX ROWID OBJ$ ' STAT #1 id=77 cnt=575 pid=76 pos=1 obj=36 op='index UNIQUE SCAN I_OBJ1 ' STAT #1 id=78 cnt=0 pid=9 pos=2 obj=36 op='index UNIQUE SCAN I_OBJ1 ' STAT #1 id=79 cnt=0 pid=8 pos=2 obj=28 op='table ACCESS BY INDEX ROWID CON$ ' STAT #1 id=80 cnt=0 pid=79 pos=1 obj=49 op='index UNIQUE SCAN I_CON2 ' STAT #1 id=81 cnt=575 pid=7 pos=2 obj=22 op='table ACCESS CLUSTER USER$ ' STAT #1 id=82 cnt=575 pid=81 pos=1 obj=11 op='index UNIQUE SCAN I_USER# ' STAT #1 id=83 cnt=0 pid=6 pos=2 obj=22 op='table ACCESS CLUSTER USER$ ' STAT #1 id=84 cnt=0 pid=83 pos=1 obj=11 op='index UNIQUE SCAN I_USER# ' STAT #1 id=85 cnt=575 pid=5 pos=2 obj=32 op='table ACCESS BY INDEX ROWID CCOL$ ' STAT #1 id=86 cnt=1079 pid=85 pos=1 obj=55 op='index RANGE SCAN I_CCOL2 ' STAT #1 id=87 cnt=575 pid=4 pos=2 obj=36 op='index UNIQUE SCAN I_OBJ1 ' STAT #1 id=88 cnt=575 pid=3 pos=2 obj=21 op='table ACCESS BY INDEX ROWID COL$ ' STAT #1 id=89 cnt=575 pid=88 pos=1 obj=47 op='index UNIQUE SCAN I_COL3 ' STAT #1 id=90 cnt=0 pid=2 pos=2 obj=288 op='table ACCESS CLUSTER ATTRCOL$ ' ===================== The format of the TKPROF command follows. Figure 9: Trace File Raw Contents

21 Invoke TKPROF using this syntax: >---tkprof --- trace_file -- output_file >> -----SORT = v , (---- option )-- > >> -- PRINT = integer INSERT = filename SYS = YES NO > >> EXPLAIN = user/password TABLE = schema.table > >< --- RECORD = filename---- If you invoke TKPROF with no arguments, online help is displayed as shown in Figure 10. D:\oracle\admin\aultdb2\udump>tkprof Usage: tkprof tracefile outputfile [explain= ] [table= ] [print= ] [insert= ] [sys= ] [sort= ] table=schema.tablename Use 'schema.tablename' with 'explain=' option. explain=user/password Connect to ORACLE and issue EXPLAIN PLAN. print=integer List only the first 'integer' SQL statements. aggregate=yes no Aggregate multiple statements insert=filename List SQL statements and data inside INSERT statements. sys=no TKPROF does not list SQL statements run as user SYS. record=filename Record non-recursive statements found in the trace file. waits=yes no Record summary for any wait events found in the trace file. sort=option Set of zero or more of the following sort options: prscnt number of times parse was called prscpu cpu time parsing prsela elapsed time parsing prsdsk number of disk reads during parse prsqry number of buffers for consistent read during parse prscu number of buffers for current read during parse prsmis number of misses in library cache during parse execnt number of execute was called execpu cpu time spent executing exeela elapsed time executing exedsk number of disk reads during execute exeqry number of buffers for consistent read during execute execu number of buffers for current read during execute exerow number of rows processed during execute exemis number of library cache misses during execute fchcnt number of times fetch was called fchcpu cpu time spent fetching fchela elapsed time fetching fchdsk number of disk reads during fetch fchqry number of buffers for consistent read during fetch fchcu number of buffers for current read during fetch fchrow number of rows fetched userid userid of user that parsed the cursor Figure 10: Example Help Listing of TKPROF The EXPLAIN option of TKPROF To use the EXPLAIN option, a user must have resource privilege on a tablespace so the needed tables can be created. The command is issued at the operating system level. To split the command on multiple lines, in UNIX you simply place a "/" (backslash) character at the end of the line to be continued. Usually you can wrap up to 256 characters in a single command without worrying about line splitting. The above command will generate a file named to whatever you specified the output file to be. If you include the SORT qualifier, the output will be sorted accordingly. If you include the EXPLAIN qualifier, a temporary table will be created in the user's default tablespace and the various SQL statements will be "explained" in accordance with the formats of the explain plan command.

22 TKPROF Statistics Each line of statistics will correspond to either the parse, execute or fetch part of the query operation. These parts of a query are defined as: Parse - The query is translated into an execution plan. If the user doesn't have the proper security or table authorization or the objects in the query don't exist, this step will catch it as well. Execute - The execution plan is executed against the ORDBMS. Fetch - In this final step, all rows that satisfy the query are retrieved from the database. For each step the following parameters are traced: count cpu - This is the number of times this step was repeated. - This is the total cpu time for the step in hundredths of a second. elapsed - This is the total elapsed time for the step in hundredths of a second. disk query - This is the total number of database blocks read from disk for the step. - This is the number of buffers retrieved in a consistent read mode current - This is the number of buffers retrieved in current mode. rows - This is the number of rows processed during the SQL statement execution step. TKPROF Summary TKPROF is a powerful too to help you understand the trace file output from tracing your SQL session. This formatted output provides you with the statistics and detailed explain plan for your queries allowing you to tune them efficiently. Using DBMS_PROFILER The DBMS_PROFILER package is similar to a statspack report for PL/SQL. Just as statspack collects database level statistics for later analysis the DBMS_PROFILER package does the same for PL/SQL. The package allows you to start, stop and flush statistics to persistent storage. The DBMS_PROFILER package is created using the PROFLOAD.SQL script located in the $ORACLE_HOME/rdbms/admin directory on UNIX and ORACLE_HOME\rdbms\admin directory on NT. The required storage tables for persistent data retention are created using the PROFTAB.SQL script co-located with the PROFLOAD.SQL script. If the data collected by DBMS_PROFILER packages is not flushed to the persistent tables created with PROFTAB.SQL the data is erased at the end of the monitoring session. Data is only flushed when the explicit call to the flush_data procedure is made or when the stop_profiler function is executed. To ensure collection of proper statistics put the application though a complete cycle before invoking the start_profiler function, otherwise startup noise of the PL/SQL portions of the application may mask or indicate non-existent problems. The profiler gathers the following information about each line of PL/SQL code: Total elapsed time in execution Number of times line has been executed Minimum and maximum times spent executing line Based on the above information the DBA and developers can concentrate their efforts on the PL/SQL statements that are the most costly. DBMS_PROFILER must be installed as the SYS user. The functions in the DBMS_PROFILER package have the following return codes: ERROR_PARAM which shows an incorrect parameter was sent to the function it corresponds to a one (1). ERROR_IO which shows that a data flush operation failed, usually due to permission or tables not being present it corresponds to a two (2). ERROR_VERSION which shows there is a mismatch between the version of profiler and the database it corresponds to a negative one (-1).

23 START_PROFILER The start_profiler function has a single input variable: run_comment VARCHAR2 which defaults to the value of SYSDATE. The function starts collection of PL/SQL statistics and should not be invoked until the application has been run through once to avoid startup noise. The function returns a BINARY_INTEGER which will be zero (0) if the call was successful, otherwise it will relate to one of the standard DBMS_PROFILER error codes. DBMS_PROFILE.START_PROFILER(run_comment IN VARCHAR2:=SYSDATE) RETURN BINARY_INTEGER; STOP_PROFILER The stop_profiler function has no input variables and returns a BINARY_INTEGER which will be zero (0) if the call was successful, otherwise it will relate to one of the standard DBMS_PROFILER error codes. The stop_profiler flushes statistics to the pre-defined flush tables and stops PL/SQL statistics gathering. DBMS_PROFILER.STOP_PROFILER RETURN BINARY_INTEGER; FLUSH_DATA The flush_data function has no input variables and returns a BINARY_INTEGER that will be zero (0) if the call was successful, otherwise it will relate to one of the standard DBMS_PROFILER error codes. The flush_data function flushes statistics to the pre-defined flush tables. The flush_data function can be used at anytime during statistics gathering to provide intermediate looks at PL/SQL statistics. To use FLUSH_DATA the PROFTAB.SQL script must have been run and the tables available to the executing user. DBMS_PROFILE.FLUSH_DATA RETURN BINARY_INTEGER; GET_VERSION The get_version procedure gets the version of the DBMS_PROFILER API to ensure that there isn't a version mismatch. The procedure GET_VERSION has the following output variables: Major BINARY_INTEGER Minor BINARY_INTEGER DBMS_PROFILER.GET_VERSION(major VARCHAR2, minor VARCHAR2); INTERNAL_VERSION_CHECK The internal version check function verifies that this version of DBMS_PROFILER will work with the version of the database. The function has no input variables and returns a BINARY_INTEGER which will be zero (0) if the call was successful, otherwise it will relate to one of the standard DBMS_PROFILER error codes. DBMS_PROFILER.INTERNAL_VERSION_CHECK RETURNS BINARY_INTEGER; Example Using DBMS_PROFILER In order to use DBMS_PROFILER you must insert calls to the various functions inside DBMS_PROFILER into your package. Look at Figure 11 which shows a simple PL/SQL anonymous block. declare x integer; begin x:=dbms_profiler.start_profiler('test Profiler'); DBA_UTILITIES.just_statistics; x:=dbms_profiler.flush_data; x:=dbms_profiler.stop_profiler; end; / Figure 11: Example Anonymous PL/SQL Block In listing 1 we start the profiler with the call to DBMS_PROFILER.START_PROFILER, we then execute the script we want monitored and the issue an implicit data flush (DBMS_PROFILER.FLUSH_DATA) and then issue the call to DBMS_PROFILER.STOP_PROFILER to stop the profiler from collection of data. We probably do not have to issue the DBMS_PROFILER.FLUSH_DATA since DBMS_PROFILER.STOP_PROFILE supposedly does this automatically.

24 The procedure we want to evaluate is contained in the DBA_UTILITIES package and is called JUST_STATISTICS. The procedure JUST_STATISTICS gathers various statistics about the Oracle database and writes them into a temporary file for review. The results of the operation as gleaned from the PL/SQL_PROFILER tables is shown in Figure 12. SQL> col run_comment format a20 SQL> select runid, run_date, run_total_time, run_comment from plsql_profiler_runs; RUNID RUN_DATE RUN_TOTAL_TIME RUN_COMMENT SEP E+11 Test Profiler 2 05-SEP SQL> col unit_name format a15 SQL> col unit_type format a15 SQL> column unit_owner format a11 SQL> select runid,unit_number,unit_type,unit_owner, unit_name, unit_timestamp, 2 total_time from plsql_profiler_units where runid=2; RUNID UNIT_NUMBER UNIT_TYPE UNIT_OWNER UNIT_NAME UNIT_TIME TOTAL_TIME ANONYMOUS BLOCK <anonymous> <anonymous> 00-DECEMB PACKAGE BODY SYS DBMS_PROFILER 05-SEP rows selected. SQL> select runid,unit_number, line#,total_occur, total_time, min_time, max_time 2 from plsql_profiler_data where runid=2 RUNID UNIT_NUMBER LINE# TOTAL_OCCUR TOTAL_TIME MIN_TIME MAX_TIME rows selected. Figure 12: Output from DBMS_PROFILER Tables Not a lot of information about DBA_UTILITIES shown is there? Why not? Remember, the calls to DBMS_PROFILER have to be inside the object being profiled. In this case we placed the calls inside the PL/SQL anonymous block, but not inside DBA_UTILITIES so all we profiled was the execution of the PL/SQL block. Look at Figure 13, it shows the (partial) results for the same run with the calls to DBMS_PROFILER placed both in the anonymous PL/SQL block and inside DBA_UTILITIES.JUST_STATISTICS. SQL> declare 2 x integer; 3 begin 4 x:=dbms_profiler.start_profiler('test Profiler2'); 5 DBA_UTILITIES.just_statistics; 6 x:=dbms_profiler.flush_data; 7 x:=dbms_profiler.stop_profiler;

25 8 end; 9 / PL/SQL procedure successfully completed. SQL> col run_comment format a20 SQL> select runid, run_date, run_total_time, run_comment from plsql_profiler_runs; RUNID RUN_DATE RUN_TOTAL_TIME RUN_COMMENT SEP E+11 Test Profiler 2 05-SEP SEP E+09 Test Profiler SEP SQL> select runid,unit_number,unit_type,unit_owner, unit_name, unit_timestamp, 2 total_time from plsql_profiler_units where runid>2; RUNID UNIT_NUMBER UNIT_TYPE UNIT_OWNER UNIT_NAME UNIT_TIME TOTAL_TIME PACKAGE BODY SYS DBMS_PROFILER 05-SEP ANONYMOUS BLOCK <anonymous> <anonymous> 00-DECEMB PACKAGE BODY SYSTEM DBA_UTILITIES 05-SEP ANONYMOUS BLOCK <anonymous> <anonymous> 00-DECEMB PACKAGE BODY SYS DBMS_PROFILER 05-SEP rows selected. SQL> select runid,unit_number, line#,total_occur, total_time, min_time, max_time 2 from plsql_profiler_data where runid>2; RUNID UNIT_NUMBER LINE# TOTAL_OCCUR TOTAL_TIME MIN_TIME MAX_TIME

26

27

28 599 rows selected. Figure 13: Results with properly placed calls As you can see, we now have full details about DBA_UTILITIES. I removed all of the rows that corresponded to unused sections of code (zero times and executions). The lines with executions map back into the definitions and code for the JUST_STATISTICS procedure. Now, by use of the V$SQLTEXT view and the above data, we should be able to pull the lines that have the most numbers of executions to see if we can reduce the executions or time required by reworking the specific lines where performance is being taxed. For example, in Figure 13 the following lines should be looked at first: RUNID UNIT_NUMBER LINE# TOTAL_OCCUR TOTAL_TIME MIN_TIME MAX_TIME Since the largest problem seems to be with DBA_UTILITIES.JUST_STATISTICS (runid 3, unit_number 3) in line number 920, let's pull that line from the SOURCE$ table and take a quick look at it. Look at Figure 14 to see the results from selecting line 920. SQL> desc source$ Name Null? Type OBJ# NOT NULL NUMBER LINE NOT NULL NUMBER SOURCE VARCHAR2(4000) SQL> desc obj$ Name Null? Type OBJ# NOT NULL NUMBER DATAOBJ# NUMBER OWNER# NOT NULL NUMBER NAME NOT NULL VARCHAR2(30) NAMESPACE NOT NULL NUMBER SUBNAME VARCHAR2(30) TYPE# NOT NULL NUMBER CTIME NOT NULL DATE MTIME NOT NULL DATE STIME NOT NULL DATE STATUS NOT NULL NUMBER REMOTEOWNER VARCHAR2(30) LINKNAME VARCHAR2(128) FLAGS NUMBER OID$ RAW(16) SPARE1 NUMBER SPARE2 NUMBER SPARE3 NUMBER SPARE4 VARCHAR2(1000) SPARE5 VARCHAR2(1000) SPARE6 DATE SQL> select obj#, name, namespace from obj$ 2 where name ='DBA_UTILITIES'; OBJ# NAME NAMESPACE DBA_UTILITIES DBA_UTILITIES 2 (Package Body) SQL> col source format a60 SQL>select source from source$ where obj#=3315 and line=920 / SOURCE

29 SELECT SUM(BYTES)/ INTO stat_val SQL> select line, source from source$ where obj#=3315 and line between 915 and 925 LINE SOURCE INSERT INTO dba_temp VALUES (stat_name,0,25); 916 COMMIT; 917 END; 918 BEGIN 919 stat_name := 'TOTAL USED MEG'; 920 SELECT /* DBA_UTIL.get_bytes */ SUM(BYTES)/ INTO stat_val 921 FROM dba_extents; 922 INSERT INTO dba_temp VALUES (stat_name, stat_val,26); 923 EXCEPTION 924 WHEN NO_DATA_FOUND THEN 925 INSERT INTO dba_temp VALUES (stat_name,0,26); 11 rows selected. Figure 14: Line showing performance problem Notice in Figure 14 that the first select that just pulled back the single line doesn't tell us much. Once we broaden the net a bit we can see why that statement is causing the most time to be used, it is counting the bytes for each and every used extent in the database! This is just a simple example, I hope you can see where this type of data could be useful in your PL/SQL tuning work. One way to make using DBMS_PROFILER easier, is to pre-instrument your code via a procedure that you build into all packages, for an example see Figure 15. PROCEDURE profiler_control( start_stop IN VARCHAR2, run_comm IN VARCHAR2, ret OUT BOOLEAN) AS ret_code INTEGER; BEGIN ret_code:=dbms_profiler.internal_version_check; IF ret_code!=0 THEN ret:=false; ELSIF start_stop NOT IN ('START','STOP') THEN ret:=false; ELSIF start_stop = 'START' THEN ret_code:=dbms_profiler.start_profiler(run_comment1=>run_comm); IF ret_code=0 THEN ret:=true; ELSE ret:=false; END IF; ELSIF start_stop = 'STOP' THEN ret_code:=dbms_profiler.flush_data; ret_code:=dbms_profiler.stop_profiler; IF ret_code=0 THEN ret:=true; ELSE ret:=false; END IF; END IF; END profiler_control; Figure 15: Example Procedure to Control DBMS_PROFILER By placing the appropriate header entry in the package header and defining the global variables RUN_PROFILER and B_RET (both BOOLEAN) you can simple add a couple of lines to the start and end of each package where performance may become an issue as shown in Figure 16. BEGIN IF RUN_PROFILER THEN DBA_UTILITIES.PROFILER_CONTROL('START','JUST_STATISTICS',b_ret); END IF; IF RUN_PROFILER THEN DBA_UTILITIES.PROFILER_CONTROL('STOP','JUST_STATISTICS',b_ret);

30 END IF; END; Figure 16: Example Calls to PROFILER_CONTROL The call to stop the profiler should be placed before any final exception handlers and after any final exception handlers (in case an exception is generated.) Once the above procedure and lines of code are added, you simply switch the package variable RUN_PROFILER to TRUE to turn on the profiler calls and to FALSE to turn them off. An example test run is shown in Figure 17. declare run_profiler boolean; BEGIN dba_utilities.run_profiler:=true; dba_utilities.running_stats(true); END; / Figure 17: Example of how to Use PROFILER_CONTROL. Using Events Events allow us to fine tune how Oracle does certain operations. For example, to fine tune SQL tracing we can use the event to adjust what we gather during our trace session. Setting an Event The term: "Setting an event" means to tell oracle to generate information in form of a trace file in the context of the event specified. The trace file is usually located in directory specified by the initialization parameter USER_DUMP_DEST. By examining the resulting trace file detailed information about the event traced can be deduced. The general format for an event is: EVENT = "<trace class><event name><action><name><trace name><qualifier>" There are 2 types of events, session-events and process-events. Process-events are initialized in the parameter file, sessionevents are initialized with the "ALTER SESSION..." or the "ALTER SYSTEM" command. When checking for posted events, the oracle server first checks for session events then for process-events. Event Classes There are 4 traceable event classes: Class 1 "Dump something": Traces are generated upon unconditioned immediate, events. This is the case when oracle data has to be dumped like, e.g., the headers of all redolog files or the contents of the controlfile. These events can not be set in the init<sid>.ora but must be set using the ALTER SESSION or the undocumented DBMS_SYSYTEM.SET_EV() procedure. Class 2 -- "Trap on Error" : Setting this class of (error-) events cause oracle to generate an errorstack every time the event occurs. Class 3 -- "Change execution path" : Setting such an event will cause oracle to change the execution path for some specific Oracle internal code segment. For example, setting event "10269" prevents SMON from doing free space coalescing. Class 4 -- "Trace something": Events from this class are set to obtain traces that are used for, e.g., SQL tuning. A common event is "10046" which will cause oracle to trace the SQL access path on each SQL-statement.

31 Trace Class Event Name Action Key Word "Name" Trace Name Dump immediate trace "name" blockdump Something redohdr file_hdrs controlf systemstate Trap on error Error number trace "name" Errorstack processstate Heapdump Trace Qualifier level block# level 10 level 10 level 10 level 10 Forever Off Level n Change execution path Trace something Even code corresponding to path trace "name" context Forever or level trace "name" context Forever Level n off Table 1: Event Classifications The Initialization File Event Settings The SET EVENTS command in an init<sid>.ora file have generally been placed there at the command of Oracle support to perform specific functions. If you look at the initialization file for an Oracle applications instance as provided by Oracle you will see several events set as well as several undocumented initialization parameters. Usually, these alerts turn on more advanced levels of tracing and error detection than are commonly available. The syntax to specify multiple events in the init.ora is: EVENT="<event 1>:<event 2>: <event 3>: <event n>" You can also split the events on multiple lines by using the continuation "\" backslash character at the end of each event and continue the next event on the next line. Such As: For Example: EVENT="<event 1>:\ <event 2>:\ <event 3>: \ <event n>" EVENT="\ trace name context forever, level 10:\ trace name context forever, level 10:\ trace name context forever, level 10:\ trace name context forever, level 10" After setting the events in the initialization file, you need to stop and restart the instance. Be sure to check the alert.log and verify if the events are in effect after the database restart. With almost all EVENT settings you can specify them at the session level using the ALTER SESSION command or a call to the DBMS_SYSTEM.SET_EV() procedure, either of which will not require an instance bounce for the EVENT to take effect. The alert.log should show the events that are in effect, for example:

32 event = trace name context forever, level 10:10211 trace name context for ever, level 10:10231 trace name context forever, level 10:10232 trace name context forever, level 10 To enable the maximum level of SQL performance monitoring (this works in concert with the SQL trace utility): event = "10046 trace name context forever, level 12" Events at the Session Level Events are also used as the SESSION level using the ALTER SESSION command or calls to the DBMS_SYSTEM.SET_EV() procedure. The general format for the ALTER SESSION command is: ALTER SESSION SET EVENTS 'ev_number ev_text level x'; Where: Ev_number is the event number Ev_text is any required text (usually "trace name context forever") x is the required level setting corresponding to the desire action, file or other required data. For example, to provide more detailed SQL trace information: ALTER SESSION SET EVENTS '10046 trace name context forever level NN' where NN: 1 -- same as a regular trace 4 -- also dump bind variables 8 -- also dump wait information dump both bind and wait information CBO is definitely not a mystery! Use event to give the detail of the various plans considered depending on the statistics available. However be very careful with this for large multi-table joins as the report can be quite lengthy! The data density, sparse characteristics, index availability, index depth all lead the optimizer to make its decisions and you can see the running commentary in trace files generated by event. Seeing What Events Are Set In a Session To see events set by the alter session command, you can use the undocumented 'dbms_system.read_ev' procedure. For example the check_param.sql script contains: set serveroutput on size declare event_level number; begin for i in loop sys.dbms_system.read_ev(i,event_level); if (event_level > 0) then dbms_output.put_line('event ' to_char(i) ' set at level ' to_char(event_level)); end if; end loop; end; / To demonstrate how the above PL/SQL anonymous PL/SQL block script can be used, use it to create the script check_param.sql. You should note that setting the init<sid>.ora parameter sql_trace sets the event Other parameters such as timed_statistics, optimizer_mode do not set events. Within the session issue:

33 PL/SQL procedure successfully completed. SQL> alter session set sql_trace=true; SQL> alter session set events '10015 trace name context forever, level 12'; Event set at level 12 Event set at level 1 PL/SQL procedure successfully completed. SQL> alter session set events '10046 trace name context forever, level 12'; Event set at level 12 Event set at level 12 PL/SQL procedure successfully completed. SQL> alter session set sql_trace=false; SQL> alter session set events '10015 trace name context off'; PL/SQL procedure successfully completed. Using DBMS_SYSTEM.SET_EV and DBMS_SYSTEM.READ_EV The DBMS_SYSTEM package contains two useful procedures related to events, these are the SET_EV procedure used to set a specific event and READ_EV used to see what the status of an event is currently. The use of the DBMS_SYSTEM.SET_EV Procedure: The procedure is defined as follows: DBMS_SYSTEM.SET_EV( SI Binary_integer, SE Binary_integer, EV Binary_integer, LE Binary_integer, NM Binary_integer); Where: SI -- Oracle SID value SE -- Oracle Serial number EV -- Oracle event to set LE -- Event level NM -- Name For example: EXECUTE SYS.DBMS_SYSTEM.SET_EV(sid,serial#,10046,level,''); The DBMS_SYSTEM.READ_EV Procedure The DBMS_SYSTEM.READ_EV has the following syntax: DBMS_SYSTEM.READ_EV( IEV binary_integer,

34 OEV binary_integer); Where: IEV -- Oracle event (in value) OEV -- Oracle event setting (out value) For example: EXECUTE sys.dbms_system.read_ev(i,event_level); Are they Supported? Used to be that Oracle support would either say to use or not use DBMS_SYSTEM SET_EV and READ_EV depending on the analyst, day of the week and phase of the moon. However, they are documented in many postings on the Metalink forums so I would have to assume they are safe to use in older releases. In new releases (>9i) the DBMS_SYSTEM package is shipped with the other DBMS packages and is documented in the appropriate manuals. Statspack and AWR Statspack was first available in of Oracle. It was a new and improved version of the old utlbstat/utlestat scripts that DABs used to monitor specific processes. Utlbstat and utlestat would create a base set of tables, collect a beginning snap-shot of statistics, then collect an ending snap-shot of statistics, generate a report and delete the tables. Statspack improved on that by leaving the tables in place an allowing you to collect multiple sets of statistics into them. You would then use the provided reports to generate a stastspack report across any two sets of statistics that would give you a delta report on the statistics, details about SQL that was generated and general physical health statistics for the database. You could set the collection interval for statspack using the DBMS_JOB procedure and job queues to collect at whatever interval you needed. In 10g we now have AWR. The Automatic Workload Repository (AWR) defaults to a collection interval every 30 minutes and collects data that is the foundation for all of the other self-tuning features. AWR is very much like STATSPACK, especially the level-5 STATSPACK collection mechanism where top SQL is collected every hour, based on your rolling thresholds for high-use SQL. In addition to the SQL, AWR collects detailed run-time statistics on the top SQL (disk reads, executions, consistent gets) and uses this information to adjust the rolling collection threshold. This technique ensures that AWR always collects the most resource intensive SQL. The AWR system provides reports that can be run against the AWR tables that provide the same type of data a statspack report used to, and, much more. AWR takes advantage of the ADDM (Adam) to gather its statistics using non-sql based collection techniques which is much more efficient than the old SQL based statspack and less intrusive on the database. Automatic Database Diagnostic Monitor I have long been a proponent of the holistic view of database tuning. The Oracle environment is an inter-related set of files, processes and memory areas that all must work together if the database is to function at peak levels. Too many experts push tuning one aspect of the environment in Oracle over the others instead of looking at the true points of pain and correcting them. Now in Oracle Database 10g has Oracle provided the tool to provide this holistic self-management, the Automatic Database Diagnostic Monitor or ADDM. The ADDM process structure is shown in Figure 16.

35 MMON Work Load Repository Server Generated Alerts Access Advisor SQL Tuning Advisor OEM Figure 16: ADDM Process Structure The ADDM allows Oracle to perform self-diagnosis. The Oracle10g instance automatically monitors itself at regular intervals (30 minutes by default) using the MMON background process and then analyzes the results to provide ongoing performance diagnostics. The statistics are stored in the workload repository and are accessed by the access advisor and the SQL tuning advisor as well as being used to generate the server generated alerts. The problems found and the results of analysis are displayed in graphical format within the new OEM (Oracle Enterprise Manager) web interface. The new displays in OEM include line, bar and pie graphs as well as warning flags and textural information (such as problem SQL listings.) The recommendations given by ADDM are based on the years of experience of Oracle's consulting, tuning and Metalink staff. Figure 17 shows some example metrics displayed on the OEM web interface. Figure 17: Example OEM Metrics ADDM also provides manual APIs in PL/SQL (DBMS_ADVISOR) and the capability of spot analysis through OEM. ADDM's analysis is a top down methodology finding the points of pain and expanding the analysis as needed to find the root cause. ADDM also calculates the impact of the issues it finds. This analysis of impacts allows the DBA to concentrate on the issues with the most payback for the time spent.

36 Users of ADDM are finding that the historical capabilities allow diagnosis of problems that happened when they weren't looking, such as during the previous nights batch jobs. This capability was provided in lesser form in statspack in previous releases or only through expensive third-party monitoring tools. ADDM also helps remove proximity myopia - the condition where what you see depends on where you look from. For example, the DBA looks at database statistics and the SA looks at operating system statistics, both see the problems from their viewpoint but don't see the true situation. By looking at overall system metrics and not just database or just system metrics, ADDM provides the holistic view required to get to the root of the problem. Figure 18 shows the wealth of information available from ADDM and OEM. Figure 18: Wealth of Metrics Available from OEM ADDM provides advice on SQL access and tuning thus providing insights into both homegrown and third-party applications. Through ADDM SQL profiles can be generated against third-party applications, forcing the optimizer to use the optimal paths to resolve problem queries. This solves many of the problems with third-party solutions where the code must be held inviolate however ineptly written it is. By allowing the use of outlines, which are customized by the ADDM for optimal performance, the sub-optimal code provided by a vendor can be tuned without modifying the code or waiting for the next release. Figure 19 shows example ADDM output on OEM. Figure 19: Example ADDM Output

37 However, as interesting as the ADDM and OEM outputs are, the developer usually won t e using those at the session level for tuning. The developer may find that the AWR reports provided by Oracle are of some use. These reports are the addmrpt.sql and awrrpt.sql. Note that any use of the ADDM tables or reports is a violation of licensing agreements if you haven t purchased a ADDM license. However the AWR tables are included under the standard and enterprise license at no charge. Contents of a Statspack/AWR Report Both the Statspack and AWR reports contain the same general material. Here is a listing of the headers for the various sections of a statspack report: STATSPACK report for -- Summary of report times and dates Cache Sizes (end) ~~~~~~~~~~~~~~~~~ -- Data on fixed cache sizes Load Profile ~~~~~~~~~~~~ -- Overall load performance numbers Instance Efficiency Percentages (Target 100%) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- Buffer, Library and SQL code effiency numbers Top 5 Timed Events ~~~~~~~~~~~~~~~~~~ -- Provides a look at the top five non-idle events Cluster Statistics for DB: TEST Instance: TEST4 Snaps: (Only present if in RAC configuration) Global Cache Service - Workload Characteristics Global Enqueue Service Statistics GCS and GES Messaging statistics GES Statistics for DB: TEST Instance: TEST4 Snaps: Wait Events for DB: TEST Instance: TEST4 Snaps: Foreground (user generated) wait events (top fve taken from here) Background Wait Events for DB: TEST Instance: TEST4 Snaps: > ordered by wait time desc, waits desc (idle events last) -- Background processes generated wait events Here is where it gets interesting for developers: SQL ordered by Gets for DB: TEST Instance: TEST4 Snaps: > End Buffer Gets Threshold: > Note that resources reported for PL/SQL includes the resources used by all SQL statements called within the PL/SQL code. As individual SQL statements are also reported, it is possible and valid for the summed total % to exceed 100 SQL ordered by Reads for DB: TEST Instance: TEST4 Snaps:

38 -> End Disk Reads Threshold: 1000 SQL ordered by Executions for DB: TEST Instance: TEST4 Snaps: > End Executions Threshold: 100 SQL ordered by Parse Calls for DB: TEST Instance: TEST4 Snaps: > End Parse Calls Threshold: 1000 SQL ordered by Version Count for DB: TEST Instance: TEST4 Snaps: > End Version Count Threshold: 20 Instance Activity Stats for DB: TEST Instance: TEST4 Snaps: Tablespace IO Stats for DB: TEST Instance: TEST4 Snaps: >ordered by IOs (Reads + Writes) desc File IO Stats for DB: TEST Instance: TEST4 Snaps: >ordered by Tablespace, File Buffer Pool Statistics for DB: TEST Instance: TEST4 Snaps: > Standard block size Pools D: default, K: keep, R: recycle -> Default Pools for other block sizes: 2k, 4k, 8k, 16k, 32k Instance Recovery Stats for DB: TEST Instance: TEST4 Snaps: > B: Begin snapshot, E: End snapshot Buffer Pool Advisory for DB: TEST Instance: TEST4 End Snap: > Only rows with estimated physical reads >0 are displayed -> ordered by Block Size, Buffers For Estimate Buffer wait Statistics for DB: TEST Instance: TEST4 Snaps: > ordered by wait time desc, waits desc PGA Aggr Target Stats for DB: TEST Instance: TEST4 Snaps: > B: Begin snap E: End snap (rows dentified with B or E contain data which is absolute i.e. not diffed over the interval) -> PGA cache hit % - percentage of W/A (WorkArea) data processed only inmemory -> Auto PGA Target - actual workarea memory target -> W/A PGA Used - amount of memory used for all Workareas (manual + auto) -> %PGA W/A Mem - percentage of PGA memory allocated to workareas -> %Auto W/A Mem - percentage of workarea memory controlled by Auto Mem Mgmt -> %Man W/A Mem - percentage of workarea memory under manual control PGA Aggr Target Histogram for DB: TEST Instance: TEST4 Snaps: > Optimal Executions are purely in-memory operations PGA Memory Advisory for DB: TEST Instance: TEST4 End Snap: 7885

39 -> When using Auto Memory Mgmt, minimally choose a pga_aggregate_target value where Estd PGA Overalloc Count is 0 Enqueue activity for DB: TEST Instance: TEST4 Snaps: > Enqueue stats gathered prior to 9i should not be compared with 9i data -> ordered by Wait Time desc, Waits desc Rollback Segment Stats for DB: TEST Instance: TEST4 Snaps: >A high value for "Pct Waits" suggests more rollback segments may be required ->RBS stats may not be accurate between begin and end snaps when using Auto Undo managment, as RBS may be dynamically created and dropped as needed Rollback Segment Storage for DB: TEST Instance: TEST4 Snaps: >Optimal Size should be larger than Avg Active Undo Segment Summary for DB: TEST Instance: TEST4 Snaps: > Undo segment block stats: -> us - unexpired Stolen, ur - unexpired Released, uu - unexpired reused -> es - expired Stolen, er - expired Released, eu - expired reused Undo Segment Stats for DB: TEST Instance: TEST4 Snaps: > ordered by Time desc Latch Activity for DB: TEST Instance: TEST4 Snaps: >"Get Requests", "Pct Get Miss" and "Avg Slps/Miss" are statistics for willing-to-wait latch get requests ->"NoWait Requests", "Pct NoWait Miss" are for no-wait latch get requests ->"Pct Misses" for both should be very close to 0.0 Latch Activity for DB: TEST Instance: TEST4 Snaps: >"Get Requests", "Pct Get Miss" and "Avg Slps/Miss" are statistics for willing-to-wait latch get requests ->"NoWait Requests", "Pct NoWait Miss" are for no-wait latch get requests ->"Pct Misses" for both should be very close to 0.0 Latch Sleep breakdown for DB: TEST Instance: TEST4 Snaps: > ordered by misses desc Latch Miss Sources for DB: TEST Instance: TEST4 Snaps: > only latches with sleeps are shown -> ordered by name, sleeps desc Dictionary Cache Stats for DB: TEST Instance: TEST4 Snaps: >"Pct Misses" should be very low (< 2% in most cases) ->"Cache Usage" is the number of cache entries being used ->"Pct SGA" is the ratio of usage to allocated size for that cache

40 Library Cache Activity for DB: TEST Instance: TEST4 Snaps: >"Pct Misses" should be very low Shared Pool Advisory for DB: TEST Instance: TEST4 End Snap: > Note there is often a 1:Many correlation between a single logical object in the Library Cache, and the physical number of memory objects associated with it. Therefore comparing the number of Lib Cache objects (e.g. in v$librarycache), with the number of Lib Cache Memory Objects is invalid SGA Memory Summary for DB: TEST Instance: TEST4 Snaps: SGA breakdown difference for DB: TEST Instance: TEST4 Snaps: Resource Limit Stats for DB: TEST Instance: TEST4 End Snap: > only rows with Current or Maximum Utilization > 80% of Limit are shown -> ordered by resource name init.ora Parameters for DB: TEST Instance: TEST4 Snaps: By having statspack installed (run the spcreate.sql script located in $ORACLE_HOME/rdbms/admin) from the SYS user (make sure you have a PERFSTAT tablespace of at least 500 megabytes available) and running (to run it every hour, execute the spauto.sql script, located in $ORACLE_HOME/rdbms/admin) it during development you can capture real-time statistics for later analysis. The configuration file for statspack can also be modified to have it take additional data relating to the SQL code, thresholds and other data taken by the statspack. Note that AWR data is automatically taken and it is installed with the database, so if you are using 10g you are already collecting this data. Using Enterprise Manager in 10g In Oracle Database 10g, the Enterprise Manager (EM) toolset hase been greatly enhanced to include a SQL tuning advisor. You can submit an entire set of SQL to the tuning advisor as a Workgroup and it will provide tuning suggestions based on the provided SQL. The EM toolset also includes a SQL explain plan generator as shown in Figure20.

41 Figure 20: Explain Plan Feature of 10g EM Once you find a troublesome SQL statement, you can click on the Run SQL Advisor button and the SQL Advisor wizard will guide you through tuning the SQL, as shown in Figure 21.

42 Figure 21: SQL Tuning Advisor Setup Once you fill in the desired data, you click the OK button and the SQL Tuning Advisor creates and submits a tuning job as shown in Figure 22.

43 Figure 22: Example Tuning Job Once the tuning job is complete, the SQL Tuning Advisor will report its findings, as shown in Figure 23.

44 Figure 23: SQL Tuing Advisor Findings Notice the last suggestion from the Advisor? This means it will generate some under-the-cover tricks to make this query run faster. If we click on the eyeglasses icon, we see what is displayed in Figure 24.

45 Figure 24: New STA Execution Plan Figure 24 shows the new execution plan if we accept the SQL profile as suggested. If you decide that this is indeed a better way for your SQL to be optimized, then you go back to the findings screen (a back arrow will usually work) and then click on the Implement button, this will then take you to a scheduling screen for implementation as shown in Figure 25.

46 Figure 25: Task List By clicking on the OK button, the STA will run the task and take you to the summary page, as shown in Figure 26.

47 Figure 26: Results from Tuning Task Completion A raw timing of the statement showed a decrease from 8 seconds of execution to 2 seconds after tuning. Running the statement through the process a second time showed the STA to be very pleased with itself as is shown in Figure 27.

48 Figure 27: STA Being Pleased With Itself As you can see form Figure 27, it says the statement is as tuned as it can get. Of course, this will be optimally tuned for the environment in which the SQL Advisor was run, so as long as your development environment is the same as the production, you should be ok. However, how you get the SQL profile from development to production is not clear. On a second SQL statement taking Oracle suggestions resulted in the statement taking twice as long. So Caveat Emptor! Conclusion This paper has tried to show what Oracle provided tuning tools are available to the developer who needs to tune their code to perform optimally. We have discussed Explain Plan, tracing and tkprof, use of events and use of statspack and AWR to assist with the tuning of SQL and PL/SQL. It is hoped that developers will utilize some of these tools and techniques for tuning code to help provide better code for their applications.