Making Friends With Oracle

2uu8-2uu9 Nethou R Coipoiation. All iights ieseiveu.
1
Ior Deve|opers: Mak|ng Ir|ends
w|th the Crac|e Database
Caiy Nillsap
Nethou R Coipoiation, Southlake, Texas, 0SA
cary.millsap@method-r.com
ReviseJ 2009,02,09
To mony opplicotion Jevelopers, o Jotobose is just o "Joto store" witb on APl tbot tbey
coll wben tbey neeJ to persist on object. lts on obstroction tbot mokes sense from one
perspective: in o worlJ wbere youre expecteJ to write Jozens of new feotures every
Joy in }ovo, PEP, or C#, wbo bos tbe time or tbe inclinotion to Jive into wbots qoinq
on Jeep insiJe tbe 0rocle Botobose? As o result of tbis obstroction, tbouqb, Jevelopers
sometimes inflict unintenJeJ performonce borrors upon tbeir customers. Tbe qooJ
news is tbot you con ovoiJ most of tbese borrors simply by better unJerstonJinq o bit
more obout wbots qoinq on insiJe tbe 0rocle kernel. Tbe trick is knowinq wbicb
Jetoils you neeJ to stuJy, onJ wbicb you con sofely leorn loter. Tbis presentotion
Jescribes, from o Jevelopers perspective, some of tbe most importont coJe potbs
insiJe tbe 0rocle kernel tbot con moke tbe Jifference between on opplicotion tbot
breoks Jown unJer looJ onJ one tbot con scole to tbousonJs of users.
1 IN1kCDUC1ICN
Since the eaily 199us, my piofessional focus has been
softwaie peifoimance. By that I mean speeJ. I'm a
uevelopei, too. In my caieei, I've wiitten a lot of C
coue. These uays, I wiite a lot of Peil. Ny aim in this
papei is to give you a bettei unueistanuing about what
goes on insiue the 0iacle Batabase in iesponse to the
coue you wiite. I'm going to show you examples of
coue wiitten in }ava, but what you'll see applies
equally iegaiuless of whethei youi coue is PBP, C#,
Ruby, Python, Peil, C, oi something else.
Ny goal is simple. If I can get you to unueistanu a little
moie cleaily what's going on insiue the 0iacle
Batabase keinel, you'll wiite bettei, fastei coue.
Although uevelopeis aie often "taught" that they
shoulun't concein themselves with what goes on
insiue the uatabase, that's ieally not tiue. Not if you
want to builu big applications that iun fast, anyway.
So my job is to help you make fiienus with 0iacle.
When we'ie uone, you'll wiite fastei coue, anu you'll
piobably wiite less coue, too, that'll be easiei to
maintain. I'll show you an example. I think that once
you get to know youi uatabase a little bettei, you'll be
impiesseu with some of the things it uoes foi you.
Naking fiienus with new softwaie is not altogethei
uiffeient fiom making a new bumon fiienu. The best
way to get staiteu is to leain youi new fiienu's
language.
Now, you'ie piobably alieauy at least a little bit
familiai with the SQL language, which enables you to
ieau anu wiite uata to the 0iacle Batabase. Teaching
you SQL is not my aim heie. Ny aim is to teach you
how to communicate about the performonce of the
application coue you wiite. Theie aie lots of tools that
let you assess the peifoimance of the client coue you
wiite. In this papei, I'll acquaint you with a tool that
0iacle Coipoiation pioviues, which will help you
measuie veiy easily how efficiently the coue you wiite
uses the 0iacle Batabase.
2 2uu8-2uu9 Nethou R Coipoiation. All iights ieseiveu.

Fxbibit 1. Sequence Jioqrom for o multi-row
Jotobose query.
2 WnLkL SCI1WAkL SLLD CCMLS IN
Let's take a look at how an application that uses 0iacle
might woik. Exhibit 1 shows a iough 0NL sequence
uiagiam that seives as a goou conceptual mouel foi
how a business task that fetches iows fiom an 0iacle
uatabase woiks.
It's a pietty simple mouel. Fiist, the application uoes
what it has to uo to connect to 0iacle anu piepaie a
SQL statement foi fetching the uata. Then it fetches a
iow at a time, piocessing each iow in tuin. It uoes this
until it has piocesseu all the uata that it neeus. Then it
cleans up aftei itself.
Nission accomplisheu, iight. It's ceitainly a thiill the
fiist time you make something like this happen:
making uata go fiom this complex anu expensive
"black box" into youi application, then peihaps into an
BTNL page wheie anyone on the Inteinet can see it.
But what about the peifoimance of the application.
Naybe on youi uevelopment system, the coue you
wiote is lightning fast. Theie aie two questions you
neeu to be able to answei:
1. Is youi coue as fast as it sboulJ be.
2. Will youi coue scole.
When I say scole, I mean it in the mathematical sense
that means the iate at which a usei's iesponse times
will cbonqe as some othei factoi in the system
changes. Foi example, foi a system "not to scale well to
laige usei counts" means that it slows uown moie
aggiessively than you want as moie useis log into the
system. If it uoesn't scale well to laige uata volumes,
then that means it will slow uown moie aggiessively
than you want as people inseit iows into youi
uatabase.
The point of this papei is to give you some insight into
how you can meosure how efficiently youi application
is wiitten, so that you can know whethei youi coue is
as fast as it shoulu be anu whethei it will scale. Why
guess. .when you can know.
3 ILLD8ACk
Piobably the most impoitant tool you neeu to make
leorninq happen moie efficiently is feeJbock. A little
giil ieaches foi the hot stove. Nommy yells, "No!"
That's feeuback. The little boy stanuing close by wants
to see what all the fuss is about, so he ueciues to touch
the stove anyway. P0W! Noie feeuback. Feeuback
fiom the stove is even moie memoiable than the
feeuback fiom Nommy.
Feeuback that is close in time to the behavioi it
measuies is moie valuable than feeuback that happens
much latei than the behavioi it measuies. Imagine
what woulu happen if, when the little boy toucheu the
hot stove, it uiun't huit until thiee months latei.
Without immeuiate feeuback, the boy might leave his
hanu on the stove foi seveial seconus, anu then what
happens thiee months latei woulu be absolutely
hoiiifying. Thiee months latei, a lot of the ieally goou
choices woulun't be available anymoie. Befeiieu
feeuback can be ueauly. Imagine if theie weie a ten-
seconu uelay on what you coulu see thiough youi cai's
winushielu. See the stoiy of the chemical element
iauium foi an impoitant histoiical example(Wikipeuia
2uu8).
So, how can you shoiten the feeuback loop about the
peifoimance of the application you aie wiiting touay.
With a featuie that comes stanuaiu with eveiy ielease
anu euition of the 0iacle Batabase since veision 7. The
featuie is calleu "extenueu SQL tiace." I've wiitten
about its histoiy in (Nigaaiu, et al. 2uu4, 1SS-182).
When you'ie inteiesteu in geneiating youi own tiace
files, you can see how to uo that in section 17 neai the
enu of this papei. Right now, let's take a look at the
kinus of things you'll finu in a tiace file that will help
you wiite bettei coue.
2uu8-2uu9 Nethou R Coipoiation. All iights ieseiveu. S
4 IN1LkkL1ING CUk 1kACL IILL
Tiace files can be intimiuating, especially when they
contain hunuieus of thousanus of lines. But even the
most complicateu tiace files aie iooteu in a
suipiisingly small numbei of funuamental piinciples,
which I'll covei heie.
0iacle tiace files iecoiu only two basic categoiies of
useful infoimation about wheie youi time has gone:
Batabase calls
Each line that begins with the token PARSE, EXEC,
oi FETCH iepiesents a single, completeu uatabase
call executeu by the 0iacle keinel. A uatabase call
line tells you, with its e value, how many
micioseconus of elapseu time the call consumeu.
Its c value tells you appioximately
1
how many
micioseconus of CP0 time the call consumeu.
0peiating system calls (0S calls)
Each line that begins with the token WAIT
iepiesents a single, completeu opeiating system
call (0S call) executeu by the 0iacle keinel.
2
An 0S
call line tells you, with its elo value, how many
micioseconus of elapseu time the call consumeu.
The tiick to unueistanuing 0iacle tiace uata is to leain
what the vaiious uatabase calls anu 0S calls mean.
0nce you know how to figuie this out, you'll be able to
ieau foi youiself an iiiefutable play-by-play account of
exactly what youi coue has spent its time uoing,
measuieu fiom the 0iacle Batabase's peispective.
S 1kACL IILL GUIDLD 1CUk
Now let's take a look at the guts of an 0iacle tiace file.
When we uiscuss 0iacle tiace file contents, you neeu
to iemembei that it's the 0iacle keinel piocess that
wiites to the tiace file. The play-by-play you'll see in
the 0iacle tiace uata stieam is the stoiy tolu fiom the
peispective of an 0iacle server piocess like the one
shown in Exhibit 2.

