Partitioning in Oracle 11

Written by
Jacques Kilchoer, Software Engineer,
Thomas Szekely, Software Engineer,
Quest Software, Inc.

White Paper
© 2009 Quest Software, Inc.
ALL RIGHTS RESERVED.

This document contains proprietary information, protected by copyright. No part of

this document may be reproduced or transmitted for any purpose other than the
reader's personal use without the written permission of Quest Software, Inc.

WARRANTY

The information contained in this document is subject to change without notice.

Quest Software makes no warranty of any kind with respect to this information.
QUEST SOFTWARE SPECIFICALLY DISCLAIMS THE IMPLIED WARRANTY OF THE
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Quest Software
shall not be liable for any direct, indirect, incidental, consequential, or other
damage alleged in connection with the furnishing or use of this information.

TRADEMARKS

All trademarks and registered trademarks used in this guide are property of their
respective owners.

World Headquarters
5 Polaris Way
Aliso Viejo, CA 92656
www.quest.com
e-mail: [email protected]

Please refer to our Web site (www.quest.com) for regional and international office
information.

Updated—May 2009

WPD-PartitioningOracle11-AG
CONTENTS
INTRODUCTION ..........................................................................................1
RECAP: ADVANTAGES OF PARTITIONING ............................................................... 1
REVIEW OF PARTITION TYPES (PRE-ORACLE 11) .......................................2
RANGE PARTITION ......................................................................................... 2
Example: Using Range Partitioning ............................................................ 2
Example: Archiving and Purging Unneeded Data .......................................... 3
HASH PARTITION .......................................................................................... 3
Example: Using Hash Partitioning .............................................................. 4
Example: Performing an Operation on a Subset of a Table ............................ 4
LIST PARTITION ............................................................................................ 4
Example: Using List Partitioning ................................................................ 5
COMPOSITE PARTITIONS .................................................................................. 5
GENERAL RESTRICTIONS ON PARTITIONING ........................................................... 6
FINDING PARTITIONED TABLES IN YOUR DATABASE .................................................. 6
NEW FEATURES OF PARTITIONING IN ORACLE 11 ......................................7
VIRTUAL COLUMNS ........................................................................................ 7
Example ................................................................................................ 7
Finding Tables with Virtual Columns in the Partitioning Key ........................... 8
Practical Issues for Virtual Columns ........................................................... 9
INTERVAL PARTITION ...................................................................................... 9
Example .............................................................................................. 10
Finding Interval-Partitioned Tables........................................................... 10
Changing a Range-partitioned Table to an Interval-partitioned Table,
or Vice-Versa........................................................................................ 10
Restrictions .......................................................................................... 11
REFERENCE PARTITION .................................................................................. 14
Example .............................................................................................. 14
Finding Reference-partitioned Tables........................................................ 16
Practical Issues for Reference-Partitioned Tables........................................ 17
Restrictions .......................................................................................... 17
SYSTEM PARTITION ...................................................................................... 19
Example .............................................................................................. 19
Finding System-partitioned Tables ........................................................... 20
Practical Issues for System-partitioned Tables ........................................... 20
Restrictions .......................................................................................... 20
ENHANCEMENTS TO COMPOSITE PARTITIONS ........................................................ 21
Pre-Oracle 11 Composite Partitions .......................................................... 21
New Types of Composite Partitions in Oracle 11......................................... 21
INDEX-ORGANIZED TABLE PARTITIONING ............................................................ 23
INDEX PARTITIONS ...................................................................................... 23
Local vs. Global Indexes......................................................................... 23
Allowed Types for Partitioned Indexes ...................................................... 24
PARTITION ADVISOR .................................................................................... 24

i
SUMMARY ................................................................................................. 25
REFERENCES ............................................................................................. 26
ABOUT THE AUTHORS ............................................................................... 27
ABOUT QUEST SOFTWARE, INC. ................................................................ 28
CONTACTING QUEST SOFTWARE ....................................................................... 28
CONTACTING QUEST SUPPORT ......................................................................... 28

ii
 White Paper

INTRODUCTION
Partitioning was introduced in Oracle 8.0, and many improvements and
enhancements have been added in each subsequent version of Oracle. Partitioning
allows you to physically break up the segments that make up a table, index, or large
object, while keeping them logically in the same Oracle object. Partitioning is
available only in Oracle Enterprise Edition, and usually requires a separate license.
Partitioning increases the complexity of managing the segments that make up your
tables and indexes, but offers several significant advantages, which are listed below.

This paper presents the enhancements to partitioning introduced in Oracle 11 and

some of the issues you should consider when using them.

Recap: Advantages of Partitioning

Partitioning offers a number of advantages, including the following:

In very large databases (VLDBs), it is useful to be able to perform operations on

subsets of a large object. Partitioning allows you to perform operations on a subset of
a table. For example, partitioning a table by date or region can optimize queries and
reports of certain business units that are interested in only that section of the data.

• Partitioning reduces maintenance windows and recovery times. Archiving

and purging are improved because you can drop a partition from a table in
a single operation without leaving partially used blocks in your table or
waiting for a Delete statement to find all the rows. The partition drop is
instantaneous.
• Partitioning a table does not require rewriting your application, because
Select and DML are unaffected.
• Partitioning increases availability of the data, because it is possible to
select from online partitions of the table when other partitions are offline.
• Partitioning simplifies administrative tasks. For example, rebuilding a 20
GB index on a table takes a long time. Using partitioning, you can create
ten 2GB local index partitions instead, and rebuild them one by one.
• Select, Insert, Update and Delete statements can become more efficient
due to partition pruning and parallel operations.

