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

588
CHAPTER 13 ■ PARTITIONING
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter("A"=1)
3 - access("B"=1)
Note the PSTART and PSTOP column values of 1 and 1.This proves that the optimizer is able
to perform partition elimination even for nonprefixed local indexes.
If you frequently query the preceding table with the following queries:
select ... from partitioned_table where a = :a and b = :b;
select ... from partitioned_table where b = :b;
then you might consider using a local nonprefixed index on (b,a). That index would be useful
for both of the preceding queries. The local prefixed index on (a,b) would be useful only for the
first query.
The bottom line here is that you should not be afraid of nonprefixed indexes or consider
them to be major performance inhibitors. If you have many queries that could benefit from
a nonprefixed index as outlined previously, then you should consider using one. The main
concern is to ensure that your queries contain predicates that allow for index partition elimination
whenever possible. The use of prefixed local indexes enforces that consideration. The
use of nonprefixed indexes does not. Consider also how the index will be used. If it will be
used as the first step in a query plan, there are not many differences between the two types
of indexes.
Local Indexes and Unique Constraints
To enforce uniqueness—and that includes a UNIQUE constraint or PRIMARY KEY constraints—
your partitioning key must be included in the constraint itself if you want to use a local index
to enforce the constraint. This is the largest limitation of a local index, in my opinion. Oracle
enforces uniqueness only within an index partition—never across partitions. What this
implies, for example, is that you cannot range partition on a TIMESTAMP field and have a primary
key on the ID that is enforced using a locally partitioned index. Oracle will instead utilize
a global index to enforce uniqueness.
In the next example, we will create a range partitioned table that is partitioned by a column
named LOAD_TYPE, but has a primary key on the ID column. We can do that by executing
the following CREATE TABLE statement in a schema that owns no other objects, so we can easily
see exactly what objects are created by looking at every segment this user owns:
ops$tkyte@ORA10G> CREATE TABLE partitioned
2 ( load_date date,
3 id int,
4 constraint partitioned_pk primary key(id)
5 )
6 PARTITION BY RANGE (load_date)
7 (
8 PARTITION part_1 VALUES LESS THAN
9 ( to_date('01/01/2000','dd/mm/yyyy') ) ,
10 PARTITION part_2 VALUES LESS THAN
11 ( to_date('01/01/2001','dd/mm/yyyy') )