dbms profiler for pl/sql

7/24/2019 Dbms Profiler for PL/SQL

1/6

Tuning PL/SQL with DBMS_PROFILER 1/6 August 2000

Tuning PL/SQL with DBMS_PROFILER

Christian Antognini

Trivadis AG

Zrich, Switzerland

Introduction

Oracle8i provides an integrated profiling and coverage tool (referred to in thisdocument as profiler) that can be used to find performance bottlenecks in PL/SQL codeand help quality assurance tests. For example it can show how many times each linewas executed and the time required to execute it. For quality assurance tests, it can beused to see if all lines of a stored object have been executed.

The goal of this article is to show how to install the profiler and to give some basicinformation about its use.

For a complete description refer to Oracle8i Supplied PL/SQL Packages Referencemanual.

DistributionThe following files, stored in $ORACLE_HOME/ r dbms/ admi n, are needed to installthe profiler:

pr of l oad. sql installs the profiler server side package (the scripts executesdbmspbp. sql and pr vtpbp. sql ) and check theinstallation, if isnt successful the package is de-installed

pr of t ab. sql creates the tables where the profiling data are stored

dbmspbp. sql installs the DBMS_PROFILER package specification

Pr vt pbp. pl binstalls the DBMS_PROFILER package body

The scripts are missing on some UNIX 8.1.5 distributions. You can copy the files froman NT distribution (you have to remove the ^M characters and some blank lines) or askOracle Support.

Installation

The script pr of l oad. sql must be started as SYS.

The script pr of t ab. sql must be started by each user that want to use the profiler.


2/6


Upgrade

If you upgrade your database from 8.1.5 to 8.1.6, you have to manually re-install thepackage and re-create the tables, as both components have changed.

Tuning/Proof SessionA typical tuning/proof session is an iterative process. Each iteration is composed fromthe following steps:

1. start data collection

2. execute the PL/SQL code

3. stop data collection

4. analyze the collected data

5. detect and solve the problem or check the code coverage

How to execute these steps depends on which tool is used. The only condition is that

steps from 1 to 3 have to be executed in the same session.To analyse the data stored in the profiler tables you have 3 possibilities:

1. write your own report

2. use the sample report pr of r ep. sql and pr of sum. sql provided by Oracle(both are stored in $ORACLE_HOME/ pl sql / demo)

3. use a third party tool

Example

To see in practice how to use the profiler lets look at a couple of examples.

The first one shows how to use it with SQL*Plus, the second one with SQL Navigatorfrom Quest Software.

As example a typical recursive function is used. The code is the following:

FUNCTI ON f act or i al ( p_n I N NUMBER ) RETURN NUMBER I SBEGI N

I F p_n I S NULL OR p_n < 0THEN

RAI SE I NVALI D_NUMBER;ELSI F p_n


3/6


SQL*Plus

To profile the function in SQL*Plus the following statements have to be executed:

r emr em St ar t dat a col l ecti onr emSELECT decode( dbms_prof i l er . st ar t _prof i l er , 0, OK , ERROR ) st at usFROM dual ;

r emr em execut e t he PL/ SQL coder emSELECT f act or i al ( 20) FROM dual ;

r emr em St op dat a col l ecti onr em

SELECT decode( dbms_prof i l er . st op_prof i l er , 0, OK , ERROR ) st at usFROM dual ;

SELECT pl sql _prof i l er _r unnumber . cur r val r uni d FROM dual ;

The return values must be checked, in fact no ORA-????? error is generated.

The following codes can be returned:

0 successful

1 incorrect parameter

2 data flush operation failed-1 version mismatch between package and tables

When the function STOP_PROFILER is called, the data is stored in the profiler tables(they are not discussed in this article) and a RUNID (tuning session identifier) isassigned to it.

With the RUNID, retrieved with the last statement, its possible to select the data fromthe profiler tables with the following script:


4/6


set scan onset ver i f y of fset f eedback of fset pagesi ze 50000set l i nesi ze 120col l i ne f ormat 999999 headi ng LI NE#col t ot al _occur f ormat 999, 999 headi ng EXEC#col t otal _t i me f ormat 999, 990. 999 headi ng ' TI ME[ ms] 'col t ext f ormat a80col cover age f ormat 90. 9 headi ng ' COVERAGE%'

r emr em st at ement t o f i nd bot t l enecksr emsel ect s . l i ne, p. t ot al _occur, p. t ot al _t i me, s . t extf rom al l _source s , (

sel ect u. uni t _owner , u. uni t _name, u. uni t _t ype, d. l i ne#,d. t ot al _occur , d. t ot al _t i me/ 1000000 tot al _t i me

f rompl sql _prof i l er_dat a d, pl sql _prof i l er_uni t s u

where u. r uni d = &&r uni dand u. r uni d = d. r uni dand u. uni t _number = d. uni t _number ) p

wher e s. owner = p. uni t _owner ( +)and s. name = p. uni t _name (+)and s. t ype = p. uni t _t ype (+)and s. l i ne = p. l i ne# ( +)and s. name = upper ( ' &&name' )and s. owner = upper ( ' &&owner ' )or der by s. l i ne;

r emr emst atement t o show coverage i n %r emsel ect exec. nbr / t ot al . nbr *100 cover age

f r om ( sel ect count ( *) nbrf rompl sql _prof i l er_dat a d, pl sql _prof i l er_uni t s uwhere d. r uni d = &&r uni dand u. r uni d = d. r uni dand u. uni t _number = d. uni t _numberand u. uni t _name = upper( ' &&name' )and u. uni t _owner = upper( ' &&owner' ) ) t otal ,

( sel ect count ( *) nbrf rompl sql _prof i l er_dat a d, pl sql _prof i l er_uni t s uwhere d. r uni d = &&r uni dand u. r uni d = d. r uni dand u. uni t _number = d. uni t _numberand u. uni t _name = upper( ' &&name' )and u. uni t _owner = upper ( ' &&owner ' )and d. t otal _occur > 0) exec;

undef r uni dundef ownerundef name


5/6


The output reports the number of execution and the time spent on each line.

LI NE# EXEC# TI ME[ ms] TEXT- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

1 FUNCTI ON f act or i al ( p_n I N NUMBER ) RETURN NUMBER I S

2 BEGI N3 20 6. 066 I F p_n I S NULL OR p_n < 04 THEN5 0 0. 000 RAI SE I NVALI D_NUMBER;6 20 3. 550 ELSI F p_n


6/6


Remarks

Sometimes the elapsed time stored in the profiler tables contains wrong (or at least verystrange) values. It seams that Oracle has some problems collecting the elapsed time.Therefore I suggest you only use these values to find where the code takes more timecompared with the other lines.

If the profiler must be started/stopped automatically while the users are testing andwithout changing the application, you can create a logon and logoff trigger like this:

CREATE OR REPLACE TRI GGER on_l ogon_t r g AFTER LOGON ON DATABASEDECLARE

l _er r NUMBER;BEGI N

l _er r : = DBMS_PROFI LER. START_PROFI LER;END;/

CREATE OR REPLACE TRI GGER on_l ogof f _t r g BEFORE LOGOFF ON DATABASEDECLARE

l _er r NUMBER;BEGI N

l _er r : = DBMS_PROFI LER. STOP_PROFI LER;END;/

Conclusion

PL/SQL developers have waited for long time such a utility. Although the

implementation is not perfect, it seems that Oracle recognizes that they must providethe developers a better programming environment. Unfortunately it has taken a longtime

dbms profiler for pl/sql

Documents