Unleashing DBMS

8/12/2019 Unleashing DBMS

1/12

Unleashing DBMS_PROFILER

BySteve Callan

Anyone whos been involved with Oracle over the past decade has seen a hugeimprovement in the ability to capture performance data. We can explain, trace, debug,

advise, and profile. Most of the attention still seems to be on SQL, and probably rightly sobecause that is the end purpose of a database, right? Select, insert, update and delete data

is what its all about. However, what frequently goes hand in hand with SQL is (no surprisehere) PL/SQL.

Quite often, performance tuning examples dwell on whats taking place with SQLstatements, and along with that, reporting on wait events. The examples show the use of

explain plans, TKPROFd trace files, and at a higher level, AWR or STATSPACK reports. Butwhats going on with the PL/SQL? Thats where DBMS_PROFILER comes into play. Otherutilities such as DBMS_DEBUG are related to profiling, and some tools, such as Forms

Builder, enable developers to debug or step through code a line at a time.

All those little things you do inside a block of code instring this, substring that,concatenate strings, over and over if inside a loop how much time is being spent on that?By using DBMS_PROFILER, you can see where all of the time goes, and not just all of theSQL time. Further, not only can you see the results by querying from a table (or tables), but

you can generate an HTML-based report with the results neatly arrayed just like within anAWR report. So, what does it take to use DBMS_PROFILER?

Oracles documentation mentions this built-in in two places: the PL/SQL Users Guide andReference guide and the PL/SQL Packages and Types Reference guide. The overview in the10gpackages and types reference guide states:

This package enables the collection of profiler (perfoprmance) [sic] data for performance

improvement or for determining code coverage for PL/SQL applications. Applicationdevelopers can use code coverage data to focus their incremental testing efforts.

With this interface, you can generate profiling information for all named library units thatare executed in a session. The profiler gathers information at the PL/SQL virtual machinelevel. This information includes the total number of times each line has been executed, the

total amount of time that has been spent executing that line, and the minimum andmaximum times that have been spent on a particular execution of that line.

Not only do we get performance, we get perfoprmance. Maybe thats undocumentedperformance? Anyway, the steps include installing the package (if not already done),creating three tables via a provided script, invoking the packages subprograms (e.g., start,stop and flush), and viewing the results.

If performing SQL> desc dbms_profiler as SYS or SYSTEM doesnt return any output, theninstall the package by running the profload.sql script as SYS in

$ORACLE_HOME/rdbms/admin. To create the tables, run the proftab.sql script (same place,

BUT as the user performing the profiling, NOT as SYS). This script creates three tables andone sequence, and is re-runnable (it attempts to drop the objects before creating them).The three tables are PLSQL_PROFILER_RUNS, PLSQL_PROFILER_UNITS, and
http://www.databasejournal.com/feedback.php/http:/www.databasejournal.com/features/oracle/article.php/3772501/Unleashing-DBMSPROFILER.htmhttp://www.databasejournal.com/feedback.php/http:/www.databasejournal.com/features/oracle/article.php/3772501/Unleashing-DBMSPROFILER.htmhttp://www.databasejournal.com/feedback.php/http:/www.databasejournal.com/features/oracle/article.php/3772501/Unleashing-DBMSPROFILER.htmhttp://www.databasejournal.com/feedback.php/http:/www.databasejournal.com/features/oracle/article.php/3772501/Unleashing-DBMSPROFILER.htm


2/12

PLSQL_PROFILER_DATA. The subprograms are shown below. Ref: Chapter 73 of OracleDatabase PL/SQL Packages and Types Reference 10gRelease 2 (10.2)

Subprogram Description

FLUSH_DATA Flushes profiler data collected in the users

session

GET_VERSION Gets the version of the API

INTERNAL_VERSION_CHECKVerifies this version works in the database

PAUSE_PROFILER Pauses profiler data collection

RESUME_PROFILER Resumes profiler data collection

