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 577 We would have to remove the DEFAULT partition, then add PART_4, and then put the DEFAULT partition back. The reason behind this is that the DEFAULT partition could have had rows with the list partition key value of CA or NM—they would not belong in the DEFAULT partition after adding PART_4. Composite Partitioning Lastly, we’ll look at some examples of composite partitioning, which is a mixture of range and hash or range and list. In composite partitioning, the top-level partitioning scheme is always range partitioning. The secondary level of partitioning is either list or hash (in Oracle9i Release 1 and earlier only hash subpartitioning is supported, not list). It is interesting to note that when you use composite partitioning, there will be no partition segments—there will be only subpartition segments. When using composite partitioning, the partitions themselves do not have segments (much like a partitioned table doesn’t have a segment). The data is physically stored in subpartition segments and the partition becomes a logical container, or a container that points to the actual subpartitions. In our example, we’ll look at a range-hash composite. Here we are using a different set of columns for the range partition from those used for the hash partition. This is not mandatory; we could use the same set of columns for both: ops$tkyte@ORA10G> CREATE TABLE composite_example 2 ( range_key_column date, 3 hash_key_column int, 4 data varchar2(20) 5 ) 6 PARTITION BY RANGE (range_key_column) 7 subpartition by hash(hash_key_column) subpartitions 2 8 ( 9 PARTITION part_1 10 VALUES LESS THAN(to_date('01/01/2005','dd/mm/yyyy')) 11 (subpartition part_1_sub_1, 12 subpartition part_1_sub_2 13 ), 14 PARTITION part_2 15 VALUES LESS THAN(to_date('01/01/2006','dd/mm/yyyy')) 16 (subpartition part_2_sub_1, 17 subpartition part_2_sub_2 18 ) 19 ) 20 / Table created. In range-hash composite partitioning, Oracle will first apply the range partitioning rules to figure out which range the data falls into. Then it will apply the hash function to decide into which physical partition the data should finally be placed. This process is described in Figure 13-4.

578 CHAPTER 13 ■ PARTITIONING Figure 13-4. Range-hash composite partition example So, composite partitioning gives you the ability to break up your data by range and, when a given range is considered too large or further partition elimination could be useful, to break it up further by hash or list. It is interesting to note that each range partition need not have the same number of subpartitions; for example, suppose you were range partitioning on a date column in support of data purging (to remove all old data rapidly and easily). In the year 2004, you had equal amounts of data in “odd” code numbers in the CODE_KEY_COLUMN and in “even” code numbers. But in 2005, you knew the number of records associated with the odd code number was more than double, and you wanted to have more subpartitions for the odd code values. You can achieve that rather easily just by defining more subpartitions: ops$tkyte@ORA10G> CREATE TABLE composite_range_list_example 2 ( range_key_column date, 3 code_key_column int, 4 data varchar2(20) 5 ) 6 PARTITION BY RANGE (range_key_column) 7 subpartition by list(code_key_column) 8 ( 9 PARTITION part_1 10 VALUES LESS THAN(to_date('01/01/2005','dd/mm/yyyy')) 11 (subpartition part_1_sub_1 values( 1, 3, 5, 7 ), 12 subpartition part_1_sub_2 values( 2, 4, 6, 8 )

578<br />

CHAPTER 13 ■ PARTITIONING<br />

Figure 13-4. Range-hash composite partition example<br />

So, composite partitioning gives you the ability to break up your data by range <strong>and</strong>, when<br />

a given range is considered too large or further partition elimination could be useful, to break<br />

it up further by hash or list. It is interesting to note that each range partition need not have the<br />

same number of subpartitions; for example, suppose you were range partitioning on a date<br />

column in support of data purging (to remove all old data rapidly <strong>and</strong> easily). In the year 2004,<br />

you had equal amounts of data in “odd” code numbers in the CODE_KEY_COLUMN <strong>and</strong> in “even”<br />

code numbers. But in 2005, you knew the number of records associated with the odd code<br />

number was more than double, <strong>and</strong> you wanted to have more subpartitions for the odd code<br />

values. You can achieve that rather easily just by defining more subpartitions:<br />

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

2 ( range_key_column date,<br />

3 code_key_column int,<br />

4 data varchar2(20)<br />

5 )<br />

6 PARTITION BY RANGE (range_key_column)<br />

7 subpartition by list(code_key_column)<br />

8 (<br />

9 PARTITION part_1<br />

10 VALUES LESS THAN(to_date('01/01/2005','dd/mm/yyyy'))<br />

11 (subpartition part_1_sub_1 values( 1, 3, 5, 7 ),<br />

12 subpartition part_1_sub_2 values( 2, 4, 6, 8 )

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

Saved successfully!

Ooh no, something went wrong!