Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

14
CHAPTER 1 ■ DEVELOPING SUCCESSFUL ORACLE APPLICATIONS
LATCH.child cursor hash table 35 80,023 79,988
LATCH.shared pool 50,455 162,577 112,122
LATCH.library cache 110,524 250,510 139,986
Run1 latches total versus runs -- difference and pct
Run1 Run2 Diff Pct
407,973 889,287 481,314 45.88%
PL/SQL procedure successfully completed.
■Note It is to be expected that you see somewhat different values in your testing. I would be surprised if
you got exactly the same values for all numbers, especially the latching numbers. You should, however, see
similar numbers, assuming you are using Oracle9i Release 2 on Linux, as I was here. In all releases, I would
expect the number of latches used to hard parse to be higher than those for soft parsing each insert, or
parsing the insert once and executing it over and over. Running the preceding test in Oracle 10g Release 1
on the same machine produced results such that the elapsed time of the bind variable approach was onetenth
of the non–bind variable approach, and the amount of latches taken was 17 percent. This was due to
two factors, one being that 10g is a new release and some internal algorithms changed. The other was due
to an improved way dynamic SQL is processed in PL/SQL in 10g.
You can see that there were only four hard parses with the bind variable approach, but
over 10,000 hard parses without bind variables (once for each of the inserts). But that is just
the tip of the iceberg. You can see here that twice as many “latches” were used in the non–bind
variable approach than when using bind variables. This is because in order to modify this
shared structure, Oracle must take care to allow only one process in at a time (it is very bad if
two processes or threads attempt to update the same in-memory data structure simultaneously—corruption
would abound). So, Oracle employs a latching mechanism, a lightweight
locking device, to serialize access. Don’t be fooled by the word “lightweight”—these are serialization
devices, allowing one-at-a-time, short duration access to a data structure. The latches
overused by the hard-parsing implementation are among the most used latches out there. The
latch into the shared pool and the latch for the library cache are big-time latches; they’re the
ones that people compete for frequently. What that means is that as we increase the number
of users attempting to hard-parse statements simultaneously, our performance problem will
get progressively worse over time. The more people parsing, the more people fighting for the
right to latch the shared pool, the longer the queues, the longer the wait.
■Note In 9i and above on machines with more than one processor, the shared pool may be divided into
multiple subpools, each protected by its own latch. This permits increased scalability for applications that do
not use bind variables, but it does not make the latching problem go away by any means.