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

CHAPTER 13 ■ PARTITIONING 571
PART_1
PART_2
Figure 13-2. Hash partition insert example
As noted earlier, hash partitioning gives you no control over which partition a row ends
up in. Oracle applies the hash function and the outcome of that hash determines where the
row goes. If you want a specific row to go into partition PART_1 for whatever reason, you
should not—in fact, you cannot—use hash partitioning. The row will go into whatever partition
the hash function says to put it in. If you change the number of hash partitions, the data
will be redistributed over all of the partitions (adding or removing a partition to a hash partitioned
table will cause all of the data to be rewritten, as every row may now belong in a
different partition).
Hash partitioning is most useful when you have a large table, such as the one shown in
the “Reduced Administrative Burden” section, and you would like to “divide and conquer” it.
Rather than manage one large table, you would like to have 8 or 16 smaller “tables” to manage.
Hash partitioning is also useful to increase availability to some degree, as demonstrated in the
“Increased Availability” section; the temporary loss of a single hash partition permits access to
all of the remaining partitions. Some users may be affected, but there is a good chance that
many will not be. Additionally, the unit of recovery is much smaller now. You do not have a
single large table to restore and recover; you have a fraction of that table to recover. Lastly,
hash partitioning is useful in high update contention environments, as mentioned in the
“Enhanced Statement Performance” section when we talked about OLTP systems. Instead of
having a single “hot” segment, we can hash partition a segment into 16 pieces, each of which
is now receiving modifications.