START_PROFILER Starts data collection in the users session

STOP_PROFILER Stops data collection in the users session

Now that the framework is in place, were ready to give it a spin. Lets use a BULK version

row-by-row block of code for testing, and this comes from Example 11-3 in the 10gPL/SQLusers guide. Instead of 500 (too small of a value, may get 0 seconds returned for the bulk

step), well use 500,000 iterations. On a warmed-up system, the times are around 25

seconds versus 4 seconds.

CREATE TABLE parts1 (pnum INTEGER, pname VARCHAR2(15));CREATE TABLE parts2 (pnum INTEGER, pname VARCHAR2(15));DECLARE

TYPE NumTab IS TABLE OF parts1.pnum%TYPE INDEX BY PLS_INTEGER;

TYPE NameTab IS TABLE OF parts1.pname%TYPE INDEX BY PLS_INTEGER;pnums NumTab;

pnames NameTab;

--Not big enough: iterations CONSTANT PLS_INTEGER := 500;iterations CONSTANT PLS_INTEGER := 500000;t1 INTEGER;

t2 INTEGER;t3 INTEGER;BEGIN

FOR j IN 1..iterations LOOP -- load index-by tables

pnums(j) := j;pnames(j) := 'Part No. ' || TO_CHAR(j);

END LOOP;

t1 := DBMS_UTILITY.get_time;FOR i IN 1..iterations LOOP -- use FOR loop

INSERT INTO parts1 VALUES (pnums(i), pnames(i));

END LOOP;

t2 := DBMS_UTILITY.get_time;FORALL i IN 1..iterations -- use FORALL statement

INSERT INTO parts2 VALUES (pnums(i), pnames(i));t3 := DBMS_UTILITY.get_time;DBMS_OUTPUT.PUT_LINE('Execution Time (secs)');DBMS_OUTPUT.PUT_LINE('---------------------');

DBMS_OUTPUT.PUT_LINE('FOR loop: ' || TO_CHAR((t2 - t1)/100));

DBMS_OUTPUT.PUT_LINE('FORALL: ' || TO_CHAR((t3 - t2)/100));COMMIT;

END;

/


3/12

The other modification that needs to be made is the addition of the start and stop calls for

DBMS_PROFILER. Add in DBMS_PROFILER.START_PROFILER(sysdate, where); and

DBMS_PROFILER.STOP_PROFILER statements where appropriate and repeat the run(create the tables once, then add delete or truncate statements at the beginning). In theexample below (only the BEGIN section is shown, DECLARE stays the same except for

adding two run variables), I added three captures: time to load the tables, and times for

each of the inserts.

run_comment VARCHAR2(30) := to_char(sysdate);run_comment1 VARCHAR2(30);

BEGIN

DBMS_PROFILER.START_PROFILER

(run_comment,'Load tables');FOR j IN 1..iterations LOOP -- load index-by tables

pnums(j) := j;pnames(j) := 'Part No. ' || TO_CHAR(j);

END LOOP;

DBMS_PROFILER.STOP_PROFILER;

t1 := DBMS_UTILITY.get_time;DBMS_PROFILER.START_PROFILER(run_comment,'For Loop');FOR i IN 1..iterations LOOP -- use FOR loop

INSERT INTO parts1 VALUES (pnums(i), pnames(i));END LOOP;


t2 := DBMS_UTILITY.get_time;DBMS_PROFILER.START_PROFILER(run_comment,'Forall');

FORALL i IN 1..iterations -- use FORALL statementINSERT INTO parts2 VALUES (pnums(i), pnames(i));

DBMS_PROFILER.STOP_PROFILER;t3 := DBMS_UTILITY.get_time;

DBMS_OUTPUT.PUT_LINE('Execution Time (secs)');

DBMS_OUTPUT.PUT_LINE('---------------------');DBMS_OUTPUT.PUT_LINE('FOR loop: ' || TO_CHAR((t2 - t1)/100));DBMS_OUTPUT.PUT_LINE('FORALL: ' || TO_CHAR((t3 - t2)/100));

