Identifying PL/SQL Performance Problems
Identifying PL/SQL Performance Problems
As you develop larger and larger PL/SQL applications, it becomes more difficult to isolate performance problems. So, PL/SQL provides a Profiler API to profile run-time behavior and to help you identify performance bottlenecks. PL/SQL also provides a Trace API for tracing the execution of programs on the server. You can use Trace to trace the execution by subprogram or exception.
The Profiler API: Package DBMS_PROFILER
The Profiler API is implemented as PL/SQL package
DBMS_PROFILER
, which provides services for gathering and saving run-time statistics. The information is stored in database tables, which you can query later. For example, you can learn how much time was spent executing each PL/SQL line and subprogram.
To use the Profiler, you start the profiling session, run your application long enough to get adequate code coverage, flush the collected data to the database, then stop the profiling session. In a typical session, you take the following steps:
1.
2.
Start by calling the procedure start_profiler
in package
DBMS_PROFILER and associating a comment with the Profiler session.
Run the application to be profiled.
3.
4.
Call the procedure flush_data
repeatedly to save incremental data and free memory allocated for data structures.
Stop by calling the procedure stop_profiler
.
The Profiler traces the execution of your program, computing the time spent at each line and in each subprogram. You can use the collected data to improve performance. For instance, you might focus on subprograms that run slowly.
For more information about package
DBMS_PROFILER
, see
Oracle9i Supplied PL/SQL
Packages and Types Reference
.
Analyzing the Collected Performance Data
The next step is to determine why more time was spent executing certain code segments or accessing certain data structures. Find the problem areas by querying the performance data. Focus on the subprograms and packages that use up the most execution time, inspecting possible performance bottlenecks such as SQL statements, loops, and recursive functions.
12-8
PL/SQL User’s Guide and Reference
Identifying PL/SQL Performance Problems
Using Trace Data to Improve Performance
Use the results of your analysis to rework slow algorithms. For example, due to an exponential growth in data, you might need to replace a linear search with a binary search. Also, look for inefficiencies caused by inappropriate data structures, and, if necessary, replace those data structures.
The Trace API: Package DBMS_TRACE
With large, complex applications, it becomes difficult to keep track of calls between subprograms. By tracing your code with the Trace API, you can see the order in which subprograms execute. The Trace API is implemented as PL/SQL package
DBMS_TRACE
, which provides services for tracing execution by subprogram or exception.
To use Trace, you start the tracing session, run your application, then stop the tracing session. As the program executes, trace data is collected and stored in database tables. In a typical session, you take the following steps:
1.
2.
Optionally, select specific subprograms for trace data collection.
Start by calling the procedure set_plsql_trace
in package
DBMS_TRACE
.
3.
4.
Run the application to be traced.
Stop by calling the procedure clear_plsql_trace
.
For more information about package
DBMS_TRACE
, see
Oracle9i Supplied PL/SQL
Packages and Types Reference
.
Controlling the Trace
Tracing large applications can produce huge amounts of data that are difficult to manage. Before starting Trace, you can optionally limit the volume of data collected by selecting specific subprograms for trace data collection.
In addition, you can choose a tracing level. For example, you can choose to trace all subprograms and exceptions, or you can choose to trace selected subprograms and exceptions.
Tuning PL/SQL Applications
12-9