1
The c statistic in 0iacle tiace uata is only as accuiate as the
qetrusoqe function youi 0S pioviues. 0n systems that uon't
use microstote occountinq (e.g., Solaiis uoes), a c statistic is
accuiate to only 1u,uuu s. Foi moie uetails, see chaptei 7
of Caiy Nillsap anu }eff Bolt, 0ptimizinq 0rocle Performonce
(Sebastopol, CA: 0'Reilly, 2uuS).
2
It's a little moie complicateu than that, because sometimes
the 0iacle keinel calls moie than one 0S call in the context
of a single WAIT line. But it usually uoesn't mattei if you
uon't know this.

Fxbibit 2. Tbe 0rocle two-tier, client-server
orcbitecture; tbe 0rocle kernel process is tbe one
tbot writes tbe troce Joto youll be reoJinq.
The following paiagiaphs contain a play-by-play
analysis of an 0iacle tiace file piouuceu by a }ava
piogiam that consumeu about 2S seconus of iesponse
time queiying 142,S17 iows out of an 0iacle uatabase.
You can see moie uetails fiom that tiace file in
section 19.1, neai the enu of this papei. The action
within the tiace file that we'ie ieally inteiesteu in
begins at line 24:
24. =====================
2S. PARSING IN CURSOR #1
26. select * from sla_run
27. END OF STMT
These lines ieveal what futuie iefeiences to "#1" will
mean: they'll be iefeiences to a cuisoi associateu with
the SQL statement "select * from slo_run".
28. PARSE #1:c=0,e=251,
Line 28 is wheie the action ieally begins. This line
ieveals that the 0iacle keinel executeu an 0iacle
Piogiam Inteiface (0PI) porse function upon the select
statement shown on line 26. What I'm calling an 0PI
porse function is the seivei-siue companion of the
0ClStmtPrepore call, which the }BBC executeu within
oui client piocess. To see uetails about what such a
function uoes, consult (0iacle Coipoiation 2uu8). This
porse function consumeu 2S1 s (that is,
2S1 micioseconus, oi u.uuu2S1 seconus) of iesponse
time.
29. BINDS #1:
Theie weie no placeholueis in the SQL statement to
which values weie to be bounu; otheiwise, we woulu
have seen moie infoimation (moie lines of tiace uata)
heie.
Su. EXEC #1:c=0,e=84,
S1. WAIT #1: nam='SQL*Net message to client' ela= 2
The 0iacle keinel executeu an 0PI exec function
(companion of 0ClStmtFxecute) upon the cuisoi
uesciibeu in lines 24 thiough 27. The function
consumeu 84 s of iesponse time. Then the 0iacle
keinel wiote some infoimation back to its callei (the
}ava piogiam) thiough its SQL*Net inteiface. The 2 s
uuiation iepoiteu heie is not the uuiation of an 0S
write call, although you have a iight to expect that it
woulu be (Nillsap, SQL*Net 2uuS). It is actually only
the uuiation of an 0S timei call executeu befoie the
write. It's an 0iacle bug, but not a veiy impoitant one.
S2. WAIT #1: nam='SQL*Net message from client' ela= 25227
Then the 0iacle keinel blockeu upon an 0S reoJ call
(the same way a reoJ of youi keyboaiu will block until
you piess the Fnter key), passing appioximately
2S,227 s of enu-usei iesponse time. This is actually
the uuiation of the whole netwoik iounu-tiip fiom the
0iacle keinel piocess to the client anu back. It also
incluues all the time spent executing coue on the
client.
SS. WAIT #1: nam='SQL*Net message to client' ela= 24
S4. FETCH #1:c=0,e=355,,r=10,
SS. WAIT #1: nam='SQL*Net message from client' ela= 7851
The keinel executeu an 0PI fetcb function (companion
of 0ClStmtIetcb) upon the cuisoi executeu in line Su.
The fetch ietuineu 1u iows in one netwoik iounu-tiip,
consuming SSS s. You can iegaiu the Sl*Net
messoqe to client call as a tiny little 24 s of coue path
executeu within the context of the fetch. Aftei the
fetch, the keinel blockeu upon an 0S reoJ call foi
anothei 7,8S1 s awaiting the next call fiom the client.
S7. FETCH #1:c=0,e=84,,r=10,

4u. FETCH #1:c=0,e=81,,r=10,
41. WAIT #1: nam='SQL*Net message from client' ela= 1282

(42,746 lines heie aie not shown)

42. WAIT #1: nam='SQL*Net message to client' ela= 2
4S. FETCH #1:c=0,e=86,,r=7,
Beie, the same thiee-line pattein iepeats thousanus of
times. The keinel ietuins ten iows pei netwoik
iounu-tiip to the client until finally theie aie only
seven iows ietuineu in the final attempteu ten-iow
fetch, at which point the client coue path can uetect
that it has fetcheu all the iows that the keinel hau to
offei, anu the queiy is finisheu.
Reauing a tiace file line-by-line is not tiemenuously
uifficult; it gets teuious, but not uifficult. Anothei layei
of uifficulty folus in when you want to summaiize the
infoimation piesenteu by a block of tiace file lines.
The job is moie complicateu than you might have
guesseu by now, because theie aie gaps anu oveilaps
in how the 0iacle keinel emits its own timing uata.
You can leain about the uetails in (Nillsap anu Bolt
2uuS).
You can often get a goou geneial sense of what's going
on in a tiace file simply by aggiegating c oi e values foi
uatabase calls anu elo values foi 0S calls. I summaiize
tiace uata with a softwaie tool that I helpeu uesign
anu uevelop, calleu the Nethou R Piofilei.
S

Summaiizing the elapseu time consumeu by uatabase
calls anu 0S calls yielus the infoimation shown in
Exhibit S.
Response time
(seconus) Call
2u.u7u 8S.8% SQL*Net message fiom client
1.6S2 7.1% CP0 seivice, fetch calls
1.68S 7.2% all othei
2S.4uS 1uu.u% Total iesponse time
Fxbibit S. Response time profile of our 2S-seconJ
query proqrom execution.
The coue spenus 8S.8% of its usei's time moving iows
acioss the netwoik
4
anu only 7.1% fetching iows out
of the uatabase. That's a pattein I want you to
iecognize when you see it, this issue of iesponse time
being uominateu by netwoik I0. It is an impoitant
peifoimance antipattein.
S

6 C1IMI2ING 1nL ULk kCGkAM
Whenevei netwoik I0 time uominates the iesponse
time of a piogiam you've wiitten, it's piobably an easy
oppoitunity foi you to optimize youi coue. It's usually
not haiu to peifoim the optimization. The step that
most people miss is to look at iesponse time

S
visit bttp:,,metboJ-r.com,softwore,profiler-info foi uetails.
4
Some of the 2u.u7u seconus of Sl*Net messoqe from client
time is spent by client }ava coue path. If I wanteu to test
exactly how much time the client piogiam is spenuing, I
woulu piofile the client-siue }ava coue.
S
Iionically, many 0iacle authois teach that you shoulu
ignoie all Sl*Net messoqe from client calls. I hope by now
that you can see how awful of an iuea that is.
2uu8-2uu9 Nethou R Coipoiation. All iights ieseiveu. S
uecomposeu this way to begin with. 0nce you see the
pioblem, you can focus youi eneigy on fixing it. So,
heie we go.
Biu you flinch at all when you saw this line of the tiace
uata that I showeu you eailiei.
S4. FETCH #1:c=0,e=355,,r=10,
Notice that the fetch call ietuineu not just one iow to
the application, but ten. Whenevei youi }ava coue asks
the }BBC foi rowSource.next, the }BBC cleveily giabs
anu buffeis iows foi you in batches of ten. The uefault
aiiay size is 1u. Bau the aiiay size been set to 1
insteau, can you guess what oui iesponse time woulu
have lookeu like.
The answei is that the piogiam's iesponse time woulu
have been about ten times woise. We tiieu it:
Aiiay fetch
size
Response time
(seconus)
1 24u.297
1u 2S.4uS
It's easy to unueistanu why, once you've seen the tiace
uata. If oui piogiam hau fetcheu one iow at a time
insteau of ten, it woulu have maue ten times moie
netwoik iounu-tiips to fetch all the uata. Thus, insteau
of the 2u seconus of iesponse time you saw in
Exhibit S, you shoulu expect 2uu seconus of netwoik
I0 time. .Which is almost exactly what uiu happen.
At this point, I hope you've begun to wonuei about the
following questions:
1. What if you weie to make the aiiay fetch biggei
than 1u. Woulu it impiove iesponse time.
2. Is theie a point of uiminishing ietuins, wheie the
aiiay fetch size can be too big.
S. Bow uo you manipulate the aiiay fetch size.
The answei to the fiist question is that yes, absolutely,
incieasing the aiiay fetch size impioves iesponse time
foi oui piogiam. We tiieu seveial aiiay fetch sizes,
anu you can see fiom the shape of the cuive in
Exhibit 4 that manipulating the aiiay fetch size hau a
piofounu impact upon peifoimance.

