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

CHAPTER 13 ■ PARTITIONING 561
elsewhere to hold a copy of both indexes, you’ll need a temporary transaction log table to
record the changes made against the base table during the time you spend rebuilding the
index, and so on. On the other hand, if the index itself had been partitioned into ten 1GB partitions,
then you could rebuild each index partition individually, one by one. Now you need
10 percent of the free space you needed previously. Likewise, the individual index rebuilds will
each be much faster (ten times faster, perhaps), so far fewer transactional changes occurring
during an online index rebuild need to be merged into the new index, and so on.
Also, consider what happens in the event of a system or software failure just before completing
the rebuilding of a 10GB index. The entire effort is lost. By breaking the problem down
and partitioning the index into 1GB partitions, at most you would lose 10 percent of the total
work required to rebuild the index.
Alternatively, it may be that you need to rebuild only 10 percent of the total aggregate
index—for example, only the “newest” data (the active data) is subject to this reorganization,
and all of the “older” data (which is relatively static) remains unaffected.
Finally, consider the situation whereby you discover 50 percent of the rows in your table
are “migrated” rows (see Chapter 10 for details on chained/migrated rows), and you would like
to fix this. Having a partitioned table will facilitate the operation. To “fix” migrated rows, you
must typically rebuild the object—in this case, a table. If you have one 100GB table, you will
need to perform this operation in one very large “chunk,” serially, using ALTER TABLE MOVE. On
the other hand, if you have 25 partitions, each 4GB in size, then you can rebuild each partition
one by one. Alternatively, if you are doing this during off-hours and have ample resources,
you can even do the ALTER TABLE MOVE statements in parallel, in separate sessions, potentially
reducing the amount of time the whole operation will take. Virtually everything you can do to
a nonpartitioned object, you can do to an individual partition of a partitioned object. You
might even discover that your migrated rows are concentrated in a very small subset of your
partitions, hence you could rebuild one or two partitions instead of the entire table.
Here is a quick example demonstrating the rebuild of a table with many migrated rows.
Both BIG_TABLE1 and BIG_TABLE2 were created from a 10,000,000-row instance of BIG_TABLE
(see the “Setup” section for the BIG_TABLE creation script). BIG_TABLE1 is a regular, nonpartitioned
table, whereas BIG_TABLE2 is a hash partitioned table in eight partitions (we’ll cover
hash partitioning in a subsequent section; suffice it to say, it distributed the data rather evenly
into eight partitions):
ops$tkyte@ORA10GR1> create table big_table1
2 ( ID, OWNER, OBJECT_NAME, SUBOBJECT_NAME,
3 OBJECT_ID, DATA_OBJECT_ID,
4 OBJECT_TYPE, CREATED, LAST_DDL_TIME,
5 TIMESTAMP, STATUS, TEMPORARY,
6 GENERATED, SECONDARY )
7 tablespace big1
8 as
9 select ID, OWNER, OBJECT_NAME, SUBOBJECT_NAME,
10 OBJECT_ID, DATA_OBJECT_ID,
11 OBJECT_TYPE, CREATED, LAST_DDL_TIME,
12 TIMESTAMP, STATUS, TEMPORARY,
13 GENERATED, SECONDARY
14 from big_table.big_table;
Table created.