Using Database Partitioning with Oracle E-Business Suite

An Oracle White Paper March 2009

Using Database Partitioning with Oracle E-Business Suite

Page 2

Using Database Partitioning with Oracle E-Business Suite

OVERVIEW...................................................................................................... 6 INTRODUCTION .......................................................................................... 6 What is partitioning and How does it work?................................................. 7 Partitioning for Performance - Partition Pruning ............................... 7 Partition-wise Joins .................................................................................. 8 Table Availability/Improved Manageability......................................... 8 Performance – The Need for Speed...................................................... 8 Physical Organization and Reduction in Total Cost of Ownership (TCO)......................................................................................................... 8 Partitioning Concepts ....................................................................................... 9 Partition Key.................................................................................................. 9 Table Partitions ............................................................................................. 9 The Evolution of Partitioning ......................................................................... 9 Partitioning AND Oracle E-Business Suite ................................................ 10 Using Database Partitioning with the Oracle E-Business Suite........... 10 What Does "Supported" Mean in Practical Terms?.......................... 10 What Is Custom Partitioning? .............................................................. 10 Examples of Custom Partitioning ....................................................... 11 Example of Creating a Partitioned Table ........................................... 11 Table Partitioning STRATEGY.................................................................... 12 Multicolumn Partition Key ................................................................... 12 Table Type............................................................................................... 12 Range Partitioning ...................................................................................... 13 Example range partitioning creation script ........................................ 13 Summary.................................................................................................. 14 List Partitioning........................................................................................... 14 Example list partitioning creation script ............................................. 15 Summary.................................................................................................. 15 Hash Partitioning ........................................................................................ 15 Example hash partitioning creation script.......................................... 16 Summary.................................................................................................. 16 Composite Partitioning .............................................................................. 16 Example composite partitioning script ............................................... 17

Using Database Partitioning with Oracle E-Business Suite

Page 3

Summary.................................................................................................. 17 Multicolumn Partitioning........................................................................... 18 PARTITIONING INDEXES...................................................................... 18 Automatically Maintaining Indexes ..................................................... 19 Global Partitioned Indexes........................................................................ 19 Prefixed and Non-prefixed Indexes .................................................... 19 Maintaining Global Partitioned Indexes ............................................. 20 Maintaining Global Hash Partitioned Indexes................................... 20 Local Partitioned Indexes .......................................................................... 21 Local Prefixed and Non-Prefixed (Partitioned Indexes).................. 21 Global Nonpartitioned Indexes ........................................................... 21 Performance Considerations regarding Prefixed and Nonprefixed Indexes..................................................................................................... 22 Summary ...................................................................................................... 22 Maintenance of Partitioned Tables & Indexes ....................................... 23 Partition Maintenance Operations and Table Partitioning Methods .. 24 Partition Maintenance Operations and Index Type/Partitioning Methods........................................................................................................ 25 Table and key compression............................................................................ 25 Implementing Compression...................................................................... 27 Creating a Compressed Table ................................................................... 27 Converting Tables to Compressed Tables: ............................................. 27 Before compression: .............................................................................. 27 After Compression:................................................................................ 28 Example of Compressing Large Tables (Large Volume Oracle EBusiness Suite Customer 10.5TB Database)........................................... 28 Before compression: .............................................................................. 28 After Compression:................................................................................ 28 OVERVIEW.................................................................................................... 29 When To Use Partitioning? ........................................................................... 29 Reasons for Creating Partitioned Tables/Indexes................................. 29 Step 1 – Is Partitioning Necessary? .......................................................... 29 Step 2 - Should This Object Be Partitioned?.......................................... 30 Step 3 - Which Partitioning Method Should Be Used?......................... 31 Step 4 - Identify the Partition Key ........................................................... 31 Step 5 – Performance Check & Access Path Analysis .......................... 32 Step 6 – Partitioned Table Creation and Data Migration ..................... 32 Method: 1 – Straight Insert................................................................... 33 Oracle Data Pump ................................................................................. 34 Method 2 – Import/Export using Data Pump.................................. 35 Step 7 – Maintenance Step ........................................................................ 35 Partition Maintenance Operations................................................................ 35 Adding a Partition or Subpartition........................................................... 36 Range and List Partitions ...................................................................... 36 Hash and Hash Subpartition ................................................................ 36 Dropping Partitions.................................................................................... 37

Using Database Partitioning with Oracle E-Business Suite

Page 4

Table Partitions....................................................................................... 37 Index Partitions ...................................................................................... 37 Moving Partitions ....................................................................................... 38 Table Partitions....................................................................................... 38 Index Partitions ...................................................................................... 38 Splitting Partitions ...................................................................................... 38 Table Partitions....................................................................................... 39 Index Partitions ...................................................................................... 39 Merging Partitions ...................................................................................... 39 Table Partitions....................................................................................... 39 Index Partitions ...................................................................................... 40 Exchanging a Partition with a Table ........................................................ 40 Renaming Partitions ................................................................................... 40 Example of How to Partition a Table.......................................................... 41 Example: Partitioning - AP_INVOICE_DISTRIBUTIONS_ALL (Oracle Payables)......................................................................................... 41 How is this table used? .......................................................................... 41 Index Analysis......................................................................................... 42 Conclusion............................................................................................... 44 Examples of Partition Keys for Oracle Applications Tables ............... 45 Practical Partitioning Case Study .................................................................. 46 Oracle General Ledger............................................................................... 46 Background – Current Table Volumes ............................................... 47 Strategy..................................................................................................... 47 Partition Maintenance............................................................................ 48 Index Strategy ......................................................................................... 48 GL_JE_LINES Indexes........................................................................ 48 GL-BALANCES Indexes ..................................................................... 48 GL_DAILY_BALANCES Indexes .................................................... 49 The Benefits of This Partitioning Strategy ......................................... 49 DEFINING YOUR PARTITIONING STRATEGY............................. 49 Revisions........................................................................................................... 51 Appendix A - Oracle Data Dictionary Table & Views for Partitioning.. 51 Appendix B - Useful Database Views .......................................................... 52

Using Database Partitioning with Oracle E-Business Suite

Page 5

since different sub ledgers such as Payables. The second part of this paper describes best practices for partitioning a table or index within Oracle E-Business Suite. It includes guidelines on the selection of a Using Database Partitioning with Oracle E-Business Suite Page 6 . and explains the differences between each using relevant Oracle E-Business Suite examples. INTRODUCTION This white paper introduces the concept of partitioning using examples based on the Oracle E-Business Suite and describes the best practices that can be employed to partition tables in the Oracle E-Business Suite. These include major transaction tables used in the Release 12 Centralized Accounting Engine (XLA). this is usually more expensive to implement than a strategy that makes optimum use of existing resources. it can hamper these same aspects of you system. It is therefore important to realize that the information in this paper is in itself not a substitute for the careful testing that should be performed before partitioning is implemented on a live system.Part 1: Introduction to Database Partitioning OVERVIEW This paper describes basic database partitioning concepts. Receivables and Fixes Assets are all clients of the XLA system. The use of partitioning falls into this category. which has some tables partitioned by default. While adding or upgrading hardware may also provide a solution. These include adding indexes and taking appropriate steps to influence the access path of the optimizer. It also describes the SQL commands that are available for maintaining partitioned tables and indexes. Modifying pre-partitioned indexes and tables is not supported. and provides examples of some of the tasks required to implement partitioning with Oracle E-Business Suite. Oracle E-Business Suite systems typically have the majority of the transactional data concentrated in a small number of key tables. if used improperly. Partitioning is supported with Oracle E-Business Suite. Partitioning can bring significant benefits in the areas of performance and manageability. Several data management strategies can help reduce the processing cost of retrieving and manipulating data when working with large volumes. The first part of this paper describes several partitioning strategies. However. and goes on to explain how partitioning can be used with table compression to reduce storage requirements further. These particular tables are partitioned by APPLICATION_ID. A further discussion describes how partitioning can be used to provide high performance and improved scalability by the strategy of reducing SQL transactions to access data subsets only.

and may optionally have individual storage characteristics: examples include compression. A well-designed partitioning strategy can improve query access and updates by limiting the operation to a single or sub-set of partitions. the optimizer can identify partitions and subpartitions that need to be accessed. Any strategy therefore requires careful analysis and testing to ensure that performance will be enhanced in the intended areas without also resulting in decreased performance in other areas. WHAT IS PARTITIONING AND HOW DOES IT WORK? Partitioning splits tables and indexes into smaller. and this topic is also mentioned in the appropriate sections. Some customers use partitioning and data compression as an integral part of that solution. or index-organized table into smaller components. The optimizer does this by using the partition information stored in the data dictionary to identify the content of a partition without querying the data it contains. everincreasing data volumes and changes in statutory requirements have resulted in many Oracle E-Business Suite customers moving less-frequently accessed data on to cheaper storage. and how to migrate data to a partitioned table. because the optimizer focuses on a specific subset of data that can be refined further if additional predicates exist. This can result in substantial improvements in query performance. All the examples given are designed to demonstrate the concepts involved in partitioning. Each component is called a partition (or subpartition for composite partitioned objects). Partitioning divides a table. as well as ones that do not. and can offer significant benefits for large databases with high performance requirements. components. Every partition has a unique name. more manageable. Partitioning is an extra layer of the data dictionary between Tables/Indexes and Tablespaces.Partition Pruning This feature enables the query optimizer to skip partitions that are not required by a particular SQL statement. Partitioning for Performance . Table/Index Partition Tablespace Using Database Partitioning with Oracle E-Business Suite Page 7 . index. and not intended to be adopted verbatim. Depending upon the SQL statement.suitable partition key. Recently. As Oracle E-Business Suite is pre-built. Implementing a suitable strategy for archiving and purging data has always been an important consideration when dealing with large amounts of data. It is easier to reap the benefits of partitioning when designing a system (or coding an application) with partitioning in mind from the start. or being stored in different tablespaces. the task is more complex.

As well as improving performance. Partition-aware operations such as MOVE. Table Availability/Improved Manageability Partitioning can significantly reduce recovery times of key transaction tables by recovering the current partitions first. as can index rebuilds. you also need to check that it includes the conditions that will enable partitioning to be effective. restore. as the application has already been coded. Performance – The Need for Speed When deciding its access path. Partition-wise joins break larger joins into smaller joins that occur between each of the partitions. performance. and physical organization. EXCHANGE. the query optimizer automatically prunes unnecessary partitions. and Information Lifecycle Management. and REBUILD can be used without affecting other active partitions. in Oracle E-Business Suite you not only need to select a suitable partition key. partitioning can help to improve system manageability. Pruning is specified for a range of partitions. only providing access to those required for the operation in question. Purging. Refer to the references section of that document for further information. Using Database Partitioning with Oracle E-Business Suite Page 8 . administration. Physical Organization and Reduction in Total Cost of Ownership (TCO) Partitioning allows data to be organized across different devices. availability. Understanding data volume growth and employing appropriate partitioning thereby gives improved control over data and reduces total cost of ownership. backup. and the relevant partitions for the query are all those between the first and the last partitions of that range. Because the optimizer is partition-aware in this way. Table manageability. and rebuild can be performed at the partition level. Partition-wise Joins Partitioning can improve the performance of multi-table joins if the tables are partitioned on the join key. and availability of a partitioned object. completing the overall join in less time and providing performance benefits for both serial and parallel execution. WHY PARTITION? Partitioning improves the manageability. This subject is discussed in more detail in a separate paper entitled Reducing Your Oracle E-Business Suite Data Footprint using Archiving. allowing data that is less frequently accessed to be stored on slower (and less expensive) storage devices.The optimizer cannot prune partitions if the SQL statement applies a function to the partitioning column. So. joins in SQL statements will benefit from pruning only if they include the partition key – and the choice here will normally be limited.

Partitioning has been included with the Oracle database since Oracle 8. Interval-List. The partition key is a set of one or more columns that determines in which partition a particular row will reside. It has been enhanced with successive releases of the Oracle database. Interval-Hash REF Partitioning. It follows that every row in a partitioned table must reside in a single partition. or MLSLABEL pseudo column. List-Range.PARTITIONING CONCEPTS Partition Key At the heart of partitioning lies the concept of a partition key. The location is automatically maintained as part of insert. update and delete operations. With the sole exception of tables containing columns of LONG or LONG RAW datatypes. new partitioning methods and features have been added. and maintenance capabilities. this key determines in which partition a particular row will reside. Range-Hash List-List. List-Hash Interval-Range. THE EVOLUTION OF PARTITIONING In every major release. Most notably. Partitioned Tables and Indexes Range partitioned tables Local partitioned indexes Global Range partitioned indexes Partition Pruning Hash and Composite range-hash partitioned tables Range partitioned index-organized tables List partitioned tables Hash partitioned index-organized tables Composite Range-list partitioned tables List partitioned index-organized tables Global hash partitioned indexes Composite Partitioning Range-Range. all tables can be partitioned (including columns of type CLOB or BLOB). The location of a row is maintained by the Oracle database. The following attributes apply to a partition: • • • Consists of an ordered list of up to 16 columns Can contain columns that are NULLABLE Cannot contain a LEVEL.0.0 Oracle 8i Oracle 9i Oracle 9iR2 Oracle 10g Oracle 11g Using Database Partitioning with Oracle E-Business Suite Page 9 . ROWID. The Oracle database automatically ensures the correct location of a row based on its partition key. extensions to manageability. a table can have a maximum of 1048575 (1024K – 1) partitions. improvements to scalability. Virtual Column based partitioning Oracle 8. or a column of type ROWID Table Partitions In Oracle Database 11g. Range-List. The following table shows a summary of the main changes. partitioning functionality has been enhanced by the addition of new partitioning techniques.