Fxbibit 4. Arroy fetcb size bos o profounJ impoct
upon our querys performonce.
In oui piogiam testing, we tiieu lots of aiiay fetch
sizes, anu we founu that the sweet spot foi us (given
oui iow sizes, oui TCPIP packet sizes, etc.) was
ioughly 2,u48. That's wheie oui iesponse times
settleu in at about 2.4 seconus. That aiiay fetch size
yielus about a 9u% ieuuction in iesponse time
compaieu to the uefault setting of 1u.
Aiiay sizes laigei than 2,u48 uiun't piouuce a
peifoimance benefit foi us, in spite of consuming a lot
moie memoiy. Foi aiiay fetch sizes laigei than 4,u96,
iesponse times actually uegiaueu a bit. When we tiieu
an aiiay fetch size setting of 16,S84, oui }ava piogiam
piomptly uieu of an out-of-memoiy eiioi.
6
The
bathtub shape of the uata in Exhibit 4 tells us that
biggei is bettei to a point, at which too big becomes
bau.
So how can you manipulate youi aiiay fetch size.
Well, if you use the Sun }BBC, you can't. But if you use
the 0iacle }BBC, it's easy. You execute the setIetcbSize
methou upon the statement object, like this:
statement.setFetchSize(size);
resultSet = statement.executeQuery(query);
while (resultSet.next()) {
// do your business upon resultSet
}
Exhibit S shows how the piogiam that useu the aiiay
fetch size of 2,u48 spent oui 2.4 seconus.

6
We useu a maximum }ava heap size of 64 NB by specifying
java Xms 2m Xmx 64m.
u
Su
1uu
1Su
2uu
2Su
S
e
c
o
n
u
s

Aiiay fetch size
Response Time
Response time
(seconus) Call
u.89u S7.1% SQL*Net message fiom client
u.82S S4.S% SQL*Net moie uata to client
u.74S S1.u% CP0 seivice, fetch calls
-u.uS8 -2.4% all othei
2.4uu 1uu.u% Total iesponse time
Fxbibit S. Response time profile of our improveJ
2.4-seconJ query proqrom execution.
Bon't feel too unsettleu by the negative numbei shown
in the "all othei" categoiy of Exhibit S. It is an aitifact
of the 1u,uuu-s accuiacy on the CP0 statistic that I
mentioneu eailiei. Sometimes, the c statistic ovei-
accounts foi elapseu uuiation. Foi example, a uatabase
call with c=10000,e=8000 woulu inuicate:
Response time
(micioseconus) Call
1u,uuu 12S.u% CP0 seivice, .
-2,uuu -2S.u% all othei
8,uuu 1uu.u% Total iesponse time
The point is that by manipulating oui aiiay fetch size,
we ieuuceu the total time we spent waiting foi
netwoik I0 calls fiom 2u.u7u seconus (Exhibit S) to a
much moie beaiable u.89u + u.82S = 1.71S seconus.
We even ieuuceu the amount of CP0 time we spent in
fetch calls, piesumably because we'ie not making
neaily as many fetch calls with the laigei aiiay fetch
size.
The oveiall peifoimance impiovement is spectaculai
(2S.4uS seconus to 2.4uu seconus) because we
taigeteu the exact ieason that the piogiam spent so
much of oui time. Such is the piincipal beauty of
piofiling: it focuses oui attention wheie it belongs, anu
it safely allows us to ignoie eveiything that uoesn't
mattei.
Section 19.2 shows some of the iaw tiace uata foi the
impioveu piogiam. Beie's a biief walk-thiough of how
that piogiam piogiesseu. The inteiesting action
begins on line 24:
24. =====================
27. END OF STMT
28. PARSE #1:c=1000,e=121,
29. BINDS #1:
Su. EXEC #1:c=0,e=57,
This is the same pattein as you saw pieviously in the
slow coue. Bowevei, what comes next is veiy
uiffeient:
SS. WAIT #1: nam='SQL*Net message to client' ela= 6
S4. WAIT #1: nam='SQL*Net more data to client' ela= 149
SS. WAIT #1: nam='SQL*Net more data to client' ela= 7
S6. WAIT #1: nam='SQL*Net more data to client' ela= 9
(many moie 'SQL*Net moie uata to client' calls happen heie)
68. WAIT #1: nam='SQL*Net more data to client' ela= 10
69. FETCH #1:c=11998,e=22206,r=2048,
Beie, the 0iacle keinel makes a Sl*Net messoqe to
client call to ship iesults back to the client, but the
iesult set is so big that it won't fit into a single netwoik
packet. So the keinel makes a numbei of Sl*Net more
Joto to client calls to fulfill the passage of uata that it
owes to the client. Finally, the keinel completes the
fetcb call, which you can see ietuineu 2,u48 iows in
22,2u6 s, aftei consuming appioximately 11,998 s
of CP0 time.
The pattein iepeats until the enu of the tiace file:
(2,8S9 lines heie aie not shown)
7u. FETCH #1:c=6999,e=6837,,r=1205,
.wheie the last 6,8S7-s fetcb ietuins the final
1,2uS iows.
7

7 C1IMI2ING 8LGINS WI1n MLASUkING
Beie's a quick quiz. What have you leaineu so fai.
a. Youi optimal 0iacle aiiay fetch size is 2,u48.
b. You shoulu always check to make suie that you've
optimizeu youi aiiay fetch size.
c. You shoulu always check to see wheie youi
iesponse time is going befoie you optimize
anything.
Choice (a) is a ieally pooi one, because the optimal
0iacle aiiay fetch size foi the next piogiam you wiite
is piobably going to be uiffeient than the optimal
aiiay fetch size foi the piogiam we just analyzeu. I
haven't stuuieu it in uetail, but I believe that youi
optimal aiiay fetch size is a function of seveial factois,
incluuing at least these:
Bow big aie the iows you'ie ietuining.
Bow big aie youi netwoik packets.
I can easily imagine, foi example, that if oui iows hau
been 1uu times laigei than they weie, then oui
optimal aiiay fetch size might have been 1uu times
smallei. Bowevei, I've leaineu enough ovei the yeais
to believe that any kinu of a mathematical mouel is

7
Eailiei, I mentioneu that this queiy ietuins 142,S17 iows.
Note that 142,S17 % 2,u48 = 1,2uS (using '%' as the
mouulus opeiatoi), so 1,2uS is exactly the numbei of iows
you shoulu expect to be left, aftei seveial 2,u48-iow fetches,
foi the final fetch to giab.
2uu8-2uu9 Nethou R Coipoiation. All iights ieseiveu. 7
useful only as a staiting point, anu that you shoulu
base youi optimizations upon ieal opeiational uata.
Choice (b) is theiefoie supeiioi to choice (a), but what
if netwoik iesponse time hau accounteu foi only
8.S8% of iesponse time. Then the impact of
successfully optimizing youi netwoik I0 woulu have
been so uiminisheu that it might not be woith youi
time investeu into uoing it.
Choice (c) is theiefoie supeiioi to choice (b). Not
eveiy piogiam you wiite will have iesponse time
uominateu by netwoik I0. Theie aie thousanus of
uiffeient ways youi piogiam can spenu youi usei's
time. Why use a checklist to attack eveiything that
might possibly be slowing youi coue uown when you
have a tool at youi uisposalthe 0iacle extenueu SQL
tiace uatato show you exoctly how youi coue is
spenuing its time. Why guess. .when you can know.
0iacle's tiace files give you a language foi
unueistanuing the peifoimance of the coue you wiite.
8 CN SLCIIICA1ICN LLGI1IMAC
I've just uesciibeu a piocess of analyzing anu
impioving peifoimance foi a queiy that ietuins
142,S17 iows. I uiun't tell you anything about how the
}ava piogiam fetching those iows was going to use
those iows. I left that to youi imagination. I meiely
hopeu you woulu tacitly assume that someone neeueu
all those iows. Bevelopeis can tenu to uo that.
I, of couise, chose such an example because it's easiei
to showcase the pioblem of "too much netwoik I0"
when you illustiate with a queiy that ietuins a lot of
iows. Bowevei, in ieal life, it's faii to ask the question,
"Why uo you neeu 142,S17 iows." 0i even, "Bo you
reolly want all those iows."
Ban Tow
8
anu I once hau a uinnei conveisation in
which we agieeu on the following postulate:
No human ever wants to see moie than 1u iows.
0ui iuea was that once you'ie piesenteu with moie
than 1u iows to look at, all in one pictuie, you'u ieally
iathei see some kinu of aggiegation (count, sum,
mean, .whatevei) of the uata insteau.
9

So, the next time you'ie askeu to impiove the
peifoimance of a queiy that ietuins a jillion iows, at
least ask the question whethei the usei using youi
piogiam ieally, reolly wants to see a jillion iows in the
fiist place. It's easiei, cheapei, anu moie effective to

