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 429<br />

we ended up adding 4 bytes to every single index key entry <strong>and</strong> factoring out no repeating<br />

data. The OPT_CMPR_COUNT column in IDX_STATS is dead accurate at providing the best compression<br />

count to be used, <strong>and</strong> OPT_CMPR_PCTSAVE will tell you exactly how much savings to<br />

expect.<br />

Now, you do not get this compression for free. The compressed index structure is now<br />

more complex than it used to be. <strong>Oracle</strong> will spend more time processing the data in this<br />

structure, both while maintaining the index during modifications <strong>and</strong> when you search the<br />

index during a query. What we are doing here is trading off increased CPU time for reduced<br />

I/O time. With compression, our block buffer cache will be able to hold more index entries<br />

than before, our cache-hit ratio might go up, <strong>and</strong> our physical I/Os should go down, but it will<br />

take a little more CPU horsepower to process the index, <strong>and</strong> it will also increase the chance of<br />

block contention. Just as in our discussion of the hash cluster, where it might take more CPU<br />

to retrieve a million r<strong>and</strong>om rows but half the I/O, we must be aware of the tradeoff. If you<br />

are currently CPU bound, adding compressed key indexes may slow down your processing.<br />

On the other h<strong>and</strong>, if you are I/O bound, using them may speed up things.<br />

Reverse Key Indexes<br />

Another feature of a B*Tree index is the ability to “reverse” its keys. At first you might ask yourself,<br />

“Why would I want to do that?” B*Tree indexes were designed for a specific environment<br />

<strong>and</strong> for a specific issue. They were implemented to reduce contention for index leaf blocks in<br />

“right-h<strong>and</strong>-side” indexes, such as indexes on columns populated by a sequence value or a<br />

timestamp, in an <strong>Oracle</strong> RAC environment.<br />

■Note We discussed RAC in Chapter 2.<br />

RAC is a configuration of <strong>Oracle</strong> in which multiple instances can mount <strong>and</strong> open the<br />

same database. If two instances need to modify the same block of data simultaneously, they<br />

will share the block by passing it back <strong>and</strong> forth over a hardware interconnect, a private network<br />

connection between the two (or more) machines. If you have a primary key index on a<br />

column populated from a sequence (a very popular implementation), everyone will be trying<br />

to modify the one block that is currently the left block on the right-h<strong>and</strong> side of the index<br />

structure as they insert new values (see Figure 11-1, which shows that higher values in the<br />

index go to the right, <strong>and</strong> lower values go to the left). Modifications to indexes on columns<br />

populated by sequences are focused on a small set of leaf blocks. Reversing the keys of the<br />

index allows insertions to be distributed across all the leaf keys in the index, though it could<br />

tend to make the index much less efficiently packed.<br />

■Note You may also find reverse key indexes useful as a method to reduce contention, even in a single<br />

instance of <strong>Oracle</strong>. Again, you will mainly use them to alleviate buffer busy waits on the right-h<strong>and</strong> side of a<br />

busy index, as described in this section.

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

Saved successfully!

Ooh no, something went wrong!