1
Partitioning in Oracle 11

REVIEW OF PARTITION TYPES (PRE-ORACLE 11)

Four types of partitions are available in versions of Oracle prior to version 11:

• Range partition
• Hash partition
• List partition
• Composite partition

Range Partition

A range partition was the first type of partitioning introduced, and is available in
Oracle 8.0 and later.

Each partition in a range-partitioned table contains rows with partition key values
less than the specified limit for that partition. Each partition must have an upper
limit value (specify MAXVALUE as the upper limit to indicate that all values are
acceptable for that column in that partition).

Oracle will not allow inserting a row that exceeds the range limit of the last partition.

If a partition has MAXVALUE as the upper limit for a partitioning key column (or any
of the preceding columns in the partitioning key) then Oracle will not reject any
values for that column for that partition.

You cannot add partitions to a table once you have a range partition with a
MAXVALUE upper limit for the leading column in the partitioning key. Instead, you
would need to split one or more of the existing partitions.

Range partitions are useful for archiving historical data using drop partitions.

Example: Using Range Partitioning

To partition the ORDERS table by order_date into four partitions (2006, 2007,
2008, and 2009), use the following code:

create table orders

(order_id number not null,
order_date date not null,
order_amt number (9,2)
)
partition by range (order_date)
(partition orders_2006 values less than (date '2007-01-01')
tablespace data1,
2
 White Paper

partition orders_2007 values less than (date '2008-01-01')

tablespace data2,
partition orders_2008 values less than (date '2009-01-01')
tablespace data3,
partition orders_2009 values less than (date '2010-01-01')
tablespace data4
) ;

Example: Archiving and Purging Unneeded Data

You can remove the data from a production table and save it in another table for
archiving purposes using EXCHANGE PARTITION and DROP PARTITION. In this
simple example, the exchange table was created with a simple CREATE TABLE AS
SELECT, but usually you will also need to create additional constraints and indexes
to match the production table. For an EXCHANGE PARTITION, the exchange table
must be an exact match of the original table.

-- create empty exchange table identical to the main table

create table orders_2006 tablespace archived_data
as select * from orders where rownum < 1 ;

-- move the data to the archive table, replacing the partition in the
-- production table with an empty partition
alter table orders exchange partition orders_2006 with table orders_2006 ;

-- drop the empty partition from the production table

alter table orders drop partition orders_2006 ;

Hash Partition

Hash partitions were introduced in Oracle 8.1. In a hash-partitioned table, rows are
allocated evenly to equal-sized hash partitions using a hashing algorithm. You will
not know in which partition any particular row will reside.

If you want to ensure equal-sized partitions, the number of partitions should be a

power of 2 s; Oracle’s hashing algorithm works best when the number of partitions
is a power of 2. The columns in the partitioning key should together make up a
unique or nearly unique value. To take an extreme example, if all the rows in the
table have the same value for the partitioning key column, then Oracle’s hashing
algorithm will come up with the same hash value for each row and all rows will be
in the same partition.

A hash-partitioned table would be used to minimize the size of your segments and
increase manageability of maintenance operations. It can also be used to spread
DML activity across several segments using Oracle’s PARALLEL operations.

3
Partitioning in Oracle 11

Example: Using Hash Partitioning

A table that stores e-mail attachments is divided into two partitions to keep each
segment at a manageable size:

create table item_pictures

(sales_item_id number not null,
sales_item_price number (8, 2) not null,
item_code varchar2 (10),
item_image blob
)
partition by hash (sales_item_id)
(partition item_pictures_p1 tablespace data1
lob (item_image)
store as item_pictures_lob_p1 (tablespace lob_data1),
partition item_pictures_p2 tablespace data2
lob (item_image)
store as item_pictures_lob_p2 (tablespace lob_data2)
) ;

Example: Performing an Operation on a Subset of a Table

Let’s extend the preceding example. Suppose you are changing the tablespaces in
which you store objects. If the table is partitioned, you can move each of the
partitions either at different times, or simultaneously in different sessions. If all the
data were in one table, the whole table would have to be moved in one statement.

To move partition 1:

alter table item_pictures

move partition item_pictures_p1 tablespace new_data1
lob (item_image) store as item (tablespace new_lob_data1) ;

To move partition 2:

alter table item_pictures

move partition item_pictures_p2 tablespace new_data2
lob (item_image) store as (tablespace new_lob_data2) ;

List Partition

A list partition is available in Oracle 9.0 and later. This method allows partitioning
by a discrete list of values present in the partitioning key column. A list-partitioned
table can have only one column in the partitioning key.

4
 White Paper

The partition with the DEFAULT value will include all the values not specified in any
other partition. If a partition includes the DEFAULT value, then you cannot add
more partitions to the table; you will need to split an existing partition. There can
be only one partition with the DEFAULT value, and you cannot specify any other
values for that partition.

The string making up the list of all values for a single partition is limited in size to
4K, and the total size of all values of the partitioning key (for all partitions) is
limited to 64K–1.

A list partition is useful when the partitioning key column that you choose to
physically separate your data contains a small number of discrete values.

Example: Using List Partitioning

Suppose you want to partition a sales table by region: Europe, North America,
South America, Middle East, etc. Use the following code:

