05.11.2015 Views

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

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

CHAPTER 11 ■ INDEXES 435<br />

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

Reverse No Reverse Reverse No Reverse<br />

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

Transaction/second 45.90 35.38 17.88 16.05<br />

CPU time (seconds) 781 789 1,256 1,384<br />

Buffer busy waits number/time 26,846/279 456,231/1,382 25,871/134 364,556/1,702<br />

Elapsed time (minutes) 3.47 4.50 8.90 9.92<br />

Log file sync number/time 2,602/72 11,032/196 12,653/141<br />

PL/SQL, in the absence of the log file sync wait, is very much helped by removing the<br />

buffer busy wait events. Pro*C is experiencing more buffer busy wait contention now but, due<br />

to the fact it is waiting on log file sync events frequently, is not benefiting. One way to improve<br />

the performance of the PL/SQL implementation with a regular index would be to introduce a<br />

small wait. That would reduce the contention on the right-h<strong>and</strong> side of the index <strong>and</strong> increase<br />

overall performance. For space reasons, I will not include the 15- <strong>and</strong> 20-user tests here, but I<br />

will confirm that the trend observed in this section continued.<br />

We can take away two things from this demonstration. A reverse key index can help alleviate<br />

a buffer busy wait situation, but depending on other factors you will get varying returns on<br />

investment. In looking at Table 11-4 for the ten-user test, the removal of buffer busy waits (the<br />

most waited for wait event in that case) affected transaction throughput marginally, but it did<br />

show increased scalability with higher concurrency levels. Doing the same thing for PL/SQL<br />

had a markedly different impact on performance: we achieved a measurable increase in<br />

throughput by removing that bottleneck.<br />

Descending Indexes<br />

Descending indexes were introduced in <strong>Oracle</strong>8i to extend the functionality of a B*Tree index.<br />

They allow for a column to be stored sorted in descending order (from big to small) in the<br />

index instead of ascending order (from small to big). Prior releases of <strong>Oracle</strong>, pre-<strong>Oracle</strong>8i,<br />

always supported the DESC (descending) keyword syntactically, but basically ignored it—it had<br />

no effect on how the data was stored or used in the index. In <strong>Oracle</strong>8i <strong>and</strong> above, however, the<br />

DESC keyword changes the way the index is created <strong>and</strong> used.<br />

<strong>Oracle</strong> has had the ability to read an index backward for quite a while, so you may be<br />

wondering why this feature is relevant. For example, if we use the table T from earlier <strong>and</strong><br />

query it as follows:<br />

ops$tkyte@ORA10G> set autotrace traceonly explain<br />

ops$tkyte@ORA10G> select owner, object_type<br />

2 from t<br />

3 where owner between 'T' <strong>and</strong> 'Z'<br />

4 <strong>and</strong> object_type is not null<br />

5 order by owner DESC, object_type DESC;<br />

Execution Plan<br />

----------------------------------------------------------<br />

0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=82 Card=11395 Bytes=170925)

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

Saved successfully!

Ooh no, something went wrong!