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

rekharaghuram
from rekharaghuram More from this publisher
05.11.2015 Views

CHAPTER 13 ■ PARTITIONING 591 ops$tkyte@ORA10G> CREATE TABLE partitioned 2 ( timestamp date, 3 id int 4 ) 5 PARTITION BY RANGE (timestamp) 6 ( 7 PARTITION part_1 VALUES LESS THAN 8 ( to_date('01-jan-2000','dd-mon-yyyy') ) , 9 PARTITION part_2 VALUES LESS THAN 10 ( to_date('01-jan-2001','dd-mon-yyyy') ) 11 ) 12 / Table created. ops$tkyte@ORA10G> create index partitioned_index 2 on partitioned(id) 3 GLOBAL 4 partition by range(id) 5 ( 6 partition part_1 values less than(1000), 7 partition part_2 values less than (MAXVALUE) 8 ) 9 / Index created. Note the use of MAXVALUE in this index. MAXVALUE can be used in any range partitioned table as well as in the index. It represents an “infinite upper bound” on the range. In our examples so far, we’ve used hard upper bounds on the ranges (values less than ). However, a global index has a requirement that the highest partition (the last partition) must have a partition bound whose value is MAXVALUE. This ensures that all rows in the underlying table can be placed in the index. Now, completing this example, we’ll add our primary key to the table: ops$tkyte@ORA10G> alter table partitioned add constraint 2 partitioned_pk 3 primary key(id) 4 / Table altered. It is not evident from this code that Oracle is using the index we created to enforce the primary key (it is to me because I know that Oracle is using it), so we can prove it by simply trying to drop that index: ops$tkyte@ORA10G> drop index partitioned_index; drop index partitioned_index * ERROR at line 1: ORA-02429: cannot drop index used for enforcement of unique/primary key

592 CHAPTER 13 ■ PARTITIONING To show that Oracle will not allow us to create a nonprefixed global index, we only need try the following: ops$tkyte@ORA10G> create index partitioned_index2 2 on partitioned(timestamp,id) 3 GLOBAL 4 partition by range(id) 5 ( 6 partition part_1 values less than(1000), 7 partition part_2 values less than (MAXVALUE) 8 ) 9 / partition by range(id) * ERROR at line 4: ORA-14038: GLOBAL partitioned index must be prefixed The error message is pretty clear. The global index must be prefixed. So, when would you use a global index? We’ll take a look at two system types, data warehouse and OLTP, and see when they might apply. Data Warehousing and Global Indexes In the past, it used to be that data warehousing and global indexes were pretty much mutually exclusive. A data warehouse implies certain things, such as large amounts of data coming in and going out. Many data warehouses implement a sliding window approach to managing data—that is, drop the oldest partition of a table and add a new partition for the newly loaded data. In the past (Oracle8i and earlier), these systems would have avoided the use of global indexes for a very good reason: lack of availability. It used to be the case that most partition operations, such as dropping an old partition, would invalidate the global indexes, rendering them unusable until they were rebuilt. This could seriously compromise availability. In the following sections, we’ll take a look at what is meant by a sliding window of data and the potential impact of a global index on it. I stress the word “potential” because we’ll also look at how we may get around this issue and how to understand what getting around the issue might imply. Sliding Windows and Indexes The following example implements a classic sliding window of data. In many implementations, data is added to a warehouse over time and the oldest data is aged out. Many times, this data is range partitioned by a date attribute, so that the oldest data is stored together in a single partition, and the newly loaded data is likewise stored together in a new partition. The monthly load process involves • Detaching the old data: The oldest partition is either dropped or exchanged with an empty table (turning the oldest partition into a table) to permit archiving of the old data. • Loading and indexing of the new data: The new data is loaded into a “work” table and indexed and validated.

CHAPTER 13 ■ PARTITIONING 591<br />

ops$tkyte@ORA10G> CREATE TABLE partitioned<br />

2 ( timestamp date,<br />

3 id int<br />

4 )<br />

5 PARTITION BY RANGE (timestamp)<br />

6 (<br />

7 PARTITION part_1 VALUES LESS THAN<br />

8 ( to_date('01-jan-2000','dd-mon-yyyy') ) ,<br />

9 PARTITION part_2 VALUES LESS THAN<br />

10 ( to_date('01-jan-2001','dd-mon-yyyy') )<br />

11 )<br />

12 /<br />

Table created.<br />

ops$tkyte@ORA10G> create index partitioned_index<br />

2 on partitioned(id)<br />

3 GLOBAL<br />

4 partition by range(id)<br />

5 (<br />

6 partition part_1 values less than(1000),<br />

7 partition part_2 values less than (MAXVALUE)<br />

8 )<br />

9 /<br />

Index created.<br />

Note the use of MAXVALUE in this index. MAXVALUE can be used in any range partitioned table<br />

as well as in the index. It represents an “infinite upper bound” on the range. In our examples<br />

so far, we’ve used hard upper bounds on the ranges (values less than ). However,<br />

a global index has a requirement that the highest partition (the last partition) must have a partition<br />

bound whose value is MAXVALUE. This ensures that all rows in the underlying table can be<br />

placed in the index.<br />

Now, completing this example, we’ll add our primary key to the table:<br />

ops$tkyte@ORA10G> alter table partitioned add constraint<br />

2 partitioned_pk<br />

3 primary key(id)<br />

4 /<br />

Table altered.<br />

It is not evident from this code that <strong>Oracle</strong> is using the index we created to enforce the<br />

primary key (it is to me because I know that <strong>Oracle</strong> is using it), so we can prove it by simply<br />

trying to drop that index:<br />

ops$tkyte@ORA10G> drop index partitioned_index;<br />

drop index partitioned_index<br />

*<br />

ERROR at line 1:<br />

ORA-02429: cannot drop index used for enforcement of unique/primary key

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!