1 / 63

Partitioning – Let’s Divide and Conquer !

Partitioning – Let’s Divide and Conquer !. Gavin Soorma, Senior Oracle DBA, Bankwest. Agenda. The what, who and why of Partitioning Partitioning – decisions and challenges Partitioning – It’s evolution Types of Partitioning What’s new in Oracle11g? Partitioned Indexes

sloan
Download Presentation

Partitioning – Let’s Divide and Conquer !

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Partitioning – Let’s Divide and Conquer! Gavin Soorma, Senior Oracle DBA, Bankwest

  2. Agenda • The what, who and why of Partitioning • Partitioning – decisions and challenges • Partitioning – It’s evolution • Types of Partitioning • What’s new in Oracle11g? • Partitioned Indexes • Composite Partitioning • Partition Maintenance Operations • Partitioning and the Cost-based Optimizer • Converting a non-partitioned table to a partitioned table

  3. What is Partitioning? a)A Structure dividing a space into parts (noun) b) To divide or separate (verb) Source: Oxford English Dictionary • Additional licensable option of the Oracle Enterprise Edition. • Partitioning allows a table, index or index-organized table to be divided and subdivided into smaller pieces called partitions and sub-partitions. • A partitioned object has multiple pieces that can be managed either collectively or individually. • Each partition has its own name, and may optionally have its own storage characteristics. • Tables are partitioned using a 'partitioning key', a set of column/columns which determine in which partition a given row will reside.

  4. Partitioning stores a data segment (Table, Index, LOB) as multiple segments while retaining a logically massive structure. Really Big Table Partition Partition Partition Partition Partition Partition Really Big Table Partition Partition Partition Partition Partition Partition Partition Partition

  5. Who Partitions? • Deciding on what and how to partition is both a Developer and DBA job. • A good of understanding of the business rules needs to be known about how the data is utilized within Oracle. For example, how data is loaded and queried by the application? • A great portion of care needs to done in selection of the type of partitioning along with the partition key. • Poor selection of partition or partition key could lead to poor DML and DDL performance. • Always test, test, and test again prior to implementing in production.

  6. Why Partition? • For Manageability Partitioning enables data management operations such data loads, index creation and rebuilding, and backup/recovery at the partition level, rather than on the entire table. This results in significantly reduced times for these operations. • For Performance Partitioning improves query performance. In many cases, the results of a query can be achieved by accessing a subset of partitions, rather than the entire table. Partition Pruning and Partition-wise joins can provide order-of-magnitude gains in performance. • For Availability Partitioning increases the availability of mission-critical databases if critical tables and indexes are divided into partitions to reduce the maintenance windows, recovery times, and impact of failures.

  7. Decisions and Challenges • License cost of Partitioning option (~11,000$ per CPU) • Number of Partitions. • Choosing the partitioning key column. • Partitioning Key – single column, multiple column. • Choosing the type of partitioning: Range, Hash-List, Range-Hash, Range-List, List-List, Range-Range …. • Which tables to Partition …. All tables > 2GB (Oracle says so …) • Think about it if table is > 1 million rows (I say so …) • Partitioned tables with non partitioned or partitioned index • Global Index vs Local Index

  8. Oracle Partitioning10 years of innovation…

  9. Partitioning Methods • Oracle provides the following partitioning methods(pre 11g): • Range Partitioning • List Partitioning • Hash Partitioning • Composite Partitioning Composite Partitioning is a combination of the methods shown above

  10. Composite Partitioning Range-List Partitioned by date_of_sale then …. Partitioned by sales_region Range-Hash Partitioned by date_of_sale then …. Partitioned by salesman_id

  11. RANGE Partitioning • Introduced in Oracle 8.0 • Useful when Data has logical ranges into which it can be distributed by – example, a range of dates • Data is mapped to partitions based on ranges of partition key values established for each partition • Each partition has a VALUES LESS THAN clause, which specifies a non inclusive upper bound for the partitions. • All partitions, except the first, have an implicit lower bound specified by the VALUES LESS THAN clause on the previous partition • A MAXVALUE literal can be defined for the highest partition. MAXVALUE represents a virtual infinite value

  12. Range Partitioning Partitioning Method create table order_details (order_id number, order_date date) partition by range(order_date) (partition p_jan values less than (to_date('01-FEB-2009','DD-MON-YYYY')), partition p_feb values less than (to_date('01-MAR-2009','DD-MON-YYYY')), partition p_mar values less than (to_date('01-APR-2009','DD-MON-YYYY')), partition p_2009 values less than (MAXVALUE) ) ; Partitioning Column (Key) Partition descriptions identifying partition bounds

  13. Hash Partitioning • Introduced in Oracle 8i. • Enables partitioning of data that does not lend itself to either range or list partitioning • As a better alternative to range partitioning when: We do not know beforehand how much data maps to a particular range. The size of range partitions would differ substantially. Range partitioning would cause the data to be undesirably clustered.

  14. Hash Partitioning • Hash function applied to the partitioning key column to place row in required partition. • Balances the data distribution between all partitions. • Is an effective means of distributing data, because Oracle hashes the data into a number of partitions, each of which can reside on a separate device. • Hash Partitioning enables the use of performance features like Partition-wise joins when two tables are hash partitioned on the join key.

  15. Hash Partitioning • Not suitable for purging and archiving data models. • Partition pruning is limited to using equality or IN-list predicates. • User has no control of the row to partition mapping. • Partition maintenance tasks like splitting, dropping and merging cannot be carried out. • Partitions can only be added and coalesced.

  16. CREATE TABLE employees ( empno NUMBER(4), ename VARCHAR2(30), sal NUMBER ) PARTITION BY HASH (empno) ( PARTITION h1 TABLESPACE t1, PARTITION h2 TABLESPACE t2, PARTITION h3 TABLESPACE t3, PARTITION h4 TABLESPACE t4 ); CREATE TABLE employees ( empno NUMBER(4), ename VARCHAR2(30), sal NUMBER ) PARTITION BY HASH(empno) PARTITIONS 3 STORE IN (t1,t2,t3) ;

  17. List Partitioning • Introduced in Oracle 9i. • List Partitioning is useful for data that has discrete or distinct values. • Enables to group and organize unordered and unrelated sets of data. • Gives data warehouse administrators precise control over which data belongs in each partition. • Enables the partitioning strategy to closely model underlying business processes. • Unlike range and hash partitioning, multicolumn partition keys are not supported for list partitioning.

  18. CREATE TABLE sales_list (salesman_id NUMBER(5), salesman_name VARCHAR2(30), sales_state VARCHAR2(20), sales_amount NUMBER(10), sales_date DATE) PARTITION BY LIST(sales_state) ( PARTITION sales_west VALUES ('California', 'Hawaii'), PARTITION sales_east VALUES ('New York', 'Virginia', 'Florida'), PARTITION sales_central VALUES ('Texas', 'Illinois'), PARTITION sales_other VALUES (DEFAULT) );

  19. 11g Interval partitioning • Pre 11g new partitions must be created in advance for new data. • Additional partitioning management overhead. • 11g interval partitioning automates partition management. • Extension of range partitioning. • Automatic creation of range partitions based on interval. • Segments are allocated as soon as new data arrives. • Local indexes are created and maintained as well

  20. CREATE TABLE order_details (order_id NUMBER, order_date DATE) PARTITION BY RANGE (order_date) INTERVAL (NUMTOYMINTERVAL(1,'MONTH')) (PARTITION P_FIRST VALUES LESS THAN ('01-JAN-2009')) ; SQL> select partition_name from user_tab_partitions where table_name='ORDER_DETAILS'; PARTITION_NAME ------------------------------ P_FIRST

  21. SQL> insert into order_details values (10001,'15-JAN-2009'); 1 row created. SQL> commit; Commit complete. SQL> select partition_name from user_tab_partitions where table_name='ORDER_DETAILS'; PARTITION_NAME ------------------------------ P_FIRST SYS_P101

  22. REF Partitioning • Related tables benefit from the same partitioning strategy. Example:Orders and Line Items table • Redundant storage of the same data solves the problem. But Data and maintenance overhead … • Oracle 11g introduces REF partitioning Child table inherits the same partitioning strategy as the parent table via PK-FK relationships. Enhanced performance as well as manageability. Partition maintenance operations on parent table cascade to child table.

  23. Before REF Partitioning Table ORDERS RANGE (order_date) … … PRIMARY KEY (order_id) Jan 2009 Feb 2009 Dec 2009 Redundant storage of order_date Table LINEITEMS RANGE (order_date) FOREIGN KEY (order_id) … … Jan 2009 Feb 2009 Dec 2009

  24. 11g REF Partitioning Table ORDERS RANGE (order_date) … … PRIMARY KEY (order_id) Jan 2009 Feb 2009 Partition By Reference Partitioning Key in Child Table Inherited through PK-FK relationship Table LINEITEMS RANGE (order_date) FOREIGN KEY (order_id) … … Jan 2009 Feb 2009

  25. CREATE TABLE mycustomers (cust_id NUMBER, cust_first_name VARCHAR2(20), cust_last_name VARCHAR2(20), cust_gender CHAR(1)) PARTITION BY LIST (cust_gender) (PARTITION p_male VALUES ('M'), PARTITION p_female VALUES ('F') ); SQL> ALTER TABLE mycustomers ADD CONSTRAINT p_cust_id PRIMARY KEY (cust_id); Table altered.

  26. CREATE TABLE mysales (cust_id NUMBER NOT NULL, quantity_sold NUMBER(10,2), amount_sold NUMBER(10,2), CONSTRAINT fk_sales_01 FOREIGN KEY (cust_id) REFERENCES mycustomers(cust_id)) PARTITION BY REFERENCE (fk_sales_01); SQL> SELECT TABLE_NAME, PARTITIONING_TYPE, REF_PTN_CONSTRAINT_NAME FROM USER_PART_TABLES WHERE TABLE_NAME IN ('MYCUSTOMERS','MYSALES'); TABLE_NAME PARTITION REF_PTN_CONSTRAINT_NAME ------------------------------ --------- -------------------------- MYCUSTOMERS LIST MYSALES REFERENCE FK_SALES_01

  27. Extended Composite Partitioning Data is partitioned along two dimesions Introduced in Oracle 8i with Range/Hash 9i extended to Range/List 11g extended to all combinations Range/Range Order Date, Shipping Date List/Range Salesman, Date of Sale List/List State, County

  28. Range-Range Partitioning Ship_date … Jan 08 Feb 08 … … … … … Dec 08 … … … … … Jan 08 Feb 08 Mar 08 Dec 08 Order_date

  29. 11g Virtual Column Partitioning • Virtual columns introduced in Oracle 11g. • Virtual columns using functions and expressions. • Virtual column not stored physically. • Partition data as per business rules and requirements – not just based on application requirements. • Treated as real columns – only DML not allowed. • Enhanced performance and manageability

  30. CREATE TABLE emp_year_sal (ename VARCHAR2(20), sal NUMBER, yearly_sal AS (sal*12) VIRTUAL) PARTITION BY RANGE (yearly_sal) (PARTITION low_sal VALUES LESS THAN (20000), PARTITION mid_sal VALUES LESS THAN (40000), PARTITION high_sal VALUES LESS THAN (60000), PARTITION others VALUES LESS THAN (MAXVALUE)); SQL> SELECT ename,sal,yearly_sal FROM emp_year_sal; ENAME SAL YEARLY_SAL ---------- ---------- ---------- SMITH 800 9600 ALLEN 1600 19200 WARD 1250 15000 JONES 2975 35700 MARTIN 1250 15000 BLAKE 2850 34200 CLARK 2450 29400 SCOTT 3000 36000

  31. SQL> SELECT ename,sal,yearly_sal FROM emp_year_sal PARTITION (low_sal); ENAME SAL YEARLY_SAL -------------------- ---------- ---------- SMITH 800 9600 ALLEN 1600 19200 WARD 1250 15000 MARTIN 1250 15000 TURNER 1500 18000 ADAMS 1100 13200 SQL> SELECT ename,sal,yearly_sal FROM emp_year_sal PARTITION(mid_sal); ENAME SAL YEARLY_SAL -------------------- ---------- ---------- JONES 2975 35700 BLAKE 2850 34200 CLARK 2450 29400 SCOTT 3000 36000 FORD 3000 36000

  32. 10g Partitioning - Summary

  33. 11g Partitioning - Summary

  34. Partition Data Dictionary Views • DBA_PART_TABLES • DBA_TAB_PARTITIONS • DBA_TAB_SUBPARTITIONS • DBA_PART_KEY_COLUMNS • DBA_PART_HISTOGRAMS • DBA_PART_INDEXES • DBA_IND_PARTITIONSDBA_IND_SUBPARTITIONS

  35. Working with Partitions SQL> select order_date from order_details partition(p_jan); SQL> select count(*) from SALES_DATA_COMP subpartition(SALES_2000_SP2); $ exp system/manager TABLES=(order_details:p_jan) $ exp system/manager TABLES=(order_details:p_jan, order_details:p_jan_subpart1)

  36. Local and Global Indexes LOCAL INDEX Index partition equipartitioned with table Single index partition only contains rows from corresponding table partition GLOBAL INDEX Index partition can contain rows from several table partitions

  37. LOCAL Partitioned Index • Equi-partitioned – each partition of local index exactly associated with corresponding partition of the table. • Cannot explicitly add or drop local index partitions – partitions to the index are added or dropped based on partitions being added or dropped from base table. • Provide higher availability and ease of maintenance. • Partition maintenance operations on base table will only affect corresponding local index partition – other partitions of the index are not affected improving availability. • Most suited for DSS environments - easier to manage during data loads and during partition-maintenance operations

  38. SQL> select partition_name from user_tab_partitions where table_name='ORDER_DETAILS'; PARTITION_NAME --------------- P_FIRST SYS_P81 SYS_P82 SQL> create index order_det_ind_local on order_details (order_date) LOCAL << NO PARTITIONING KEY DEFINED (partition p1_ind tablespace users, partition p2_ind tablespace example); create index order_det_ind_local on order_details (order_date) * ERROR at line 1: ORA-14024: number of partitions of LOCAL index must equal that of the underlying table

  39. SQL> create index order_det_ind_local on order_details (order_date) LOCAL tablespace example; Index created. SQL> select partition_name,tablespace_name from user_ind_partitions where index_name='ORDER_DET_IND_LOCAL'; PARTITION_NAME TABLESPACE_NAME --------------- ------------------------------ P_FIRST EXAMPLE SYS_P102 EXAMPLE SYS_P103 EXAMPLE

  40. Global Partitioned Index • Index partitioning key is independent of the table partitioning method. • Better suited for OLTP environments than local indexes. • Better performance as they minimise the number of index partition probes. • Lower availability than local indexes as partition maintenance operations can affect all the index partitions.

  41. Global Partitioned Indexes • Highest partition of the global index needs to have a MAXVALUE clause to ensure all rows of the underlying table are represented – this partition cannot be dropped. • Can be created as a global hash or global range partitioned index. • Can enable partition pruning to take place at the index level even if not possible on the underlying partitioned table

  42. Table Partitioned on order_date CREATE INDEX order_id_ind_global ON order_details (order_id) GLOBAL PARTITION BY RANGE (order_id) (PARTITION p_ind1 values less than (100001), PARTITION p_ind2 values less than (200001), PARTITION p_ind3 values less than (300001)); PARTITION p_ind3 values less than (300001)) * ERROR at line 6: ORA-14021: MAXVALUE must be specified for all columns CREATE INDEX order_id_ind_global ON order_details (order_id) GLOBAL PARTITION BY RANGE (order_id) (PARTITION p_ind1 values less than (100001), PARTITION p_ind2 values less than (200001), PARTITION p_ind3 values less than (300001), PARTITION p_ind_others values less than (MAXVALUE));

  43. Partition Maintenance Operations • Add • Coalesce • Drop • Truncate • Split • Exchange • Move • Rename • Merge …. Consider the effect of these operations on Index partitions …..

  44. Partition Maintenance ALTER TABLE sales ADD PARTITION jan96 VALUES LESS THAN ( '01-FEB-1999' ) TABLESPACE tsx; ALTER TABLE scubagear ADD PARTITION p_named TABLESPACE gear5; ALTER TABLE parts MOVE PARTITION depot2 TABLESPACE ts094 NOLOGGING COMPRESS; ALTER TABLE order_details SPLIT PARTITION p_2009 AT (TO_DATE ('01-JUL-2009','DD-MON-YYYY')) INTO (PARTITION p_2009h1, PARTITION p_2009h2); ALTER TABLE four_seasons MERGE PARTITIONS quarter_one, quarter_two INTO PARTITION quarter_two ;

  45. Index Maintenance • Indexes in UNUSABLE state is one of the major issues in dealing with partitioned tables and indexes. • SELECT or DML statement that accesses index in such state will return an ORA-01502 error. • Partition maintenance operations will mark the affected local index partition and ALL global index partitions as UNUSABLE. ALTER TABLE MOVE PARTITION ALTER TABLE SPLIT PARTITION ALTER TABLE TRUNCATE PARTITION ALTER INDEX SPLIT PARTITION • SQL*Loader operations which bypass index maintenance

  46. LOCAL Index SQL> SELECT PARTITION_NAME FROM USER_IND_PARTITIONS WHERE INDEX_NAME='SALES_DATA_IND'; PARTITION_NAME ------------------------------ SALES_1998 SALES_1999 SALES_2000 SALES_2001 P_2009 SQL> ALTER TABLE sales_data MOVE PARTITION sales_1999 TABLESPACE users; Table altered. SQL> SELECT PARTITION_NAME,STATUS FROM USER_IND_PARTITIONS WHERE INDEX_NAME='SALES_DATA_IND'; PARTITION_NAME STATUS ------------------------------ -------- SALES_1998 USABLE SALES_1999 UNUSABLE SALES_2000 USABLE SALES_2001 USABLE P_2009 USABLE

  47. SQL> ALTER TABLE sales_data TRUNCATE PARTITION sales_1999_h2; Table truncated. SQL> select partition_name,status from user_ind_partitions where index_name='PROD_ID_IND'; PARTITION_NAME STATUS ------------------------------ -------- P1 UNUSABLE P2 UNUSABLE P_OTHERS UNUSABLE ALL Global Index Partitions are marked as UNUSABLE even though only one single table partition has been accessed

  48. SQL> SELECT COUNT (*) FROM sales_data WHERE time_id ='01-DEC-1999' * ERROR at line 1: ORA-01502: index 'SH.SALES_DATA_IND' or partition of such index is in unusable state SQL> ALTER SESSION SET SKIP_UNUSABLE_INDEXES=TRUE; System altered. SQL> SELECT COUNT (*) FROM sales_data WHERE time_id ='01-DEC-1999‘ COUNT(*) ---------- 310

  49. SQL> EXPLAIN PLAN FOR SELECT COUNT(*) FROM sales_data WHERE time_id ='01-DEC-1999'; Explained. SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY); PLAN_TABLE_OUTPUT ------------------------------------------------------------------------------------------------------ Plan hash value: 1021418022 ------------------------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | ------------------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 1 | 9 | 342 (26)| 00:00:05 | | | | 1 | SORT AGGREGATE | | 1 | 9 | | | | | | 2 | PARTITION RANGE SINGLE| | 276 | 2484 | 342 (26)| 00:00:05 | 2 | 2 | |* 3 | TABLE ACCESS FULL | SALES_DATA | 276 | 2484 | 342 (26)| 00:00:05 | 2 | 2 | ------------------------------------------------------------------------------------------------------ Because index partition is in an UNUSABLE state, a full table scan is being performed of the SALES_DATA table

  50. SQL> ALTER INDEX sales_data_ind REBUILD PARTITION sales_1999; Index altered. SQL> EXPLAIN PLAN FOR SELECT COUNT(*) FROM sales_data WHERE time_id ='01-DEC-1999'; Explained. SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY); PLAN_TABLE_OUTPUT ------------------------------------------------------------------------------------------------------------------------ Plan hash value: 3608419564 ---------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | ---------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 9 | 5 (0)| 00:00:01 | | | | 1 | SORT AGGREGATE | | 1 | 9 | | | | | | 2 | PARTITION RANGE SINGLE| | 310 | 2790 | 5 (0)| 00:00:01 | 2 | 2 | |* 3 | INDEX RANGE SCAN | SALES_DATA_IND | 310 | 2790 | 5 (0)| 00:00:01 | 2 | 2 | ----------------------------------------------------------------------------------------------------------

More Related