dbms_profiler
dbms_profilerClick here for the paper I presented at IOUG in 2006 on Trace Analyzer.
PL/SQL developers are always trying to optimize their code to perform more efficiently. As of Oracle 8.1.5, a utility exists that assists developers with this process, dbms_profiler, one of the most under-utilized utilities within Oracle.
The basic idea behind profiling is for the developer to understand where their code is spending the most time, so they can detect and optimize it. The profiling utility allows Oracle to collect data in memory structures and then dumps it into tables as application code is executed. dbms_profiler is to PL/SQL, what tkprof and Explain Plan are to SQL.
Installation
The profiling tools are not a part of the base installation of Oracle, so that will require more on the part of the developer. Two tables need to be installed along with the Oracle supplied PL/SQL package.
In the $ORACLE_HOME/rdbms/admin directory, two files exist that create the environment needed for the profiler to execute.
· proftab.sql - Creates three tables and a sequence and must be executed before the profload.sql file.
· profload.sql - Creates the package header and package body for DBMS_PROFILER. This script must be executed as the SYS user.
Once the environment is established, the three tables created by proftab.sql contain the vital information needed to benchmark PL/SQL performance. Queries against these tables will provide the insight needed to optimize the PL/SQL code.
The plsql_profiler_runs table contains information related to a profiling session. Things, such as when the run was started, who started it, and how long the run lasted are contained in this table. This table has the following important columns:
· runid- This is the unique run identifier given to each profiler execution.
· related_run - Runid of related run that can be called by the programmer.
· run_owner - User who started the run.
· run_date - Timestamp of the date of the run.
· run_comment– User provided text concerning anything about this run that they wish to specify. This is used mainly for documentation, since run_id is hard to remember.
· run_total_time – Total elapsed time for this run.
The plsql_profiler_units table defines each PL/SQL component (unit) that was executed during a profiler run. Benchmarks for each of the units are stored in this table in the following columns:
· runid- References plsql_profiler_runs(runid).
· unit_number - Internally generated library unit number.
· unit_type - Library unit type (PACKAGE, PROCEDURE, etc).
· unit_owner - Library unit owner name (the owner of the object).
· unit_name - Library unit name (the name of the object as defined in the user_objects view).
· unit_timestamp – Time when the unit was created. The “unit”, being the procedural object (procedure, function, package). This column holds the same data as the created column in the user_objects view.
· total_time – Total time used by this unit for the given run.
The primary key for this table is runid, unit_number.
The plsql_profiler_data table is where the real performance benchmarks are stored. This table contains the execution statistics for each line of code contained in our PL/SQL unit. This table can be joined to the user_source view and can extract the actual line of code for each benchmark. The primary key includes runid, unit_number, and line#.
The plsql_profiler_data table has the following important columns as indicated by the results of the following query:
select runid, unit_number, line#, total_occur, total_time,
min_time, max_time
from plsql_profiler_data;
RUNID UNIT_NUMBER LINE# TOTAL_OCCUR TOTAL_TIME MIN_TIME MAX_TIME
---------- ----------- ---------- ----------- ---------- ---------- ----------
1 1 8 3 33284677 539733 28918759
1 1 80 2 1134222 516266 617955
1 1 89 0 0 0 0
1 1 90 0 0 0 0
1 1 92 0 0 0 0
1 1 95 0 0 0 0
1 1 103 0 0 0 0
1 1 111 0 0 0 0
1 1 112 0 0 0 0
1 1 116 1 1441523 1441523 1441523
1 1 119 0 0 0 0
1 1 121 1 1431466 1431466 1431466
1 1 123 1 136330 136330 136330
1 1 132 1 978895 978895 978895
1 1 140 0 0 0 0
1 1 141 0 0 0 0
1 1 143 0 0 0 0
1 1 146 1 2905397 2905397 2905397
1 1 152 2 1622552 574374 1048177
1 1 153 0 0 0 0
1 1 157 1 204495 204495 204495
1 1 160 0 0 0 0
The line# above is used to tie these execution benchmarks back to a line of source in the user_source view.
The profload.sql file contains calls to two other files:
· dbmspbp.sql – This file creates the actual sys.dbms_profiler package. This must be created as the SYS user which is the main drawback of this utility.
· prvtpbp.plb – This file creates the sys.dbms_profiler_lib library object and it is wrapped. Again, this must be executed as the SYS user.
Figure 8.1 depicts the relationships between the three profiler tables, as well as the indirect relationship to the dba_source or user_source view (Source). Note that everything begins with a RUN and drills down to the real performance data for a particular PL/SQL line of code.
http://dl.iteye.com/upload/attachment/615819/dd95e82d-20bc-3bc2-920a-d254441ddf67.jpg
Figure 8.1 – Relationships between dbms_profiler tables
The environment is now configured, and the profiling utility is ready to be put to work.
Starting a Profiling Session
The profiler does not begin capturing performance information until the call to start_profiler is executed.
SQL> exec dbms_profiler.start_profiler('Test of raise procedure by Scott');
PL/SQL procedure successfully completed.
The profiler captures data on a session-by-session basis. This means that if the user SCOTT started the profiler by executing the command above, only PL/SQL objects that were executed and owned by SCOTT will be profiled, and consequently have data in the profiler tables described earlier. The SCOTT user is only used as an example; it could be any database user.
Flushing Data during a Profiling Session
The flush command enables the developer to dump statistics during program execution without stopping the profiling utility. The only other time Oracle saves data to the underlying tables is when the profiling session is stopped, as shown below:
SQL> exec dbms_profiler.flush_data();
PL/SQL procedure successfully completed.
A developer could use the flush procedure with dbms_debug and step, line by line, through a procedure, flushing performance benchmarks along the way. Or, if you have a very long running PL/SQL program, flushing data can be very useful in the performance tuning process.
Stopping a Profiling Session
Stopping a profiler execution is done after an adequate period of time of gathering performance benchmarks – determined by the developer. Once the developer stops the profiler, all the remaining (unflushed) data is loaded into the profiler tables.
SQL> exec dbms_profiler.stop_profiler();
PL/SQL procedure successfully completed.
The dbms_profiler package also provides procedures that suspend and resume profiling (pause_profiler(), resume_profiler()).
Now that the profiler has stopped, the data is available for diagnostics from within Oracle, and we can begin working with it.
Working with Captured Profiler Data
The profiler utility populates three tables with information, plsql_profiler_runs, plsql_profiler_units, and plsql_profiler_data. Each “run” is initiated by a user and contains zero or more “units”. Each unit contains “data” about its execution – the guts of the performance data benchmarks.
The performance information for a line in a unit needs to be tied back to the line source in user_source. Once that join is made, the developer will have all of the information that they need to optimize, enhance, and tune their application code, as well as the SQL.
Useful Scripts
To extract high-level data, including the length of a particular run, the script (profiler_runs.sql) below can be executed:
<div style="padding-bottom: 1pt; padding-left: 4pt; padding-right: 4pt; padding-top: 1pt;">< profiler_runs.sql
页:
[1]