8
You can finu Ban at bttp:,,www.sinqinqsql.com.
9
0ui coiollaiy, of couise, was, "Auuitois aie not human."
give a usei less uataif that's what he ieally wants
than to make youi piogiam fastei at ietuining stuff
that people uiun't ieally want to begin with.
9 1kACL IILL GUIDLD 1CUk #2
Let's look at anothei example of some tiace uata that
ieveals anothei peifoimance antipattein you shoulu
know about. Section 19.S shows an exceipt of an
0iacle tiace file foi a sequence of 1u,uuu inseits,
which consumeu S2.7u6 seconusabout
SS seconusof enu-usei iesponse time.
Fiist, befoie we look at the tiace uata, let me ask you
this: Is SS seconus a goou iesponse time foi a piogiam
that inseits 1u,uuu iows into a table. 0i is it a bau
iesponse time.
People's fiist iesponse when I ask a question like that
is usually eithei eyes-aveiteu silence oi "What kinu of
machine uiu it iun on." The tiuth is, unless you've
iecently encounteieu an application that uiu
something similai to what this piogiam uiu, you
piobably uon't have any iuea. Theie's nothing wiong
with that. In a few minutes, you'll know the answei
anyway.
So, let's walk thiough the lines anu see what's going
on. The inteiesting action begins at line 24:
24. =====================
26. insert into JAVA_TEST_TABLE values ('0')
27. END OF STMT
Lines 24 thiough 27 inuicate that cuisoi "#2" iefeis to
the SQL statement that inseits a iow into
jovo_test_toble.
28. PARSE #2:,e=678,
29. BINDS #2:
These lines inuicate that an 0PI porse call has
consumeu 678 s of iesponse time, anu that theie
weie no values bounu to placeholueis in the
statement. (That makes sense, because theie aien't
any placeholueis in the statement.)
Su. EXEC #2:,e=1245,,r=1,
The 0iacle keinel executeu an 0PI exec function,
which consumeu 1,24S s of iesponse time to inseit
one iow.
S1. XCTEND rlbk=0, rd_only=0
The keinel executeu an 0PI commit function (seivei-
siue companion to 0ClTronsCommit), which
committeu eveiything this session has uone thus fai to
the uatabase.
A netwoik iounu-tiip consumeu 1,1S6 s of iesponse
time.
Anu then, in the following lines, you see the same
pattein ovei anu ovei.
S4. =====================
SS. PARSING IN CURSOR #2
S6. insert into JAVA_TEST_TABLE values ('1')
S7. END OF STMT
S8. PARSE #2:,e=302,
S9. BINDS #2:
4u. EXEC #2:,e=202,,r=1,
41. XCTEND rlbk=0, rd_only=0
42. WAIT #2: nam='log file sync' ela= 113
4S. WAIT #2: nam='SQL*Net message to client' ela= 2
4S. =====================
46. PARSING IN CURSOR #2
48. END OF STMT
49. PARSE #2:,e=232,
Su. BINDS #2:
S1. EXEC #2:,e=146,,r=1,
SS. WAIT #2: nam='log file sync' ela= 107
(1u6,S1S lines heie aie not shown)
Bowevei, you can see, on lines 42 anu SS, a kinu of 0S
call that I haven't shown you yet in this papei. The
0iacle name loq file sync iefeis to a synchionization
event that takes place between the 0iacle keinel
piocess inseiting the iows anu a "backgiounu" 0iacle
piocess calleu the "ieuo log wiitei." The two loq file
sync calls shown heie consumeu 11S s anu then
1u7 s of iesponse time.
Summaiizing the elapseu time consumeu by uatabase
calls anu 0S calls (aggiegating the e anu elo values foi
the inuiviuual call types) yielus the infoimation shown
in Exhibit 6.
Response time
(seconus) Call
14.6S7 44.8% SQL*Net message fiom client
6.S89 19.S% log file sync
4.9u1 1S.u% CP0 seivice, paise calls
u.94S 2.9% CP0 seivice, execute calls
S.8S6 17.8% all othei
S2.7u6 1uu.u% Total iesponse time
Fxbibit 6. Response time profile of our SS-seconJ
insert proqrom execution.
10 C1IMI2ING 1nL INSLk1 kCGkAM
Now let's ievisit the question, "Is SS seconus a goou
iesponse time foi this piogiam." Exhibit 6 gives
enough uata to piove that the answei is a iesounuing
no. Beie's why.
The whole point of oui piogiam is to inseit
1u,uuu iows into a table. The 0iacle function that uoes
that woik is iepiesenteu in the tiace uata by the EXEC
lines. This piogiam spent only 2.9% of its timeless
than a seconu!actually putting iows into the
uatabase; yet I hau to wait moie than half a minute foi
the piogiam to complete. The iemainuei of the time
was spent (wasteu.) uoing othei things.
Again, you can see in Exhibit 6, the uominant iesponse
time contiibutoi fits the "excessive netwoik I0"
antipattein. The tiace file actually shows one netwoik
iounu-tiip foi eveiy single iow that's inseiteu into the
uatabase. The next step shoulu be obvious to you by
now: we neeu to finu a way to inseit moie than one
iow pei netwoik iounu-tiip.
Beie's how the oiiginal }ava coue was wiitten:
import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.SQLException;
import java.sql.Statement;

for (Integer i : ilist) {
String sql = String.format("insert into t values ('%d')", i);
Statement st = conn.createStatement();
st.executeUpdate(sql);
}
This coue peifoims the extiaoiuinaiily nasty act of
cieating 1u,uuu (the size of ilist) uistinct SQL
statements within the 0iacle Batabase. Yes, youi
uatabase auministiatoi might tell you not to woiiy,
that he has a uatabase paiametei calleu cursor_sborinq
that will take caie of the pioblem.
But it won't.
.Because youi pioblem isn't so much the
4.9u1 seconus of porse woik that's being uone on the
0iacle Batabase seivei as it is the 14.6S7 seconus of
woik moving uata acioss the netwoik fiom youi client
coue to youi seivei coue. Nanipulating youi 0iacle
Batabase's cursor_sborinq paiametei may make youi
uatabase auministiatois happy (some of the ieu lights
on his uashboaiu will tuin gieen), but it's not going to
make youi users happy, because theii iesponse times
will still be intoleiable.
1u

1u
The 0iacle cursor_sborinq paiametei lets youi uatabase
auministiatoi instiuct the 0iacle keinel to tianslate youi
SQL statements into what those statements might have
lookeu like if you hau useu placeholueis insteau of liteial
values. It's a clevei plan, but theie aie two big pioblems with
it. Fiist, it puts even more woikloau on youi uatabase seivei.
Noie impoitantly, it uoes nothing to ieuuce the quantity of
netwoik I0 that is oui example's uominant pioblem.
People can aigue all they want about whethei to make
aujustments to the netwoik oi the uatabase, but a
goou application uevelopei can stop all the uiscussion
by wiiting the coue a uiffeient way. I'll show you how
we ie-wiote it shoitly. Befoie I get into the coue
changes, let me show you the peifoimance
impiovement we weie able to achieve, which you can
see in Exhibit 7. That shoulu seive as some motivation
foi you to move foiwaiu.
Response time
(seconus) Call
u.u8S SS.u% SQL*Net message fiom client
u.u4u 26.4% log file sync
u.u29 19.2% CP0 seivice, execute calls
-u.uu1 -u.S% all othei
u.1S1 1uu.u% Total iesponse time
Fxbibit 7. Response time profile of our optimizeJ
0.1S1-seconJ insert proqrom execution.
That's a 99.S% peifoimance impiovement, fiom
S2.7u6 seconus to u.1S1 seconus. Noie impoitantly,
that's an impiovement fiom "get up fiom youi uesk"
slow to "click-flash" fast. Anu it fiees up ovei
S2 seconus' woith of capacity on youi system that
allows othei woik to take place without having to
compete against your piogiam foi iesouices.
The changes we maue to the coue aie all in iesponse
to what the piofile in Exhibit 6 showeu us. A simple
top-uown walk of that piofile leu us to ask the
following questions:
Bo we ieally neeu to spenu 14.6S7 seconus uoing
netwoik communications.
Bo we ieally neeu to spenu 6.S89 seconus
executing loq file sync calls.
Bo we ieally neeu to spenu 4.9u1 seconus
piepaiing SQL.
Now let's onswer those questions.
We've alieauy seen the "excessive netwoik I0"
antipattein in the queiy example I woikeu thiough foi
you eailiei. It is ielateu to the excessive amount of
time we've spent piepaiing SQL (those PARSE calls
that showeu up in oui iaw tiace uata).
The answei heie is, once again, to figuie out how to
piocess moie than one iow pei uatabase call. The
geneial stiategy we want to employ is to piepaie oui
SQL statement only once, binu values into that
statement to iepiesent all oui iows to be inseiteu, anu
then make suie we'ie bunuling bunches of iow
inseitions into each uatabase call oui coue motivates.
You can uo that with the }ava Batabase Connectivity
API fiom Sun (the Sun }BBC). Theie aie goou
iesouices on the Inteinet to show you how (Ciawfoiu,
Failey anu Flanagan 2uuS). We've founu the 0iacle
}BBC to be a little bit easiei to use, anu oui expeiience
leaus us to believe it's a little bit fastei, too. Beie's the
coue we useu to piouuce oui u.1S1-seconu example:
import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.SQLException;
import java.sql.Statement;
import oracle.jdbc.OracleConnection;