COMMIT;END;

/

What are the results? We could query the tables directly, but thats not very interesting.Using Toad, the data appears as so:

PLSQL_PROFILER_RUNS


4/12

PLSQL_PROFILER_UNITS

PLSQL_PROFILER_DATA (ordered by RUNID ascending)

Kind of dull in a way. But there is a way to have the format shown in HTML. MetaLink note

243755.1, Implementing and Using the PL/SQL Profiler, contains a downloadable ZIP file,with a SQL script to take a run and generate HTML output. You can run profiler.sql as is andenter a run ID, or pass the ID in as a parameter.

SQL> @profilerRUNID RUN_DATE RUN_COMMENT

---------- ------------------ -----------2 17-SEP-08 17:36:28 17-SEP-08

3 17-SEP-08 17:36:29 17-SEP-08

4 17-SEP-08 17:36:59 17-SEP-08

Usage:sqlplus apps/

SQL> START profiler.sql

Enter value for 1:

The script generates a file named profiler_X.html, with X being the selected run ID. Thecontents of run ID 3 (using the for loop) appear as so:


5/12

Looks better, but what happened statement by statement? For that, we need to add in oneitem, and that is compile with debug. Ill turn the anonymous block into a procedure and

capture the start and stop overall for the looping process (dont care about the inserts asthat is overhead for both parts).

CREATE or REPLACE PROCEDURE profiler_demoAS

TYPE NumTab IS TABLE OF parts1.pnum%TYPE INDEX BY PLS_INTEGER;TYPE NameTab IS TABLE OF parts1.pname%TYPE INDEX BY PLS_INTEGER;

pnums NumTab;pnames NameTab;

iterations CONSTANT PLS_INTEGER := 500000;

t1 INTEGER;t2 INTEGER;t3 INTEGER;

run_comment VARCHAR2(30) := to_char(sysdate);

run_comment1 VARCHAR2(30);BEGIN

execute immediate 'truncate table parts1 reuse storage';execute immediate 'truncate table parts2 reuse storage';

FOR j IN 1..iterations LOOP -- load index-by tablespnums(j) := j;pnames(j) := 'Part No. ' || TO_CHAR(j);

END LOOP;t1 := DBMS_UTILITY.get_time;

DBMS_PROFILER.START_PROFILER(run_comment,'Start of Loops');FOR i IN 1..iterations LOOP -- use FOR loop

INSERT INTO parts1 VALUES (pnums(i), pnames(i));

END LOOP;


6/12

t2 := DBMS_UTILITY.get_time;

FORALL i IN 1..iterations -- use FORALL statementINSERT INTO parts2 VALUES (pnums(i), pnames(i));


t3 := DBMS_UTILITY.get_time;DBMS_OUTPUT.PUT_LINE('Execution Time (secs)');

DBMS_OUTPUT.PUT_LINE('---------------------');DBMS_OUTPUT.PUT_LINE('FOR loop: ' || TO_CHAR((t2 - t1)/100));

DBMS_OUTPUT.PUT_LINE('FORALL: ' || TO_CHAR((t3 - t2)/100));COMMIT;

END;

/

Compile the procedure with DEBUG (alter procedure profiler_demo compile_debug) and

then run profiler again. The output will be exactly what were looking for in terms of line byline detail and timings. You have to admit this is MUCH better than pouring through a

formatted trace file to see where all of the time went.

Oracle Performance Tuning Tools

Within Oracle, performance tuning (sometimes referred to as performance andtuning) is by

far one of the hardest subject areas to master. There are no shortcuts to being good attuning an Oracle database, but there certainly are a lot of tools and advice covering thespecifics of how, what, when and where. Why you should tune should be fairly obvious.

For many DBAs, an attempt to tune a database probably boils down to a comfort level, or a

lack thereof. Many people have no compunction about digging into code and making

