You want the new rows to be evenly distributed across four partitions; therefore, hash
partitioning would be the best choice. Here is the SQL you use to create a hash-partitioned table:
create table oe.cust
(cust_num number not null primary key,
ins_dt date,
first_nm varchar2(25),
last_nm varchar2(35),
mi char(1),
addr1 varchar2(40),
addr2 varchar2(40),
city varchar2(40),
state_cd char(2),
zip_cd varchar2(10))
partition by hash (cust_num)
partitions 4
store in (prd01, prd02, prd03, prd04);
You do not necessarily have to specify the same number of partitions as tablespaces; if you
specify more partitions than tablespaces, the tablespaces are reused for subsequent partitions in a
round-robin fashion. If you specify fewer partitions than tablespaces, the extra tablespaces at the
end of the tablespace list are ignored.
If you run the same queries that you ran for range partitioning, you may find some unexpected
results, as you can see in this query:
SQL> select partition_name, tablespace_name, high_value
2 from dba_tab_partitions
3 where table_name = 'CUST';
PARTITION_NAME TABLESPACE_NAME HIGH_VALUE
-------------------- --------------- --------------------
SYS_P1130 PRD01
SYS_P1131 PRD02
SYS_P1132 PRD03
SYS_P1133 PRD04
4 rows selected.
Because you are using hash partitioning, the HIGH_VALUE column is NULL.
?–
?–
?–
Chapter 16: Managing Large Databases 561
TIP
Oracle strongly recommends that the number of partitions in a hash
partitioned table be to a power of 2 to get an even distribution of rows
in each table; Oracle uses the low order bits of the partition key to
determine the destination partition for the row.
Pages:
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839