((OracleConnection)conn).setDefaultExecuteBatch(1000);
conn.setAutoCommit(false);
String sql = String.format("insert into t values (?)");
PreparedStatement pst = conn.prepareStatement(sql);
for (Integer i : ilist) {
pst.setInt(1, i);
pst.executeUpdate();
}
conn.commit();
Fiist, we impoiteu the 0iacle }BBC that's iequiieu to
use the setBefoultFxecuteBotcb value to 1,uuu.
Skipping ovei the setAutoCommit call foi a moment,
you can see that now insteau of piepaiing thousanus
of uistinct SQL statements insiue the loop, we've
piepaieu a single SQL statement outsiue the loop, anu
this statement uses the '?' chaiactei as a placeholuei
foi the values to be inseiteu. 0sing (anu ieusing) a
PreporeJStotement will save 9,999 of the 0PI paise
calls that plagueu the oiiginal S2-seconu piogiam.
Insiue the loop, we now have a setlnt call that binus
the value of i to the fiist (anu only) '?' placeholuei in
the SQL statement, anu then we have an execute0pJote
call to uo the inseition. Since the uefault execute batch
size is now set to 1,uuu, this coue will only make a ieal
0iacle uatabase call (anu the associateu netwoik
iounu-tiip) once foi eveiy 1,uuu calls.
So, with this coue, we've saveu thousanus of netwoik
I0s anu ieuuceu the amount of time the piogiam
spenus paising insiue the uatabase to piactically zeio.
Nagic.
The loq file sync time iepiesents anothei impoitant
peifoimance impiovement oppoitunity.
11
The
iepeateu appeaiance of eithei loq file sync calls oi
XCTEND lines in a tiace file (in oui case, we hau both)
is an inuication of iepeateu uatabase commit
piocessing. Excessive commit piocessing can cieate a
peifoimance pioblem that acceleiates as the amount
of concuiient woikloau incieases (so it's a scalability
pioblem too), anu it even cieates a functional pioblem
as well.

11
In case you'ie wonueiing how you'll figuie out what these
event names mean when you'ie uone ieauing this papei, I
covei that in section 18.
1u 2uu8-2uu9 Nethou R Coipoiation. All iights ieseiveu.
Let's talk about the functional pioblem fiist. Imagine
that you'ie iesponsible foi iunning this 1u,uuu-iow
inseit once a uay. Imagine that it clicks along just fine
foi weeks on enu, but then one uay, pait-way into the
piogiam's execution, youi system housing the 0iacle
uatabase ciashes. It happens.
So when someone gets the 0iacle uatabase iestaiteu,
one of the things you'ie going to have to uo is figuie
out how many of the iows maue it into the uatabase
befoie it ciasheu. In fact, you'ie going to have to figuie
out exactly wbicb iows maue it into the uatabase
befoie it ciasheu, because you'ie going to neeu to
make suie that eithei you uelete those iows so you
can iun youi piogiam again, oi you'ie going to neeu to
figuie out exactly which iows you neeu to inseit so
that all 1u,uuu will be in the uatabase when you'ie
uone. None can be missing, anu none can be
uuplicateu.
If you'ie like most application uevelopeis, you'ie only
going to want to uo this job once. It's not going to be a
lot of fun figuiing out which iows maue it anu which
iows uiun't. If you'ie lucky, theie'll be some kinu of
batch iu oi uate fielu that will allow you to pinpoint
exactly which iows maue it in. Naybe you'll be
tempteu to wiite some kinu of clean-up functions to go
with youi application so that this kinu of scenaiio will
be easiei foi you (oi youi customeis) to ueal with if it
evei happens again.
If you use 0iacle uiffeiently, howevei, you won't have
to uo that.
If, insteau of committing eveiy single iow to the
uatabase as youi application inseits it, you waiteu
until the enu of all 1u,uuu inseitions anu then
committeu the whole tiansaction, youi life woulu be
mucb simplei. Then, if the 0iacle system evei faileu in
the miust of youi job, you'u know: eithei theie aie
1u,uuu new iows in the uatabase (if youi commit call
succeeueu) oi theie aie u new iows in the uatabase (if
youi commit call faileu).
Plus, you'll save a lot of unnecessaiy woik that
consumes a lot of unnecessaiy time. Implementing the
single-commit iuea ieuuceu oui time spent waiting foi
loq file sync events fiom 6.S89 seconus (Exhibit 6) to
u.u4u seconus (Exhibit 7). That's huge. AnJ we
eliminateu ovei six seconus of laboi that otber
piocesses on the system hau to wait behinu, which
makes the whole system fastei foi eveiyone.
The uecision of how often to commit is an impoitant
one. I've shown heie why committing aftei eveiy iow
can be bau. Bowevei, committing only once at the enu
of a multi-million-iow inseit may be bau, too, because
of the stiess upon the 0iacle Batabase unuo
management subsystem, anu because maybe you uon't
want to have to iestait a whole multi-million-iow
tiansaction aftei an instance failuie. Naybe it woulu
be bettei to commit in batches of 1u,uuu iows, oi
maybe even 1u iows. Pait of youi application uesign
iesponsibility is to manage this tiaueoff, which shoulu
incluue the task of using meosurements insteau of
guesses about the costs of commit piocessing.
Section 19.4 shows some of the tiace uata foi an
execution of the new piogiam. Notice that each EXEC
line now piocesses 1,uuu iows (r=1000) insteau of
just one. Anu notice that theie is only one loq file sync
calls now, iight at the enu of the tiace file.
11 AGAIN, MLASUkING IS VI1AL
So, what have you leaineu fiom this papei. It's easy to
stait thinking in absolutes about "best piactices." I'm
suspicious about most so-calleu best piactices because
of Claike's Fouith Law: Foi eveiy expeit, theie is an
equal anu opposite expeit (Wikipeuia 2uu8).
Theie is one "best piactice," though, that I believe in
ueeply:
You shoulu always meosure youi application's
peifoimance anu taiget youi optimization
effoits at places wheie youi coue will benefit
fiom it most.
As you now unueistanu, the way I implement this
piactice in the 0iacle woilu touay is with the extenueu
SQL tiace featuie. Theie aie othei ways to peek into
what the 0iacle keinel is uoing,
12
but no othei way
gives you such a simple sequential listing of exactly
wheie oll of the time has gone foi just the coue path
that you'ie inteiesteu in. If you leain how to use the
extenueu SQL tiace featuie, you'll leain a lot moie
about 0iacle, anu you'll leain exactly what you neeJ to
know, iight when you neeu to leain it.
I think one of the nicest things about 0iacle tiacing
(anu piofiling in geneial) is that it focuses youi
attention wheie it neeus to be iight now. It uoesn't
leave you feeling like you have to know everytbinq
about 0iacle all at once. It's also a featuie that's
available in uevelopment, testing, anu piouuction
enviionments, so it's tiuly a single tool that you can
use thioughout youi entiie softwaie lifecycle.
As a uevelopei, you can make it ieally easy to tiace
youi coue. Ny team have tiieu to make it easy foi

