Partitioned Tables
Partitioning a table (or index, as you will see in the next section) helps make a large table more
manageable. A table may be partitioned, or even subpartitioned, into smaller pieces. From an
application point of view, partitioning is transparent (that is, no explicit references to a particular
partition are necessary in any end-user SQL). The only effect that a user may notice is that queries
against the partitioned table using criteria in the where clause that matches the partitioning
scheme run a lot faster!
There are many advantages to partitioning from a DBA point of view. If one partition of a table
is on a corrupted disk volume, the other partitions in the table are still available for user queries
while the damaged volume is being repaired. Similarly, backups of partitions can occur over a
period of days, one partition at a time, rather than requiring a single backup of the entire table.
Partitions are one of three types: range partitioned, hash partitioned, or, as of Oracle9i, list
partitioned; as of Oracle 11g, you can also partition by parent/child relationships, applicationcontrolled
partitioning, and many combinations of basic partition types, including list-hash, listlist,
list-range, and range-range. Each row in a partitioned table can exist in one, and only one,
partition. The partition key directs the row to the proper partition; the partition key can be a
composite key of up to 16 columns in the table.
Pages:
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74