create table sales

(sale_date date not null,
sale_code varchar2 (20) not null,
sale_amt number (9, 2) not null,
invoice_id number not null,
line_items number not null,
region varchar2 (20)not null
)
partition by list (region)
(partition sales_p1 values ('NORTH AMERICA')
tablespace users,
partition sales_p2 values ('SOUTH AMERICA', 'MIDDLE EAST')
tablespace users,
partition sales_p3 values ('ASIA')
tablespace users,
partition sales_p4 values (default)
tablespace users
) ;

Composite Partitions

Oracle 8.1 introduced composite partitions. Composite partitioning extends

partitioning to two levels; that is, partitions can be further partitioned into
subpartitions. Composite partitions are discussed in the Composite Partitions in
Oracle 11 section later in this document.

5
Partitioning in Oracle 11

General Restrictions on Partitioning

For tables with partitioning key columns, the limit is 16 columns in the partitioning
key (with exceptions as listed for individual partition types).

Since Oracle 10.2, the maximum number of partitions or subpartitions in a table is

1024K–1 (previously it was 64K–1).

A clustered table cannot be partitioned.

A table with a LONG or LONG RAW column cannot be partitioned.

The columns in the partitioning key can be of any built-in datatype except ROWID,
LONG, LOB, or XMLType. TIMESTAMP WITH TIME ZONE columns cannot be used in
a partitioning key, but TIMESTAMP or TIMESTAMP WITH LOCAL TIME ZONE columns
can be used in the partitioning key.

Finding Partitioned Tables in Your Database

To find portioned tables in your database, query the following views:

• DBA_PART_TABLES shows information on the partitioned table as a

whole (one row per table).
• DBA_PART_KEY_COLUMNS shows information on the partitioning key
columns.
• DBA_TAB_PARTITIONS shows information on the partitions in the table.
• DBA_TAB_SUBPARTITIONS shows information on the subpartitions in
the table.
• DBA_PART_LOBS shows information on the LOB columns and segments
belonging to the partitioned table (one row per LOB column and segment.).
• DBA_LOB_PARTITIONS shows information on the LOB segment
partitions in the table.
• DBA_PART_INDEXES shows information on a partitioned index as a
whole (one row per table).
• DBA_IND_PARTITIONS shows information on the partitions in the index.
• DBA_IND_SUBPARTITIONS shows information on the subpartitions in
the index.
• DBA_SUBPARTITION_TEMPLATES shows information on the
subpartition templates for the table.

6
 White Paper

NEW FEATURES OF PARTITIONING IN ORACLE 11

Several important enhancements were made to partitioning in Oracle 11:

• Partitioning on virtual columns

• Interval partitions
• Reference partitions
• System partitions
• Composite partitioning enhancements:
• A range-partitioned table can be composite-partitioned as range/range
• A list-partitioned table can be composite-partitioned as list/range,
list/hash, or list/list
• An interval-partitioned table can be composite-partitioned as
interval/range, interval/hash, or interval/list
• All the new types allow for local-partitioned indexes
• A new partition advisor can recommend a partitioning strategy for a table

Virtual Columns

Oracle 11 introduced virtual columns. A virtual column is an additional column that

is the result of an expression and is stored in the table. A virtual column can be
defined when you create the table or when you modify the table by adding a virtual
column.

A virtual column can be used in the partitioning key.

Example
Suppose in your phonebook table you want a virtual column that will store the
username in uppercase. Use the following code:

create table phonebook (

country_code number (2) not null,
area_code number(4) not null,
phone_number number (20) not null,
first_name varchar2 (30),
last_name varchar2 (30) not null,
last_name_upper generated always as (upper (last_name)) virtual
) ;

7
Partitioning in Oracle 11

You can use that virtual column in the partitioning key of your table, as follows:

create table phonebook_p (

country_code number (2) not null,
area_code number(4) not null,
phone_number number (20) not null,
first_name varchar2 (30),
last_name varchar2 (30) not null,
last_name_upper generated always as (upper (last_name)) virtual
)
partition by range (last_name_upper)
(partition phonebook_p1 values less than ('H') tablespace data1,
partition phonebook_p2 values less than ('R') tablespace data2,
partition phonebook_p3 values less than (maxvalue) tablespace data3
) ;

Finding Tables with Virtual Columns in the Partitioning Key

To find tables that have at least one virtual column in the partitioning key, use
this query:

select
a.owner, a.table_name, a.partitioning_type,
b.column_name, c.virtual_column, c.data_default
from dba_part_tables a, dba_part_key_columns b, dba_tab_cols c
where
a.owner = b.owner
and a.table_name = b.name
and b.object_type = 'TABLE'
and a.owner = c.owner
and a.table_name = c.table_name
and b.column_name = c.column_name
and exists (select null from dba_tab_cols d
where a.owner = d.owner
and a.table_name = d.table_name
and d.hidden_column = 'NO' and d.virtual_column = 'YES')
order by a.owner, a.table_name, b.column_position ;

8
 White Paper

Practical Issues for Virtual Columns

Virtual columns take up no space in the row and can be used with any partitioning
type that has partitioning key columns, except as otherwise noted below.

As with all new features, it is important to test virtual columns carefully before
implementing them in production. For example, in our version of Oracle 11, we
found that we were able to create a check constraint on a virtual column with no
error, but then subsequent inserts into the table caused an OR-00600, indicating an
Oracle bug.

Restrictions