12
0iacle's Active Session Bistoiy (oi ASB) is one name you
might iecognize.
uevelopeis to instiument coue the iight way by
publishing a fiee, open souice instiumentation libiaiy
foi 0iacle calleu (Nethou R Coipoiation 2uu8).
IL0 consists of a couple of 0iacle PLSQL packages
with functions you can call fiom }ava, PBP, oi
whatevei language you'ie wiiting in. If you'ie cuiious
about how goou instiumentation woiks, stuuying the
PLSQL within IL0 is a goou place to stait.
12 SUMMAk
is a vital featuie of goou softwaie. Speeu uoesn't
just happen by acciuent. It is a featuie that you have to
uesign into goou piogiams. Besigning goou
peifoimance into youi coue is extiemely uifficult to uo
without goou feeuback about the speeu of youi coue
as you'ie wiiting it.
Nany 0iacle application uevelopeis woik unuei the
assumption that the 0iacle Batabase keinel is a "black
box" that they shoulun't bothei to unueistanu. But
wiiting coue within the abstiaction mouel that the
0iacle Batabase is meiely a "peisistent uata stoie"
almost assuies that you will wiite coue that is slowei
anu that wastes fai moie piecious computing
iesouices than it shoulu.
The 0iacle extenueu SQL tiace mechanism pioviues
the feeuback that you neeu to wiite fast, efficient coue
foi 0iacle-baseu systems. Extenueu SQL tiacing
ieveals wheie youi time is being spent insiue the
0iacle Batabase keinel, all the way uown to the
inuiviuual uatabase oi opeiating system subioutine
call.
With this papei, I hope I have illuminateu the
following key points foi you:
0iacle extenueu SQL tiace uata shows you exactly
wheie youi coue spenus youi usei's time.
With tiace uata, you can ueteimine whethei youi
coue is efficient.
If youi coue can iun fastei, tiacing shows you why
anu by how much. It allows you to pieuict the
peifoimance impact of changing youi coue,
without so much tiial anu eiioi.
Tiacing pievents you fiom wasting time "tuning"
aspects of youi piogiam that won't iesult in
appieciable iesponse time benefits.
Tiacing pievents the feeling that you have to
know "eveiything about 0iacle" befoie you can
wiite fast, piovably efficient coue.
You can use peifoimance feeuback in youi
piogiams to cieate self-aujusting applications that
auapt to youi softwaie's tiue opeiational
constiaints.
Not eveiy peiceiveu iequiiement is a legitimate
iequiiement. Tiacing allows you to measuie
objectively the peifoimance cost of a featuie,
which in tuin helps the business make bettei
uecisions about which softwaie featuies it tiuly
iequiies.
Knowing how to measuie peifoimance, anu
knowing how to ueteimine whethei the
peifoimance you have obseiveu is optimal aie
moie impoitant than youi being able to
iemembei lists of softwaie peifoimance "best
piactices."
You can make youi application easiei to tune anu
uebug by incoipoiating extenueu SQL tiacing into
youi coue. Iueally, you shoulu iegaiu the ability to
measuie peifoimance at iun-time as an impoitant
functional specification.
I hope this papei encouiages you to instiument youi
coue, gain access to youi 0iacle tiace uata, anu stuuy
it foi some of youi own applications that mean
something to you anu that neeu to be fast.
I haven't coveieu eveiything you neeu to know heie,
of couise. Foi example, I haven't uiscusseu how
connection management coue paths pievent youi
application fiom scaling. I haven't tolu you any uetails
about why excessive paise calls anu excessive visits to
the uatabase buffei cache cause an application not to
scale. But I have shown you enough to get you staiteu
upon a much moie infoimeu path towaiu wiiting
scalable, high-peifoimance 0iacle-baseu applications.
I've also incluueu, in section 18 neai the enu of this
papei, a list of call names that you'll encountei
fiequently as you look thiough tiace files.
With this papei, you'll be able to come a long way in
unueistanuing what youi tiace files aie tiying to tell
you. If you'ie inteiesteu in stuuying 0iacle tiace files
in moie uetail, then I hope you will have a look at
(Nillsap anu Bolt, 0ptimizing 0iacle Peifoimance
2uuS), wheie }eff Bolt anu I have wiitten about the
subject in uepth.
13 ACkNCWLLDGMLN1S
Thank you to Baiolu Palacio foi wiiting anu testing
the }ava coue useu in my examples, anu to Kaien
Noiton, Lauia Nogaj, Naik Sweeney, Ron Ciisco, anu
}eff Bolt foi ieviewing my woik. I am inuebteu to Ken
Feilita anu eveiyone else at Nethou R foi theii iueas,
ieseaich, encouiagement, anu manifest contiibutions
that make it possible foi me to wiite in the fiist place.
To uiaw the 0NL sequence uiagiam shown in
Exhibit 1, I useu the nifty tool at
bttp:,,www.websequenceJioqroms.com,.
14 8I8LICGkAn
Ciawfoiu, William, }im Failey, anu Baviu Flanagan. An
lntroJuction to }BBC, Port S. 2uuS.
http:www.onjava.compubaonjavaexceiptjavae
ntnut_2inuexS.html (accesseu 12 24, 2uu8).
Nethou R Coipoiation. lnstrumentotion librory for
0rocle {ll0). 2uu8.
http:souicefoige.netpiojectshotsos-ilo.
Nillsap, Caiy. 'Sl*Net messoqe to client' isn't wbot you
miqbt tbink it is. Nov 28, 2uuS.
https:poital.hotsos.comnewsletteisvolume-i-
issue-2tipssql-net-message-to-client-isn2u19t-
what-you-might-think-it-is.
Nillsap, Caiy, anu }eff Bolt. 0ptimizinq 0rocle
Performonce. Sebastopol, CA: 0'Reilly, 2uuS.
Nigaaiu, Nogens, et al. 0rocle lnsiqbts: Toles of tbe
0ok Toble. Beikeley, CA: Apiess, 2uu4.
0iacle Coipoiation. Hy 0rocle Support.
https:metalink.oiacle.comCSPuiinuex.html.
. "0iacle Call Inteiface Piogiammei's uuiue." 0rocle
Corporotion. 2uu8.
http:uownloau.oiacle.comuocscuB28SS9_u1ap
puev.111b28S9Stoc.htm.
Wikipeuia. Clorke's tbree lows. Bec 17, 2uu8.
http:en.wikipeuia.oigwikiClaike%27s_thiee_laws.
. RoJium. Bec 18, 2uu8.
http:en.wikipeuia.oigwikiRauium.