changes to production code on the fly, and many of those same people also know that

investigating Oracle internals is also necessary, but lack the confidence or knowledge to gothat extra step. As an analogy, operating a database is akin to owning/operating a car. You

can clean up and detail the exterior and passenger compartment to the nth degree, but ifthe engine doesnt work, or works poorly, then the flashy car isnt going anywhere soon orfast.

Armed with some fundamentals of car/database mechanics, you can diagnose and fix many

problems. Your alternatives are to live with the problem or pay a lot of money tospecialists/consultants. If all you needed to do was clean a battery post to make the engine

start more reliably, and after seeing how simple it was to perform that routine maintenance,wouldnt you feel bad about spending the money and time to get that done? If all you

needed to do was add an index to prevent a full table scan and reduce an hours-long

running query down to a few minutes, wouldnt you feel bad about literally giving money toa well-dressed (at your expense) high-priced consultant?

Performance tuning boils down to four components: recognizing that there is a problem,

knowing which tools are at your disposal, and knowing what to look for, and then fixing theproblem. Recognizing the problem comes about from a reactive or proactive perspective.

The tools are many, but which one is the right one to use? Were not going to knoweverything regarding what to look for, but how about being able to find the most common


7/12

problems? Fixing the problem then becomes a matter of trying, and in many cases, applyingsome tried and true measures.

Identifying Tools

Gavin PowellsOracle Performance Tuning for 10gR2 does an excellent job in identifying

tools and what to look for. The tools include the following:

Explain plan

SQL trace with TKPROF

TRCSESS

Autotrace in SQL*Plus

Performance views

Explain Plan

No doubt youve seen many references to an explain plan, but what should you be looking

for in a plan? Mastering the essentials or basics of what an explain provides goes a longways towards identifying and solving problems. Powell lays out a list of red flags related toindexes and joins.

Full table scans and poor use of indexing, or lack of use of indexing

Inappropriate use of indexing where full table scans can sometimes be faster

Overindexing on individual tables or too many indexes in a database in general

Large selections from large tables sometimes caused by filtering too late

Unnecessary sorting

Joins

Sort-merge where nested loops or hash joins can be used

Cartesian joins, some outer joins, and anti-joins

Highly complex mutable (multiple-table) joins

Noncorrelated subquery semi-joins

Using views, especially multiple layers of views calling subviews

Inherently poorly performing steps like UNION and concatenation operations

Many of the red flags are easy to understand, but some are probably obscure to manyDBAs. What is an anti-join? Can you provide a definition of what a noncorrelated subquerysemi-join is? Its okay if you cant answer these questions; after all, were not experts (yet),right? But at least were becoming familiar with the terminology.Powells book (chapter 12)

provides the reader with the information necessary to use and implement a plan table (and

with plenty of examples throughout the book).

Powell states that the explain plan (the resulting query plan it generates) can be used forverification and fine tuning, and that it is important to note that query plans do not tell youeverything. If more information is needed, then a tracing tool should be used.


8/12

Other tools

Before diving into more complex tools, determine what your tracing needs consist of. Powell

categorizes tracing into six groups (with key parameter settings included):

No tracing

timed_statistics = TRUE

timed_os_statistics = 0sql_trace = false

Some tracing


timed_os_statistics = 5sql_trace = false

max_dump_file_size = 1Mstatistics_level = BASIC or TYPICAL

SQL tracing

timed_statistics = TRUEtimed_os_statistics = 5

sql_trace = TRUE

max_dump_file_size = 1Mstatistics_level = TYPICAL

Too much tracing


timed_os_statistics = 5sql_trace = TRUE

max_dump_file_size = 1Mstatistics_level = ALL

Oracle Support Tracing

trace_enabled = FALSE

Session-Level Tracing

Steps covered elsewhere, including Oracle documentation

Depending on your version of Oracle, you may have to enter 1M as 1024000 (i.e., use aninteger value).