Workflow Directory Services has a concurrent Using Database Partitioning with Oracle E-Business Suite Page 10 . Partitioning does not require any changes to your Oracle E-Business Suite application code. Several Oracle E-Business Suite modules take advantage of partitioning out of the box. Directory Services (Runtime tables). "Can I use the database partitioning feature in my Oracle E-Business Suite environment?" As mentioned earlier. you can severely degrade performance. As stated earlier. hash or composite partitioning method. It is also unlikely to be as effective as the Oracle E-Business Suite code will have been written to take advantage of a specific strategy. and the use of custom partitioning with Oracle E-Business Suite is supported. Oracle Development will not consider changes to code to support a specific partitioning key or scheme as a product defect. several products in Oracle E-Business Suite utilize partitioning in the base product. it is important to note that if an incorrect partitioning strategy is chosen. There are some cases where the standard application code that depends on partitioning may break. Using Database Partitioning with the Oracle E-Business Suite A common question asked is. However. partitioning is implemented at the database level. What Is Custom Partitioning? Custom partitioning applies in cases where an existing (unpartitioned) Oracle EBusiness Suite product table is redefined as a partitioned table by. and Engineering. the answer is yes. What Does "Supported" Mean in Practical Terms? Partitioning should be transparent to the users and is supported for Oracle EBusiness Suite as long as it has been implemented correctly and does not cause performance issues. Currently. partitioning can actually degrade rather than enhance performance. Although it is easy to partition an existing non-partitioned table. it is less likely that the partitioning will be effective if the partition keys have not been included in the standard code across all the products being used. Modifying existing base product indexes and tables that have already been partitioned is not recommended or supported as it can cause application errors. However. Workflow. for example with the inadvertent introduction of locking or other issues. The next sections answer some common questions about database partitioning and Oracle E-Business Suite. This is discussed in more detail in the second part of this paper. For example. using a range. Oracle Payables (Trial Balance). These including Advanced Planning and Scheduling. for example. HR (Employee Directory). Custom partitioning should not cause Oracle E-Business Suite flows or transactions to fail with standard Oracle E-Business Suite product code.PARTITIONING AND ORACLE E-BUSINESS SUITE Several products in the Oracle E-Business Suite utilize partitioning in the base product. and then give partitioning examples. Projects Resources. list. Daily Business Intelligence. if not planned carefully. and it will only be effective if the application code includes conditions for it to be used effectively.

Other examples include MSC Planning. which is partitioned by PLAN_ID. LAST_UPDATE_DATE NOT NULL. PARTITION feb04_per VALUES LESS THAN (‘FEB-2005’) .oracle. . Example of Creating a Partitioned Table The partition clause needs to be included as part of the create table command.com/schan/2006/11/17 Examples of Custom Partitioning An example of case 1 above would be choosing to partition the table OE_ORDER_LINES_ALL. An example of case 2 would be changing the partition key of the table WF_ITEM_ACTIVITY_STATUSES. which is already partitioned by the column ITEM_TYPE and sub-partitioned by ITEM_KEY. Further information can be found in the Partitioning and Purging Best Practices for Oracle E-Business Suite at the following URL: http://blogs. END_DATE NOT NULL.). CREATION_DATE CREATED_BY LAST_UPDATE_LOGIN DESCRIPTION ATTRIBUTE1 ATTRIBUTE2 ATTRIBUTE3 ATTRIBUTE4 ATTRIBUTE5 ATTRIBUTE6 ATTRIBUTE7 ATTRIBUTE8 CONTEXT YEAR_START_DATE QUARTER_START_DATE ) PARTITION BY RANGE (PERIOD_NAME) ( PARTITION jan04_per VALUES LESS THAN (‘JAN-2005’). PERIOD_NUM NOT NULL. Using Database Partitioning with Oracle E-Business Suite Page 11 . In this case. ENTERED_PERIOD_NAME NOT NULL.program that bulk loads data into the WF_LOCAL_USER_ROLE table. . . and changing the strategy would have dire consequences. This would stop working effectively if you change the partitioning strategy. the application code prunes by partition. This is shown in the following example: CREATE TABLE GL_PERIODS (PERIOD_SET_NAME NOT NULL. PERIOD_NAME NOT NULL. START_DATE NOT NULL. . . LAST_UPDATED_BY NOT NULL. PERIOD_YEAR NOT NULL. QUARTER_NUM NOT NULL. which is not partitioned in the standard product. PERIOD_TYPE NOT NULL. ADJUSTMENT_PERIOD_FLAG NOT NULL.

These are now considered in more detail. Clustered tables cannot be partitioned. As data is removed from the table. Heap Organized Tables Heap organized tables are the most common type of tables. The best strategy to partition a table depends on the data distribution of the table and access methods. The four partitioning strategies available for partitioning tables within the Oracle database are as follows: • • • • Range List Hash Composite A partitioned table declaration contains following elements: • • The physical structure of the table The partition structure. Multicolumn Partition Key It is possible for a table to have a partition key that consists of several columns. which will be covered later in the section on Multicolumn Partitioning. it is placed in the first free area of space in a segment large enough to hold it. which defines the partition key The four different types of partitioning methods are declared in the PARTITION BY clause part of the create table command. The following restrictions apply: An IOT cannot be list-partitioned. and HASH partitioning on a sublevel.TABLE PARTITIONING STRATEGY Several partitioning strategies exist. in which data is stored as an unordered collection (heap). As data is added. Materialized Views (snapshots) can be partitioned. space becomes available for reuse by INSERT and UPDATE statements. which is analogous to composite column indexes. Using Database Partitioning with Oracle E-Business Suite Page 12 . Note that composite partitioning is limited to being a RANGE partition on the top level. Table Type Partitioning can be applied to ‘normal’ tables (sometimes referred to as Heap Organized Tables) and to the more specialized Index Organized Tables (IOT). The exception is list partitions where a static list of literals is used.