1S A8CU1 1nL AU1nCk
Caiy Nillsap is well-known in the global 0iacle
community as a speakei, euucatoi, consultant, anu
wiitei. Be is the founuei anu piesiuent of Nethou R
Coipoiation (bttp:,,metboJ-r.com), a small company
uevoteu to genuinely satisfying softwaie peifoimance.
Nethou R offeis consulting seivices, euucation
couises, anu softwaie toolsincluuing the Nethou R
Piofileithat help you optimize youi softwaie
peifoimance.
Caiy is the authoi (with }eff Bolt) of 0ptimizinq 0rocle
Performonce (0'Reilly), foi which he anu }eff weie
nameu 0rocle Hoqozine's 2uu4 Authois of the Yeai. Be
is also a contiibutoi to 0rocle lnsiqbts: Toles of tbe 0ok
Toble (Apiess). Be is the foimei vice Piesiuent of
0iacle Coipoiation's System Peifoimance uioup, anu
a co-founuei of Botsos. Caiy is also an 0iacle ACE
Biiectoi anu a founuing paitnei of the 0ak Table
Netwoik, an infoimal association of "0iacle scientists"
that aie well known thioughout the 0iacle
community. Caiy blogs at
bttp:,,corymillsop.bloqspot.com.
16 kLVISICN nIS1Ck
2uu9u2u9: Auueu footnote 4. Thank you, Nichael
Thomas foi pointing out this omission.

2uu8-2uu9 Nethou R Coipoiation. All iights ieseiveu. 1S
17 ALNDIk: CkLA1ING AND IINDING
CkACLL 1kACL IILLS
This section uesciibes how to cieate anu finu youi
own 0iacle extenueu SQL tiace files.
17.1 1urn|ng the 1race Cn and Cff
You can tuin tiacing on oi off by executing an 0iacle
function call fiom youi application. Foi 0iacle
Batabase 1u
g
anu beyonu, you can tuin tiacing on anu
off with calls to functions in the stanuaiu 0iacle
package calleu Jbms_monitor:
dbms_monitor.session_trace_enable(null,null,true,true)
dbms_monitor.session_trace_disable(null,null)
Theie aie othei ways to uo it, too, but this one is
simple anu secuie. It will iequiie the peison acting as
youi uatabase auministiatoi to giant you peimission
to execute the Jbms_monitor package.
If you'ie using an 0iacle Batabase veision piioi to 1u
g
,
then ask youi uatabase auministiatoi to install the
0iacle package calleu Jbms_support. Theie aie
instiuctions about how to uo it at the Ny 0iacle
Suppoit web site (0iacle Coipoiation n.u.).
17.2 I|nd|ng our 1race I||e
When you've tiaceu youi coue, you'll neeu to finu youi
tiace file. The piocess iunning youi 0iacle keinel coue
wiites youi tiace files to the opeiating system
uiiectoiy nameu by an 0iacle instance paiametei. In
0iacle veision 11, the 0iacle keinel will wiite youi
tiace files into the "Biag Tiace" uiiectoiy, which you
can iuentify by using the following SQL statement:
select * from v$diag_info where name='Diag Trace'
In oluei veisions of 0iacle, you can iuentify youi tiace
file uiiectoiy by using this SQL statement:
select * from v$parameter where name in
('user_dump_dest','background_dump_dest')
The user_Jump_Jest uiiectoiy is wheie most of youi
tiace files aie piobably going to show up. If you use
0iacle paiallel execution featuies, then you'll finu
some of youi tiace uata in the bockqrounJ_Jump_Jest
uiiectoiy.
Biffeient poits of 0iacle use uiffeient naming
conventions foi tiace files. Youi tiace file names will
piobably look something like one of the following:
xe_oro_10840.trc
proJ7_2SS89_oro.trc
oro_1492_Jelto1.trc
0RA0121S.trc
fin1_oro_11297_P0STlN6.trc
HFRK0R_S7_I6_0RAClF_01S.trc
Tiace files may look uiffeient on uiffeient platfoims
anu uiffeient veisions of 0iacle, but you can count on
youi tiace file names containing some oi all of the
following elements:
The stiing ora;
Youi 0iacle instance name;
Youi 0iacle keinel piocess iu (on Niciosoft
Winuows, it will be youi piocess's thieau iu);
If you set a trocefile_iJentifier in youi 0iacle
session, then the stiing value of that paiametei;
anu
The suffix .trc.
If you'ie wiiting coue that will connect to an 0iacle
instance that someone else manages, you'll neeu to
cooiuinate with that peison to get peimissions to ieau
youi tiace files.
1S
Without access to youi tiace files,
optimizing the coue you wiite is going to be a lot moie
expensive foi youi company.
18 ALNDIk: 1nL IMCk1AN1 CCDL A1nS
You can leain a lot in a ten-minute session looking at
0iacle tiace uata, but what happens when you see a
call name that you uon't unueistanu. This section
contains some veiy biief staitei auvice that will guiue
you thiough the most common coue paths that you'll
see uesciibeu in youi tiace files.
Foi calls not listeu heie, the best online souices aie
piobably uoogle anu oiacle.com (in that oiuei).
Bowevei, you'll leain moie ieliably by leaining to use
a tool like Btroce oi stroce (oi truss, sctroce, tusc,
.whatevei 0S call tiacing tool youi platfoim gives
you) to see what 0S call each 0iacle call name maps to.
0nce you'ie to that point, it's easy: theie is lots of
ieliable uocumentation foi 0S calls available all ovei
the place, all the way uown to the souice coue level foi
many opeiating systems.
Beie aie some 0iacle keinel coue paths you'ie going
to be seeing ovei anu ovei again:
FXFC
If youi execution has a queiy component, see the
IFTCE entiy. If you aie executing a PLSQL
package with no ieal time consuming SQL
statements within it, then use the 0iacle

1S
Nethou R Coipoiation sells an extension foi 0iacle SQL
Bevelopei that automates the piocess of acquiiing 0iacle
tiace files foi application uevelopeis.
Jbms_profiler package to iuentify which lines of
PLSQL aie costing you the most time.
IFTCE
Bon't visit the buffei cache (the value cr + cu fiom
youi 0iacle extenueu SQL tiace uata) moie than
1u times pei iow ietuineu pei uata souice. Foi
example, a 4-table join that ietuins S iows shoulu
have cr + cu < 12u.
PARSF
A goou application nevei paises (that is, prepores)
a given SQL statement moie than once pei session.
A qreot application nevei paises a given SQL
statement moie than once pei 0iacle instance
staitup. Paising too often pievents an application
fiom scaling to laige usei counts, no mattei how
many CP0s youi system might happen to have. It's
because paising is a softwaie-seiializeu opeiation.
buffer busy woits
Bappens to youi piogiam when it tiies to change
an in-memoiy block in the uatabase buffei cache,
but some othei piocess is in the miust of
mouifying that buffei. Fix the pioblem by woiking
with youi uatabase auministiatoi to make the
most competeu-foi uatabase blocks less
inteiesting to so many concuiient 0iacle sessions.
Jb file scottereJ reoJ
Inuicates a ieau of two oi moie 0iacle blocks in a
single reoJv 0S call. Conventional auvice instiucts
youi uatabase auministiatoi to make the uatabase
buffei cache biggei when he sees lots of this kinu
of 0S call. Bettei auvice is to wiite moie efficient
queiies that follow the iule-of-ten auvice
explaineu in the IFTCE section.
Jb file sequentiol reoJ
Noimally inuicates the ieau of a single 0iacle
block with a preoJ 0S call. If you can eliminate
unnecessaiy buffei cache visits as uiiecteu in the
IFTCE section, you'll natuially eliminate Jb file
sequentiol reoJ calls as well.
enqueue
Inuicates that youi coue is tiying to change a iow
that anothei 0iacle session has lockeu. If you
wiote the piogiam that's holuing the lock, then
iewiite it to holu the lock foi a smallei total
uuiation. Foi example, uon't allow any enu-usei
uata entiy oppoitunities to occui between an
insert, upJote, Jelete, oi merqe SQL statement anu
its subsequent commit. If you uiun't wiite the coue
that's holuing the lock, then finu out who uiu.
lotcb* (call names with the woiu lotcb in them)
You'll see sboreJ pool oi librory cocbe latch waits
(maybe both of them) when you wiite coue that
makes too many paise calls. You'll see cocbe
buffers cboins oi cocbe buffers lru cboin latch waits
when you wiite inefficient SQL that visits the
uatabase buffei cache too many times. Bon't uo
those things.
Note that in 0iacle veision 1u anu beyonu, the
names of many latch-ielateu 0S calls each
contains the name of the latch, as in lotcb: cocbe
buffers cboins. Piioi to veision 1u, all latch-ielateu
0S calls weie iecoiueu unuei the call name lotcb
free, anu the type of the latch was listeu as the
value of the p2 fielu in the WAIT line.
loq file sync
Inuicates commit call piocessing, which you can
easily abuse when, foi example, you wiite
applications that use auto-commit.
Sl*Net messoqe from client
Inuicates a netwoik iounu-tiip. Bon't make
unnecessaiy netwoik iounu-tiips. See the PARSF
section foi how to eliminate unnecessaiy paise
calls anu the associateu iounu-tiips. It's almost
nevei a goou iuea to wiite applications that
piocess only one uatabase iow at a time.
If you'ie sloppy in how you collect youi tiace uata
foi inteiactive applications, then some of the time
incluueu in youi Sl*Net messoqe from client
uuiations will be time that the enu usei spenus
iegaiuing the uata just piesenteu to him. This is a
false negative peifoimance inuicatoi that you
shoulu fix by being moie caieful about how you
collect youi tiace uata. Scope youi tiace uata
collecting to incluue only the time that youi enu
usei is waiting on the application to peifoim some
opeiation.
Sl*Net more Joto to client
This is what you'll see when you ciank up youi
aiiay fetch size foi piogiams that select a lot of
iows. It's like a Sl*Net messoqe to client, except
it's in the context of a single uata tiansfei that's
alieauy in piogiess.
unoccounteJ-for
If you use a commeicial piofiling tool like the
Nethou R Piofilei (also solu as the Botsos
Piofilei), the piesence of unoccounteJ-for time
almost always inuicates time that youi piocess
has spent pieempteu by the opeiating system. Fix
it by making youi piogiam (anu the piogiams it
competes against foi CP0 time) use as little CP0 as
possible. Eliminate unnecessaiy paise calls, anu
ensuie that youi SQL visits the uatabase buffei
cache as little as possible.
2uu8 Nethou R Coipoiation. All iights ieseiveu.
1S
19 ALNDIk: 1kACL IILLS
This section contains exceipts fiom the iaw 0iacle extenueu SQL tiace uata iefeienceu in this papei.
19.1 S|ow uery
The following tiace file exceipt shows tiace uata foi the 2S.4uS-seconu queiy piogiam.
1. /usr/lib/oracle/xe/app/oracle/admin/XE/udump/xe_ora_9024_METHODR_TESTING_.trc
2. Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
S. ORACLE_HOME = /usr/lib/oracle/xe/app/oracle/product/10.2.0/server
4. System name: Linux
S. Node name: oracle01.dev.method-r.com
6. Release: 2.6.25.6-27.fc8
7. Version: #1 SMP Fri Jun 13 16:38:52 EDT 2008
8. Machine: i686
9. Instance name: XE
1u. Redo thread mounted by this instance: 1
11. Oracle process number: 18
12. Unix process pid: 9024, image: oracleXE@oracle01.dev.method-r.com
1S.
14. *** SERVICE NAME:(SYS$USERS) 2008-11-25 11:12:29.682
1S. *** SESSION ID:(26.22686) 2008-11-25 11:12:29.682
16. =====================
17. PARSING IN CURSOR #2 len=69 dep=0 uid=55 oct=42 lid=55 tim=1198860497736569 hv=3164292706 ad='30e088a4'
18. alter session set events '10046 trace name context forever, level 12'
19. END OF STMT
2u. EXEC #2:c=1000,e=91,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1198860497736561
22. WAIT #2: nam='SQL*Net message to client' ela= 2 driver id=1952673792 #bytes=1 p3=0 obj#=-1 tim=1198860497737042
2S. WAIT #2: nam='SQL*Net message from client' ela= 985 driver id=1952673792 #bytes=1 p3=0 obj#=-1 tim=1198860497738097
24. =====================
2S. PARSING IN CURSOR #1 len=21 dep=0 uid=55 oct=3 lid=55 tim=1198860497738418 hv=3808180571 ad='2d45e9d0'
27. END OF STMT
28. PARSE #1:c=0,e=251,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1198860497738414
29. BINDS #1:
Su. EXEC #1:c=0,e=84,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1198860497738645
S1. WAIT #1: nam='SQL*Net message to client' ela= 2 driver id=1952673792 #bytes=1 p3=0 obj#=-1 tim=1198860497738727
S2. WAIT #1: nam='SQL*Net message from client' ela= 25227 driver id=1952673792 #bytes=1 p3=0 obj#=-1 tim=1198860497764024
SS. WAIT #1: nam='SQL*Net message to client' ela= 24 driver id=1952673792 #bytes=1 p3=0 obj#=-1 tim=1198860497764438
S4. FETCH #1:c=0,e=355,p=0,cr=4,cu=0,mis=0,r=10,dep=0,og=1,tim=1198860497764514
SS. WAIT #1: nam='SQL*Net message from client' ela= 7851 driver id=1952673792 #bytes=1 p3=0 obj#=-1 tim=1198860497772417
S7. FETCH #1:c=0,e=84,p=0,cr=1,cu=0,mis=0,r=10,dep=0,og=1,tim=1198860497772568
4u. FETCH #1:c=0,e=81,p=0,cr=1,cu=0,mis=0,r=10,dep=0,og=1,tim=1198860497774051
41. WAIT #1: nam='SQL*Net message from client' ela= 1282 driver id=1952673792 #bytes=1 p3=0 obj#=-1 tim=1198860497775378
(42,746 lines heie aie not shown)
4S. FETCH #1:c=0,e=86,p=0,cr=1,cu=0,mis=0,r=7,dep=0,og=1,tim=1198860521138298
19.2 Improved uery
The following tiace file exceipt shows tiace uata foi the impioveu 2.4uu-seconu inseit piogiam.
1. /usr/lib/oracle/xe/app/oracle/admin/XE/udump/xe_ora_28638_QUERY_2048.trc
6. Release: 2.6.25.6-27.fc8
8. Machine: i686
1S.
1S. *** SESSION ID:(26.27749) 2008-12-10 09:51:02.061
16. =====================
17. PARSING IN CURSOR #2 len=69 dep=0 uid=55 oct=42 lid=55 tim=1200121349669845 hv=3164292706 ad='30d22bc0'
19. END OF STMT
24. =====================
2S. PARSING IN CURSOR #1 len=21 dep=0 uid=55 oct=3 lid=55 tim=1200121349671182 hv=3808180571 ad='2d7dd08c'
27. END OF STMT
29. BINDS #1:
SS. WAIT #1: nam='SQL*Net message to client' ela= 6 driver id=1952673792 #bytes=1 p3=0 obj#=-1 tim=1200121349677583
S4. WAIT #1: nam='SQL*Net more data to client' ela= 149 driver id=1952673792 #bytes=2001 p3=0 obj#=-1 tim=1200121349677942
SS. WAIT #1: nam='SQL*Net more data to client' ela= 7 driver id=1952673792 #bytes=2002 p3=0 obj#=-1 tim=1200121349678167
4u. WAIT #1: nam='SQL*Net more data to client' ela= 7 driver id=1952673792 #bytes=2000 p3=0 obj#=-1 tim=1200121349679641
41. WAIT #1: nam='SQL*Net more data to client' ela= 3402 driver id=1952673792 #bytes=2002 p3=0 obj#=-1 tim=1200121349683312
4S. WAIT #1: nam='SQL*Net more data to client' ela= 121 driver id=1952673792 #bytes=2002 p3=0 obj#=-1 tim=1200121349684161
Su. WAIT #1: nam='SQL*Net more data to client' ela= 7 driver id=1952673792 #bytes=2001 p3=0 obj#=-1 tim=1200121349686943
6u. WAIT #1: nam='SQL*Net more data to client' ela= 8 driver id=1952673792 #bytes=1997 p3=0 obj#=-1 tim=1200121349691851
69. FETCH #1:c=11998,e=22206,p=0,cr=16,cu=0,mis=0,r=2048,dep=0,og=1,tim=1200121349699630
(2,8S9 lines heie aie not shown)
7u. FETCH #1:c=6999,e=6837,p=0,cr=16,cu=0,mis=0,r=1205,dep=0,og=1,tim=1200121352051111
19.3 S|ow Insert
The following tiace file exceipt shows tiace uata foi the slow S2.7u6-seconu inseit piogiam.
1. /usr/lib/oracle/xe/app/oracle/admin/XE/udump/xe_ora_9835_METHODR_TESTING_.trc
6. Release: 2.6.25.6-27.fc8
8. Machine: i686
2uu8 Nethou R Coipoiation. All iights ieseiveu.
17
1S.
1S. *** SESSION ID:(24.25822) 2008-11-25 11:39:16.895
16. =====================
17. PARSING IN CURSOR #3 len=69 dep=0 uid=55 oct=42 lid=55 tim=1198862067281227 hv=3164292706 ad='30e088a4'
19. END OF STMT
24. =====================
2S. PARSING IN CURSOR #2 len=40 dep=0 uid=55 oct=2 lid=55 tim=1198862067286178 hv=223277221 ad='30d87524'
27. END OF STMT
29. BINDS #2:
S4. =====================
SS. PARSING IN CURSOR #2 len=40 dep=0 uid=55 oct=2 lid=55 tim=1198862067289787 hv=1228865179 ad='2d6c3ea4'
S6. insert into JAVA_TEST_TABLE values ('1')
S7. END OF STMT
S8. PARSE #2:c=0,e=302,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=1198862067289781
S9. BINDS #2:
42. WAIT #2: nam='log file sync' ela= 113 buffer#=737 p2=0 p3=0 obj#=-1 tim=1198862067290479
4S. WAIT #2: nam='SQL*Net message to client' ela= 2 driver id=1952673792 #bytes=1 p3=0 obj#=-1 tim=1198862067290546
4S. =====================
46. PARSING IN CURSOR #2 len=40 dep=0 uid=55 oct=2 lid=55 tim=1198862067292826 hv=2978669578 ad='2d75ac84'
48. END OF STMT
Su. BINDS #2:
S1. EXEC #2:c=0,e=146,p=0,cr=1,cu=4,mis=0,r=1,dep=0,og=1,tim=1198862067293093
SS. WAIT #2: nam='log file sync' ela= 107 buffer#=739 p2=0 p3=0 obj#=-1 tim=1198862067293425
(1u6,S1S lines heie aie not shown)
19.4 Improved Insert
The following tiace file exceipt shows tiace uata foi the impioveu u.1S4-seconu inseit piogiam.
1. /usr/lib/oracle/xe/app/oracle/admin/XE/udump/xe_ora_3807_INSERT_TEST.trc
6. Release: 2.6.25.6-27.fc8
8. Machine: i686
1S.
1S. *** SESSION ID:(24.34335) 2008-12-22 16:37:52.283
16. =====================
17. PARSING IN CURSOR #2 len=69 dep=0 uid=55 oct=42 lid=55 tim=1201157687776660 hv=3164292706 ad='28e47760'
19. END OF STMT
24. =====================
2S. PARSING IN CURSOR #1 len=39 dep=0 uid=55 oct=2 lid=55 tim=1201157687837622 hv=2094431222 ad='28f82278'
26. Insert into JAVA_TEST_TABLE values (:1)
27. END OF STMT
29. BINDS #1:
Su. kkscoacd
S1. Bind#0
S2. oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
SS. oacflg=03 fl2=1000000 frm=01 csi=178 siz=24 off=0
S4. kxsbbbfp=b7f27e2c bln=22 avl=01 flg=05
SS. value=0
S6. WAIT #1: nam='SQL*Net more data from client' ela= 27 driver id=1952673792 #bytes=3 p3=0 obj#=-1 tim=1201157687844067
S7. WAIT #1: nam='SQL*Net more data from client' ela= 11 driver id=1952673792 #bytes=1 p3=0 obj#=-1 tim=1201157687844425
4u. WAIT #1: nam='SQL*Net message from client' ela= 4885 driver id=1952673792 #bytes=1 p3=0 obj#=-1 tim=1201157687850661
41. BINDS #1:
42. kkscoacd
4S. Bind#0
44. oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
4S. oacflg=03 fl2=1000000 frm=01 csi=178 siz=24 off=0
46. kxsbbbfp=b7f27e2c bln=22 avl=02 flg=05
47. value=1000
48. WAIT #1: nam='SQL*Net more data from client' ela= 17 driver id=1952673792 #bytes=1 p3=0 obj#=-1 tim=1201157687851385
(8S lines heie aie not shown)
S4. BINDS #1:
SS. kkscoacd
S6. Bind#0
S7. oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
S8. oacflg=03 fl2=1000000 frm=01 csi=178 siz=24 off=0
S9. kxsbbbfp=b7f27e2c bln=22 avl=02 flg=05
6u. value=9000
6S. EXEC #1:c=1000,e=1539,p=0,cr=118,cu=153,mis=0,r=1000,dep=0,og=1,tim=1201157687885866
67. WAIT #0: nam='log file sync' ela= 39869 buffer#=376 p2=0 p3=0 obj#=-1 tim=1201157687927436
7u. XCTEND rlbk=0, rd_only=1

Making Friends With Oracle

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Making Friends With Oracle

Încărcat de

Drepturi de autor:

Formate disponibile

2uu8-2uu9 Nethou R Coipoiation. All iights ieseiveu.

S-ar putea să vă placă și