2Agenda The what, who and why of Partitioning Partitioning – decisions and challengesPartitioning – It’s evolutionTypes of PartitioningWhat’s new in Oracle11g?Partitioned IndexesComposite PartitioningPartition Maintenance OperationsPartitioning and the Cost-based OptimizerConverting a non-partitioned table to a partitioned table
3What is Partitioning?a) A Structure dividing a space into parts (noun)b) To divide or separate (verb)Source: Oxford English DictionaryAdditional 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.
4Partitioning stores a data segment (Table, Index, LOB) as multiple segments while retaining a logically massivestructure.Really BigTablePartitionPartitionPartitionPartitionPartitionPartitionReally Big TablePartitionPartitionPartitionPartitionPartitionPartitionPartitionPartition
5Who 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.
6Why Partition? For Manageability For Performance For Availability 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 PerformancePartitioning 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 AvailabilityPartitioning 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.
7Decisions 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 indexGlobal Index vs Local Index
8Oracle Partitioning 10 years of innovation… Database ReleaseCore FunctionalityOracle 8.0 (1997)Range PartitioningOracle 8iHash and Composite PartitioningOracle 9iList PartitioningOracle 9i Release 2Composite Range-List PartitioningOracle 10gGlobal Hash IndexesOracle 10g Release 21M partitions per tableOracle 11gInterval Partitioning, System Partitioning, REF Partitioning, Virtual Column Partitioning, Partition Advisor , Composite All Partitioning
9Partitioning MethodsOracle provides the following partitioning methods(pre 11g):Range PartitioningList PartitioningHash PartitioningComposite PartitioningComposite Partitioning is a combination of the methods shown above
10Composite Partitioning Range-HashPartitioned by date_of_salethen ….Partitioned by salesman_idRange-ListPartitioned by date_of_salethen ….Partitioned by sales_region
11RANGE Partitioning Introduced in Oracle 8.0 Useful when Data has logical ranges into which it can be distributed by – example, a range of datesData is mapped to partitions based on ranges of partition key values established for each partitionEach 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 partitionA MAXVALUE literal can be defined for the highest partition. MAXVALUE represents a virtual infinite value
12Partition descriptions identifying partition bounds Range PartitioningPartitioning Methodcreate 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
13Hash PartitioningIntroduced in Oracle 8i.Enables partitioning of data that does not lend itself to either range or list partitioningAs 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.
14Hash PartitioningHash 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.
15Hash 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.
16CREATE 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);PARTITION BY HASH(empno)PARTITIONS 3STORE IN (t1,t2,t3);
17List 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.
1911g 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
20CREATE 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_partitionswhere table_name='ORDER_DETAILS';PARTITION_NAMEP_FIRST
21SQL> insert into order_details values(10001,'15-JAN-2009');1 row created.SQL> commit;Commit complete.SQL> select partition_name from user_tab_partitionswhere table_name='ORDER_DETAILS';PARTITION_NAMEP_FIRSTSYS_P101
22REF PartitioningRelated tables benefit from the same partitioning strategy.Example:Orders and Line Items tableRedundant storage of the same data solves the problem.But Data and maintenance overhead …Oracle 11g introduces REF partitioningChild 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.
2411g REF Partitioning … Table ORDERS RANGE (order_date) … PRIMARY KEY (order_id)Jan 2009Feb 2009Partition By ReferencePartitioning Key in Child TableInherited through PK-FKrelationshipTable LINEITEMSRANGE(order_date)FOREIGN KEY(order_id)……Jan 2009Feb 2009
25CREATE 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.
26CREATE TABLE mysales(cust_id NUMBER NOT NULL, quantity_sold NUMBER(10,2),amount_sold NUMBER(10,2),CONSTRAINT fk_sales_01FOREIGN 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 WHERETABLE_NAME IN ('MYCUSTOMERS','MYSALES');TABLE_NAME PARTITION REF_PTN_CONSTRAINT_NAMEMYCUSTOMERS LISTMYSALES REFERENCE FK_SALES_01
27Extended Composite Partitioning Data is partitioned along two dimesionsIntroduced in Oracle 8i with Range/Hash9i extended to Range/List11g extended to all combinationsRangeListHash11g9i8iRange/Range Order Date, Shipping DateList/Range Salesman, Date of SaleList/List State, County
2911g 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
30CREATE 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_SALSMITHALLENWARDJONESMARTINBLAKECLARKSCOTT
31SQL> SELECT ename,sal,yearly_sal FROM emp_year_sal PARTITION (low_sal); SMITHALLENWARDMARTINTURNERADAMSSQL> SELECT ename,sal,yearly_sal FROM emp_year_sal PARTITION(mid_sal);JONESBLAKECLARKSCOTTFORD
3210g Partitioning - Summary Partitioning StrategyData DistributionSample Business UsageRange PartitioningBased on consecutive ranges of valuesOrders table rangepartitioned by order_dateList PartitioningBased on unordered lists ofvalues.Orders table list partitionedby countryHash PartitioningBased on a hash algorithm.Orders table hash partitionedby customer_idComposite PartitioningRange-RangeRange-ListRange-HashList-ListList-RangeList-HashBased on a combination of two of the above-mentioned basictechniques of Range, List,Hash, and Interval PartitioningOrders table is rangeand sub-partitioned by hashon customer_idand sub-partitioned by rangeon shipment_date
3311g Partitioning - Summary Partitioning ExtensionPartitioning KeySample Business UsageInterval PartitioningIntervalInterval-RangeInterval-ListInterval-HashAn extension to RangePartition. Defined by aninterval, providing equi-widthranges. With the exception ofthe first partition all partitionsare automatically created ondemandwhen matching dataarrives.Orders table partitioned byorder_date with a predefineddaily interval, starting with'01-Jan-2007'REF PartitioningPartitioning for a child table isinherited from the parent tablethrough a primary key –foreign key relationship. Thepartitioning keys are not storedin actual columns in the childtable.(Parent) Orders table rangepartitioned by order_dateand inherits the partitioningtechnique to (child) orderlines table. Columnorder_date is only present inthe parent orders tableVirtual column basedPartitioningDefined by one of the abovementionedpartition techniquesand the partitioning key isbased on a virtual column.Virtual columns are not storedon disk and only exist asmetadata.Orders table has a virtualcolumn that derives the salesregion based on the firstthree digits of the customeraccount number. The orderstable is then list partitionedby sales region.
34Partition Data Dictionary Views DBA_PART_TABLESDBA_TAB_PARTITIONSDBA_TAB_SUBPARTITIONSDBA_PART_KEY_COLUMNSDBA_PART_HISTOGRAMSDBA_PART_INDEXESDBA_IND_PARTITIONS DBA_IND_SUBPARTITIONS
35Working 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)
36Local and Global Indexes LOCAL INDEXIndex partitionequipartitionedwith tableSingle index partitiononly contains rows fromcorresponding table partitionGLOBAL INDEXIndex partition cancontain rows fromseveral tablepartitions
37LOCAL 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
38SQL> select partition_name from user_tab_partitions where table_name='ORDER_DETAILS'; P_FIRSTSYS_P81SYS_P82SQL> 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
39SQL> create index order_det_ind_local on order_details (order_date) tablespace example;Index created.SQL> select partition_name,tablespace_name from user_ind_partitions where index_name='ORDER_DET_IND_LOCAL';PARTITION_NAME TABLESPACE_NAMEP_FIRST EXAMPLESYS_P EXAMPLESYS_P EXAMPLE
40Global 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.
41Global 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
42Table 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 columnsTable Partitionedon order_dateCREATE INDEX order_id_ind_globalON 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));
43Partition Maintenance Operations AddCoalesceDropTruncateSplitExchangeMoveRenameMerge….Consider the effect of these operations on Index partitions …..
44Partition 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 ts094NOLOGGING COMPRESS;ALTER TABLE order_detailsSPLIT 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 ;
45Index MaintenanceIndexes 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 error.Partition maintenance operations will mark the affected local index partition and ALL global index partitions as UNUSABLE.ALTER TABLE MOVE PARTITIONALTER TABLE SPLIT PARTITIONALTER TABLE TRUNCATE PARTITIONALTER INDEX SPLIT PARTITIONSQL*Loader operations which bypass index maintenance
46LOCAL Index SQL> SELECT PARTITION_NAME FROM USER_IND_PARTITIONS WHERE INDEX_NAME='SALES_DATA_IND';PARTITION_NAMESALES_1998SALES_1999SALES_2000SALES_2001P_2009SQL> 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 STATUSSALES_ USABLESALES_ UNUSABLESALES_ USABLESALES_ USABLEP_ USABLELOCAL Index
47ALL Global Index Partitions are marked as UNUSABLE 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 STATUSP UNUSABLEP UNUSABLEP_OTHERS UNUSABLEALL Global Index Partitions are marked as UNUSABLEeven though only one single table partition has been accessed
48SQL> 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 stateSQL> ALTER SESSION SET SKIP_UNUSABLE_INDEXES=TRUE;System altered.WHERE time_id ='01-DEC-1999‘COUNT(*)310
49performed of the SALES_DATA table SQL> EXPLAIN PLAN FOR SELECT COUNT(*) FROM sales_dataWHERE time_id ='01-DEC-1999';Explained.SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);PLAN_TABLE_OUTPUTPlan hash value:| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop || 0 | SELECT STATEMENT | | | | (26)| 00:00:05 | | || 1 | SORT AGGREGATE | | | | | | | || 2 | PARTITION RANGE SINGLE| | | | (26)| 00:00:05 | | ||* 3 | TABLE ACCESS FULL | SALES_DATA | | | (26)| 00:00:05 | | |Because index partition is in an UNUSABLE state, a full table scan is beingperformed of the SALES_DATA table
50SQL> 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_OUTPUTPlan hash value:| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop || 0 | SELECT STATEMENT | | | | (0)| 00:00:01 | | || 1 | SORT AGGREGATE | | | | | | | || 2 | PARTITION RANGE SINGLE| | | | (0)| 00:00:01 | | ||* 3 | INDEX RANGE SCAN | SALES_DATA_IND | | | (0)| 00:00:01 | | |
51Update Global IndexesBy default, many table maintenance operations on partitioned tables invalidate (mark UNUSABLE) global indexes.We can override this default behaviour if you specify UPDATE GLOBAL INDEXES.Partition DDL statement takes longer to execute since indexes which were previously marked UNUSABLE are updatedSQL> ALTER TABLE sales_data move partition sales_2000 tablespace example UPDATE GLOBAL INDEXES;SQL> SELECT PARTITION_NAME,STATUS FROM USER_IND_PARTITIONS WHERE INDEX_NAME='PROD_ID_IND';PARTITION_NAME STATUSP USABLEP USABLEP_OTHERS USABLE
52Partition Pruning Very important feature for VLDB and Data Warehouses. CBO eliminates unneeded partitions when building a partition access list.Operations performed only on partitions relevant to the SQL statement dramatically reduce the amount of disk reads as well as CPU time.If using global partitioned indexes, can perform partition pruning on the index partitions by eliminating index partitions even if table partitions cannot be eliminatedRange Partitioningrange, equality and IN-list predicatesHash Partitioningequality and IN-list predicates
53SQL> EXPLAIN PLAN FOR SELECT COUNT( SQL> EXPLAIN PLAN FOR SELECT COUNT(*) FROM sales_data WHERE time_id='21-JAN-2000';Explained.SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);PLAN_TABLE_OUTPUTPlan hash value:| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop || 0 | SELECT STATEMENT | | | | (3)| 00:00:03 | | || 1 | SORT AGGREGATE | | | | | | | || 2 | PARTITION RANGE SINGLE| | | | (3)| 00:00:03 | | ||* 3 | TABLE ACCESS FULL | SALES_DATA | | | (3)| 00:00:03 | | |The Pstart and Pstop columns indicate that a single partition has been accessedby the optimizer even though the “TABLE ACCESS FULL” operation is indicated
54Partition-wise JoinsSignificantly improve the performance when joining tables with millions of rows.Useful in VLDB and DSS environments.Applies to Merge and Hash joins and not to Nested Loop joins.Two tables that are equi-partitioned on the join column.Optimizer breaks the join operation into a number of smaller joins that can be performed sequentially or in parallel.If using parallel joins, will minimise the data exchanged by parallel slaves
55Both tables are hash partitioned on the CUST_ID column CREATE TABLE "SH"."SALES_DATA_HASH"( "PROD_ID" NUMBER NOT NULL ENABLE,"CUST_ID" NUMBER NOT NULL ENABLE,"TIME_ID" DATE NOT NULL ENABLE,"CHANNEL_ID" NUMBER NOT NULL ENABLE,"PROMO_ID" NUMBER NOT NULL ENABLE,"QUANTITY_SOLD" NUMBER(10,2) NOT NULL ENABLE,"AMOUNT_SOLD" NUMBER(10,2) NOT NULL ENABLE)PCTFREE 5 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS NOLOGGINGPARTITION BY HASH ("CUST_ID")PARTITIONS 4STORE IN (EXAMPLE, USERS);CREATE TABLE SH.CUSTOMERS_HASH(CUST_ID NUMBER,CUST_FIRST_NAME VARCHAR2(20),CUST_LAST_NAME VARCHAR2(40),CUST_CITY VARCHAR2(30))PARTITION BY HASH (CUST_ID)Both tables are hash partitioned on the CUST_ID column
56SQL> EXPLAIN PLAN FOR SELECT SUM (a.amount_sold),b.cust_city FROM sales_data_hash a, customers_hash bWHERE a.cust_id =b.cust_idGROUP BY b.cust_city;Explained.PLAN_TABLE_OUTPUTPlan hash value:| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop || 0 | SELECT STATEMENT | | 839K| 44M| (10)| 00:00:14 | | || 1 | HASH GROUP BY | | 839K| 44M| (10)| 00:00:14 | | || 2 | PARTITION HASH ALL | | 839K| 44M| (4)| 00:00:14 | | ||* 3 | HASH JOIN | | 839K| 44M| (4)| 00:00:14 | | || 4 | TABLE ACCESS FULL| CUSTOMERS_HASH | | 1818K| (2)| 00:00:01 | | || 5 | TABLE ACCESS FULL| SALES_DATA_HASH | 839K| 20M| (3)| 00:00:13 | | |
57Note the physical reads and consistent Statistics7 recursive calls0 db block gets4794 consistent gets296 physical reads0 redo sizebytes sent via SQL*Net to client932 bytes received via SQL*Net from client42 SQL*Net roundtrips to/from client2 sorts (memory)0 sorts (disk)6039 consistent gets4100 physical reads608 rows processedNote the physical reads and consistentgets using the Partition wise join on HashPartitioned versus Non Partitioned tables
58Using DBMS_REDEFINITION SQL> EXEC DBMS_REDEFINITION.CAN_REDEF_TABLE('SH','SALES_NO_PART');PL/SQL PROCEDURE SUCCESSFULLY COMPLETED.CREATE TABLE "SH"."SALES_INTERIM"( "PROD_ID" NUMBER NOT NULL ENABLE,...) PCTFREE 5 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESSTABLESPACE "EXAMPLE"PARTITION BY RANGE ("TIME_ID")(PARTITION SALES_1998 VALUES LESS THAN (TO_DATE('01-JAN-1999','DD-MON-YYYY')),PARTITION SALES_2001 VALUES LESS THAN (TO_DATE('01-JAN-2002','DD-MON-YYYY')),PARTITION P_2009 VALUES LESS THAN (MAXVALUE));
60SQL> SELECT PARTITION_NAME FROM USER_TAB_PARTITIONS WHERE TABLE_NAME='SALES_NO_PART'; PARTITION_NAMESALES_1998SALES_1999SALES_2000SALES_2001P_2009SQL> SELECT COUNT(*) FROM SALES_NO_PART PARTITION(SALES_1999);COUNT(*)247945SQL> DROP TABLE SALES_INTERIM;TABLE DROPPED.
61Exchange PartitionSQL> select partition_name from user_tab_partitions where table_name='SALES_NO_PART';PARTITION_NAMESALES_1998SALES_1999SALES_2000SQL> select count(*) from sales_2001; << NON PARTITIONED TABLECOUNT(*)259418SQL> alter table sales_no_part add partition sales_20012 values less than ('01-JAN-2002') tablespace example;Table altered.
62SQL> select partition_name from user_tab_partitions where table_name='SALES_NO_PART'; SALES_1998SALES_1999SALES_2000SALES_2001SQL> ALTER TABLE sales_no_partEXCHANGE PARTITION sales_2001WITH TABLE sales_2001UPDATE GLOBAL INDEXES;Table altered.SQL> select count(*) from sales_no_part partition(sales_2001);COUNT(*)259418
63THANKS FOR ATTENDING! Gavin Soorma firstname.lastname@example.org Phone: