Performance Instrumentation for PL/SQL: When, Why, How

Performance Instrumentation for PL/SQL When, Why, How Karen Morton

Your speaker…

Karen Morton

Sr. Principal Database Engineer

Educator, DBA, developer, consultant, researcher, author, speaker, …

Come see me…

karenmorton.blogspot.com

An Oracle user group near you

Why guess?

When you can know .

Method R.

“ R” stands for

response time .

Target the

right task

1

Collect its

R

Details

2

Forecast, act

3

Stop when cost of

additional repairs exceeds

cost of the problem

Go to Step 1

4

The hardest part is

getting the “right”

information

Collecting properly scoped,

Un-aggregated profile data

If you can’t measure it, you can’t manage it.

― David Garvin

There are two types of performance problems in this world...

1

Response time problems.

2

Inefficiencies that aren’t response time problems.

Yet.

Therefore...

You must be able to attack response time problems for specific tasks that the business cares about.

Example...

Posting hurts.

Fix it.

Why should you care?

You need to be able to attack inefficiencies that aren’t yet noticeable as user response time problems.

Example...

Posting takes 3 hours.

It should take 2, but no user really cares.

Why should *you* care?

Because

costs you money

waste

TCO $$ Waste Labor $$ Hardware $$ Software $$

And waste...

...makes other work go slower…

...even your fast stuff

recap...

You must be able to attack

1. Response time problems

2. Efficiency problems

Here’s where

instrumentation

comes in

Why is this program slow?

SQL> exec p

PL/SQL procedure successfully completed.

SQL>

What is “slow”?

SQL> set timing on

SQL> exec p

PL/SQL procedure successfully completed.

Elapsed 00:02:09:98

SQL>

So we open up our code.

create or replace procedure p

as

begin

q;

r;

s;

end;

/

Let’s find out.

create or replace procedure p as

t0 number;

t1 number;

t2 number;

t3 number;

begin

t0 := dbms_utility.get_time;

q;

t1 := dbms_utility.get_time ;

dbms_output.put_line ('Procedure q: ' || to_char((t1 - t0)/100));

r;

dbms_output.put_line ('Procedure r: ' || to_char((t2 - t1)/100));

s;

dbms_output.put_line ('Procedure s: ' || to_char((t3 - t2)/100));

dbms_output.put_line ('Total R : ' || to_char((t3 - t0)/100));

end;

/

So now we know.

SQL> set timing on

SQL> exec p

Procedure q: 1

Procedure r: 114

Procedure s: 15

Total R : 130

Elapsed 00:02:09:99

SQL>

What was the co $ t?

Response time increased

by .01 seconds

(From 129.98 to 129.99)

Code additions

4 variable declarations

8 lines of code

These new lines

of code are called performance instrumentation .

With this data,

we know where

to focus our attention.

Where would you start

if you didn’t have this data?

What would happen if

you started work on

procedure Q or S ?

Procedure q: 1 Procedure r: 114 Procedure s: 15 Total R : 130

Why guess?

When you can know .

Profiling is a

requirement of good

development hygiene

It makes your apps

faster and cheaper

Without profiling…

Can’t tell where time goes

“ Tune” everything you can

Learn about everything possible

“ Tuning” continues even when improvement is impossible

With profiling…

Know where code spends time

Optimize only relevant code path

Learn first in high-impact areas

“ Tuning” ceases when objective is achieved

Performance

instrumentation

in real life

I just started a new job

and need to drive 15 miles from home to the office each day.

I decide to leave home at

7:40am expecting to be

there by 8:00am.

Day 1 Depart 7:40am Arrive 8:20am

Total Drive Time

40 minutes

Argh!

It’s not good to be

late for your first

day on a new job!

What am I going to do?

First, let me find out how my drive time was spent.

Category Miles Elapsed Time (minutes) Neighborhood 1 3 Burke Centre Pkwy 2.5 8 Fairfax County Pkwy 6 12 I-66 2.5 8 Hwy 28 2 5 Westfields Blvd to Office 1.5 4 Total 15.5 40 minutes

Try another route?

Buy a faster car?

Hire private air transport?

Conclusion Leave earlier to allow for traffic fluctuations

Why guess?

When you can know .

What is instrumentation

and why is it important?

Measures the

attributes of a system

Creates monitoring mechanisms

Tracks and measures performance

What are the objectives

of proper instrumentation?

Easy to

activate

Capture timings of

business-critical

tasks

Lightweight

Leverages

built-in functionality

What are the benefits of proper instrumentation?

Appropriately

scoped trace

information

More meaningful

information

This?

Or this?

This?

Or this?

Why did this take so long?

What would happen if…?

Is this thing efficient?

Am I done yet?

Easily answer questions like:

Provide final word

on disputes

How do I instrument my code?

Start with

supplied packages

DBMS_SESSION

set_identifier

identifies current

session to make

tracing easier