The following restrictions apply to virtual columns, not specifically to partitioning:

• A virtual column cannot be created in an index-organized, object, clustered

or temporary table.
• The columns used in the function defining the virtual column must be
columns belonging to the same table. A virtual column cannot be defined
based on another virtual column.
• If the column is defined based on a deterministic user-defined function,
then the virtual column cannot be used as a partitioning key column.
• The datatype of the virtual column cannot be a user-defined datatype, an
Oracle supplied datatype, a LOB or a LONG RAW.

Interval Partition

Interval partitioning is an extension of range partitioning. One of the drawbacks of

range partitioning was that if you did not want to specify a partition with a
MAXVALUE upper limit for the partitioning key, you had to be sure to create enough
partitions to contain any possible value in the partitioning key column. For example,
suppose that you have a table partitioned by sales_year. You need to make sure
that you always have a partition ready for any future years that may be entered in
the table. If the partition does not exist, a row insert with a date beyond the last
partition in the table will fail.

Interval partitioning does not share this drawback. You can create a range-
partitioned table with an added parameter (the INTERVAL parameter), which will
specify to Oracle the upper limit it should generate when it automatically creates a
new partition if you insert a row with a partitioning key value greater than the
upper limit of the last partition in the table.

9
Partitioning in Oracle 11

Example
Suppose you want to create a table of customers partitioned by customer signup
date, with Oracle automatically creating a partition every 18 months. Use the
following code:

create table customers (

customer_id number(6) not null,
cust_first_name varchar2(20) not null,
cust_last_name varchar2(20) not null,
signup_date date not null,
credit_limit number(9,2) not null
)
partition by range (signup_date)
interval (interval '1-6' year to month)
(partition customers_p1
values less than (to_date ('20080101', 'YYYYMMDD'))
tablespace data1,
partition customers_p2
values less than (to_date ('20090101', 'YYYYMMDD'))
tablespace data2) ;

Note that the ranges specified for existing partitions at table creation time do not
have to be separated by the INTERVAL value. The INTERVAL value will apply when
inserting a row with a value that exceeds the highest partition key value in the table.

Finding Interval-Partitioned Tables

To find interval-partitioned tables in your database, run this query:

select a.owner, a.table_name, a.interval, b.column_name

from dba_part_tables a, dba_part_key_columns b
where a.partitioning_type = 'RANGE' and a.interval is not null
and a.owner = b.owner and a.table_name = b.name and b.object_type = 'TABLE'
order by a.owner, a.table_name ;

Changing a Range-partitioned Table to an Interval-

partitioned Table, or Vice-Versa
You can change a range-partitioned table to an interval-partitioned table using the
ALTER TABLE SET INTERVAL command. You can also change an interval-partitioned
table to a range-partitioned table with that command. For example:

create table x (y number) partition by range (y)

(partition xp1 values less than (1000)) ;
-- change to interval-partitioned table:
10
 White Paper

alter table x set interval (2000) ;

-- change back to range-partitioned table:
alter table x set interval () ;

Restrictions
You cannot use interval partitioning on an index-organized table.

There can be only one column in the partitioning key. The column must be of a
NUMBER or DATE datatype.

When you create the table, you must specify at least one range partition. The high
value for the last range partition is called the transition point; if you insert a value
past the transition point, Oracle will automatically create a new partition.

When and How the New Partition Will Be Added

The new partition is created with a system-defined name.

If you insert a row that requires the creation of a new partition, the new partition
will be created regardless of whether the transaction is committed.

Oracle will insert “sparse” partitions. Recall the example CUSTOMERS table above.
If you add a row with signup_date 31 January 3001, Oracle will not add all the
partitions in between; it will add just one new partition. The upper limit for the new
partition will be the upper limit that would be determined from by adding N *
INTERVAL to the upper limit for the highest existing partition, with a value N that
will yield a upper limit higher than the value in the inserted row.

Consider the following example:

create table x (y number)
partition by range (y)
interval (2500)
(partition xp1 values less than (3000)) ;
insert into x (y) values (10000) ;

Existing partitions before insert statement :

TABLE NAME PARTITION NAME UPPER LIMIT

X XP 1 3000

Existing partitions after insert statement :

TABLE NAME PARTITION NAME UPPER LIMIT

X XP 1 3000

X SYS_Pnnnnnn 10500

11
Partitioning in Oracle 11

Explanation:

If we had inserted 10000 rows in table X with values for Y from 1 to 10000

for i in 1..10000 loop

insert into x (y) values (i) ;
end loop ;

we would have the following partitions in the table:

Partition Upper Limit Rows

XP1 3000 1 to 2999 (partition created during CREATE TABLE)
SYS_Pnnnnnn 5500 = 3000 + 1 × 2500 3000 to 5499 (partition created automatically by Oracle)
SYS_Pnnnnnn 8000 = 3000 + 2 × 2500 5500 to 7999 (partition created automatically by Oracle)
SYS_Pnnnnnn 10500 = 3000 + 3 × 2500 8000 to 10000 (partition created automatically by Oracle)

If we create the empty table and only add one row with value 10000, Oracle will
create only one new partition with upper limit 10500.

SQL> create table x (y number)

2 partition by range (y)
3 interval (2500)
4 (partition xp1 values less than (3000)) ;
Table created.

SQL> insert into x (y) values (10000) ;

1 row created.

SQL> select partition_name, high_value