In some cases. Range partitioning can be useful for Oracle E-Business Suite tables. Index organized tables offer several performance benefits. The values in the value list are a static list of non-inclusive literals. Creating a table using range partitioning requires specification of: • • • Partitioning Method: Range Partition Columns Partitions: Identifying the partition boundaries Each partition’s end point is specified using the following syntax: • VALUES LESS THAN (value-list) The value-list must correspond in type and position to the partition key. Using Database Partitioning with Oracle E-Business Suite Page 13 . Range Partitioning Range partitioning should be considered where data is based on consecutive ranges of values. the table itself is stored as a B-Tree index structure. Example range partitioning creation script CREATE TABLE GL_BALANCES (SET_OF_BOOKS_ID NUMBER(15) NOT NULL. which determines the partition to which the row belongs. Another example of range partitioning would be to partition the GL_BALANCES table by the column PERIOD_NAME. Additional benefits include faster access to table rows by primary key: as the table rows are stored in primary key order. BUDGET_VERSION_ID NUMBER(15). with the smaller B-Tree resulting in faster access to frequently accessed columns. Rows are identified by a partition key. PERIOD_NAME VARCHAR2(15) NOT NULL. The partition key must match the access predicate (access path key) in order to map rows to partitions based upon ranges of column values. IOT performance can further be enhanced by moving infrequently accessed nonkey columns from the B-Tree leaf block to an optional overflow storage area. with data located according to the primary key. within the data type restrictions. CODE_COMBINATION_ID NUMBER(15) NOT NULL. The partition key consists of any columns from the table. resulting in a marked reduction of performance for operations such as parallel DML. the table AP_INVOICES_ALL could be range-partitioned by using the INVOICE_ID column as the partitioning key. CURRENCY_CODE VARCHAR2(15) NOT NULL. range access by the primary key involves minimal data block accesses. For example. including a reduced need for space compared to heap organized tables. A disadvantage of range partitioning is that it is not always possible to predict how much data will map into a given range. Range partitioning was introduced in Oracle8. sizes of partitions may differ substantially.Index Organized Tables In an index organized table. ACTUAL_FLAG VARCHAR2(1) NOT NULL.

NULL can be specified as a value. List Partitioning List partitioning gives you complete control as it allows you to map your rows to specific partitions. PARTITION feb04_per VALUES LESS THAN (‘FEB-2005’) . ). . this partitioning strategy is used when the partitioning criteria is an unordered list of values. which allows the optimizer to prune unnecessary partitions. List partitioning was introduced in Oracle 9i. . ) PARTITION BY RANGE (PERIOD_NAME) ( PARTITION jan04_per VALUES LESS THAN (‘JAN-2005’). There are tables that are frequently accessed using a range predicate on a suitable partitioning column. the majority of the SQL that accesses this table will use the condition PERIOD_NAME in the query. Creating a list partition requires specification of the following: • • • Partitioning Method: List Partitioning column Partition description: A set of literal values. Similarly to range partitioning. Unlike range partitioning. partition key values are specified with a VALUES (value-list) clause. but any literal or NULL values can only appear once. and has the advantage of allowing unorganized and unrelated sets of data to be grouped together if required. . There is no “other” values clause. . within the data type restrictions. it allows complete control over how rows map to specific partitions. which determines if a row is in the partition or not Using Database Partitioning with Oracle E-Business Suite Page 14 . which will effectively map to one of the partitions. . This is done by employing a list of static values as the description of the partitioning key. In this example.LAST_UPDATE_DATE DATE NOT NULL. . All values of the partition key for a partition must be listed as literals. . Summary Range partitioning may be suitable when one or more of the following conditions apply: • • There is a “rolling window” of data. . The following restrictions apply to partition keys: The partition key can be any single column from the table. . Index Only Tables (IOTs) cannot be list partitioned. Typically. . .

An example this type of partitioning is shown as follows with the OE_ORDER_LINES_ALL table by OPEN_FLAG. LINE_NUMBER NOT NULL NUMBER ORDERED_ITEM VARCHAR2(2000). . Range queries are not suitable for use with hash-partitioned tables.e. ) PARTITION BY LIST (open_flag) ( PARTITION open_orders VALUES (‘Y’). HEADER_ID NUMBER NOT NULL. it is ideal for distributing data evenly across devices. . this method of partitioning is most useful for Oracle E-Business Suite batch programs that use parallel workers and where block contention is significant. There are two drawbacks to hash partitioning: • Hash partitioning only utilizes partition pruning on equality predicates. Typically. equality and IN lists. i. where open_orders and closed_orders are used as the partition names. Example list partitioning creation script CREATE TABLE OE_ORDER_LINES_ALL (LINE_ID NUMBER NOT NULL. Hash Partitioning Hash partitioning used a hashing algorithm to decide the physical placement of data. this partitioning strategy will be used when there is no clear partitioning criteria. It stripes data into different partitions by applying a hashing algorithm to the partitioning key. PARTITION closed_orders VALUES (‘N’) ). Summary List partitioning maps specific rows to partitions. Introduced in Oracle 8i. The partition key for list partitioning can only be based on a single column. • Generally. . ORG_ID NUMBER. . Creating a table using hash partitioning requires specification of: • • • Partitioning Method: Hash Partitioning column(s) Number of partitions or individual partition descriptions Using Database Partitioning with Oracle E-Business Suite Page 15 . distributing rows evenly between partitions and thereby making each one approximately the same size. . LINE_TYPE_ID NUMBER NOT NULL. based on a static list of literal values. As hash partitioning controls the physical placement of data across a fixed number of partitions. . Hash partitioning will distribute data evenly across a fixed number of partitions. OPEN_FLAG VARCHAR2(1) NOT NULL. A typical example would be the interface import program. hash partitioning is an easy-to-use alternative to range partitioning when data does not follow any clear historical pattern and there is no obvious partitioning key.

However. ). . How the data is divided further depends on the secondary method of partitioning used: • Range-hash partitioning: The database uses a hashing algorithm to further divide the data into sub-partitions within each partition range. it is not suitable for historical data. so the only possible choices for composite partitioning methods are range-hash or range-list. List. OPEN_FLAG VARCHAR2(1) NOT NULL. i. . Summary Hash partitioning may be suitable when there is no natural partition key for the table. there is a limit to the combination of partitioning methods that can be used together.. While this strategy will maximize I/O throughput. Using Database Partitioning with Oracle E-Business Suite Page 16 . To avoid data skew amongst partitions. and Hash Partitioning. ) PARTITION BY HASH (LINE_ID) PARTITIONS 8 . hash partitioning allows data to be mapped evenly to a number of partitions.An example this type of approach is partitioning the table OE_ORDER_LINES_ALL by the primary key. Hash partitioning can minimize block contention in batch processing by increasing scalability. as the name suggests. As well as offering some of the performance benefits of range partitioning. Only range-partitioned tables can be sub-partitioned. partitions tables using a combination of range and hash or list partitioning. ORG_ID NUMBER. the database first distributes data into partitions according to the limits established by the first method of partitioning. hash partitioning makes use of partition pruning and partition-wise joins based upon the partition key. . or the data does not follow any business view or logical view. . . by range. . The composite partitioning method of range-hash combines the best of both worlds by allowing logical groupings at the partition level and handling data skew within the sub-partitions. LINE_TYPE_ID NUMBER NOT NULL. . . HEADER_ID NUMBER NOT NULL. Example hash partitioning creation script CREATE TABLE OE_ORDER_LINES_ALL (LINE_ID NUMBER NOT NULL. LINE_ID. . Using composite partitioning. LINE_NUMBER NOT NULL NUMBER ORDERED_ITEM VARCHAR2(2000). Composite Partitioning Composite partitioning is based upon a combination of the previously described partitioning strategies of Range. . .e. Composite partitioning.

Summary Composite Range-Hash partitioning may be suitable in the following cases. partition wf_item3 values less than ('AP'). .). . . partition wf_item48 values less than ('OE'). partition wf_item49 values less than ('OF'). The subpartition partition key can be the same as or different from the range partition key. Consider an example where the table WF_ITEM_ACTIVITY_STATUSES has a composite key based upon ITEM_TYPE and ITEM_KEY. . . . . partition wf_item51 values less than ('OL').• Range-list partitioning: The database divides the data into sub-partitions. partition wf_item59 values less than ('QA'). where the leading key has a small number of distinct values and the second key has a large number of distinct values. partition wf_item4 values less than ('AR'). partition wf_item57 values less than ('PQ'). partition wf_item58 values less than ('PR'). partition wf_item5 values less than ('AZ'). • Historical data and cases using the composite partitioning method. partition wf_item2 values less than ('AM'). Creating a table using range-hash partitions requires specification of: • • • • • • Partitioning Method: Range Partitioning column(s) Boundary of partition Subpartitioning method: Hash Subpartitioning column(s) Number of subpartitions for each partition Example composite partitioning script The following example shows how to partition the WF_ITEM_ACTIVITY_STATUSES table using composite partitioning (range and hash). This table is generally accessed by ITEM_TYPE. It follows that the secondary method of partitioning will be less specific and not range orientated. . which has a small number of distinct • Using Database Partitioning with Oracle E-Business Suite Page 17 . based on an explicit list specified. Each range is partitioned. partition wf_item56 values less than ('PO'). create table wf_item_activity_statuses … partition by range (item_type) subpartition by hash (item_key) subpartitions 8 (partition wf_item1 values less than ('A1'). . partition wf_item50 values less than ('OK').

This is typically provided by the trailing columns in the partition key. All index types can be partitioned. bear in mind that the database will only use the next column that makes up the partition key if it cannot uniquely identify a single destination partition from the first key column. and the rules for partitioning indexes are similar to those for tables. Bitmap. and can be used with a partitioned or non-partitioned table. but must be local to the partitioned table. Several different methods are available for partitioning indexes. Indexes can be partitioned or non-partitioned. any local indexes will also be partitioned automatically by the database. a bitmap index cannot be global partitioned. That is. For example. When deciding in which partition to place a particular row. For range and hash partitioned tables. For example. where later columns give a higher degree of granularity then previous columns. Typically. An applicable scenario would be for example if you wanted to decompose a country by region or state. Partitioning indexes offers comparable manageability and performance benefits to partitioning tables. the local index inherits the partitioning method of the table. when combined with the ITEM_KEY column (which has a high number of distinct values and selectivity) the partitioning key efficiency improves and results in the best of both partitioning methods. The index types are independent of the index partition method.values (NDVs). This is known as equipartitioning. if the table AP_INVOICES_ALL is partitioned on the INVOICE_ID column using range partitioning. The database does not evaluate all the columns in the partition key when deciding in which partition to place a row. However. Local Indexes: A local index on a partitioned table is created where the index is partitioned in exactly the same manner as the underlying partitioned table. and FunctionBased indexes. a higher degree of granularity may be needed in the partition key. The information is stored in that partition’s index only: there is no master index to refer to. but some restrictions apply. In certain cases. Each partition of a local index corresponds to one and only one partition of the underlying table. Using Database Partitioning with Oracle E-Business Suite Page 18 . Range) Prefixed Nonprefixed Indexes can be of different types: B*Tree. as follows: • • • • Local (inherits same partitioning method as table) Global (Hash. PARTITIONING INDEXES The rules for partitioning indexes are similar to those for tables and you can mix partitioned and nonpartitioned indexes with partitioned and nonpartitioned tables. Multicolumn Partitioning Multicolumn partitioning should be used when the partitioning key is composed of several columns. each partition is a completely separate index. It should be noted that when an index is partitioned. customers will only have 5 or fewer ITEM_TYPES. using the same partition key. up to 16 partition key columns can be specified. Bitmap Join.

These are discussed later in this paper. Global partitioned indexes can also be used on nonpartitioned tables. It therefore follows that the index key in a global partitioned index will refer to rows stored in more than one table partition. using the ALTER TABLE command and specifying the UPDATE INDEXES clause can be used to force the database to override this behavior. Prefixed and Non-prefixed Indexes Global partitioned indexes can be either prefixed or non-prefixed. A global index could then be created on this table. These types of indexes can be sub-divided into two further categories.e. Global prefixed partitioned indexes can be unique or nonunique. There is no required relation between the table and index partitioning method. For example. and the index is updated at the same time as the base table. From a maintenance point of view. Global Non-Partitioned Indexes: A global non-partitioned index is essentially identical to an index on a non-partitioned table. in that they allow you to pick a partitioning method that is different from that of the table. the corresponding indexes and index partitions are marked as UNUSABLE (for global indexes). Global-partitioned indexes can be range or hash partitioned. Automatically Maintaining Indexes After running table maintenance operation on a partitioned table (for example. using a different partitioning key from the table. the table GL_BALANCES could be rangepartitioned using the SET_OF_BOOKS_ID column. Here also there are restrictions on the combination of index and partitioned types allowed. and update the index at the same time as it executes the maintenance operation. rather than an attribute that is specified directly. CODE_COMBINATION_ID. which is partitioned independently i. using a different partitioning-key from the table. this means that each index does not have to be rebuilt individually. Currently. In Oracle 10g. Global Partitioned Indexes A global partitioned index is an index on a partitioned or non-partitioned table. i.Global Partitioned Indexes: A global partitioned index is an index on a partitioned or non-partitioned table that is partitioned independently. • Using Database Partitioning with Oracle E-Business Suite Page 19 . This is a consequence of the index key column and partition key column matching. range-partitioned using a different partitioning key such as. global partitioned indexes can be either range or hash partitioned. The index structure is not partitioned. • A global partitioned index is prefixed if the partition key is the leading index key. Global partitioned indexes are flexible. prefixed and non-prefixed. merging two adjacent partitions). Global-partitioned indexes can be partitioned using range or hash partitioning. A global partitioned index is non-prefixed if the table partition key is not the same as the leading index key.e.

which will spread index entries evenly over multiple partitions. the index must be recovered to the same point. During table or index interaction during partition maintenance. individual partitions can be exchanged. It therefore follows that partition independence it is not possible for global indexes. the OE_ORDER_LINES_U1 index is based on the column LINE_ID. For example. most of the index insertions occur on the right edge of an index. both global indexes and global partitioned indexes will be marked as unusable. all partitions in a global index will be affected. moved. Using Database Partitioning with Oracle E-Business Suite Page 20 . can be altered. However. Global hash partitioned indexes can be useful in scenarios where there are is a low number of index leaf blocks accessed. This is because the index entries have a hashing algorithm applied to them. This will in turn spread the contention over multiple partitions. When the underlying table partition has any SPLIT. almost every attribute of a partitioned table or index is alterable after the table or index has been created and populated. Physical properties of a partition. Changes to a table’s logical properties. MOVE. Depending on the type of operation performed on a table partition. the partition must be moved for the changes to take effect.Maintaining Global Partitioned Indexes Unlike a nonpartitioned table or index. the UPDATE INDEXES clause can be specified. merging. otherwise the index entries will be scattered across partitions. this may affect the data within existing partitions. and does not have to be rebuilt once the operation has completed. in the table OE_ORDER_LINES_ALL. the indexes on the table will be affected. these operations affect all the data within the partition.). or splitting the partitions of the table or index. dropping. Global partitioned indexes are more difficult to maintain than local indexes. The value for LINE_ID comes from a sequence. they do offer a more efficient access method to any individual record. such as the number and types of data columns. The table or index’s partition key definition can be altered by adding. can be made to partitioned as well as nonpartitioned tables. The advantages of using this option are that the index will remain online and available throughout the operation. can also be altered. For some attributes. If a table partition is recovered to a point in time. They offer better performance by reducing contention when the index is right growing (that is. The entire global index must also be recreated. such as the storage attribute. truncated. DROP. When altering a table partition. The partition’s logical properties. Maintaining Global Hash Partitioned Indexes Global hash partitioned indexes were introduced with the Oracle 10g database. or TRUNCATE maintenance operations performed on it. In addition. or dropped. such as the name. using the same syntax. An example of a right-growing index is an index based on a sequence value. This automatically maintains the affected global indexes and partitions. However.

the index is available to all partitions. dropped. it follows that the database automatically maintains the index partition whenever any maintenance operation is performed on the underlying tables: for example. Local indexes can only be unique if the partition key is part of the index key. Since the index structure is not partitioned. A local index is prefixed if the partition key of the table and the index key are the same. Global Nonpartitioned Indexes Global nonpartitioned indexes offer the same efficient access to any individual record in any partition. Local indexes are easier to maintain than other types of partitioned indexes. Generally. As the Oracle database ensures that the index partitions are synchronized with their corresponding table partitions. i. Local Prefixed and Non-Prefixed (Partitioned Indexes) Local prefixed indexes can be unique or non-unique and can be specified against all four table partition types. and behave just like a non-partitioned index. because the local indexes are automatically maintained. Whereas global partitioned indexes can be defined on a non-partitioned table. which is know as equipartitioning. Enforcing this restriction ensures that the rows with the same index key will always map to the same partition. if the AP_INVOICES_L1 index is defined on column INVOICE_DATE. the index keys within the index will refer only to the rows stored in the single underlying table partition. when partitions are added. or merged. nonprefixed local indexes are a poor choice for Oracle E-Business Suite. the index AP_INVOICES_L1 is local prefixed because the leading column and the partition key match.Local Partitioned Indexes A local index on a partitioned table is partitioned using the same method as used by the underlying partitioned table. local indexes must be defined on partitioned tables. The table and local index are either partitioned in exactly the same manner. A scenario where this type of index would be useful is with a query that does not include the partition key of the table as a filter. with its index key as the (INVOICE_ID. A local index is created by specifying the LOCAL attribute. so any action that make one partition's data invalid or unavailable only affects a single partition. SUPPLIER_ID) columns. and. or have the same partition key. Using Database Partitioning with Oracle E-Business Suite Page 21 . If a local index AP_INVOICES_L1 is created on this partitioned table. but you still want the optimizer to use an index.e. as it is unlikely that the vast majority of SQL statements referencing this table will include the partitioning key in the where clause. On the other hand. An example would be the AP_INVOICES_ALL table being partitioned on the column INVOICE_ID. For local indexes. the local index inherits the partitioning method of the table. otherwise it is a local non-prefixed index. This enables each table-index pair to be independent. then it is a non-prefixed local index. can offer higher availability. and can be created as UNIQUE or NONUNIQUE.. The term equipartitioning refers to the concept of having each local partitioned index associated with exactly one partition of the table.

Consider the case where the referenced column was part of the join predicate and had a global index created on it. For example. the database will simply prune the partitions based on the partition key. choosing the wrong index prefix method could result in suboptimal performance due to the additional overhead of using or maintaining an additional index. • • Global Range Partitioned (prefixed) Global Hash Partitioned (prefixed). Using Database Partitioning with Oracle E-Business Suite Page 22 . With a nonprefixed index. You also need to consider how you expect the optimizer to behave if you use one of these types of indexes. Their relative performance depends on several contributing factors. • Local Partitioned Prefixed Use in place of indexes which already contain the partition key as a prefix. introduced in Oracle 10g Extremely useful for right-growing indexes experiencing contention due to high levels of concurrency. always include the partition key filter. The optimizer can make use of partition pruning if there is a prefixed (local or global) index and a predicate that is part of the index column. or to perform an index range scan. Performance Considerations regarding Prefixed and Nonprefixed Indexes Before deciding between a prefixed or nonprefixed index. which are not prefixed by the table partition key. The SQL statement needs to reference this column as a join predicate to ensure the optimizer uses this index. the application of the predicate is being restricted to a subset of index partitions. as the local index is equipartitioned with the underlying table. or as part of a large batch program? In either case. Summary The Oracle database offers a variety of techniques for partitioning indexes. The following index partition methods are available: • Global Non-partitioned (prefixed) Use Global Non-partitioned indexes for all indexes. Allows the index to be partitioned without affecting the table. In such a case. This is required to look up a single key. the database will have to apply a predicate involving the index column to all index partitions. it is worth considering it will be used. the GL_BALANCES table is partitioned using the PERIOD_NAME column and a global nonpartitioned index created on the column CODE_COMBINATION_ID. using the local (non-prefixed) index. is the index likely to be employed by endusers transactions. Note that if there is also a predicate on the partitioning column(s). multiple index probes may not be required. By doing this. This can be done by defining exactly how the table is to be accessed. For example. • Local Partitioned Non-Prefix Should only be used when all the queries.

COALESCE (HASH).Maintenance of Partitioned Tables & Indexes Oracle provides a comprehensive set of SQL commands for managing partitioned tables and indexes. dropping. It is important to understand which partition maintenance operations are allowed with the different table and index partitioning methods. TRUNCATE. splitting. A number of different kind of maintenance operations for partitions and subpartitions can be performed on tables and indexes. SPLIT. Dropping unused partitions or partitions containing historical data that is no longer required. merging. including ADD (HASH). DROP. MERGE. These are described in the next section of this paper. or adding new partitions to a table. For example: • • Merging two partitions together. moving and compressing partitions. These include commands for adding new partitions. The alter table command includes a number of options that enable these operations be carried out. truncating. MOVE. or splitting or adding partitions if new partition key values are added. EXCHANGE. Using Database Partitioning with Oracle E-Business Suite Page 23 .

Useful when want to convert non-partitioned tables to partitioned table.. COALESCE SUBPARTITION DROP PARTITION EXCHANGE PARTITION EXCHANGE SUBPARTITION MERGE PARTITIONS MODIFY DEFAULT ATTRIBUTES MODIFY DEFAULT ATTRIBUTES FOR PARTITION MODIFY PARTITION MODIFY SUBPARTITION N/A Composite: Range/List ADD PARTITION MODIFY PARTITION . Adds additional literal values to the defining value list that establishes the partition key. as are any corresponding local indexes.. The two original partitions are dropped. Removes literal values from the defining value list that establishes the partition key. ADD VALUES MODIFY PARTITION. ADD VALUES MODIFY SUBPARTITION . Not used for hash-partitioned table. ADD SUBPARTITION MODIFY PARTITION ... but the physical partition is still kept. Drops a partition for a given table. storing data in a compressed format using table compression...Partition Maintenance Operations and Table Partitioning Methods Table: ALTER TABLE Clause for Maintenance Operations of Table Partitions Operation Adding Partitions Description Adds a new partition after the highest partition. DROP VALUES MOVE PARTITION N/A N/A N/A N/A N/A MOVE PARTITION MOVE PARTITION MOVE SUBPARTITION RENAME PARTITION RENAME SUBPARTITION SPLIT PARTITION TRUNCATE PARTITION TRUNCATE SUBPARTITION RENAME PARTITION RENAME PARTITION RENAME PARTITION SPLIT PARTITION N/A SPLIT PARTITION TRUNCATE PARTITION TRUNCATE PARTITION TRUNCATE PARTITION Using Database Partitioning with Oracle E-Business Suite Page 24 . MODIFY PARTITION MODIFY PARTITION MODIFY PARTITION MODIFY PARTITION. Allows a more meaningful name to be used instead of the system-generated ones. Allows a partition to be moved to another tablespace.. Range Hash List Composite: Range/Hash ADD PARTITION MODIFY PARTITION .. Modifies the storage parameters of all partitions. for example when a partition gets too large. ADD SUBPARTITION N/A DROP PARTITION DROP SUBPARTITION EXCHANGE PARTITION EXCHANGE SUBPARTITION MERGE PARTITIONS MERGE SUBPARTITION S MODIFY DEFAULT ATTRIBUTES MODIFY DEFAULT ATTRIBUTES FOR PARTITION MODIFY PARTITION MODIFY SUBPARTITION MODIFY SUBPARTITION . DROP VALUES MOVE SUBPARTITION RENAME PARTITION RENAME SUBPARTITION SPLIT PARTITION SPLIT SUBPARTITION TRUNCATE PARTITION TRUNCATE SUBPARTITION ADD PARTITION ADD PARTITION ADD PARTITION Coalescing partitions Dropping partitions Exchanging Partitions Merging Partitions Reduces the number of partitions in a table or index by redistributing contents into one or more remaining partitions as determined by the hash function. Renames partitions and sub-partitions of tables and indexes. Removes all rows from a table partition.. The same logic only applies to local indexes due to equipartitioning.. Merges the contents of two partitions into one partition.. N/A COALESCE PARTITION N/A DROP PARTITION N/A DROP PARTITION Modifying Default Attributes Changes a partition into a non-partitioned table and vice versa. Note: The new attributes affect only future partitions. moving an existing partition to a new tablespace.... Redistributes the contents of a partition into two new partitions. EXCHANGE PARTITION EXCHANGE PARTITION EXCHANGE PARTITION MERGE PARTITIONS N/A MERGE PARTITIONS MODIFY DEFAULT ATTRIBUTES MODIFY DEFAULT ATTRIBUTES MODIFY DEFAULT ATTRIBUTES Modifying Real Attributes of Partitions Modifying List Partitions: Adding Values Modifying List Partitions: Dropping Values Moving Partitions Renaming Partitions Splitting Partitions Truncating Partitions Modifies existing attributes of a table or index: for example.

Oracle® Database Concepts 11g. It can only change the way data is organized and accessed. a benefit of using key compression in addition is that it eliminates the repeated occurrences of key column prefix values. Additional Information: For additional information refer to Oracle® Database Administrator's Guide 10g Release 2 (10. saving storage space and reducing I/O. Some or all of the partitions of a B-Tree index can also be compressed using key compression. note that partitioning cannot reduce the physical size of tables in a database. Introduced in Oracle 9i Release 2. modifying the logical view of the tables so that only those records applicable to a given transaction are accessed.2). and Oracle® Database VLDB and Partitioning Guide 11g TABLE AND KEY COMPRESSION Using the compression feature of the Oracle database.Partition Maintenance Operations and Index Type/Partitioning Methods Table: ALTER INDEX Clause for Maintenance Operations of Table Partitions Operation Adding Index Partitions Dropping Index Partitions Modifying Default Attributes of Index Partitions Index Type Global Local Global Local Global Local Modifying Real Attributes of Index Partitions Global Local Modifying Real Attributes of Index Partitions Global Local Rebuilding Index Partitions Renaming Index Partitions Global Local Global Local Splitting Index Partitions Global Local Range N/A DROP PARTITION n/a MODIFY DEFAULT ATTRIBUTES MODIFY DEFAULT ATTRIBUTES MODIFY PARTITION Composite: Hash and List ADD PARTITION (hash only) N/A N/A - Composite: Range/List N/A N/A - MODIFY DEFAULT ATTRIBUTES - MODIFY DEFAULT ATTRIBUTES MODIFY DEFAULT ATTRIBUTES FOR PARTITION - MODIFY PARTITION MODIFY PARTITION MODIFY PARTITION - MODIFY PARTITION MODIFY SUBPARTITION - MODIFY PARTITION REBUILD PARTITION REBUILD PARTITION RENAME PARTITION RENAME PARTITION SPLIT PARTITION N/A MODIFY PARTITION REBUILD PARTITION RENAME PARTITION N/A MODIFY PARTITION MODIFY SUBPARTITION REBUILD SUBPARTITION RENAME PARTITION RENAME SUBPARTITION N/A Finally. table compression is a database feature that allows compression of some or all of the partitions that belong to a particular table. B-tree indexes can also be compressed using a technique known as key compression. an entire table can be compressed or specific partitions belonging to a table can be compressed. Using Database Partitioning with Oracle E-Business Suite Page 25 . Although bitmap indexes are already stored in a compressed manner by default.

2. and replaces all duplicate values with a short reference to the symbol table. but this has been allowed in Oracle 10g.0. Connected to: Oracle9i Enterprise Edition Release 9. ALTER TABLE AP_INVOICES_ALL ADD TRANSMISSION_FLAG VARCHAR2(1) * ERROR at line 1: ORA-22856: cannot add columns to object tables Using Database Partitioning with Oracle E-Business Suite Page 26 .0 .0.Production With the Partitioning. OLAP and Oracle Data Mining options JServer Release 9. For example. not all tables will have good compression ratios.0 . compression from dba_tables where owner='AR' and table_name = 'AP_INVOICES_ALL'.0 .-------AP_INVOICES_ALL ENABLED SQL> ALTER TABLE AP_INVOICES_ALL ADD TRANSMISSION_FLAG VARCHAR2(1).0.Production SQL> 2 3 4 select table_name. Table compression may improve query performance by reducing disk I/O and memory use in the buffer cache.The Oracle database compresses data by removing duplicate values in a data block. Data is only compressed during bulk operations/direct path inserts.Production on Fri Apr 6 10:50:32 2007 Copyright (c) 1982. Given the nature of the data. 2002. The following session extract shows an example of the problem. Not all DDL/DML commands are supported on compressed tables (see immediately below). you can compress partitions containing data to keep it on-line for longer. Oracle Corporation. TABLE_NAME COMPRESS -----------------------------. or HASH or LIST subpartitions. All rights reserved. it is advisable to carry out suitable analysis to determine the expected benefits before deciding whether it is worth compressing a table in a production instance. The compression ratio increases proportionately to the number of duplicate column values in each block.6. The compression algorithm maintains a symbol table of commonly used values per column at the beginning of the data block. Compression is more suited for read-only data or tables where rows are rarely updated. including: It cannot be used with HASH partitions. While the compression algorithm guarantees that compression will never increase the size of the existing table.2. which results in a small CPU overhead. Internally data has to be uncompressed to be updated and then recompressed.6. In Oracle 9iR2 adding a column to a compressed table resulted in an error. There are some restrictions when it comes to compressing tables.2. SQL*Plus: Release 9.6. Each data block can have different levels of compression.

Example of creating a compressed table CREATE TABLE OE_ORDER_LINES_ALL ( LINE_ID NUMBER NOT NULL. Example of Compressing an Existing Table This test was performed using Oracle E-Business Suite 11.2. LINE_TYPE_ID NUMBER NOT NULL.---------.5. HEADER_ID NUMBER NOT NULL.0.008 Using Database Partitioning with Oracle E-Business Suite Page 27 . This allows more data to be kept online. This process can be accelerated by using the parallel option and specifying the number of parallel workers.Given that range and composite partitioning can separate data into distinct partitions.6. ALTER TABLE AP_INVOICES_ALL MOVE COMPRESS. Converting Tables to Compressed Tables: Use the ALTER TABLE command with the COMPRESS clause to compress a database table.10 CU2 (Vision Database) with Oracle Database 9. OPEN_FLAG VARCHAR2(1) NOT NULL ) COMPRESS. ORDERED_ITEM VARCHAR2(2000). ORG_ID NUMBER. but bear in mind that this may have an adverse effect on overall system performance. ALTER TABLE RA_CUST_TRX_LINE_GL_DIST_ALL MOVE PARALLEL 20 COMPRESS.------AP_INVOICES_ALL 19817 8388608 . LINE_NUMBER NUMBER NOT NULL. as well as reducing the physical storage costs.0) Before compression: TABLE_NAME NUM_ROWS BYTES GB -----------------------------. including: • • • Converting an existing compressed table to a compressed one Creating a new compressed table Adding compressed partitions to an uncompressed table Creating a Compressed Table This can be achieved by adding the compressed clause to the create table statement.---------. Implementing Compression Table compression can be implemented in a number of different ways. consider using the table compression feature to compress read-only partitions.

2.4076E+11 134.0) Before compression: TABLE_NAME NUM_ROWS BYTES GB BLOCKS EMPTY_BLOCKS -----------------------------.---------.243438 17058752 0 GL_IMPORT_REFERENCES 243433330 9.-----------GL_JE_LINES 540851270 3.490875 10922809 0 Creating compressed tablespaces: CREATE TABLESPACE USER_DATA DATAFILE 'diska:tabspace_file2.5035 11602728 0 RA_CUST_TRX_LINE_GL_DIST_ALL 481210970 1.-----------GL_JE_LINES 540851270 1.1499E+10 20.---------.---------.---------.-------AP_INVOICES_ALL ENABLED TABLE_NAME NUM_ROWS BYTES GB -----------------------------.2.5104E+10 90.5TB Database) This test was performed under Oracle E-Business Suite 11.5TB Production Database 10.6981875 11602728 0 RA_CUST_TRX_LINE_GL_DIST_ALL 481210970 8.75575 10922809 0 After Compression: TABLE_NAME NUM_ROWS BYTES GB BLOCKS EMPTY_BLOCKS -----------------------------.00225 Example of Compressing Large Tables (Large Volume Oracle E-Business Suite Customer 10.------AP_INVOICES_ALL 19817 2359296 .8341E+10 17.dat' SIZE 20M DEFAULT COMPRESS STORAGE ( … ).---------.---------.6342E+10 34.---------.---------.65825 17058752 0 GL_IMPORT_REFERENCES 243433330 2.10 CU2 (10.0.After Compression: TABLE_NAME COMPRESS -----------------------------.9921E+10 85.---------.5.---------. Using Database Partitioning with Oracle E-Business Suite Page 28 .

it is essential to choose and extensively test the partitioning scheme and key to ensure it achieves the desired performance. go on to identify and understand the situations where it will help. focus on the SQL that will benefit. it is important to identify the root cause of a performance issue. In general. Performance issues can usually be solved by means other than partitioning. key reasons for partitioning tables and indexes include improving performance and manageability. This is true even where partitioning seems to be an obvious solution. review the indexes being used. and tune the SQL as applicable. Customers can obtain assistance from Oracle Support for performance issues with standard code. The exact sequence depends on the particular situation. Even if all the data being accessed is within a specified range. and if so. it is advisable to check the way that the application is being used. and consider some of the trade-offs and costs as explained further in the section: Defining Your Partitioning Strategy. The following steps will help formulate a partitioning strategy. Step 1 – Is Partitioning Necessary? Partitioning is not necessarily the best solution to a performance problem. partitioning is not necessarily the only or best option. for example with a poorly performing program where the evidence suggests that partitioning a particular table or set of tables will resolve the issue. this time with the goal of putting the principles into a practical context that can be applied to Oracle E-Business Suite installations. Using Database Partitioning with Oracle E-Business Suite Page 29 . As discussed earlier. start by determining whether partitioning is the best solution. It is essential to employ an optimal partitioning scheme and partition key to achieve the performance that will meet the designated business goals. Performance – In any performance investigation. Next. Any consideration of partitioning as an option should include the following points: 1.Part 2: Practical Guidelines for Partitioning Oracle E-Business Suite OVERVIEW This section major section revisits the subjects discussed in Part 1. Hence. as well as management of archiving and purging processes. Other important reasons include management of data movement resulting from changes in the data lifecycle. WHEN TO USE PARTITIONING? Reasons for Creating Partitioned Tables/Indexes As there are a number of possible strategies for partitioning tables and indexes.

2. the following questions should be answered: • What is the functional purpose of the table. for example representing a key entity such as an invoice. Partitioning can be used to help achieve this. This is likely to reduce the overall data volumes and therefore improve performance by reducing the amount of I/O and associated CPU usage.Oracle E-Business Suite includes several archive and purge routines that will remove data that is no longer required from a system. detailed analysis is necessary to establish the best partitioning approach. and then set then to null once they have been posted. Simplified administration – Where possible. This reduces the total cost of ownership. 4. Note that this is not applicable to hash partitioning. How is the data being accessed? There are several methods to determine access paths. examples include HZ_PARTIES and GL_PERIODS. and what exactly does it store? This will help determine how the table is being used within Oracle EBusiness Suite.Should This Object Be Partitioned? Once a table or index has been identified as suitable candidate for partitioning. Integration with Oracle Information Lifecycle Management (ILM) ILM is concerned with everything that happens to data during its lifetime and includes an approach to move less frequently accessed data to cheaper storage. limiting administrative activities to specific partitions can reduce backup and recovery times. a large percentage of the table will have rows with null values in the corresponding column. Traces for a particular set of Oracle Applications Framework or HTML screens. or Partition Advisor (an Oracle Enterprise Manager plug-in). These tools should be run over at least a complete monthly business cycle to provide a full understanding of how a particular table is accessed. Oracle Forms. What is the growth rate of the table? Analyzing the statistics over a period of time will help to understand the growth rate and any data patterns. Archiving and purging . such as Statspack. • • • Using Database Partitioning with Oracle E-Business Suite Page 30 . Step 2 . Having identified a table or index as a candidate for partitioning. Automatic Workload Repository (AWR). Which other modules or business flows use the table? Many tables are used by more than one product. only certain partitions may need to be backed up or recovered. or concurrent requests can also help in the diagnosis. For example. a posting program may set the POSTED_FLAG to “N” for new records. 3. For example. Archiving and purging prior to an upgrade can help reduce the duration processing the data during the upgrade. This means that over time.

Shares some characteristics with range partitioning e. List Hash Composite Partitioning Range/Hash Composite Partitioning Range/List For indexes. Consider a case of partitioning the GL_BALANCES table. The following table summarizes the various table partitioning strategies and their benefits. Note: Partition key is based on a single column. and prefixed and nonprefixed. by reviewing the AWR or Statspack SQL repository. range alone would lead to wide skews. Useful to avoid data skew across partitions. Using Database Partitioning with Oracle E-Business Suite Page 31 . Uses partition pruning and partition joins according to the partition key. This can be confirmed from an examination of which SQL statements are using the table. For example. this column is the most frequently used to access the data. causing the loss of partition independence. Step 4 . There will be a natural partition key for many large transaction tables or entities. Oracle database partitions by range and then creates sub-partitions for each specific value. An update may result in row migration. Generally not useful for Oracle E-Business Suite. This will typically be the column that is most frequently used as the predicate to access the data. the Oracle database partitions by range. partition pruning.g. the next step is to identify an appropriate partitioning strategy. PERIOD_NAME. Offers the benefits of range and list partitioning. When selecting a partition key. Whenever a particular query includes PERIOD_NAME. Distributes data in a manner that does not correspond to either a logical or business view of data and is not an effective way to manage historical data. Offers the benefits of range and hash partitioning.Which Partitioning Method Should Be Used? After it has been determined that a table or index will benefit from partitioning. evaluate the different indexing methods: global and local partitioned. however. the optimizer uses partition pruning and only accesses those partitions that match the required PERIOD_NAME. leading to partition dependence. enabling I/O to be maximized while avoiding hot spindles. Good for SQL that primarily scans data based on time periods or key values.Step 3 . as the boundaries of range partition define the order of partition in tables and indexes. PLAN_ID and the majority of the access paths are based on this key. it is important consider what happens when an update takes place on the column that the partition key is based on. Useful for tables which have a natural partition key such as OPEN_FLAG. Useful when rows are to be mapped to a particular partition based upon a specific value. Partitioning Strategy Range Characteristics and Usefulness Convenient for partitioning historical and transaction data. so this would be a natural candidate for a partition key. an update statement will translate into a delete statement followed by an insert statement. Useful for scalability (minimizes block contention) and for tables that do not have natural partition keys. Data placed within these partitions is logically ordered by the boundaries that define the range (note that data partitioning of data within a sub-partition has no logical order). Typically. then creates subpartitions within each range to distribute the data. Typically. Useful for tables that have a natural partition key. Queries on this table often include the PERIOD_NAME column.Identify the Partition Key At the heart of any good partitioning strategy lies the choice of a suitable partitioning key. The Oracle database hashes the data resulting in approximately equal stripes across devices.

ALB. ALB. for example to ensure that the transactions access the correct number of partitions. redo log.rowid BETWEEN chartorowid(:l_start_rowid) AND chartorowid(:l_end_rowid) Execution Plan: ----------------------------------------------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | ----------------------------------------------------------------------------------------------------------------------| 0 | UPDATE STATEMENT | | 176K| 9M| 199K (3)| 00:39:57 | | | | 1 | UPDATE | AP_LIABILITY_BALANCE | | | | | | | |* 2 | FILTER | | | | | | | | | 3 | PARTITION HASH ALL | | 176K| 9M| 199K (3)| 00:39:57 | 1 | 32 | |* 4 | TABLE ACCESS BY ROWID RANGE| AP_LIABILITY_BALANCE | 176K| 9M| 199K (3)| 00:39:57 | 1 | 32 | | 5 | TABLE ACCESS BY INDEX ROWID | AP_INVOICES_ALL | 1 | 19 | 3 (0)| 00:00:01 | | | |* 6 | INDEX UNIQUE SCAN | AP_INVOICES_U1 | 1 | | 2 (0)| 00:00:01 | | | ----------------------------------------------------------------------------------------------------------------------Predicate Information (identified by operation id): --------------------------------------------------2 .vendor_site_id) = (SELECT AI. ALB.last_update_login = -1 WHERE ALB. UPDATE /*+ ROWID (ALB) */ ap_liability_balance ALB SET (ALB. and it is therefore highly advisable to test the theoretical partitioning strategy. For example. the optimizer had to scan all 32 partitions. ALB.filter(CHARTOROWID(:L_START_ROWID)<=CHARTOROWID(:L_END_ROWID)) 4 .invoice_id). An inefficient partitioning scheme for a given table may result in worse performance rather than better. Always thoroughly test the newly partitioned tables and indexes before introducing them into a production instance.vendor_site_id FROM ap_invoices_all AI WHERE AI. The output produced by this tool will include the columns PSTART and PSTOP. test to check the optimizer is accessing the correct number of partitions using the DBMS_XPLAN tool (available since Oracle 8i) as this will verify that partition pruning is occurring. Using Database Partitioning with Oracle E-Business Suite Page 32 .creation_date = SYSDATE.last_update_date = SYSDATE. In the example below. ALB. ALB.invoice_id = ALB. Each has its advantages and disadvantages in terms of rollback segment.last_updated_by = 1. and buffer cache usage.access("AI".vendor_id.vendor_id. Suitability of a partitioning strategy can be checked by performing some basic explain plan analysis. AI.access("ALB".ROWID>=CHARTOROWID(:L_START_ROWID) AND "ALB".Step 5 – Performance Check & Access Path Analysis It is important to ensure that the proposed partitioning strategy does not cause performance regressions."INVOICE_ID"=:B1) Step 6 – Partitioned Table Creation and Data Migration Two methods exist to migrate data to a partitioned table.ROWID<=CHARTOROWID(:L_END_ROWID)) 6 .created_by = 1.

Method: 1 – Straight Insert INSERT /*+ APPEND PARALLEL*/ INTO RA_CUSTOMER_TRX_ALL_PART SELECT * FROM RA_CUSTOMER_TRX_ALL This method is the simplest. To minimize the overhead of index maintenance. The table name must have a different name from the nonpartitioned table. it is preferable to perform the insert with the NOLOGGING option and then switch back to LOGGING once complete. Always create the indexes after the data has been successfully migrated to the newly created partitioned table. Some methods for migration are more straightforward than others. If using this method. This procedure could be further enhanced by executing it in parallel. the partition key will be known. and Datapump utilities can all be used to load or unload data stored in partitioned tables. Create an empty partitioned table using the partitioned clause and with the parallel option. Populate data for the required partition from the nonpartitioned table. 3. it is advisable to employ the direct-path-insert method. 2. Import/Export. the INSERT /*+ APPEND */ hint may not be effective. so it is important to analyze the data and estimate how many partitions will have to create. If logging is enabled and indexes are present. The assumption is that having performed the analysis.General guidelines: Always ensure that there is a method in place to revert to a nonpartitioned table if serious problems occur. since this statement will generate a large amount of undo and redo. drop indexes prior to migration and recreate them once the partitioned table has been populated. The steps for this method can be summarized as follows: 1. records will go to the correct partitions after creating the partitioned table. The SQL*Loader. As part of the insert. • Using Database Partitioning with Oracle E-Business Suite Page 33 . In addition. Example include: • Consider using the APPEND hint with an INSERT as an easy code change that provides good performance. A number of performance enhancing features can be applied to the INSERT or SELECT SQL statement. as well as the exact number of partitions that need to be created. All these utilities are partition and subpartition aware. using the APPEND hint.

Data Pump also has the added benefit of allowing you to specify whether to move a subset of data using data filters that are specified as part of Export and Import parameters. It enables very high-speed movement of data in and out of the database. However. By default. 5. Build table indexes for the partitioned table. Additional Information: For further information. Oracle Data Pump Data Pump was introduced in Oracle 10gR1. Any job submitted by Data Pump is run within the database. and database dump files generated by the new Data Pump Export utility are not compatible with dump files generated by the original Export utility. and replaces the existing import (imp) and export (exp) utilities. and have a similar interface to the original export (exp) and import (imp) utilities. Consequently. The Data Pump command line clients. where the table structure allows it. Data Pump automatically chooses the fastest method appropriate for each table. The table into which data is being imported is a pre-existing table. Oracle Data Pump offers many features over and above the existing import and export utilities. such being able to specify multiple threads to execute the Data Pump job.4. Oracle Data Pump was introduced in Oracle 10gR1. expdp and impdp. they can be used interchangeably. this feature makes any job independent of the standalone client that was used to submit the import or export process. As both these methods use the same external data representation. it uses direct path for loading and unloading data. and are still fully supported. Using Database Partitioning with Oracle E-Business Suite Page 34 . Data Pump Export and Data Pump Import. 6. or change the synonym. Data Pump does not work with utilities older than the 10g R1. files generated by the original Export (exp) utility cannot be imported with the Data Pump Import (impdp) utility. invoke the Data Pump Export utility and Data Pump Import utility. Note that both these existing utilities are still shipped with the database. This also allows Database Administrators to submit and monitor jobs independently. This includes object tables that are partitioned. Gather statistics for the new objects. and data unloaded with one method can be loaded using the other. which is partitioned. Data Pump Access Methods Data Pump uses direct path and external table access methods to load and unload table row data. refer to Oracle® Database Utilities manual for 10g or 11g. Rename the partitioned table to the same as the original table. there are certain cases where Data Pump uses external tables instead of direct path inserts: • • A global index on a multi-partitioned tables exists during a single-partition load. and forms the basis of Oracle’s new data movement utilities.

Since the import/export job is inside the database. Remove the parallel option from newly partitioned table. and will therefore need twice the amount of space. 4. Using Data Pump Import the non-partitioned table data into the partitioned table. Build table indexes. with access being granted to users who will be performing exports and imports. Create an empty partitioned table. • • • 2. It requires additional space to hold the Data Pump export file. For example. and follows a similar basic strategy to Method 1. 8. Create a directory. 7. Export the non-partitioned table using Data Pump Export. Rename the partitioned table to the original table or change the synonym. 3. this method has the overhead of requiring performance of a Data Pump Export followed by a Data Pump Import. However. Step 7 – Maintenance Step Once the partitioned table has been created successfully. partitions may need to be split or added if new partition key values are added or partitions are merged. 1. Populate the data for the required partition from the non-partitioned table. exporting to a file requires creation of a database DIRECTORY object for the output directory. Gather table statistics. a number of maintenance operations may need performing. and grant READ and WRITE permissions on it to the relevant users. Some of the most common maintenance operations involve the following actions: • • Adding partitions or subpartitions Dropping a partition Using Database Partitioning with Oracle E-Business Suite Page 35 . the Data Pump Export/Import can be done in parallel. so the Oracle database will be able to read this file. Rename existing non-partitioned table to <table-name_OLD>. Periodically.Method 2 – Import/Export using Data Pump This method makes use of Data Pump Import and Data Pump Export as provided with the Oracle Database. Grant READ or WRITE permissions to a directory object to the relevant users. However. The steps for this method are as follows. which must have a different name from the non-partitioned table with the parallel option. PARTITION MAINTENANCE OPERATIONS There are several SQL commands dedicated to partition maintenance. it is advisable to drop unused partitions and partitions containing historical data that is no longer required for any business reason. 5. 6.

Adding a Partition or Subpartition Adding a partition will have different effects. use the SPLIT PARTITION statement. merging. Depending on the type of table (Heap-Organized or Index-Organized). Range and List Partitions For Range and List partitions. By default. Modifying the logical structure of a partitioned table can be done in the same manner as for a non-partitioned table. These rows are determined by the database according to a hashing function. moving. Hash and Hash Subpartition When adding a new partition to an existing hash-partitioned table. it must not exist in any other partition of the table. Maintenance operations can also be applied to individual partitions. These cases are described below: • Regular (Heap) Organized Table . For example. by adding. or splitting partitions of the table or index. This is not the case with nonpartitioned tables and indexes. the partition key definition of a partitioned table or index can be altered. ADD PARTITION statement can be used.Indexes will be marked UNUSABLE unless the UPDATE INDEXES clause is specified as part of the ALTER Using Database Partitioning with Oracle E-Business Suite Page 36 . which means that existing global and local indexes remain usable. global and local index partitions may be invalidated and marked UNUSABLE. such as exchanging. To add a partition at the beginning or in the middle of a table. For a list partition. this creates an empty partition segment after the last existing partition (as the partition key range is not known). Adding a new partition does affect global indexes. or the physical properties of the partition (such as the storage attribute) modified. dropping. or dropping the partition. the name of a partition can be changed. Similarly. the ALTER TABLE . Rows from the existing partition are then distributed into the new partition. depending on the type of partitioning.• • • • Moving a partition Splitting and merging partitions Exchanging a partition with a table Renaming a partition Changes made to most of the attributes of a partitioned table or index can be done even after it has been created and populated. truncating. the literal value has to be specified: this describes the contents of the partition... where most of the attribute changes are applied to the entire object at object creation time. the addition of another hash partition causes the rehashing of rows.

list. which is then marked as valid. DROP PARTITION/SUBPARTITION command. the equivalent of a DDL statement is run to discard all the rows stored in that partition. For hash-partitioned tables or hash subpartitions of range-hash partitioned tables. Table Partitions Partitions can be dropped from range. The highest partition of a global index cannot be dropped. If a table only contains a single partition. use the MERGE PARTITION statement instead of the DROP PARTITION statement. the corresponding local partition will also be dropped (regardless of its status). unless the index has a default storage tablespace defined at index level. Index Partitions Local indexes cannot be dropped directly: instead. when the table partition is dropped.Local indexes behave in the same way as with heap tables and will be marked UNUSABLE. To preserve the data in the partition. the next highest partition is marked as UNUSABLE. a coalesce operation has to be performed instead. Only the owner of the table or a user with the DROP ANY TABLE privilege can use the DROP_TABLE_PARTITION or TRUNCATE_TABLE_PARTITION clause. Local indexes for all the partitions are marked UNUSABLE and must be rebuilt. • Index-Organized Table .. When a partition is dropped. When the partition of a global index that contains data is dropped. the table must be dropped. the index entries are recreated in the next highest partition. Global indexes or all partitions of partitioned global indexes are marked UNUSABLE and must be rebuilt. Global indexes remain USABLE. Any new local index partitions are stored in the same tablespace as the table partition.TABLE statement. or composite range-list partitioned tables. Dropping Partitions A partition can be dropped by using the ALTER TABLE . Using Database Partitioning with Oracle E-Business Suite Page 37 . On rebuild. These rows cannot be rolled back. then the partition cannot be dropped: instead..

To move a subpartition of a composite partitioned table or index. it may take too long to back up. This can be performed using the ALTER TABLE . Using Database Partitioning with Oracle E-Business Suite Page 38 .. The physical storage attribute of a partition can be modified by using the MOVE PARTITION clause of the ALTER TABLE statement. thus potentially causing a change during the move or rebuild. all storage attributes can be specified. It is important to note that modifying some other attributes. • Index-Organized Table . hash partitions or sub-partitions cannot be split. Splitting Partitions When a partition becomes very large. affects only future storage and does not affect existing data. In such a case. Some physical attributes such as TABLESPACE cannot be modified using the MOVE PARTITION clause. recover or maintain. MOVE/MODIFY PARTITION command.Any local or global index defined for the partition being moved remains USABLE. Index Partitions Depending on the type of database table. Regular (Heap) Organized Table . such as table compression. tables and indexes are not moved but are rebuilt.. table partitions can only be moved one partition at a time. This will result in the redistribution of the partition contents into two new partitions. This depends on the type of table. Local indexes – Each index partition is marked UNUSABLE and must be rebuilt. Table Partitions Unlike a nonpartitioned table that can be moved in a single step. Typically. the keyword SUBPARTITION is used instead of PARTITION. when a partition containing data is moved.All partitions will be invalidated/marked as UNUSABLE unless the UPDATE INDEXES clause is specified as part of the ALTER TABLE statement as follows: • Global Indexes – All global indexes or all partitions of partitioned global indexes are marked UNUSABLE and must be rebuilt. However. Secondly. When moving a table partition or rebuilding an index partition. it is possible to split the partition using the SPLIT PARTITION clause of the ALTER TABLE or ALTER INDEX statement.Moving Partitions Given the tablespace model for Oracle Applications (OATM) – why would you want to move a partition? OATM. is still optional. as follows. although highly recommended. the indexes may be invalidated and marked UNUSABLE. but can be changed using the MODIFY PARTITION clause. if Information Lifecycle Management (ILM) is adopted using the move partition command then it is possible to move the partitions that need to be archived onto cheaper disks.

The characteristics of a table partition split and index partition split are different. when a partition containing data is split two index partitions are created. The characteristics of a table partition merge and index partition merge are different.. Table Partitions When merging two adjacent range partitions into one partition. This is described further below.All global indexes (or all partitions of partitioned global indexes) are marked UNUSABLE and must be rebuilt. • Index-Organized Table – The database marks local indexes as UNUSABLE. These indexes may be invalidated/marked UNUSABLE. the list of literals specified in the SPLIT PARTITION clause will determine into which partition the existing rows will be inserted. Using Database Partitioning with Oracle E-Business Suite Page 39 . The first partition will contain all the values less than the partition key value. Merging Partitions The ALTER TABLE . Rows matching the partition key value will be placed into the first partition. Index Partitions Depending on the type of database table. the resulting partition inherits the higher or upper boundary of the two merged partitions. The two original partitions are also dropped. Regular (Heap) Organized Table . Local indexes – Each new index partition is marked UNUSABLE and must be rebuilt. as described below. Table Partitions Table partitioning is performed if a partition that is range-partitioned is split. The nature of hash partitioning means that it is not possible to merge hashpartitioned tables or hash subpartitions of a range-hash partitioned table.All new partitions will be invalidated and marked as UNUSABLE unless UPDATE INDEXES is specified as part of the ALTER TABLE statement. When a list partition is split. This results in the creation of two new partitions that together contain all the rows of the original partitions. and the remaining rows will be placed into the second partition. and the second partition will contain rows that are greater than or equal to the partition key value. Global indexes remain USABLE. It is not possible to merge nonadjacent range partitions. as described below.. MERGE PARTITION command can be used to merge the contents of two partitions into a single partition. as follows: • Global Indexes . along with any corresponding local indexes.

Global indexes on the partitioned table will be marked UNUSABLE. the resulting partition will still be the default partition. EXCHANGE PARTITION command. If a default list partition is merged with any other partition. in contrast to table partitions. Global indexes remain USABLE. Using Database Partitioning with Oracle E-Business Suite Page 40 . Exchanging a partition does not move any rows. which are not exchanged with a local index. as there is no ordering of list partitions. Indexes on the non-partitioned table. Renaming Partitions When renaming partitions or sub-partitions..All global indexes or all partitions of partitioned global indexes. it is important to ensure that the partition key values are valid values of the partition. Using the NOVALIDATE clause will skip this validation. by a scan of the nonpartitioned table rows. This will be verified before the actual exchange takes place. are marked UNUSABLE and must be rebuilt..All new partitions will be invalidated and marked as UNUSABLE unless UPDATE INDEXES is specified as part of the ALTER TABLE statement: • Global Indexes . The resulting single merged partition consists of all the data from the original two partitions. are marked UNUSABLE and will only be maintained/valid if the UPDATE GLOBAL INDEXES clause has been specified. when partitions containing data are merged into a single partition. • Index-Organized Table – The database marks local indexes as UNUSABLE. Local indexes partitions are exchanged with matching non-partitioned indexes defined on the non-partitioned table. When exchanging a partition with a table. the indexes may be invalidated marked UNUSABLE. This is summarized below: Regular (Heap) Organized Table . the partition name must be unique within the affected table or index.Any two list partitions can be merged. Local Indexes – All local index partitions and subpartitions are marked UNUSABLE and must be rebuilt. range list and hash-partitioned tables can be exchanged with non-partitioned tables. and the tables can be populated or empty. the two partitions do not need to be adjacent. Exchanging a Partition with a Table Using the ALTER TABLE . Index Partitions Depending on the type of database table.

The purpose of analyzing the partitioning method and partition key selection is to determine which flows within the Oracle E-Business Suite can potentially gain the most from the partitioning functionality.050 5. the information is accessed by concurrent programs and reports within the same module.. index partitions and subpartitions can be renamed using the ALTER INDEX .870. this table holds the invoice distribution information that is either manually entered or system-generated.To rename a partitioned/nonpartitioned table or index. Using Database Partitioning with Oracle E-Business Suite Page 41 .. tend to grow very large and are therefore ideal candidates for partitioning. use one of these two statements: RENAME OE_ORDER_LINES_ALL TO OE_ORDER_LINES_ALL_BKP. this table can become very large.AP_INVOICE_DISTRIBUTIONS_ALL (Oracle Payables) Functional Analysis For a larger Oracle E-Business Suite customer this table can grow upwards of 48GB in size. Typically.---------. An invoice can comprise of one or more distributions.512 How is this table used? This is one of the main Oracle Payables tables. RENAME PARTITION command.---------AP_INVOICE_DISTRIBUTIONS_ALL 94. EXAMPLE OF HOW TO PARTITION A TABLE The objective of partitioning a table is to ensure that the optimizer returns the rows that satisfy the query criteria in the most efficient manner. with over 94 million rows. TABLE_NAME NUM_ROWS BYTES GB -----------------------------. The diagram on the below shows how the AP_INVOICE_DISTRIBUTIONS_ALL table is used by other products. such as the Invoice Workbench form. Similarly.---------. There are a number of approaches than can be used to determine the most common access path used to access a particular table and hence.. The tables supporting product workbenches. but can also be accessed by other interrelated products. Table partitions and subpartitions can be renamed using the ALTER TABLE .. the partition key. such as Oracle Purchasing. ALTER TABLE OE_ORDER_LINES_ALL RENAME TO OE_ORDER_LINES_ALL_BKP. The optimizer should use partition pruning to minimize I/O and use partition-wise joins as necessary. and Oracle Project Accounting. and like other detail tables. RENAME PARTITION command. This table belongs to the Oracle Payables product. From a functionality perspective.0869E+10 48. Example: Partitioning . Oracle Bill of Materials.

In most cases. Using Database Partitioning with Oracle E-Business Suite Page 42 .If customizations are present or if further clarification of the access paths and keys used is needed. The advantage of this approach is that often different sets of users will query or interact with the same information in different ways and then it is important to be aware of all the different ways a particular table is accessed. In some cases the output from the Statspack/AWR report may be truncated depending on the length of the SQL. in which case you use the V$SQL table to get the complete SQL based upon the hash value shown in the Statspack/AWR report and then use the explain plan tool to generate an explain plan. it is better to take several traces of different flows that make use of the table in question. Index Analysis The next step is to check whether the indexed columns are being used across the majority of SQL statements. The Statspack/AWR repository can be useful in some cases to identify which particular SQL is accessing a table. then also review the SQL contained in the statspack/AWR repositories. The following table shows that composite indexes that include the INVOICE_ID column on the leading edge in most cases have the highest number of distinct keys (DK).

25m AP_INVOICE_DISTRIBUTIONS_N5 87.04m 66.08m AP_INVOICE_DISTRIBUTIONS_N6 95.24m 95.invoice_id = p_inv_rec. 'DISCOUNT'.55m 14.19m ACCOUNTING_EVENT_ID 1 POSTED_FLAG 27319 PREPAY_DISTRIBUTION_ID 0 AWARD_ID 92.invoice_distribution_id and aphd.82m 92.24m 14.pay_dist_lookup_code. ap_payment_history_all aph where aid. ----------------------------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| ----------------------------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 1 | 63 | 211 (1)| | 1 | SORT AGGREGATE | | 1 | 63 | | | 2 | NESTED LOOPS | | 44 | 2772 | 211 (1)| | 3 | NESTED LOOPS | | 44 | 1672 | 123 (1)| | 4 | TABLE ACCESS BY INDEX ROWID| AP_INVOICE_DISTRIBUTIONS_ALL | 44 | 616 | 14 (0)| |* 5 | INDEX RANGE SCAN | AP_INVOICE_DISTRIBUTIONS_U1 | 44 | | 4 (0)| |* 6 | TABLE ACCESS BY INDEX ROWID| AP_PAYMENT_HIST_DISTS | 1 | 24 | 3 (0)| |* 7 | INDEX RANGE SCAN | AP_PAYMENT_HIST_DISTS_N2 | 1 | | 2 (0)| |* 8 | TABLE ACCESS BY INDEX ROWID | AP_PAYMENT_HISTORY_ALL | 1 | 25 | 2 (0)| |* 9 | INDEX UNIQUE SCAN | AP_PAYMENT_HISTORY_U1 | 1 | | 1 (0)| ----------------------------------------------------------------------------------------------------- Using Database Partitioning with Oracle E-Business Suite Page 43 .75m AP_INVOICE_DISTRIBUTIONS_U2 95.invoice_distribution_id = aphd.payment_history_id = aphd.18m INVOICE_ID OLD_DIST_LINE_NUMBER 1.78m AP_INVOICE_DISTRIBUTIONS_N7 AP_INVOICE_DISTRIBUTIONS_U1 5.invoice_id and aid. 'PAYMENT UNCLEARING'.68m 201701 0 6759 157980 88 AP_INVOICE_DISTRIBUTIONS_N28 CHARGE_APPLICABLE_TO_DIST_ID AP_INVOICE_DISTRIBUTIONS_N29 AP_INVOICE_DISTRIBUTIONS_N3 94. 'PAYMENT CLEARING ADJUSTED') The explain plan is shown in the following table.posted_flag = 'Y' and aph. --'EXCHANGE RATE VARIANCE'.amount) from ap_payment_hist_dists aphd. ap_invoice_distributions_all aid.75m 316273 93.41m 2 62518 0 92.73m AP_INVOICE_DISTRIBUTIONS_N30 AP_INVOICE_DISTRIBUTIONS_N4 93.amount.68m DETAIL_TAX_DIST_ID DIST_CODE_COMBINATION_ID 0 BC_EVENT_ID ACCOUNTING_DATE BATCH_ID ASSETS_ADDITION_FLAG ASSETS_TRACKING_FLAG POSTED_FLAG ORG_ID PO_DISTRIBUTION_ID INVOICE_ID INVOICE_LINE_NUMBER DISTRIBUTION_LINE_NUMBER INVOICE_DISTRIBUTION_ID 97.24m An example of SQL that accesses this table is as follows: select sum(--decode(aphd.32m 85389 250673 10 91.16m 99.28m OLD_DISTRIBUTION_ID 71.16m RELATED_ID 0 82280 PARENT_REVERSAL_ID 10. 'AWT') and aph.52m 29.16m 0 734737 103. -1 * aphd.52m 93.2m Column Name -----------------133562 PROJECT_ID TASK_ID 40893 PA_ADDITION_FLAG PROJECT_ID REQUEST_ID 64627 AWT_INVOICE_PAYMENT_ID 250664 AWT_INVOICE_ID 8 RCV_TRANSACTION_ID 2.pay_dist_lookup_code in ('CASH'.Index Name -----------------------------AP_INVOICE_DISTRIBUTIONS_N13 AP_INVOICE_DISTRIBUTIONS_N14 AP_INVOICE_DISTRIBUTIONS_N15 AP_INVOICE_DISTRIBUTIONS_N16 AP_INVOICE_DISTRIBUTIONS_N17 AP_INVOICE_DISTRIBUTIONS_N18 AP_INVOICE_DISTRIBUTIONS_N19 INVENTORY_TRANSFER_STATUS AP_INVOICE_DISTRIBUTIONS_N2 AP_INVOICE_DISTRIBUTIONS_N20 AP_INVOICE_DISTRIBUTIONS_N21 AP_INVOICE_DISTRIBUTIONS_N23 AP_INVOICE_DISTRIBUTIONS_N24 CORRECTED_INVOICE_DIST_ID AP_INVOICE_DISTRIBUTIONS_N25 AP_INVOICE_DISTRIBUTIONS_N26 AP_INVOICE_DISTRIBUTIONS_N27 Rows ----- DK -----15. aphd.payment_history_id and aph.transaction_type in ('PAYMENT CLEARING'.

This only leaves hash or range partitioning.access("APH"."POSTED_FLAG"='Y') 9 . as it does not make sense to use it in this scenario."PAYMENT_HISTORY_ID"="APHD"."PAY_DIST_LOOKUP_CODE"='AWT' OR "APHD". range partitioning appears to be the best approach.filter(("APH". this will need to be tested.access("AID". Using Database Partitioning with Oracle E-Business Suite Page 44 .Predicate Information (identified by operation id): --------------------------------------------------5 .access("AID".filter("APHD". This analysis provides clues to the partitioning approach that will provide the best performance."PAYMENT_HISTORY_ID") The choice for partition key and partition strategy is determined by analyzing how the data is accessed."TRANSACTION_TYPE"='PAYMENT UNCLEARING') AND "APH". List partitioning can be eliminated. given its functional importance and frequent usage. Conclusion The INVOICE_ID is a good column to use a partition key. As mentioned above. The next stage is to decide which partitioning method to use."PAY_DIST_LOOKUP_CODE"='DISCOUNT') 7 ."TRANSACTION_TYPE"='PAYMENT CLEARING' OR "APH"."INVOICE_DISTRIBUTION_ID"="APHD"."INVOICE_DISTRIBUTION_ID") 8 ."INVOICE_ID"=TO_NUMBER(:B0)) 6 . As there is a natural partitioning key and given that the vast majority of access to this table will be made by INVOICE_ID. it is relatively unique and has a high degree of selectivity so the optimizer can make use of partition pruning. In addition."TRANSACTION_TYPE"='PAYMENT CLEARING ADJUSTED' OR "APH"."PAY_DIST_LOOKUP_CODE"='CASH' OR "APHD".

Range PERIOD_NAME Using Database Partitioning with Oracle E-Business Suite Page 45 . unearned revenue. debits or credits entries. This column identifies the organization that owns the non–labor resource that was utilized as the work was performed. This will of course mean there will be more partitions as each PERIOD_NAME will have its own unique partition. The GL data model is comprised of Batches. RA_CUST_TRX_LINE_GL_ DIST_ALL Holds accounting records for revenue. Additionally. as this is the only way to uniquely identify an invoice. In most cases this column is used to join to this table and certainly can benefit from partitioning as CBO could partition prune based on AE_LINE_ID. this column provides a way to naturally segregate the data. which access a particular SET_OF_BOOKS_ID. and unbilled receivables for each invoice or credit memo line.g. Range or Hash AE_LINE_ID PA_EXPENDITURE_ITEMS _ALL Range EXPENDITURE_ITEM_ID This is a system generated number that uniquely identifies the expenditure item and is used a common access and filter predicate of this table. foreign currency. either directly or top-down (e. Stores the smallest categorized expenditure units charged to projects and tasks. Range or List SET_OF_BOOKS_ID GL_IMPORT_REFERENCES Range JE_HEADER_ID AP_AE_LINES_ALL Stores the accounting representation for a particular transaction in terms of balanced.Examples of Partition Keys for Oracle Applications Tables Table name Table Description Suggested Partitioning Method Range Suggested Partition Key Description AP_INVOICES_ALL Contains one row for each invoice.g. other important information such as the account and other reference information pointing to the original transaction is also stored. The financial calendar is broken into a fixed number of periods. from line level). Also ledger currency. At least one accounting distribution must exist for each invoice or credit memo line. PA_EXPENDITURE_ITEMS _ALL Hash ORGANIZATION_ID GL_BALANCES Stores actual. Headers. This will be especially advantageous for concurrent programs. Stores individual transactions from sub-ledgers that have been summarized into Oracle General Ledger journal entry lines through the Journal Import process. This column will uniquely identify a line record in the table. Oracle Receivables creates one row for each accounting distribution. this column allows us to naturally segregate the data based on a time/period component. This is the primary key for this table. Note: An alternative way of partitioning this table would be to use list partitioning and still use the PERIOD_NAME column as the partition key. and Lines. INVOICE_ID This is the primary key for this table and most queries against this table will have this column included. from batches) or bottom-up (e. budget and encumbrance balances for detail and summary accounts. Although this is a very unselective column due to the low number of distinct values. in the majority of cases this column will be used to uniquely identifies a header record. Given that each row in this table will be in the context of an ORGANIZATION_ID. as all the rows in this table are always in the context of a GL_PERIOD. This column is only populated for usage items. The PERIOD_NAME name column is the most commonly used to join to this table. Typically when joining to these tables. These are both in transaction currency as well as functional currency. and statistical balances for each accounting period that has ever been opened.

Queries against this table will usually be specific to an ITEM_TYPE. and commitment lines. However when combined with the ITEM_KEY column that has a high number of distinct values and selectivity. This case study reviews the partitioning strategy for the large GL tables such as GL_JE_LINES. and GL_DAILY_BALANCES. Range CUSTOMER_TRX_LINE_ID WF_ITEM_ATTRIBUTE_VA LUES Range/Hash ITEM_TYPE/ITEM_KEY PRACTICAL PARTITIONING CASE STUDY In this section. Oracle General Ledger The customer’s Financial Management System (FMS) database is currently 340 GB in size with General Ledger representing 90% of this data. System generated Invoice line identifier that uniquely identifies a customer transaction line. This column is often used as an access or filter predicate. an invoice can have one line for Product A and another line for Product B. Typically. GL_BALANCES. The customer wants to improve manageability and performance by partitioning. Contains the data for the attributes defined in the WF_ITEM_ATTRIBUTES table. For example.Table name Table Description Suggested Partitioning Method List Suggested Partition Key Description OE_ORDER_LINES_ALL Stores information for all order lines in Oracle Order Management OPEN_FLAG Popular filter condition used on this table as functionally orders can be OPEN or CLOSED. Cost distribution lines amount are implicitly debit amounts. which don’t contain the value of the EXPENDITURE_ITEM_ID. This column will uniquely identify an order line and therefore any joins to this table will include this column. RA_CUSTOMER_TRX_LINE S_ALL Stores information about invoice. The database is dominated by three large GL tables and their associated indexes: GL_JE_LINES. by using range partitioning the CBO can ignore those partitions. debit memo. Range EXPENDITURE_ITEM_ID ORGANIZATION_ID Functionally all the expenditure items will belong to a particular organization. Using Database Partitioning with Oracle E-Business Suite Page 46 . product-specific examples from customers demonstrate how a particular table can be partitioned. it creates one or more corresponding cost distribution lines to hold the cost amounts and the General Ledger account information to which the cost amounts will post. we get a more efficient partitioning key that gives us the best of both partitioning methods. bills receivable. When a cost distribution program processes an expenditure item. customers will only use 5 different values for ITEM_TYPE. This column is used for common access & filter predicates and could be used by the optimizer to disregard partitions that do not contain the value of the CUTOMER_TRX_LINE_ID. GL_BALANCES and GL_DAILY_BALANCES. credit memo. and therefore this is a natural way of segregating the data. Each line requires one row in this table. Hash LINE_ID PA_COST_DISTRIBUTION _LINES_ALL Stores information about the cost distribution of expenditure items.

. i. ‘MAY-00’. 170. ‘APR-02’. 55. etc.000.000 records (6% of database) GL_DAILY_BALANCES 16 GB table – approx.000 records (35 % of database) GL_BALANCES 20 GB table – approx. partition OTHER values less than MAXVALUES tablespace data_other ). partition DEC98 values less than ('DEC-99') tablespace data_dec98. partition DEC99 values less than ('DEC-AA') tablespace data_dec99. 360. The partition called ‘APR_OTHER’ will contain any future April periods. In fact. partition APR99 values less than ('APR-AA') tablespace data_apr99.. partition APR_OTHER values less than ('APR-50') tablespace data_apr_other..000 records (5% of database) Strategy The partition key PERIOD_NAME was chosen. partition AUG99 values less than ('AUG-AA') tablespace data_aug99. partition DEC00 values less than ('DEC-01') tablespace data_dec00. each period has a partition (<MON>_OTHER) to catch any future rows for that period.e. ) partition by range ( period_name ) ( partition APR00 values less than ('APR-01') tablespace data_apr00.000. partition SEP99 values less than ('SEP-AA') tablespace data_sep99. partition AUG98 values less than ('AUG-99') tablespace data_aug98. create table GL_JE_LINES ( …. The following statements show the partition range values necessary to achieve a workable range. ‘APR-01’. e. partition AUG00 values less than ('AUG-01') tablespace data_aug00. partition DEC_OTHER values less than ('DEC-50') tablespace data_dec_other. . …. Using Database Partitioning with Oracle E-Business Suite Page 47 . . partition APR98 values less than ('APR-99') tablespace data_apr98. The tables GL_BALANCES and GL_DAILY_BALANCES were also partitioned on PERIOD_NAME using the same strategy as used with GL_JE_LINES.. that the partition called ‘APR00’ will contain all the rows where period_name = ‘APR-00’.000. The column format was MON-RR.Background – Current Table Volumes The largest database tables are as follows: GL_JE_LINES 119 GB table – approx. for example. This strategy means.g. partition AUG_OTHER values less than ('AUG-50') tablespace data_aug_other.

Due to invalidation. alter table gl_je_lines drop partition SEP-98. For purging data (based on PERIOD_NAME). the 'bucket' partition APR_OTHER cannot retain its name hence it would be split into two (2) different names: APR_OTHER1. the index will need to be rebuilt. the customer creates a new partition for APR-01 data: ALTER TABLE GL_JE_LINES split partition APR_OTHER at ('APR-02') into (partition APR01 tablespace data_apr01. which will become the new 'bucket' for future April periods. the customer needs to create a new partition prior to the Open Period process. In the following example. Note with the SPLIT command.Partition Maintenance 1. PERIOD_NAME) • Local Index: GL_JE_LINES_U1 – 12GB (JE_HEADER_ID. JE_LINE_NUM) GL-BALANCES Indexes • Global Index: GL_BALANCES_N1 – 5GB (CODE_COMBINATION. partition APR_OTHER1 tablespace data_apr_other1 ). GL_JE_LINES Indexes • Global Index: GL_JE_LINES_N1 – 17GB (CODE_COMBINATION. At month-end. Index Strategy The indexes associated with these tables are also very large and need to be created as either local or global indexes depending upon their usage. PERIOD_NAME) • Local Index: GL_BALANCES_N2 – 4GB (PERIOD_NAME) Using Database Partitioning with Oracle E-Business Suite Page 48 . just use the DROP partition command after the data has been archived. This process would also take place for GL_BALANCES and GL_DAILY_BALANCES. This command will also drop any local indexes associated with this partition. 2.

Using Database Partitioning with Oracle E-Business Suite Page 49 . Performance .2GB (PERIOD_NAME) • Global Index: GL_DAILY_BALANCES_N3 – 1. CURRENCY_CODE) • Local Index: GL_DAILY_BALANCES_N2 – 1. Purging historic data . 3. However. Partitioning is a very useful feature that can bring significant benefits to system performance and manageability. Partitioning means that it is possible to simply drop the partition and deal with any global indexes.Operations can take place on individual partitions. Some large process such as summary accounts and open period should benefit from partitioning by period.Performance improvements of SQL were achieved through partition pruning. 4. Much of Oracle E-Business Suite code accesses these large tables by PERIOD_NAME. PERIOD_NUM) • Global Index: GL_DAILY_BALANCES_N4 – 152MB (TEMPLATE_ID) The Benefits of This Partitioning Strategy The following points summarize the main benefits: 1. it can also cause problems if implemented without careful thought. 2.2GB (PERIOD_YEAR. which limits the choice of keys. the information in this paper is no substitute for the thorough testing that needs to be performed simulating your real-life workload.Prior to partitioning the purge process for GL_JE_LINES took approximately 36-48 hours to purge each month of data. Read-only partitions – This customer placed old period partitions in read only tablespaces as this reduced the cost of storage. DEFINING YOUR PARTITIONING STRATEGY As stated in the introduction. PERIOD_NAME.• Global Index: GL_BALANCES_N3 – 4GB (PERIOD_NUM. The biggest problem when defining partition strategies for the Oracle E-Business Suite is that the application code has been prebuilt. PERIOD_YEAR) • Global Index: GL_BALANCES_N4 – 590MB (TEMPLATE_ID) GL_DAILY_BALANCES Indexes • Global Index: GL_DAILY_BALANCES_N1 – 2GB (CODE_COMBINATION. This also has other advantages by reducing maintenance activities. Maintenance .

performance-wise: they will work just as well with or without the table partition key in the WHERE clause. For example. and is probably the most common mistake made when introducing partitioning to an existing system. system performance may be impacted while the database deletes and inserts all affected data from all global indexes in one transaction. the 1-to1 mapping of this scheme of index and table partitions allows for total independence of data. This will be most noticeable in an Oracle RAC system. the introduction of partitioning is complex. Whether this impact is manageable with respect to your workload and any service level agreements is something that thorough testing can help answer.Furthermore. changes to the partitioning strategies delivered with the base product are not recommended or supported. will incur a significant performance penalty by requiring all index partitions to be scanned. Using Database Partitioning with Oracle E-Business Suite Page 50 . requiring both substantial analysis and robust testing of its effect on different components in your workload. you would also need to consider the indexes – should you use Local or Global? Both choices can have repercussions across the Oracle E-Business Suite system. However. As a final point.. In addition. While this might improve manageability and performance by keeping active data on your fastest storage devices. as the ALTER TABLE MOVE PARTITION commands are fast. Local indexes would be the best for manageability. from a manageability point of view. this benefit can also introduce a performance problem: SQL statements that access the partitioned table. introducing a range or list partitioning scheme using a date column as a key would allow historical data to be moved easily to cheaper storage by simply moving partitions. all indexes remain usable and there is no need to update or rebuild them. partition maintenance operations result in the global indexes becoming unusable until manually rebuilt. Therefore. it is worth mentioning that a partition advisor was introduced in Oracle Database 11gR1. but do not have the partition key in the WHERE clause. Global indexes have the opposite effect. and a compression advisor in 11gR2. requiring a corresponding volume of rollback/undo and redo activity that is normally associated with DML transactions. if you are using the UPDATE INDEXES clause and affecting a large amount of data. Alternatively. resulting in higher logical and physical I/O requirements. However.

This paper was revised with the reference to OracleMetaLink: Note 752322.ORACLE DATA DICTIONARY TABLE & VIEWS FOR PARTITIONING Summary of ALTER TABLE & ALTER INDEX clauses used for maintenance operation for table and index partitions:• • • Add Partition – To add a new partition after the highest partition Drop Partition – To drop a partition including its indexes Exchange Partition – To change a partition into a non-partitioned table and vice versa Merge Partition – To merge two adjacent partitions Modify Partition – To modify the storage parameters of a partition Modify default attributes – To modify the storage parameters of all partitions Move Partition – To move a partition generally to defrag or to change tablespace Rename Partition – Change name of a partition Split Partition – Split a partition into two Truncate Partition – Remove data of a partition • • • • • • • The following clauses are allowed with ALTER INDEX • • • Drop Partition – Only a global index partition can be dropped Modify Partition – To modify the storage parameters of a partition Modify default attributes – To modify the storage parameters of all partitions Rebuild Partition – To rebuild a partition generally to defrag or to change Rename Partition – Change name of a partition SPLIT PARTITION – Split a partition into two UNUSABLE – To set some or all index partition as unusable • • • • Using Database Partitioning with Oracle E-Business Suite Page 51 .REVISIONS This white paper was first issued in February 2008.1 in November 2008. APPENDIX A .

subpartition storage parameters. default values ALL view displays partitioning information for all partitioned tables accessible to the user. View DBA_TABLES DBA_PART_TABLES ALL_PART_TABLES USER_PART_TABLES Description Table structure. Display the histogram data (end-points for each histogram) for histograms on table partitions. USER view is restricted to partitioning information for partitioned tables owned by the user Display partition-level partitioning information.USEFUL DATABASE VIEWS The following database view can be used to view partitioned tables and index information. Display the following for index partitions: partition-level partitioning information. DBA_TAB_PARTITIONS ALL_TAB_PARTITIONS USER_TAB_PARTITIONS DBA_TAB_SUBPARTITIONS ALL_TAB_SUBPARTITIONS USER_TAB_SUBPARTITIONS DBA_PART_KEY_COLUMNS ALL_PART_KEY_COLUMNS USER_PART_KEY_COLUMNS DBA_SUBPART_KEY_COLUMNS ALL_SUBPART_KEY_COLUMNS USER_SUBPART_KEY_COLUMNS DBA_PART_COL_STATISTICS ALL_PART_COL_STATISTICS USER_PART_COL_STATISTICS DBA_SUBPART_COL_STATISTICS ALL_SUBPART_COL_STATISTICS USER_SUBPART_COL_STATISTICS DBA_PART_HISTOGRAMS ALL_PART_HISTOGRAMS USER_PART_HISTOGRAMS DBA_SUBPART_HISTOGRAMS ALL_SUBPART_HISTOGRAMS USER_SUBPART_HISTOGRAMS DBA_PART_INDEXES ALL_PART_INDEXES USER_PART_INDEXES DBA_IND_PARTITIONS ALL_IND_PARTITIONS USER_IND_PARTITIONS DBA_IND_SUBPARTITIONS ALL_IND_SUBPARTITIONS USER_IND_SUBPARTITIONS DBA_SUBPARTITION_TEMPLATES ALL_SUBPARTITION_TEMPLATES USER_SUBPARTITION_TEMPLATES Display the subpartitioning key columns for compositepartitioned tables (and local indexes on composite-partitioned tables). Display subpartition-level partitioning information. and partition statistics generated by the DBMS_STATS package or the ANALYZE statement. Display column statistics and histogram information for subpartitions of tables. Display the following information for index subpartitions: partition-level partitioning information. Using Database Partitioning with Oracle E-Business Suite Page 52 . Display the histogram data (end-points for each histogram) for histograms on table subpartitions. storage parameters for the partition. Partition type. Display the partitioning key columns for partitioned tables. Display column statistics and histogram information for the partitions of tables. Display partitioning information for partitioned indexes. Partition Y/N DBA view displays partitioning information for all partitioned tables in the database. and subpartition statistics generated by the DBMS_STATS package or the ANALYZE statement. partition storage parameters. storage parameters for the partition. Display information about existing subpartition templates. statistics collected by the DBMS_STATS package or the ANALYZE statement.APPENDIX B . statistics collected by the DBMS_STATS package or the ANALYZE statement.

. Other names may be trademarks of their respective owners.com Copyright © 2008. electronic or mechanical. CA 94065 U.506. This document is not warranted to be error-free. whether expressed orally or implied in law.S.7200 oracle. without our prior written permission. All rights reserved. Worldwide Inquiries: Phone: +1. nor subject to any other warranties or conditions.506.650. We specifically disclaim any liability with respect to this document and no contractual obligations are formed either directly or indirectly by this document. Oracle.A. for any purpose.650.Partitioning for the Oracle E-Business Suite Oracle Applications Development Performance Group March 2009 Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores. This document is provided for information purposes only and the contents hereof are subject to change without notice. This document may not be reproduced or transmitted in any form or by any means. including implied warranties and conditions of merchantability or fitness for a particular purpose.7000 Fax: +1. Oracle is a registered trademark of Oracle Corporation and/or its affiliates.