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

346
CHAPTER 10 ■ DATABASE TABLES
buffer busy waits 76,538 24 14.94
log file parallel write 722 14 8.45
latch: cache buffers chains 144 1 .63
enq: HW - contention 678 1 .46
What you want to do for a table is try to determine the maximum number of concurrent
(truly concurrent) inserts or updates that will require more space. What I mean by “truly concurrent”
is how often you expect two people at exactly the same instant to request a free block
for that table. This is not a measure of overlapping transactions; it is a measure of how many
sessions are doing inserts at the same time, regardless of transaction boundaries. You want to
have about as many freelists as concurrent inserts into the table to increase concurrency.
You should just set freelists really high and then not worry about it, right? Wrong—of
course, that would be too easy. When you use multiple freelists, there is a master freelist and
process freelists. If a segment has a single freelist, then the master and process freelists are
one and the same thing. If you have two freelists, you’ll really have one master freelist and two
process freelists. A given session will be assigned to a single process freelist based on a hash of
its session ID. Now, each process freelist will have very few blocks on it—the remaining free
blocks are on the master freelist. As a process freelist is used, it will pull a few blocks from the
master freelist as needed. If the master freelist cannot satisfy the space requirement, then
Oracle will advance the HWM and add empty blocks to the master freelist. So, over time, the
master freelist will fan out its storage over the many process freelists (again, each of which has
only a few blocks on it). So, each process will use a single process freelist. It will not go from
process freelist to process freelist to find space. This means that if you have ten process freelists
on a table, and the one your process is using exhausts the free buffers on its list, it will
not go to another process freelist for space—even if the other nine process freelists have five
blocks each (45 blocks in total), it will go to the master freelist. Assuming the master freelist
cannot satisfy the request for a free block, it would cause the table to advance the HWM or, if
the table’s HWM cannot be advanced (all the space is used), to extend (to get another extent).
It will then continue to use the space on its freelist only (which is no longer empty). There is
a tradeoff to be made with multiple freelists. On one hand, use of multiple freelists is a huge
performance booster. On the other hand, it will probably cause the table to use slightly more
disk space than absolutely necessary. You will have to decide which is less bothersome in your
environment.
Do not underestimate the usefulness of the FREELISTS parameter, especially since you
can alter it up and down at will with Oracle 8.1.6 and later. What you might do is alter it to a
large number to perform some load of data in parallel with the conventional path mode of
SQL*Loader. You will achieve a high degree of concurrency for the load with minimum waits.
After the load, you can reduce the value to some more reasonable, day-to-day number. The
blocks on the many existing freelists will be merged into the one master freelist when you alter
the space down.
Another way to solve the previously mentioned issue of buffer busy waits is to use an
ASSM managed tablespace. If you take the preceding example and create the table T in
an ASSM managed tablespace as follows: