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.

596<br />

CHAPTER 13 ■ PARTITIONING<br />

The global index is, of course, unusable after this operation. Since each index partition<br />

can point to any table partition, <strong>and</strong> we just took away a partition <strong>and</strong> added a partition, that<br />

index is invalid. It has entries that point into the partition we dropped. It has no entries that<br />

point into the partition we just added. Any query that would make use of this index either will<br />

fail <strong>and</strong> not execute or, if we skip unusable indexes, the query’s performance will be negatively<br />

impacted by not being able to use the index:<br />

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

ops$tkyte@ORA10G> select /*+ index( partitioned PARTITIONED_IDX_GLOBAL ) */ count(*)<br />

2 from partitioned<br />

3 where timestamp between sysdate-50 <strong>and</strong> sysdate;<br />

select /*+ index( partitioned PARTITIONED_IDX_GLOBAL ) */ count(*)<br />

*<br />

ERROR at line 1:<br />

ORA-01502: index 'OPS$TKYTE.PARTITIONED_IDX_GLOBAL' or partition<br />

of such index is in unusable state<br />

ops$tkyte@ORA10G> select count(*)<br />

2 from partitioned<br />

3 where timestamp between sysdate-50 <strong>and</strong> sysdate;<br />

COUNT(*)<br />

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

6750<br />

Execution Plan<br />

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

0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=59 Card=1 Bytes=9)<br />

1 0 SORT (AGGREGATE)<br />

2 1 FILTER<br />

3 2 PARTITION RANGE (ITERATOR) (Cost=59 Card=7234 Bytes=65106)<br />

4 3 TABLE ACCESS (FULL) OF 'PARTITIONED' (TABLE) (Cost=59 Card=7234<br />

ops$tkyte@ORA10G> set autotrace off<br />

So, our choices after performing this partition operation with global indexes are<br />

• Skip the index, either transparently as <strong>Oracle</strong> 10g is doing in this example or by setting<br />

the session parameter SKIP_UNUSABLE_INDEXES=TRUE in 9i (<strong>Oracle</strong> 10g defaults this setting<br />

to TRUE). But then we lose the performance the index was giving us.<br />

• Have the query receive an error, as it would in 9i unless SKIP_UNUSABLE_INDEXES were set<br />

to FALSE, <strong>and</strong> as would any query in 10g that explicitly requests to use a hint. We need to<br />

rebuild this index to make the data truly usable again.<br />

The sliding window process, which so far has resulted in virtually no downtime, will now<br />

take a very long time to complete while we rebuild the global index. Runtime query performance<br />

of queries that relied on these indexes will be negatively affected during this time—either

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

Saved successfully!

Ooh no, something went wrong!