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.

600<br />

CHAPTER 13 ■ PARTITIONING<br />

We might observe the following:<br />

ops$tkyte@ORA10G> exec runStats_pkg.rs_stop;<br />

Run1 ran in 81 hsecs<br />

Run2 ran in 94 hsecs<br />

run 1 ran in 86.17% of the time<br />

Name Run1 Run2 Diff<br />

...<br />

STAT...CPU used when call star 39 59 20<br />

...<br />

STAT...redo entries 938 3,340 2,402<br />

STAT...db block gets 1,348 5,441 4,093<br />

STAT...session logical reads 2,178 6,455 4,277<br />

...<br />

LATCH.cache buffers chains 5,675 27,695 22,020<br />

...<br />

STAT...table scan rows gotten 97,711 131,427 33,716<br />

STAT...undo change vector size 35,100 3,404,056 3,368,956<br />

STAT...redo size 2,694,172 6,197,988 3,503,816<br />

The index rebuild approach did run faster, both as observed by the elapsed time <strong>and</strong><br />

the CPU time. This fact has caused many a DBA to pause <strong>and</strong> say, “Hey, I don’t want to use<br />

UPDATE GLOBAL INDEXES—it’s slower.” That is too simplistic of a view, however. What you need<br />

to remember is that while the operations overall took longer, processing on your system was<br />

not necessarily interrupted. Sure, you as the DBA might be looking at your screen for a longer<br />

period of time, but the really important work that takes place on your system was still taking<br />

place. What you need to do is see if this tradeoff makes sense for you. If you have an eighthour<br />

maintenance window overnight in which to load new data, then by all means, use the<br />

rebuild approach if that makes sense. However, if you have a m<strong>and</strong>ate to be available continuously,<br />

then the ability to maintain the global indexes will be crucial.<br />

Looking at the redo generated by each approach, we can see that the UPDATE GLOBAL<br />

INDEXES generated considerably more—over 230 percent more—<strong>and</strong> we would expect that to<br />

only go up as we add more <strong>and</strong> more global indexes to the table. The redo generated by the<br />

UPDATE GLOBAL INDEXES is unavoidable <strong>and</strong> cannot be turned off via NOLOGGING, since the<br />

maintenance of the global indexes is not a complete rebuild of their structure but more of an<br />

incremental “maintenance.” Additionally, since we are maintaining the live index structure,<br />

we must generate undo for that—in the event the partition operation fails, we must be prepared<br />

to put the index back the way it was. And remember, undo is protected by redo itself, so<br />

some of the redo you see generated is from the index updates <strong>and</strong> some is from the rollback.<br />

Add another global index or two <strong>and</strong> you would reasonably expect these numbers to increase.<br />

So, UPDATE GLOBAL INDEXES is an option that allows you to trade off availability for<br />

resource consumption. If you have the need to provide continuous availability, it will be the<br />

option for you. But you will have to underst<strong>and</strong> the ramifications <strong>and</strong> size other components<br />

of your system appropriately. Specifically, many data warehouses have been crafted over time<br />

to use bulk, direct path operations, bypassing undo generation <strong>and</strong>, when permitted, redo<br />

generation as well. Using UPDATE GLOBAL INDEXES cannot bypass either of those two elements.<br />

You’ll need to examine the rules you used to size these components before using this feature,

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

Saved successfully!

Ooh no, something went wrong!