2 from user_tab_partitions
3 where table_name = 'X'
4 order by partition_position ;
PARTITION_NAME HIGH_VALUE
------------------------------ --------------------
XP1 3000
SYS_P6957 10500

Tablespace and Storage Parameters for the New Partition

At table creation time, partitions with no specified tablespace will be stored in the
default tablespace for the table, which is either specified on the table create
statement or taken from the user’s default. When new partitions are added after
table creation, they will be placed either in the default tablespace for the table or in
one of the tablespaces specified in the STORE IN clause (which are used in a round-
robin fashion).

The storage parameters will be taken from either the tablespace default storage
parameters or the default storage parameters specified on the create table statement.

12
 White Paper

For example:

create table customers (

customer_id number(6) not null,
cust_first_name varchar2(20) not null,
cust_last_name varchar2(20) not null,
signup_date date not null,
credit_limit number(9,2) not null
)
tablespace data
partition by range (signup_date)
interval (interval '1-6' year to month)
store in (data1, data2, data3, data4)
(partition customers_p1 values less than (to_date ('20080101', 'YYYYMMDD')),
partition customers_p2 values less than (to_date ('20090101', 'YYYYMMDD'))
) ;

In this example, the two partitions created at table creation time will go into the
default tablespace for the table, which is DATA (since no tablespace was specified
for the individual partitions in the CREATE TABLE statement). Any subsequent
partitions added will be created in tablespaces DATA1, DATA2, DATA3, DATA4, used
in a round-robin fashion. Of course you can manually add a partition and explicitly
specify a tablespace in the ADD PARTITION statement.

Partition Operations Allowed

The following operations all work as usual on an interval-partitioned table:

• MOVE PARTITION
• EXCHANGE PARTITION
• TRUNCATE PARTITION
• ADD PARTITION
• DROP PARTITION
• RENAME PARTITION
• SPLIT PARTITION
• MERGE PARTITION.

Splitting and merging partitions may modify the upper limit generated for new
partitions that will be added, if one of the split or merged partitions is the last
partition in the table. The upper limit that Oracle will generate for any new partition
depends on the transition point (the upper limit for the last partition in the table.)

13
Partitioning in Oracle 11

Reference Partition

Reference partitioning enables you to partition a child table using the same
partitioning as its parent table. The parent table is the table referenced by a foreign
key constraint. The child table will have exactly the same number of partitions as
the parent table, and partition operations made on the parent table will propagate
to the child table.

Any changes in the number of partitions to the parent table are propagated to the
child table.

Example
Suppose you want to create a table of orders partitioned by order date, with a child
table named order_detail having the same partitioning scheme. You can create
order_detail as a reference-partitioned table, and the rows in order_detail will be
partitioned by order_date even though the order_detail table does not contain the
order_date column.

TABLE ORDERS

PARTITION 2007 PARTITION 2008

ORDER_ID ORDER_DATE ORDER_AMT ORDER_ID ORDER_DATE ORDER_AMT

1 2007-01-01 22.33 4 2008-01-01 23832.39

2 2007-06-15 356.78 5 2008-05-20 243.99

3 2007-12-30 123.25 6 2008-11-30 9878.22

Foreign key on ORDER_ID

TABLE ORDER_DETAIL

PARTITION P1 PARTITION P2

ORDER_ID ITEM_ID ITEM_AMT ORDER_ID ITEM_ID ITEM_AMT

1 32423 11.12 6 923832 323.21

1 32897 9.76 6 287218 32.89

2 83732 57.62 6 928237 897.22

create table orders

(order_id number not null,
order_date date not null,
order_amt number (9,2),
constraint orders_pk primary key (order_id)

14
 White Paper

using index tablespace idx

)
tablespace data
partition by range (order_date)
(partition orders_p1 values less than (date '2008-01-01') tablespace data1,
partition orders_p2 values less than (date '2009-01-01') tablespace data2
) ;

create table order_detail

(order_id number not null,
item_id number not null,
item_amt number (7, 2),
constraint order_detail_pk primary key (order_id, item_id)
using index tablespace idx local,
constraint order_detail_fk1 foreign key (order_id)
references orders (order_id)
)
tablespace data
partition by reference (order_detail_fk1) ;

For order_detail, you could have specified a list of partitions and tablespaces in the
create table clause, but it is not necessary.

Here’s an alternative example:

create table order_detail

(order_id number not null,
item_id number not null,
item_amt number (7, 2),
constraint order_detail_pk primary key (order_id, item_id)
using index tablespace idx local,
constraint order_detail_fk1 foreign key (order_id)
references orders (order_id)
)
tablespace data
partition by reference (order_detail_fk1)
(partition order_detail_p1 tablespace data1,
partition order_detail_p2 tablespace data2
) ;

15
Partitioning in Oracle 11

Finding Reference-partitioned Tables

To find reference-partitioned tables in your database, and the name of the foreign
key constraint, run this query:

select owner, table_name, ref_ptn_constraint_name

from dba_part_tables
where partitioning_type = 'REFERENCE'
order by owner, table_name ;

To see the list of columns in the referencing constraint on the child table, the
corresponding list of columns for the primary key constraint in the parent table, and
the partitioning type for the parent table, run this query:

