Database Reference
In-Depth Information
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 “Reduced Contention in an OLTP System” section. Instead of having a single hot segment, we can
hash partition a segment into 16 pieces, each of which is now receiving modifications.
