UNDERSTANDING EXPLAIN PLAN 3

Partition Operations

SINGLE

Accesses a single partition

    Describes partition boundaries applicable to a single partitioned object (table or index). The partition boundaries are provided by the values of pstart and pstop of the PARTITION

ITERATOR

Accesses multiple partitions.

Accesses multiple partitions. Iterates over the operation below it, for each partition in the range given by the PARTITION_START and PARTITION_STOP columns.

ALL				Accesses all partitions.
INLIST		Accesses multiple partitions based on the values contained in an IN list predicate.
INVALID			Indicates an empty partition set.
RANGE	Partitions a table where each of the various segments contain table rows that share the same range of values for a particular column

Each partition is a separate segment, and partitions can be stored in separate tablespaces and have individual storage definitions. Although partitions are implemented transparently to an application and need not be specified in SQL, SQL statements can specify a partition name. For instance, the following statement applies an update to an individual partition (S1) only:

UPDATE sales_part PARTITION(s1)  SET purge_ind=’Y’  WHERE sale_value < 10000 

SINGLE RANGE		Creates a single partition of a table.
HASH	Partitions a table into various segments, subjecting the column to a hashing algorithm to determine which partition the rows will be stored in. This methodology ensures that each partition  has approximately the same number of rows.

In  Oracle8i hash partition, rows are distributed to the various partitions based on the value of specific columns. However, in the case of hash partitions the column is subjected to a hashing algorithm to determine which partition the rows will be stored in. The hashing algorithm applies a mathematical function to the column value and assigns the row to its partition based on the return value of the function. This ensures that each partition has approximately the same number of rows. It also means that you cannot reasonably anticipate which rows will end up in specific partitions. Rows that have adjacent column values will not necessarily end up in the same partition. They are usually allocated to separate partitions.

The following statement creates a variant of the SALES table that is partitioned by the hash of SALE_DATE. Six partitions are created with default storage attributes, though it could have explicitly named and supplied storage parameters for each partition:

CREATE TABLE SALES_HASH_PART  (column definitions)  PARTITION BY HASH (sale_date) PARTITIONS 8

The key advantage of hash partitions is that they are usually well-balanced: each partition will hold approximately the same number of rows. This improves the performance of many parallel operations on the partition.

Note: For a hash partition to be well-balanced using the default hashing algorithm, the number of partitions must be a power of 2 (i.e. 2, 4, 8, 16, 32).

The disadvantage of hash partitions is that you often will not get partition elimination for range-based queries such as "what were the total sales for quarter 4". Furthermore, you cannot purge old data using a hash partition. For example, a range partition that would have allowed you to easily remove all sales data for a specific year will require all the overhead of locating and removing each individual when you use hash partitioning.

Note: Consider hash partitioning when the balance of rows between partitions is more important than the benefits of partition elimination or purging data by dropping a partition. Remember to make the number of partitions a power of 2.