Lets instance know which end users are on which connection

DBMS_SESSION.set_identifier

(client_id =>'jqpublic~ora11r1')

LOGON Trigger

SYS_CONTEXT('USERENV', 'CLIENT_IDENTIFIER')

SYS_CONTEXT('USERENV', 'SERVICE_NAME')

SYS_CONTEXT('USERENV', 'IP_ADDRESS')

SYS_CONTEXT('USERENV', 'TERMINAL')

SYS_CONTEXT('USERENV', 'OS_USER')

SYS_CONTEXT('USERENV', 'SESSIONID')

SELECT client_identifier,…

FROM V$SESSION

… plus almost 40 other views

DBMS_SYSTEM

ksdddt

writes date/time stamp

ksdwrt

writes any message

DBMS_SYSTEM.ksdddt

*** 2008-10-02 15:36:51.314

DBMS_SYSTEM.ksdwrt

(dest=>1, ' Here I am! ' )

Here I am!

DBMS_APPLICATION_INFO

set_module

register business tasks

and related logical

units of work

read_module

determine current

business task and

logical unit of work

set_session_longops

monitor progress

of long-running

operations

DBMS_APPLICATION_INFO.

set_module(

module_name=> ' Order Entry ' ,

action_name=> ' Get Order Items ' )

SELECT module, action, …

FROM V$SESSION

– or –

FROM V$SESSION_LONGOPS

… plus almost 40 other views

DBMS_MONITOR

client_id_trace_enable

database_trace_enable

serv_mod_act_trace_enable

session_trace_enable

start extended

SQL tracing

DBMS_MONITOR.

serv_mod_act_trace_enable(

service_name=> ' ora11r1 ' ,

module_name=> ' Order Entry ' ,

action_name=> ' Get Order Items ' )

Trace file will contain

*** ACTION NAME:(Get Order Items)

2009-08-02 01:48:56.573

*** MODULE NAME:(Order Entry)

2009-08-02 01:48:56.573

SELECT *

FROM DBA_ENABLED_TRACES

TRACE_TYPE SERVICE_MODULE_ACTION

PRIMARY_ID ora11r1

QUALIFIER_ID1 Order Entry

QUALIFIER_ID2 Get Order Items

WAITS TRUE

BINDS TRUE

PLAN_STATS FIRST_EXEC

INSTANCE_NAME <null>

client_id_stat_enable

serv_mod_act_stat_enable

gather performance

metrics

DBMS_MONITOR.

client_id_stat_enable

(client_id =>'jqpublic~ora11r1')

CLIENT_IDENTIFIER STAT_NAME TIME_SECS

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

jqpublic~ora11r1 DB CPU .009

jqpublic~ora11r1 DB time .009

jqpublic~ora11r1 sql execute elapsed time .007

jqpublic~ora11r1 parse time elapsed .001

. . .

SELECT * FROM V$CLIENT_STATS

SELECT * FROM V$SERV_MOD_ACT_STATS when using serv_mod_act_stat_enable

Where should I place instrumentation?

Set module & action

below the

BEGIN statement

Update module & action

for any new

business tasks

Place above all

END and RETURN

statements

(set to null)

Place inside all

EXCEPTION

handlers

(set to null)

Avoid placing

calls inside

LOOPs

Example...