select
a.owner, a.table_name, a.ref_ptn_constraint_name, c.column_name,
e.owner, e.table_name, d.partitioning_type, e.constraint_name, f.column_name
from dba_part_tables a, dba_constraints b, dba_cons_columns c,
dba_part_tables d, dba_constraints e, dba_cons_columns f
where
a.partitioning_type = 'REFERENCE'
and a.owner = b.owner
and a.ref_ptn_constraint_name = b.constraint_name
and b.constraint_type = 'R'
and b.owner = c.owner
and b.constraint_name = c.constraint_name
and e.constraint_type in ('P', 'U')
and e.owner = b.r_owner
and e.constraint_name = b.r_constraint_name
and d.owner = e.owner
and d.table_name = e.table_name
and e.owner = f.owner
and e.constraint_name = f.constraint_name
and c.position = f.position
order by
a.owner, a.table_name, d.owner, d.table_name, c.position ;

16
 White Paper

Practical Issues for Reference-Partitioned Tables

You cannot drop the foreign key constraint on the child table, disable the foreign
key constraint, or put the foreign key constraint in ENABLE NOVALIDATE mode.

In our version of Oracle 11, we were able to drop the primary key constraint on the
parent table using DROP PRIMARY KEY CASCADE (something that Oracle surely
intended to prevent.) But once the primary key constraint was dropped, any DML
on the child table returned an ORA-00600 error indicating an Oracle bug. Be
careful not to drop the primary key constraint on the parent table!

A reference-partitioned table can itself serve as the parent to another reference-

partitioned table. In that case, partition changes (e.g. SPLIT PARTITION) occurring on
the “grandparent” table will be replicated to the child table and the “grandchild” table.

If you attempt to insert a row into the child table where the foreign key column
values are not found in the parent table, you will receive the following error:

ORA-14400: inserted partition key does not map to any partition

as opposed to the usual error:
ORA-02291: integrity constraint (…) violated - parent key not found

Restrictions
The following restrictions apply to reference-partitioned tables:

• The parent table must be partitioned (as might seem obvious). It can have
any partitioning type except interval partitioning.
• The foreign key constraint on the child table must be ENABLE VALIDATE
NOT DEFERRABLE and cannot have the ON DELETE SET NULL clause.
• The columns in the foreign key constraint used for partitioning must be
NOT NULL.
• The foreign key and the primary key constraint it references cannot contain
virtual columns.
• The foreign key constraint used for partitioning may not be self-referencing
(i.e. point to a primary key constraint on the same table). (This also seems
obvious.)
• The ROW MOVEMENT clause must be the same on both tables (either
ENABLE or DISABLE).
• You cannot create a reference-partitioned table using a CREATE TABLE …
AS SELECT … statement. You should use CREATE TABLE … followed by
INSERT … SELECT …
• The child table cannot be an index-organized table.
• You will not be able to perform an EXCHANGE PARTITION on the parent
table (see partition operations below for an explanation.)

17
Partitioning in Oracle 11

When and How the New Partition Will Be Added

When the child table is created, it will be created with the same number of
partitions as the parent table. The table partitions in the child table will have the
same names as the table partitions in the parent table. If a partition is added to the
parent table (via ADD PARTITION or SPLIT PARTITION), then a new partition will be
added to the child table, and it will have the same name as the partition in the
parent table.

Tablespace and Storage Parameters for the New Partition

The tablespace and storage parameters for the new partition in the child table are
taken from the table defaults. The default tablespace for the table will be either the
tablespace specified at table creation time, or, if no default tablespace is specified,
the user’s default tablespace. The storage parameters will be taken from the
tablespace default storage parameters.

Partition Operations Allowed

The following operations all work as usual on a reference-partitioned table (the

child table) and its parent table:

• MOVE PARTITION
• TRUNCATE PARTITION
• RENAME PARTITION
• EXCHANGE PARTITION, with the following caveat:
Oracle does not allow you to perform an EXCHANGE PARTITION on a table
that has a primary key or unique constraint referenced by an enabled
foreign key constraint. The usual method is to disable the foreign key
constraints referencing the parent table, exchange the partition in the
parent table, and re-enable the foreign key constraints referencing the
parent table. Since you cannot disable or drop the foreign key constraint
used for partitioning, you will not be able to perform the EXCHANGE
PARTITION on the parent table; the parent table will always have an
enabled foreign key constraint referencing it unless you drop the reference-
partitioned child table.

The following operations are allowed only on the parent table, and are disallowed
on the reference-partitioned table (the child table). When one of these operations is
performed on the parent table, it will be replicated on the child table.

• ADD PARTITION
• DROP PARTITION
• SPLIT PARTITION
• MERGE PARTITION

18
 White Paper

System Partition

In system-partitioned tables, you must explicitly control partitioning. There is no

partitioning key in the table. When you create the table, you must name every
partition, and each insert operation on the table must include a partition name.

The documentation suggests that this method of partitioning can be used to equi-
partition dependent tables, such as nested table or domain index storage tables
with partitioned base tables. These cases are less well known or less common, so in
the interest of simplicity we will present a simple system-partitioned table.

Example
Suppose you want to create a table of orders partitioned by order date, with a child
table named order_detail having the same partitionining scheme.

create table all_obj

(owner varchar2 (30),
object_name varchar2 (30),
object_type varchar2 (30),
created date,
last_ddl_time date
)
partition by system
(partition my_tables tablespace data1,
partition my_indexes tablespace data2
) ;

The following statement will insert rows into the table. Notice that every insert
portion of the insert statement must specify a partition name in addition to the
table name.

insert into all_obj partition (my_tables)

