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

434
CHAPTER 11 ■ INDEXES
Table 11-2. Performance Test for Use of Reverse Key Indexes with PL/SQL and Pro*C: Two Users
Reverse No Reverse Reverse No Reverse
PL/SQL PL/SQL Pro*C Pro*C
Transaction/second 46.59 49.03 20.07 20.29
CPU time (seconds) 77 73 104 101
Buffer busy waits number/time 4,267/2 133,644/2 3,286/0 23,688/1
Elapsed time (minutes) 0.68 0.65 1.58 1.57
Log file sync number/time 19/0 18/0 3,273/29 2,132/29
As you can see from this two-user test, PL/SQL still outperforms Pro*C, but the use of the
reverse key index is showing some positive benefits on the PL/SQL side and not so much on
the Pro*C side. That too is a trend that will continue. The reverse key index is solving the buffer
busy wait problem we have due to the contention for the rightmost block in the index structure;
however, it does nothing for the log file sync waits that affect the Pro*C program. This was the
main reason for performing both a PL/SQL and a Pro*C test: to see the differences between
these two environments. This begs the question, why would a reverse key index apparently
benefit PL/SQL but not Pro*C in this case? It comes down to the log file sync wait event.
PL/SQL was able to continuously insert and rarely had to wait for the log file sync wait event
upon commit, whereas Pro*C was waiting every 100 rows. Therefore, PL/SQL in this case was
impacted more heavily by buffer busy waits than Pro*C was. Alleviating the buffer busy waits
in the PL/SQL case allowed it to process more transactions, and so the reverse key index positively
benefited PL/SQL. But in the Pro*C case, the buffer busy waits were not the issue—they
were not the major performance bottleneck, so removing the waits had no impact on overall
performance.
Let’s move on to the five-user test, shown in Table 11-3.
Table 11-3. Performance Test for Use of Reverse Key Indexes with PL/SQL and Pro*C: Five Users
Reverse No Reverse Reverse No Reverse
PL/SQL PL/SQL Pro*C Pro*C
Transaction/second 43.84 39.78 19.22 18.15
CPU time (seconds) 389 395 561 588
Buffer busy waits number/time 19,259/45 221,353/153 19,118/9 157,967/56
Elapsed time (minutes) 1.82 2.00 4.13 4.38
Log file sync number/time 691/14 6,655/73 5,391/82
We see more of the same. PL/SQL, running full steam ahead with few log file sync waits,
was very much impacted by the buffer busy waits. With a conventional index and all five users
attempting to insert into the right-hand side of the index structure, PL/SQL suffered the most
from the buffer busy waits and, therefore, benefited the most when they were reduced.
Now, taking a look at the ten-user test in Table 11-4, we can see the trend continues.