Do you have a system where disk space is constantly being consumed by trace files? Is

trace_enabled enabled? Is this (below) an example of what youre seeing for number andsizes of trace files? This example is from one node of a three node RAC cluster. Note howmany GB of disk space was consumed within the last hour.


9/12

Check the setting and disable it.

NAME TYPE VALUE

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

log_archive_trace integer 0sql_trace boolean FALSE

trace_enabled boolean TRUE

tracefile_identifier stringSQL > alter system set trace_enabled=false;System altered.

Powell lays out very clear examples of how to enable and use SQL Trace, with one of the

steps being how to identify your trace file of interest. Going one step further, TKPROF is

introduced as a means of formatting a trace file and making it more human readable. A 10g

tool namedtrcsesscan be used to combine multiple trace files into one. And as manyusers know, Autotrace within SQL*Plus is a handy way to get execution plan statistics.

Performance views

Oracle provides many views into its internal workings, and performance views are just one

of those mandatory items or subjects you need to be familiar with. Armed with some indepth knowledge of just a few views, you can expose quite a bit of information about whats

going on (or not). Four views (v$sqlarea, v$sql, v$sqltext, and v$sql_plan) can help youdetermine problems related to these potential problem areas:
http://download-west.oracle.com/docs/cd/B19306_01/server.102/b14211/sqltrace.htm#i20110http://download-west.oracle.com/docs/cd/B19306_01/server.102/b14211/sqltrace.htm#i20110http://download-west.oracle.com/docs/cd/B19306_01/server.102/b14211/sqltrace.htm#i20110http://download-west.oracle.com/docs/cd/B19306_01/server.102/b14211/sqltrace.htm#i20110


10/12

Executions

Disk + Buffer Reads per Row

Rows per Sort

Rows per Fetch

Parses per Execution

Disk versus Logical Reads

Optimizer Cost CPU Time Elapsed Time

Powell provides examples of these factors to help identify bad (in terms of performance)SQL code.

In Closing

This article serves as an introduction to a very good book on performance tuning. In the

next article, well take a look at more examples within the book and go into more detail ofwhat to look for and how to solve performance problems. Later on, well look at a book from

Rampants Oracle In-Focus Series, Oracle Tuning, The Definitive Reference.

Buy this book
http://books.internet.com/books/1555583458http://books.internet.com/books/1555583458http://books.internet.com/books/1555583458


11/12

In Closing

The DBMS_PROFILER package has been around since at least Oracle8idays. For some

reason, it seems to get short shrift in many of the tuning books and online discussionforums. After seeing how easy it is to implement, perhaps youll add this built-in to your


12/12

tuning arsenal. Other variations of using this include joining the profiler tables toUSER_SOURCE or ALL_SOURCE yourself (which is what takes place in the profiler script;

use that as a starting point if so desired), drilling down to the worst or most time consuminglines, and using three scripts contained in the plsql/demo directory (profdemo, profrep andprofsum.sql).

Also buried inside the demo directory are the remnants of a Java-based viewing utility.There was a profview.html in older versions (not present at least in 10gWindows), a

Windows batch file (profview_nt.bat), and a jar file (profview.jar). The batch file will error

out with a failure to load the Main-Class manifest from profview.jar. The command to runthe viewer (assuming you can fix the manifest error, or happen to have an older version ofthis and want to modernize it) is java riw. Overall, the HTML output is probably the easiest

and quickest means of viewing the profile information in a better-than-text-only interface.

See All Articles by ColumnistSteve Callan

for in terms of line by line detail and timings. You have to admit this is MUCH better thanpouring through a formatted trace file to see where all of the time went.
http://www.databasejournal.com/article.php/3099361http://www.databasejournal.com/article.php/3099361http://www.databasejournal.com/article.php/3099361http://www.databasejournal.com/article.php/3099361http://www.databasejournal.com/article.php/3099361

Unleashing DBMS

Documents

Transcript of Unleashing DBMS