(owner, object_name, object_type, created, last_ddl_time)
select owner, object_name, object_type, created, last_ddl_time from all_objects
where object_type = 'TABLE' ;

The following is another example of an insert statement:

insert first
when object_type = 'TABLE'
then
into all_obj partition (my_tables)
(owner, object_name, object_type, created, last_ddl_time)
values (owner, object_name, object_type, created, last_ddl_time)
when object_type = 'INDEX'

19
Partitioning in Oracle 11

then
into all_obj partition (my_indexes)
(owner, object_name, object_type, created, last_ddl_time)
values (owner, object_name, object_type, created, last_ddl_time)
select owner, object_name, object_type, created, last_ddl_time
from all_objects ;

Finding System-partitioned Tables

To find system-partitioned tables in your database, run this query:

select owner, table_name

from dba_part_tables
where partitioning_type = 'SYSTEM'
order by owner, table_name ;

Practical Issues for System-partitioned Tables

Each INSERT or MERGE statement on the table must include the partition name. If
the partition name is omitted, you will receive this error:

ORA-14701: partition-extended name or bind variable must be used for DMLs on

tables partitioned by the System method

System-partitioned tables do not have any partitioning key columns. Therefore,

system-partitioned tables cannot have locally partitioned unique indexes.

Restrictions
The following restrictions apply to system partitioning:

A system-partitioned table cannot be composite-partitioned.

• You cannot create a system-partitioned table using a CREATE TABLE … AS

SELECT … statement. You should use CREATE TABLE … followed by INSERT
… SELECT …
• An index-organized table cannot be system-partitioned.

When and How the New Partition Will Be Added

Partitions will be added only when the user issues a SQL statement including a
partition operation that will add a partition.

20
 White Paper

Tablespace and Storage Parameters for the New Partition

The tablespace and storage parameters for any new partition, if not specified on the
SQL statement creating the partition, are taken from the table defaults. The default
tablespace for the table will be either the tablespace specified at table creation
time, or, if no default tablespace is specified, the user’s default tablespace. The
storage parameters will be taken from the tablespace default storage parameters.

Partition Operations Allowed

The following operations all work expected on a system-partitioned table:

• MOVE PARTITION
• EXCHANGE PARTITION
• TRUNCATE PARTITION
• ADD PARTITION
• DROP PARTITION
• RENAME PARTITION
• MERGE PARTITION

SPLIT PARTITION cannot be used on a system-partitioned table, due to the lack of

any partitioning key columns.

Enhancements to Composite Partitions

Pre-Oracle 11 Composite Partitions

In previous versions of Oracle, the following types of composite partitions were
introduced:

• Oracle 8.1: Range/hash (range partitions and hash subpartitions)

• Oracle 9.0: Range/list (range partitions and list subpartitions)

New Types of Composite Partitions in Oracle 11

Oracle 11 introduced the following new composite partition types:

• Range/range (range partitions and range subpartitions)

• List/range (list partitions and range subpartitions)
• List/hash (list partitions and hash subpartitions)
• List/list (list partitions and list subpartitions)

21
Partitioning in Oracle 11

• Interval/range (interval partitions and range subpartitions)

• Interval/hash (interval partitions and hash subpartitions)
• Interval/list (interval partitions and list subpartitions)

Practical Considerations

For the primary practical considerations for each partition type, refer to the detailed
discussions above.

For range, list and hash subpartitions, you can create a subpartition template to
establish default subpartition characteristics. The subpartition template will be used
when a new partition is added via ADD PARTITION or SPLIT PARTITION, or when
the table is created without explicitly specifying the subpartitions for an individual
partition.

Example

Subpartition templates are not new to Oracle 11, so we will simply provide an
example of a subpartition template:

create table books

(book_id number not null,
author_first_name varchar2 (40),
author_last_name varchar2 (100),
region varchar2 (20),
language varchar2 (20)
)
partition by range (region)
subpartition by list (language)
subpartition template
(subpartition indo_european values ('ENGLISH', 'FRENCH', 'SPANISH',
'GERMAN')
tablespace data1,
subpartition asian values ('CHINESE', 'KOREAN', 'JAPANESE')
tablespace data2,
subpartition indian values ('HINDI', 'TAGALOG', 'TAMIL')
tablespace data3,
subpartition other values (default) tablespace data4
)
(partition p1 values less than ('EUROPE'),
partition books_p2 values less than ('NORTH AMERICA'),
partition books_p3 values less than (maxvalue)
) ;

22
 White Paper

Restrictions

The only physical attributes that can be specified for a subpartition are TABLESPACE
and COMPRESSION.

An index-organized table cannot be subpartitioned.

Index-organized Table Partitioning

The new partitioning types (interval, reference, system) cannot be used to partition
an index-organized table.

An index-organized table cannot contain a virtual column; therefore you will not
be able to partition an index-organized table with a virtual column in the
partitioning key.

There are no new features for partitioning of index-organized tables.

Index Partitions

There are no new features for index partitioning in Oracle 11, except that all new
partition types and composite partition types can have locally partitioned indexes.
However, we will include a brief recap of index partitioning considerations.

Local vs. Global Indexes

Indexes on a partitioned table or a composite-partitioned table can be locally
partitioned, globally partitioned, or global (meaning they are not partitioned.)

Advantages of Local Partitioned Indexes