PROCEDURE get_emp_simple_instr IS fnlist_stack fnlist_tab; lnlist_stack lnlist_tab; BEGIN DBMS_APPLICATION_INFO.set_module(module_name => 'Human Resources’,action_name => 'Get Employees'); SELECT first_name, last_name BULK COLLECT INTO fnlist_stack, lnlist_stack FROM employees; DBMS_APPLICATION_INFO.set_module(NULL, NULL); EXCEPTION WHEN OTHERS THEN DBMS_APPLICATION_INFO.set_module(NULL, NULL); DBMS_OUTPUT.PUT_LINE('get_emp_simple_instr => ERROR'); END get_emp_simple_instr;

08:00:00 MODULE = ‘Human resources’ ACTION= ‘get employees’ 08:02:04 MODULE = null ACTION = null

PROCEDURE get_emp_jobs_instr_flawed IS jtlist_stack jtlist_tab; lnlist_stack lnlist_tab; BEGIN DBMS_APPLICATION_INFO.set_module(module_name => 'Human Resources', action_name => 'Get Employees and Jobs'); get_emp_simple_instr; SELECT last_name, job_title BULK COLLECT INTO lnlist_stack, jtlist_stack FROM employees e, jobs j WHERE e.job_id = j.job_id; DBMS_APPLICATION_INFO.set_module(NULL, NULL); EXCEPTION WHEN OTHERS THEN DBMS_APPLICATION_INFO.set_module(NULL, NULL); DBMS_OUTPUT.PUT_LINE('get_emp_jobs_instr_flawed => ERROR'); END get_emp_jobs_instr_bad;

08:10:00 MODULE = ‘Human resources’ ACTION = ‘get employees and jobs’ 08:12:04 MODULE = null ACTION = null 08:10:01 MODULE = ‘Human resources’ ACTION = ‘get employees’ 08:13:32 <end>

Problems can occur

when one similarly

instrumented procedure

calls another

Remember to

store module & action

in variables

and “reset” as needed

throughout code

PROCEDURE get_emp_instr_good IS fnlist_stack fnlist_tab; lnlist_stack lnlist_tab; preModuleName VARCHAR2(48) := NULL; preActionName VARCHAR2(32) := NULL; BEGIN DBMS_APPLICATION_INFO.read_module( module_name => preModuleName, action_name => preActionName); DBMS_APPLICATION_INFO.set_module( module_name => 'Human Resources', action_name => 'Get Employees'); SELECT first_name, last_name BULK COLLECT INTO fnlist_stack, lnlist_stack FROM employees; DBMS_APPLICATION_INFO.set_module( module_name => preModuleName, action_name => preActionName); EXCEPTION WHEN OTHERS THEN DBMS_OUTPUT.PUT_LINE('HR_Package.get_emp_instr_good ERROR'); DBMS_APPLICATION_INFO.set_module( module_name => preModuleName, action_name => preActionName); END get_emp_instr_good;

Instrumentation

Library for Oracle

( ILO )

Used to simplify the

process of instrumenting

your code

3 packages

ILO_TASK

ILO_TIMER

ILO_SYSUTIL

Requires

Oracle version

9.2.0.1

or above

Makes

instrumenting

code

easy

Encapsulates & simplifies

the use of

dbms_application_info

and

dbms_session

Download from

SourceForge.net

Open Source !

Can be modified to

meet your needs

Place 1 st call

below the

BEGIN statement

ILO_TASK.begin_task(

module_name=> ' Human Resources ' ,

action_name=> ' Get Employees ' )

Change for any new

business tasks

ILO_TASK.begin_task(

module_name=> ' Human Resources ' ,

action_name=> ' Get Jobs ' )

Place end calls

above all

END and RETURN

statements

and inside all

EXCEPTION

handlers

ILO_TASK.end_task

That’s

it!

PROCEDURE get_emp_instr_better IS fnlist_stack fnlist_tab; lnlist_stack lnlist_tab; BEGIN ILO_TASK.BEGIN_TASK(module_name => 'Human Resources' ,action_name => 'Get Employees'); SELECT first_name, last_name BULK COLLECT INTO fnlist_stack, lnlist_stack FROM employees; ILO_TASK.END_TASK; EXCEPTION WHEN OTHERS THEN DBMS_OUTPUT.PUT_LINE('get_emp_instr_better ERROR'); ILO_TASK.END_TASK; END get_emp_instr_better;

Turning on trace

using ILO

Activating trace is a

run-time decision

The developer adds

BEGIN_TASK & END_TASK

calls to the code

The DBA starts

tracing with

DBMS_MONITOR

The developer can start

tracing with ilo_task

SET_MARK_ALL_TASKS_INTERESTING

(TRUE, TRUE)

Case

study

The Problem

Business critical task

taking 40 seconds

MAX tolerated

execution time

15 seconds

Weeks spent searching for root cause and fix

Task was a single

PL/SQL package

with 2,300 lines

of code

Code was executed

over 100 times

per hour

Running on

multi-node RAC

Trace collection not

very helpful due to

improper scoping

Needed instrumentation

to provide

proper scoping

Code contained

36 business tasks

all marked with

in-line comments

In-line comments

used to guide

instrumentation

with ILO

Spent

40 minutes

to instrument

36 tasks

Instrumented

code placed

into production

Tracing activated

using dbms_monitor

for the instrumented

module & actions

Problem

code

was executed

Tracing

deactivated

Trace file

retrieved

and profiled

Majority of time spent waiting for gc cr multi block request

Further drilldown showed one insert and one delete to be largest “R” contributors

Reviewed the insert statement which was actually inserting via a SELECT

1) Noted excessive LIO 2) Plan showed use of full table scan

The Fix

Added index on ts_row_seq

Problem code was

executed and

traced again

New response time 10.118 seconds

Total time to

find and fix

the problem:

less than 1 hour

Why guess?

When you can know .

Summary

When should you consider

performance

instrumentation?

Any time there is code

whose performance

you might ever

care about.

Why should

performance

instrumentation

matter?

Because when it

isn’t in place,

managing performance

is too complex

and expensive.

How should

performance

instrumentation

be done?

By adding a few

extra lines of code

to register

each business task.

Performance

doesn’t need

to be hard

Let your software

help you!

It’s a mindless task

your computer is willing

to do for you…

… if you just

ask it to.

Why guess?

When you can know .

Thank you!

Questions & Answers

Performance Instrumentation for PL/SQL: When, Why, How

0 comments

Notes on slide 1

2 Favorites