05.11.2015 Views

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

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

CHAPTER 11 ■ INDEXES 433<br />

if ( (++cnt%100) == 0 )<br />

{<br />

exec sql commit;<br />

}<br />

}<br />

exec sql whenever notfound continue;<br />

exec sql commit;<br />

exec sql close c;<br />

The Pro*C was precompiled with a PREFETCH of 100, making this C code analogous to the<br />

PL/SQL code in <strong>Oracle</strong> 10g.<br />

■Note In <strong>Oracle</strong> 10g Release 1 <strong>and</strong> above, a simple FOR X IN ( SELECT * FROM T ) in PL/SQL will<br />

silently array fetch 100 rows at a time, whereas in <strong>Oracle</strong>9i <strong>and</strong> before, it fetches just a single row at a time.<br />

Therefore, if you want to reproduce this example on <strong>Oracle</strong>9i <strong>and</strong> before, you will need to modify the PL/SQL<br />

code to also array fetch with the BULK COLLECT syntax.<br />

Both would fetch 100 rows at a time <strong>and</strong> then single row insert the data into another table.<br />

The following tables summarize the differences between the various runs, starting with the<br />

single user test in Table 11-1.<br />

Table 11-1. Performance Test for Use of Reverse Key Indexes with PL/SQL <strong>and</strong> Pro*C: Single User<br />

Reverse No Reverse Reverse No Reverse<br />

PL/SQL PL/SQL Pro*C Pro*C<br />

Transaction/second 38.24 43.45 17.35 19.08<br />

CPU time (seconds) 25 22 33 31<br />

Buffer busy waits number/time 0/0 0/0 0/0 0/0<br />

Elapsed time (minutes) 0.42 0.37 0.92 0.83<br />

Log file sync number/time 6/0 1,940/7 1,940/7<br />

From the first single-user test, we can see that PL/SQL was measurably more efficient<br />

than Pro*C in performing this operation, a trend we’ll continue to see as we scale up the user<br />

load. Part of the reason Pro*C won’t scale as well as PL/SQL will be the log file sync waits that<br />

Pro*C must wait for, but which PL/SQL has an optimization to avoid.<br />

It would appear from this single-user test that reverse key indexes consume more CPU.<br />

This makes sense because the database must perform extra work as it carefully reverses the<br />

bytes in the key. But, we’ll see that this logic won’t hold true as we scale up the users. As we<br />

introduce contention, the overhead of the reverse key index will completely disappear. In fact,<br />

even by the time we get the two-user test, the overhead is mostly offset by the contention on<br />

the right-h<strong>and</strong> side of the index, as shown in Table 11-2.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!