Local partitioned indexes are vastly easier to maintain than global indexes, because
they are automatically maintained during partition maintenance operations such as
EXCHANGE PARTITION (if you include indexes), TRUNCATE PARTITION, and DROP
PARTITION. There are exceptions:

• Global indexes will become unusable and will need to be rebuilt or

recreated after any ALTER TABLE partition operation that involves
movement of rows or changing the number of rows in the table
(TRUNCATE PARTITION, DROP PARTITION, SPLIT PARTITION, MERGE
PARTITION, MOVE PARTITION, or EXCHANGE PARTITION).
• Local indexes will become unusable and need to be rebuilt or recreated
after any ALTER TABLE partition operation that involves movement of rows
(SPLIT PARTITION, MERGE PARTITION, MOVE PARTITION, or EXCHANGE
PARTITION that does not include indexes).

23
Partitioning in Oracle 11

For any of these operations, Oracle has an UPDATE GLOBAL INDEXES clause to
rebuild global indexes as part of the operation, and an UPDATE ALL INDEXES clause
to update global and local indexes as part of the operation. Note that rebuilding
indexes will mean that the operation is no longer a simple data dictionary update
and the ALTER TABLE statement will not be instantaneous.

Advantages of Global Indexes

There are situations where a global index will be preferable to a local partitioned
index, depending on how the data is accessed. For example, if you query with a
column in the where clause that is in a local partitioned index but not in the
partitioning key, Oracle will need to read each index partition to find the row.
(Oracle will not always perform index partition elimination when the query is a local
nonprefixed index.) However, if a global partitioned index includes that column in
the partitioning key, Oracle will need to read only one index partition. Therefore, for
performance reasons you may want to create a global index or a global partitioned
index. You should, however, be aware of the potential of increased maintenance
tasks when using global indexes or global partitioned indexes on a partitioned table.

When Local Indexes Cannot Be Used

In some cases, you cannot use a local partitioned index on a partitioned table. For
example, for a unique locally partitioned index, or a local index used to enforce a
primary key or unique constraint, the index columns must be a superset of the
partitioning key. If your index columns are not a superset of the partitioning key,
then you will be unable to create a unique locally partitioned index on your
partitioned table, and a non-unique locally partitioned index cannot be used by
Oracle to enforce a primary key or unique constraint.

Allowed Types for Partitioned Indexes

Global partitioned indexes may be range-partitioned or hash-partitioned.

Partition Advisor

Oracle 11 includes a partition advisor that can recommend a partitioning strategy

for a table based on a supplied workload of SQL statements. See the Performance
Tuning Guide, Chapter 18, for a discussion of the advisors supplied with Oracle 11.

24
 White Paper

SUMMARY
Oracle 11 introduced the following enhancements to partitioning:

• Partitioning on virtual columns

• Interval partitions
• Reference partitions
• System partitions
• Composite partitioning enhancements:
• A range-partitioned table can be composite-partitioned as range/range
• A list-partitioned table can be composite-partitioned as list/range,
list/hash, or list/list
• An interval-partitioned table can be composite-partitioned as
interval/range, interval/hash, or interval/list
• All the new types allow for local-partitioned indexes
• A new partition advisor can recommend a partitioning strategy for a table

Many of these enhancements are natural extensions of partitioning that previous

users of partitioning had anticipated and will find useful.

25
Partitioning in Oracle 11

REFERENCES
Oracle 11 documentation

Thomas Kyte: Expert Oracle Database Architecture (Apress)

(http://asktom.oracle.com)

26
 White Paper

ABOUT THE AUTHORS

Thomas Szekely is a software engineer with 22 years of experience in software
development. He has worked at Quest Software since 2000, developing software
tools for Oracle DBAs.

Jacques Kilchoer has been a software engineer and a database administrator. He

currently works at Quest Software in R&D for database management tools.

Both authors work on Space Manager with LiveReorg, a tool to allow you to manage
partitioned tables and reorganize segments in the database.

27
Partitioning in Oracle 11

ABOUT QUEST SOFTWARE, INC.

Quest Software, Inc., a leading enterprise systems management vendor, delivers
innovative products that help organizations get more performance and productivity
from their applications, databases, Windows infrastructure and virtual
environments. Through a deep expertise in IT operations and a continued focus on
what works best, Quest helps more than 100,000 customers worldwide meet higher
expectations for enterprise IT. Quest Software helps organizations deliver, manage
and control complex database environments through award-winning products for
Oracle, SQL Server, IBM DB2, Sybase and MySQL. Quest Software can be found in
offices around the globe and at www.quest.com.

Contacting Quest Software

Phone: 949.754.8000 (United States and Canada)
Email: [email protected]
Mail: Quest Software, Inc.
World Headquarters
5 Polaris Way
Aliso Viejo, CA 92656
USA
Web site: www.quest.com

Please refer to our Web site for regional and international office information.

Contacting Quest Support

Quest Support is available to customers who have a trial version of a Quest product
or who have purchased a commercial version and have a valid maintenance
contract. Quest Support provides around the clock coverage with SupportLink, our
web self-service. Visit SupportLink at http://support.quest.com

From SupportLink, you can do the following:

• Quickly find thousands of solutions (Knowledgebase articles/documents).

• Download patches and upgrades.
• Seek help from a Support engineer.
• Log and update your case, and check its status.

View the Global Support Guide for a detailed explanation of support programs,
online services, contact information, and policy and procedures. The guide is
available at: http://support.quest.com/pdfs/Global Support Guide.pdf

28