Archive Purge ILM Paper

Reducing Your Oracle E-Business Suite Data Footprint using Archiving, Purging, and Information Lifecycle Management An Oracle White Paper November 2008

Reducing your E-Business Suite Data Footprint using Archiving, Purging and Information Lifecycle Management

Executive Summary .......................................................................................... 2 The Storage Dilemma – How big is Your Data Footprint? .............. 2 The Challenge – Meeting the demand .................................................. 3

Does Data Have A Lifecycle?.......................................................................... 3 Data lifecyCle for the Oracle E-Business Suite ............................................ 5

Differing Data Types ............................................................................... 5 Don’t Be Managed By Your Data................................................................... 5

The Solution.............................................................................................. 6 How long should I keep my data for?............................................................ 8 Oracle E-Business Suite Archiving and Purging Programs ........................ 9

Enforcing Cross-Product Dependencies .............................................. 9 Purge Portal ................................................................................................. 10 Oracle General Ledger (GL) ..................................................................... 12 Oracle Payables/Oracle Purchasing (AP/PO)....................................... 12

Invoice Purge Criteria............................................................................ 12 Payment Purge Criteria.......................................................................... 13 Supplier Purge Criteria .......................................................................... 13 Requisition Purge Criteria ..................................................................... 13 Purchase Order Purge Criteria ............................................................. 13

Oracle Receivables (AR) ............................................................................ 14 Oracle Cash Management (CE) ................................................................ 16

Purging..................................................................................................... 16 Archiving ................................................................................................. 16

Oracle Fixed Assets (FA)........................................................................... 17 Order Management (ONT)....................................................................... 18 Oracle Application Object Library (FND) and Workflow (WF) ........ 19

Purge Concurrent Request/Manager Data Program ........................ 19 Purge Page Access Tracking Repository ................................................. 20 Purging Workflow Data............................................................................. 20

Information Lifecycle Management (ILM).................................................. 22 ILM for the Oracle E-Business Suite....................................................... 22 Step 1 – Define Your Data Classes.......................................................... 22 Step 2 – Create Storage Tiers for Data Classes ...................................... 23 Step 3 – Create Data Migration Policies.................................................. 24 Step 4 – Define and Enforce Compliance Policies................................ 24

The ILM Assistant .......................................................................................... 24 Step: 1 - Create Storage Tiers for the Data Classes ............................... 25 Step: 2 - Define a Date Lifecycle .............................................................. 26 Step: 3 - Assigning a table to a Lifecycle ................................................. 28

Where to start?................................................................................................. 33 Functional/End User Requirements ................................................... 34 Technical Considerations ...................................................................... 35

Conclusion........................................................................................................ 36 References ........................................................................................................ 37 Revisions........................................................................................................... 38 Appendix A: Example Archive & Purge Programs (Oracle E-Business Suite Rel 11.5.10) ............................................................................................. 39 Appendix B: Examples Archive & Purge Programs (Oracle E-Business Suite Rel 12) ..................................................................................................... 42

Reducing your E-Business Suite Data Footprint using Archiving, Purging and Information Lifecycle Management

EXECUTIVE SUMMARY One of the challenges faced today by many enterprise software customers is managing their exponential data growth while lowering costs. There are a number of reasons for this exponential growth of data such as:

- Consolidation: Many customers have consolidated their front and back office systems into a fewer systems or one large global single instance.

- New software features: These provide a new user experience with detailed transaction level information and hundreds of cross-industry capabilities spanning enterprise resource planning, customer relationship management, and supply chain planning products.

- Increased data volume : Many customers now operate globally and are experiencing an increased growth in transactions.

The combined result of all of these influences is that many customers now face a host of challenges when it comes to storage.

The Storage Dilemma – How Big is Your Data Footprint? An organization’s data footprint can be

defined as the total storage needed by the organization to fulfill its business needs.

An organization’s data footprint can be defined as the total storage needed by the organization to fulfill its business needs. For any organization business data is one of the most important assets of an organization. It is fair to assume that the data generated by a corporation will increase over time, with historical data being accessed less frequently. However, there is a need to maintain data for regulatory compliance reasons. Many multinational corporations will need to adhere to each country’s legislation and specific mandates for data retention. The requirement to keep data means that administrators have to decide which data to keep online and which data to archive. As you can appreciate, for multinational companies this could pose some additional challenges. In some cases this may result in a larger quantities of data having to be kept online and organizations having a larger than necessary storage pool.

Reducing your E-Business Suite Data Footprint using Archiving, Purging and Information Lifecycle Management Page 2

The Challenge – Meeting the demand

Many organizations will face several challenges when it comes to data for example how to keep up with the demand of rapid storage growth especially when there are new applications to deploy that need to meet regulatory requirements. In addition, to this many organizations are trying to reduce the costs and complexities associated with storage, while still trying to meet their service level agreements (SLA) with their business community. It is not surprising that most customers will feel that their database storage needs will increase. There are also other challenges when it comes to having such a large data footprint such as upgrades; for example, how much data do you upgrade?

DOES DATA HAVE A LIFECYCLE? The data lifecycle summarizes how data is

transformed from an active to inactive state. The cycle begins with data being

created in an active state and will be referenced or used on a frequent basis.

Active Data - In most cases this is the data an organization needs to survive. Although

taken for granted, active data is of most interest to an organization and usually

there will be a business to create active data.

Data and Time Based Value - Data is most active and frequently accessed in its

creation state. Data will have a different value at different moments in time and

therefore will need to be managed differently.

Inactive Data - This is the state of data at the end of the data lifecycle; i.e. it is no

longer active and has no need or purpose for business tasks.

Most of us are familiar with the concept of the data lifecycle which begins with data being created and stored initially, and continues to the time when it becomes obsolete and has to be either deleted or kept for compliancy reasons such as for the Sarbanes-Oxley Act or disaster recovery reasons.

Figure 1 – Data lifecycle

Data is most active and frequently accessed when it is initially created; also, data can have different values at different moments in time and therefore will need to be managed differently. As time progresses this data is accessed less and less frequently as it has lost its importance and business value. More often than not, you will find that most users only access around 20% of the data, and tend to be focused on the most up-to-date transactions. Therefore, most data transitions from being active to passive, usually as a consequence of an Oracle E-Business event such as month, quarter, or year-end processing. Data retention legislation


introduces new phases. Instead of being archived and purged, less frequently accessed data needs to be moved to low-cost storage mediums.

All data goes through different stages in its lifecycle. As a consequence, it is important for customers to understand how their data is used, how long does it need to be kept for. By understanding these requirements customers can then develop a formal strategy that should provide a means to link usage patterns with the most suitable type of storage. As a result minimizing the total cost of storing data over its life cycle.

Figure 2A – Data active versus volume changes over time

Figure 3 – Data will increase over time


DATA LIFECYCLE FOR THE ORACLE E-BUSINESS SUITE When it comes to the data lifecycle the Oracle E-Business Suite is no different. Almost all aspects of the data lifecycle will be handled by the Oracle E-Business Suite. The creation of active data will usually occur as a result of data entry, typically these will be handled by your product workbenches or open interfaces. Any cross product dependencies/data sharing will be handled by the Oracle E-Business Suite.

As time progresses and data becomes less active and eventually it should get deleted; however, given the requirements of compliancy and financial reporting, this data may not be deleted immediately. The storage will be handled by the Oracle database. Customers have the option to archive data via the standard archive programs (where available) or via third-party vendors. Finally, purging will also be handled by standard purge programs (where available). Archiving and purging is described later in this paper.

Differing Data Types

Within the Oracle E-Business Suite data can be categorized into three different types:

- Transient – In general, data that will be held for a short amount of time; for example, login information or concurrent request information.

- Transactional – This is fiscal or non-fiscal data, typically related to entities within the Oracle E-Business Suite, such as invoices or employee HR information.

- Seed – Typically this would be lookup or reference data and in most cases would help to contextualize transient or transaction data with regards a particular state or type. Examples of seed data would be an approval code or status of a particular invoice, or the status of a concurrent request.

In most cases the transient and transactional data types will be the ones that will be the most active and follow the data lifecycle and will need to be monitored in terms of storage space usage.

DON’T BE MANAGED BY YOUR DATA Anyone responsible for managing an Oracle E-Business Suite implementation needs to understand what kind of data is being is being created, how is it being used, and how long it need to be retained. With this information, customers can develop a road-map/strategy to balance usage patterns/needs with the optimal storage and therefore minimize the total cost of data over its lifecycle. There may be some challenges in understanding the exact nature of data stored in an Oracle E-Business Suite implementation due to the differing business rules and inter- and cross-product dependencies. Without the ability to manage your Oracle E-Business Suite data effectively, relative to its use/need and storage requirements, runaway database growth will happen. As many customers can appreciate, if we don’t ask the tough questions like “why do I need this data”, then data will be unmanaged and in


most cases more and more disk space and CPU power will be added. This will inevitably result in increased operational costs and poor performance, and may potentially impact your ability to maintain your SLAs’ because of limited database ability.

The Solution

What is the solution? We are familiar with the concept that data and its usefulness are inversely proportional with time. We also know that as a consequence, that the number of times data is accessed reduces as time progresses. The only solution is for customers to periodically review their Oracle E-Business Suite data and consider a range of measures to reduce their data footprint. Customers could consider simply reducing storage costs by moving older data onto cheaper storage devices, but then they will also need to ensure that system performance remains optimal with exceptionally high data volumes.

Since we have already raised the question about how much data does an organization need to keep online, the next question is what options are available for customers of the Oracle E-Business Suite to better manage their data.

The Oracle supplied solutions fall into two categories, data growth control methods and data management methodologies.

Growth Control Methods

- Archive/Purge

- Database Compression

Data Management Methods

- Database Partitioning

- Information Lifecycle Management (ILM) Information Lifecycle Management (ILM) is a concept that has evolved over time and

is driven by the need to improve and organize data storage. ILM is a policy

based approach that is used to organize data as it progresses through it’s lifecycle:

from the time it gets created and stored until it is no longer needed. With Oracle’s

ILM offering it is possible for customers to adopt a tier based approach to the way

they organize the storage of their E-Business Suite deployment. By

contextualizing data into different time periods of retention.

Customers need to evaluate carefully which combination of these methods will suite their requirements, as several permutations are available. Here are some examples:

- Adopt a 100% pure archive and purge strategy where any important data is initially archived and then finally purged when it is no longer needed. The archived tables could be placed in a read-only schema and the datafiles could be resized to reduce their physical space. In addition, database compression feature could be used in conjunction with or as an alternative to resizing the datafiles.

- Customers could adopt a combination of an archive/purge and ILM strategy, where inactive data is put onto cheaper storage, then after a period of time, this data is archived and eventually purged. Alternatively, customers could choose not to use ILM but instead use database partitioning.


- Customers could fully implement ILM and. and place less frequently accessed data, that would ordinarily be archived and purged, onto cheaper and less expensive storage devices.

- Customers could use a 3rd Party archiving product with Oracle’s ILM product.

It makes sense to use the Oracle-supplied standard archive and purge programs (where available), even though there may be some reluctance to use them as once the data for example, is purged – it’s gone. For some, this may sound a little too permanent, given the fact that business users may want to infrequently access historic data. The traditional approach adopted by some implementations is to have a production database and a read-only historic database. But even with this approach customers are essentially putting off the inevitable. The solution is to address your business needs and find a solution that gives you the best of both worlds, which is unwanted data is purged and the data you need is archived and available online.

This paper describes the some of the standard archive and purge programs that are supplied as part of the Oracle E-Business Suite and also how an ILM policy based approach can be used to organize the storage of an Oracle E-Business Suite deployment.

ARCHIVING AND PURGING

For those who are new to this area, archiving can be defined as periodically saving your data with a reduced set of attributes, which in some cases could be fewer database columns. Purging is defined as deleting data that you no longer need, such as data that is older than any specified retention policy.

Figure 4 – Different factors influencing the decision to archive and purge

There are several factors that will influence your archiving and purging policies:


Archive:

• Are there any statutory requirements that you must conform to?

• Are there any business requirements that you need to consider?

• Is there a possibility that you will ever need to import the data once it has been archived?

Purging:

• Are you trying to stabilize the growth of your database?

• Are you purging to improve performance e.g. reduce the amount of data prior to an upgrade?

HOW LONG SHOULD I KEEP MY DATA FOR? The simplest of questions are the hardest to answer. Typically, most Oracle E-Business Suite customers do not need to access more than 20-30% of their data on a regular basis. This means that the largest amount of data can be classified as historical data. Failing to categorize the data will generally result in the purchase of more hardware. Not only does this increase the total cost of ownership (TCO), the increase in data volumes become more difficult to manage and may affect upgrades.

The aim of having a data retention policy and disposal schedule is as follows:

• Identify records that need preserving permanently.

• Retain records according to their purpose. For example, consider whether you need to keep invoices online, which were paid over 8 years ago.

• Ensure that records that are kept to comply with legislation.

• Prevent changes to, or the premature destruction of records, which need to be retained for a specified period to satisfy legal and/or financial requirements.

It is imperative that Oracle E-Business Suite customers have a data policy/strategy that considers the retention, archive and purge for each type of transaction. For customers that have a consolidated single Oracle E-Business Suite implementation for multiple countries, it is therefore important to develop a generic policy that meets the statutory requirements of all countries or, if this is not possible, develop specific policies for each country.

As data is frequently interdependent, it might be more suitable to define rules on a “per-product” basis, although you also have to consider product inter-dependencies to ensure that referential integrity is maintained. The majority of Oracle E-Business Suite customers keep all of their data online and only focus on archiving and purging their largest tables.


ORACLE E-BUSINESS SUITE ARCHIVING AND PURGING PROGRAMS It is very important to periodically review and control the growth of data in the Oracle E-Business Suite so that you can reduce your E-Business Suite data footprint. If you do not periodically remove data that is no longer required, inevitably more time and effort will be required to manage your data.

This section describes the use of the standard archive and purge programs

provided with the Oracle E-Business Suite. Most of the main entities within the Oracle E-Business Suite have their own standard

archive and purging programs. Within the Oracle E-Business Suite there are many purge and archive programs; please refer to Appendix A and B for examples. In this section we give example of some products that provide archive and purge functionality, currently available. The products covered include both administrative products as well as products related to your business flows.

Enforcing Cross-Product Dependencies

One of the advantage of using the Oracle-supplied archive and purge programs is that in most cases the cross-product dependencies and business rules should be enforced so that you don’t have orphan data. For example, won’t get a scenario where you have an invoice that was matched to a purchase order and the purchase order was purged. For the many products that are related by business flow it is important to correctly validate all the related data before purging. Typically, these cross-product dependencies are handled by the standard Oracle E-Business Suite archive/purge programs (where available).


Figure 5 – A product may have several cross-product dependencies

Purge Portal Introduced in Oracle E-Business Suite Release 11.5.10, the purge portal allows administrators to configure, deploy, and monitor archive/purge programs from a single console. Concurrent Purge programs can be configured, initiated, and monitored from this console as well. The portal also allows you to set the execution frequency as well view history of purge programs. A new concurrent program type called “purge” was created and programs of this type can be added to this list of programs shown in the console. This portal is further enhanced in Release 12.

To access the purge portal, use the following navigation:

System Administrator > Oracle Applications Manager >Purging/Critical Activities


Figure 6 – Accessing the Purge Portal

Figure 7 – Purge Portal Scheduled activities screen

For Additional Information: Please refer to Oracle® Applications System Administrators Maintenance Guide Release 11i: Chapter 6 Part No.: B13924-04


Oracle General Ledger (GL) Oracle General Ledger allows you to archive and purge account balances, as well as journal batches, entries, lines, and associated journal references. These steps can be done for one or more accounting periods, so long as the periods are permanently closed.

Most of the main entities within the Oracle E-Business Suite have their own standard

archive and purging programs.

You can archive and purge actual, budget, or encumbrance balances. In addition, for translated actual and budget balances, you can purge them before you re-run your translation. Except for translated balances, you must archive balances or journals prior to purging them.

You can also purge data related to the Mass Maintenance functionality, which allows you to move balances by period from one account to another or merge balances by period from multiple accounts into a single account. The moved/merged balances are added to the existing balances in your target accounts.

The Purge/Archive functionality is run using a series of concurrent requests.

Tables Archived and Purged: Base Table Archive Table GL_BALANCES GL_JE_BATCHES GL_JE_HEADERS GL_JE_LINES GL_IMPORT_REFERENCES

GL_ARCHIVE_BATCHES GL_ARCHIVE_BATCHES GL_ARCHIVE_HEADERS GL_ARCHIVE_LINES GL_ARCHIVE_REFERENCES

For Additional Information: Please refer to Oracle® General Ledger User Guide Release 11i: Chapter 8 Part No.: B12270-03

Oracle Payables/Oracle Purchasing (AP/PO) Oracle Payables (AP) provides integrated purging functionality, by purging entities in other products that are related to the Payables entity that is being purged. There is no archiving functionality in Oracle Payables.

The following entities are purged in AP by the standard purge program:

Invoices – PO Match, Purchase Orders, Requisitions, Inactive Suppliers, Schedules by CUM/Organization

Before any information is purged within Payables, a test is performed to check that the information is eligible to be purged. The following items list some examples of the criteria used by the purge process:

Invoice Purge Criteria

The purge program deletes invoice batches, their associated invoice distributions, related invoice validations, invoice validation history records, accounting entries, and payments. Invoices will only be purged if they meet the following criteria:


• Last Update Date of the invoice and its distributions and the Invoice Date are on or before the Last Activity Date

• The invoice is fully paid or is a zero–amount invoice

• The invoice has been transferred to General Ledger

Payment Purge Criteria

The purge program deletes both related payments and the accounting entries associated with those payments. Example of the criteria used to purge payments include payments that have been transferred to General Ledger.

Supplier Purge Criteria

If you are purging suppliers that have bank account assignments, only the link to the bank account is deleted, but the bank details are retained. Suppliers that meet the following criteria will be purged:

• A supplier is inactive, and the values of Inactive On and Last Update Date are on or before the Last Activity Date you specify

• A supplier is not a parent company or subsidiary of another supplier

• Supplier is not referenced by records in any operating unit in Oracle Payables, Oracle Purchasing, or Oracle Assets

Requisition Purge Criteria

Requisitions that meet the following criteria will be purged:

• Requisition is cancelled or finally closed

• All purchase orders referencing the requisition meet the Purchase Order Purge Criteria

Purchase Order Purge Criteria

The purge program deletes related purchase requisitions and receipts. Once you purge receiving transactions and their associated accounting information, you can no longer re-cost those accounting entries.

Documents can be purged such as purchase orders if

• The document has not been marked as finally closed at header level

• If the Last Activity Date of the document is before the Last Activity Date that you specify in the submit purge window.

Note that Oracle Purchasing automatically updates some of your purchase order information, even if you are not using the Purchase Order form. For example, when you receive items against a purchase order, Purchasing automatically updates your purchase order shipment to reflect the quantity received.


There is limited archiving and purging functionality in Purchasing., Keep in mind that purchase orders are automatically archived when they are approved for the first time and during the approval process if the revision number has been incremented since the order was last approved.

The purge process is initiated from the Submit Purge Window in Oracle Payables.

The main tables where data is purged from are as follows:

Entity Base Tables Purged Invoices – PO Match, Purchase Orders, Requisitions, Inactive Suppliers, Schedules by CUM/Organization

AP_CHRG_ALLOCATIONS AP_DOC_SEQUENCE_AUDIT AP_CHECKS AP_PAYMENT_HISTORY AP_INVOICE_PAYMENTS AP_PAYMENT_SCHEDULES AP_TRIAL_BALANCE AP_HOLDS AP_INV_APRVL_HIST AP_INVOICE_DISTRIBUTIONS AP_DOC_SEQUENCE_AUDIT AP_INVOICES AP_BATCHES AP_LIABILITY_BALANCE AP_AE_LINES AP_AE_HEADERS AP_ENCUMBRANCE_LINES AP_ACCOUNTING_EVENTS CHV_ITEM_ORDERS CHV_HORIZONTAL_SCHEDULES CHV_AUTHORIZATIONS DELETE_CHV_CUM_ADJUSTMENTS CHV_CUM_PERIODS CHV_SCHEDULE_ITEMS CHV_SCHEDULE_HEADERS CHV_ITEM_ORDERS CHV_HORIZONTAL_SCHEDULES CHV_AUTHORIZATIONS CHV_SCHEDULE_ITEMS CHV_SCHEDULE_HEADERS PO_VENDORS PO_VENDOR_SITES_ALL PO_VENDOR_CONTACTS AP_BANK_ACCOUNT_USES_ALL PO_VENDOR_LIST_ENTRIES PO_VENDOR_LIST_HEADERS PO_ASL_DOCUMENTS PO_ASL_ATTRIBUTES PO_APPROVED_SUPPLIER_LIST

For Additional Information: Please refer to Oracle® Payables User Guide Release 11i: Chapter: 10 Part No.: A81180-07

Oracle Receivables (AR) Oracle Receivables provides both archiving and purging functionality. Transactions can be put into a shadow archive table before they are purged. The functionality also provides the ability to archive at three different levels and gives you greater


control over which information is archived. The levels offered are (1)headers, (2)headers and lines, and (3)headers, lines, and distributions.

The actual process is split into four distinct phases: Selection and Validation, Archive, Purge, and an option to copy to a file. Within the first step, the selected transactions that are eligible for purging/archiving based upon the specified criteria are validated. This validation is done to identify the related transactions and store the information in the archive tables.

The main criteria used to select Receivables transactions for archiving and purging areas follows:

• GL Date Type – The actual value that will be used as the selection criteria. This is the end date of the period.

• Specify what date type to use for purging. The options are Invoice GL Date, Receipt GL Date, or All GL Dates.

• Archive Period - All transactions in this period or earlier periods will be purged, as long as the period is closed.

• Open Receivables Only.

• Postable Items Only.

• Customer Name.

The key tables that can be cleared using the AR archive and purge processes are: Base Table Archive Table AR_ACTION_NOTIFICATIONS* AR_ADJUSTMENTS* AR_BATCHES AR_CALL_ACTIONS* AR_CASH_BASIS_DISTRIBUTIONS* AR_CASH_RECEIPTS AR_CASH_RECEIPT_HISTORY AR_CORRESPONDENCE_PAY_SCHED* AR_CORRESPONDENCES* AR_CUSTOMER_CALL_TOPICS* AR_DISTRIBUTIONS AR_MISC_CASH_DISTRIBUTIONS AR_NOTES* AR_PAYMENT_SCHEDULES* AR_RATE_ADJUSTMENTS* AR_RECEIVABLE_APPLICATIONS RA_BATCHES RA_CUSTOMER_TRX RA_CUSTOMER_TRX_LINES RA_CUST_TRX_LINE_GL_DIST RA_CUST_TRX_LINE_SALESREPS* The tables marked with * are only purged; there is no option to archive these tables.

AR_ARCHIVE_HEADER AR_ARCHIVE_DETAIL AR_ARCHIVE_CONTROL AR_ARCHIVE_CONTROL_DETAIL AR_PURGE_TRX_AUX AR_PURGE_REC_AUX AR_ARCHIVE_PURGE_LOG AR_ARCHIVE_PURGE_INTERIM AR_PURGE_OE_EXCEPTIONS


For Additional Information: Please refer to Oracle® Receivables User Guide Release 11i: Chapter: 10 Part No.: A80838-06

Oracle Cash Management (CE) Oracle Cash Management allows the bank statements and interface tables to be both purged and archived.

Purging

The purge process deletes all statement header and line information from the open interface tables or the bank statement tables, or both - nothing is retained. When you purge a bank statement, any system transactions reconciled to the bank statement must also be purged.

Warning: If you use Oracle Cash Management to reconcile journal entries in Oracle General Ledger, you should run the Oracle Cash Management Purge Program before you purge journals in Oracle General Ledger.

Archiving

Within Cash Management, you cannot archive without also purging. The archiving process copies all bank header and statement line information. This information is copied from either the open interface tables or the bank statement tables into special archive tables the system maintains.

The ability to Purge and Archive the imported bank statements can be performed automatically by setting up the system Archive and Purge options. Bank statements can also be archived and purged by running the Archive/Purge Bank Statements concurrent program. When the program completes, a copy of the Archive/Purge Bank Statements Report is displayed showing the number of headers and lines that were archived or purged.

The following tables are purged in the Cash Management product: Base Table Archive Table CE_STATEMENT_HEADERS CE_STATEMENT_LINES CE_STATEMENT_RECONCILLIATIONS CE_STATEMENT_RECONCILLIATION_ERRORS CE_STATEMENT_LINES_INTERFACE CE_STATEMENT_HEADERS_INTERFACE

CE_ARCH_HEADERS CE_ARCH_LINES CE_ARCH_RECONCILIATIONS CE_ARCH_RECON_ERRORS CE_ARCH_INTERFACE_HEADERS CE_ARCH_INTERFACE_LINES CE_ARCH_INTRA_HEADERS CE_ARCH_INTRA_LINES

For Additional Information: Please refer to Oracle® Cash Management User Guide: Chapter 8 – Inquiry and Reporting, Part No.: A80839-06


Oracle Fixed Assets (FA) Within Oracle Assets, you can archive and purge transaction and depreciation data for the asset book and fiscal year you specify.

The purge program will remove depreciation expense and adjustment transaction records for the two main parameters of ‘BOOK’ and ‘YEAR’. It does not remove asset identification, financial, or assignment information. The process includes assets that have been retired or ones that have fully depreciated in value, for the fiscal year. Information from a fiscal year is purged in chronological order from the earliest year for the book to the most recent.

Oracle Assets does not allow you to purge until the archive process has been successfully completed. Information can be recovered following an archive and purge. An audit trail is maintained of the fiscal years that have been archived, purged, and restored, together with summary information of how many records were processed

The following tables are purged in the Fixed Asset product: Base Table Archive Table FA_ADJUSTMENTS FA_DEPRN_SUMMARY FA_DEPRN_DETAIL

FA_ARCHIVE_SUMMARY_<Archive_Number> FA_ARCHIVE_DETAIL_<Archive_Number> FA_ARCHIVE_ADJUSTMENT_<Archive_Number>

For Additional Information: Please refer to Oracle® Assets User Guide Release 11i: Chapters 3,5,11 Part No.: A81359-08

Oracle Cost Management (CST)

Oracle Cost Management allows you to purge cost types and all costs within the cost type. Alternatively, you can purge only part of the cost information such as, ‘make’ or ‘buy’ items, resource and outside processing costs, overhead rates and amounts, or resource and overhead associations. Note that frozen costs in standard costing or average costs in average costing cannot be purged.

Purging will permanently remove the selected cost type information from the database and these records are not retrievable.

To purge cost information, navigate to the Purge Cost Information window.

The following tables are purged in the cost management product: Base Tables Purged Archive Table CST_RESOURCE_COSTS CST_RESOURCE_OVERHEADS CST_DEPARTMENT_OVERHEADS CST_COST_TYPE_HISTORY CST_ITEM_COST_DETAILS CST_ITEM_COSTS

CST_COST_TYPES CST_COST_TYPE_HISTORY


For Additional Information: Please refer to Oracle® Cost Management User’s Guide Release 11i: Chapter: 3, Part No.: A75088-04

Order Management (ONT) Order Management contains Purge Selection and Order Purge programs. Collectively the Purge Orders concurrent programs allow the purging of selected closed orders and their workflow history. Users can establish a set of rules to determine precisely what gets purged and this is stored as a ‘Purge Set’. Modification to a purge set is possible before confirming the purge process.

A “Purge Set” can be created in the two following ways:

• Purge Set Creation using the Create Purge Set Concurrent Program - Order Purge Selection and then running order purge.

• Multi-selection of orders within the application are saved as a purged set.

The purge process works by using a purge set, which contains the orders based on criteria specified by the user. Once orders have been selected for purging within a purge set, users can choose to purge the entire set, a subset of the purge set, or to cancel the purge.

The results of what will be purged after applying the criteria is available and can be reviewed before the information is finally purged. Any data that matches the criteria but cannot be purged, is listed in the ‘Process Exception Report’.

Orders can only be purged if they meet the following conditions:

• Orders must be closed.

• No open demand exists for orders, open work orders, open invoices, open returns, and open requisitions.

The following two concurrent programs are used to initiate the purge process:

Order Purge Selection. This is used to create a purge set that defines which orders will be purged. It inserts candidate records into the OE_PURGE_ORDERS table.

Order Purge. This takes the purge set and deletes all order information that is in the purge set.

Typically, OE_ORDER_LINES_ALL is the table that will grow the fastest in this product. Most other tables grow at a rate similar to that of the OE_ORDER_HEADERS_ALL table.

The following Order Management tables are purged of selected order data, depending upon the input parameters and a successful submission of the Order Purge concurrent program:

Base Table


OE_HOLD_RELEASES OE_HOLD_SOURCES OE_LINE_SETS OE_LOT_SERIAL_NUMBERS OE_ORDER_HEADERS_ALL OE_ORDER_HOLDS OE_ORDER_LINES_ALL OE_PRICE_ADJ_ATTRIBS OE_PRICE_ADJ_ASSOCS OE_PRICE_ADJUSTMENTS OE_SETS OE_SALES_CREDITS

Oracle Application Object Library (FND) tables will be purged of any attachments for orders selected for purging by the Order Purge concurrent program. The concurrent program only purges data and there is no option to archive the data to a shadow table beforehand.

For Additional Information: Please refer to Oracle® Order Management User’s Guide: Chapter:5 – Order Management Processes – Order Purge Part No: A88765-06

Oracle Application Object Library (FND) and Workflow (WF) Oracle Applications Manager (OAM) provides additional functionality to schedule and submit purge programs.

Purge Concurrent Request/Manager Data Program

This program can be used to delete the following:

• Request log files – These include concurrent manager log files and report output files from your product directories.

• Records from Oracle Application Object Library database tables that contain historical information about concurrent requests and concurrent manager processes.

To run this program navigate to Concurrent -> Request -> Run. Query the Purge Concurrent Requests and/or Manager Data program.

The tables that are affected by running this program are as follows: Base Tables Purged Archive Table FND_CONCURRENT_REQUESTS

This table contains a complete history of all concurrent requests.

FND_RUN_REQUESTS

When a user submits a report set, this table stores information about the reports in the report set and the parameter values for each report.

FND_CONC_REQUEST_ARGUMENTS This table records arguments passed by the concurrent manager to each program it starts running.

FND_DUAL This table records when requests do not update database tables

FND_CONCURRENT_PROCESSES This table records information about


Oracle E-Business Suite and operating system processes

FND_CONC_STAT_LIST This table collects runtime performance statistics for concurrent requests.

FND_CONC_STAT_SUMMARY

This table contains the concurrent program performance statistics generated by the Purge Concurrent Request and/or Manager Data program. The Purge Concurrent Request and/or Manager Data program uses the data in FND_CONC_STAT_LIST to compute these statistics.

FND_CONC_PP_ACTIONS

This stores the post request processing actions (e.g. print, notify) for each submitted request. There is a CONCURRENT_REQUEST_ID for each REQUEST_ID in the FND_CONCURRENT_REQUESTS.

FND_RUN_REQ_PP_ACTIONS

This stores the post request processing actions (e.g., print, notify) for submitted request set programs that are stored in FND_RUN_REQUESTS

Purge Page Access Tracking Repository The amount of data recorded by the Page Access Tracking depends on which applications, responsibilities, and users, have tracking turned on, plus the tracking level selected and amount of user traffic. It is recommended that on a regular basis the Page Access Tracking repository is purged. The frequency of data purged also depends on how much historical tracking data is needed in the UI reports.

Please refer to OracleMetalink Note: 278881.1 - Page Access Tracking in Oracle Applications 11i, for further information.

Purging Workflow Data Several tables can grow to be quite large within the Oracle Workflow and Oracle XML Gateway products. These tables might contain obsolete workflow information that is stored for all completed workflow processes in addition to obsolete XML transactions. The size of these tables and indexes can affect the performance of several products for any transactions that reference them. The tables concerned are the WF_ITEM_ACTIVITY_STATUS and WF_ITEM_ATTRIBUTE_VALUES.

It is recommended that these tables should be frequently purged using the Purge Obsolete Workflow Runtime Data concurrent program (FNDWFPR). It is possible to enter restrictions to specify the data that you want to purge. This program purges obsolete runtime information associated with work items, including status information and any associated notifications and Oracle XML Gateway transactions. It also purges obsolete information such as activities that are no longer in use, expired users and roles, notifications, and Oracle XML Gateway transactions that were not handled through a workflow process.


There are several useful OracleMetalink notes available on the purging of workflow data:

- 277124.1 - FAQ on Purging Oracle Workflow Data

- 337923.1 - A closer examination of the Concurrent Program Purge

- 264191.1- Quick Reference: How To Purge Obsolete Workflow Runtime

- 315972.1 - Workflow Purge Does Not Remove Records From WF_ITEM_ACTIVITY

For Additional Information: Please refer to Oracle® Applications System Administrator’s Guide: Chapter 2 (Concurrent Manager Purge), Chapter 3 (Workflow Purge).


INFORMATION LIFECYCLE MANAGEMENT (ILM) ILM is a term that has been applied by many technology companies to refer to the methods to better organize data. Currently most Oracle E-Business Suite implementations follow the one-size fits all approach concerning how data is stored. No distinction is made about the importance of the data, the number of times it is accessed, or the storage medium. ILM manages the entire data lifecycle and is a complete methodology that incorporates both procedures and software, in addition to purging and archiving. In other words, it provides a framework that helps manage and control the flow of data from the time of inception until it is no longer needed.

ILM comes in many flavors. In general, it focuses on storing your data according to its value. When used with the Oracle E-Business Suite, ILM is usually time-centric and concerned with segregating your data based on data retention requirements; for example, current data is kept on the fastest storage devices and older data is kept on slower cheaper storage devices.

The Oracle ILM framework makes use of tools and database features such as partitioning and table compression. The Oracle ILM Assistant provides a complete view of your physical storage, classified by your data storage policies/data retention requirements from a single console.

For further information about ILM please visit the following link: http://www.oracle.com/technology/deploy/ilm/index.html

ILM for the Oracle E-Business Suite Implementing ILM for the Oracle E-Business Suite can be done in four simple steps. You need to understand the nature of your data in order to have a successful ILM strategy and to get the most out of the product. ILM utilizes the partitioning functionality in the Oracle database. Partitioning is completely transparent to the Oracle E-Business Suite code.

Implementing an ILM strategy can be completed in four steps. Before attempting

to classify data, you first need to understand the exact nature of your data.

Step 1 – Define Your Data Classes In the first step, you would need to examine all the data that is stored in your E-Business Suite instance, in terms of size and data retention requirements. It is unrealistic to apply ILM to every table in the Oracle E-Business Suite, but it is certainly recommended for the larger tables and/or key entities.

After understanding the nature of your data, classify your data into different

classes.

The most typical form of classification for data in the Oracle E-Business Suite will be date-related, though it might include other product-specific statuses of a document for example an invoice in an approved state.

One of the key points for deploying ILM is reducing the total cost of ownership (TCO) for storage; you need to handle different data classes of data by separating them onto physically different storage devices.


User Defined Data Classes

When applying the concept of ILM to an Oracle E-Business Suite implementation, data should be classified in terms of current transactional and date suitable for archiving. Should you wish to have a more elaborate classification scheme in terms of compliance, mission critical, archive and purged data, this is also possible.

Reference data, such as lookup codes, should never be archived or purged as this information is required to maintain referential integrity and might be referenced by your current data may be using these lookup codes. These tables tend to be fairly static and not large enough to warrant consideration.

Where ILM for the Oracle E-Business Suite differs from conventional ILM offerings is that data within the Oracle E-Business Suite is related to data, not only within a single product, but also across products. For example, an invoice in Oracle Payables that has been matched to a purchase order in Oracle Purchasing will have this relationship reflected in the Oracle Payables tables. Archiving either of these entities without checking their inter-relationships could destroy the referential integrity and compromise your data. In addition, data can also be related to the same business flow such as Order-to-Cash or Procure-to-Pay.

The ILM approach can only be achieved by partitioning and it therefore follows that your data must be able to be partitioned in some way. Typically, transaction data can easily be partitioned either using some kind of date field or ID range. For example, you could partition the table AP_INVOICES_ALL using range partitioning based on the INVOICE_ID column. As this column is based on a rolling sequence, recent invoices will have a higher INVOICE_ID.

Step 2 – Create Storage Tiers for Data Classes The next step of this process is to categorize your existing storage devices in terms of high performance, low cost, and online archive. Typically, the high performance storage tier is where all the most recent and frequently-accessed data should reside. Common sense dictates that the low cost storage tier should be used to store less frequently accessed (usually historic) data. This tier would be built using large capacity disks, such as those found in modular storage arrays. The online archive storage tier will hold the oldest data and reside on your slower but higher capacity devices.

Once data classes have been defined, the existing storage devices need to be

evaluated and classified by their relative performance.

Once the storage tiers have been defined, the next step in the process is to assign each of the data classes (partitions) identified in Step 1 to an appropriate storage tier. ILM physically distributes data across the appropriate storage devices based on the class of data and policies that you defined. As the partitioning is completely transparent to users accessing the data, no code changes are required and therefore it can be implemented during any maintenance period at minimal cost.

In summary, the purpose of this step is to classify data based on data type and then depending on your classifications, align those classifications with the appropriate class of storage for your business needs.


Step 3 – Create Data Migration Policies As data moves through the data lifecycle, it will be promoted to the next storage class/tier; there may also be other reasons to migrate data between classes to take advantage of the different storage tiers. For example, as the data has already been partitioned, the partition containing the orders more than 12 months old can be moved from the high performance storage tier to the low cost online storage tier.

As data moves through the data lifecycle, it is promoted to the next storage tier. A

Data migration policy will need to be defined to decide when data needs to be

moved between tiers.

As the data is being moved within the database, it can be physically moved, without causing any disruption to regular Oracle E-Business Suite users. In Oracle 10g R2, the partition can be moved online. Depending on the policies that you defined, sometimes individual records may be moved rather than more generic sets of data.

After creating the physical storage tiers, you can assign data partitions to appropriate storage tiers and then segment compression, can be used on historical partitions, which are not frequently accessed.

Step 4 – Define and Enforce Compliance Policies The fourth step in defining the ILM environment is the creation of compliance policies and this is a new area of consideration for the Oracle E-Business Suite. The new regulatory requirements such as the Sarbanes-Oxley Act, HIPAA, DOD5015.2-STD in the US and the European Data Privacy Directive in the European Union impose strict rules on how data is held and how organizations have to protect against unauthorized changes.

If data storage is decentralized and fragmented, compliance policies have to be enforced at every data location and this would be difficult to manage. Storing data in a central location reduces the enforcement overhead as they can be managed and enforced from one central location. The area of compliance is beyond the scope of this document, but you can find further information regarding retention, auditing, and data privacy laws at http://www.oracle.com/technology.

THE ILM ASSISTANT The ILM assistant has a single interface

that can be used to manage your ILM environment.

The Oracle ILM Assistant provides a single graphical interface for managing your ILM environment and lifecycle. This tool allows the user to create a lifecycle which is then assigned to a set of database tables. It also allows the user to create various different policies that are then applied to the different tables in the database. The ILM assistant also advises when it is time to move, archive, or delete data. Given that there will be an associated cost for storing data, the ILM assistant can show the cost savings of moving data from one storage tier to another. The ILM Assistant uses the partitioning feature of the Oracle database and currently on works using range partitioning. Interval and reference partitioning (introduced in Oracle Database 11g) are also particularly suited for use in an ILM environment.

ILM can be implemented using the ILM assistant by performing the following steps:


1. Define Logical Storage Tiers

2. Define the Data Lifecycle

3. Assign a table to a Lifecycle

The following examples demonstrate a subset of features of the ILM assistant.

Step: 1 - Create Storage Tiers for the Data Classes Define as many logical tiers as you need to address your requirements. You will have to associate a tablespace with a logical tier as part of the logical storage tier definition process.

Figure 8 – Defining Storage Tiers for Data Classes

The following screen shows and example of a completed set of defined storage tiers.


Figure 9 – Example of completed set of storage tiers

Step: 2 - Define a Date Lifecycle When a lifecycle is defined, the start date of the lifecycle has to be defined along with the current stage of the lifecycle.

Figure 10 – Defining a lifecycle

Each stage of the data lifecycle should be defined including the final stage.


Figure 11 – Creating a stage for a lifecycle

This screen shows an example of a lifecycle with all its stages defined.

Figure 12 – Completed lifecycle with all stages defined

This summary screen shows all the lifecycles defined.


Figure 13 – Summary screen of defined lifecycle

Step: 3 - Assigning a table to a Lifecycle

Once you have defined your lifecycle, the ILM assistant will show you all the tables that can be associated to the lifecycle.

Figure 14 – Summary screen of all available tables that can be managed by the ILM assistant

The ILM assistant provides useful information about the tables that are candidates for partitioning as well as the ability to run a simulation, which shows the costs involved in partitioning the table.


Figure 15 – Partitioning simulation for a chosen table

Once you click the simulation button, you are presented with a breakdown of the partition details for the table as well as the associated costs for storing the table with, and without ILM.

Figure 16 – Summary screen showing cost-breakdown of storing a table with and without ILM

The storage cost details of a particular table is broken down further based upon which type of storage tier will host the data.


Figure 17 – Summary screen showing cost-breakdown of storing a table with and without

ILM

The ILM assistant contains functionality to alert the user if there are any events/action items pending in any of the lifecycles.

Figure 18 – Events functionality in the ILM assistant

In this example, two events have been listed.


Figure 19 – Example of displaying scheduled events in the ILM assistant

The ILM Assistant requires a minimum of Oracle Database 9i and that Oracle Application Express, formerly known as HTML Db, is installed into the database. The ILM Assistant is available for download from the Oracle ILM page on OTN.

Summary

Oracle ILM when used with the Oracle E-Business Suite is a tool that allows the management of data as it goes through its lifecycle. It consists of the following components that work together to control data growth and maximize the performance of SQL within an Oracle E-Business Suite instance:

• Partitioning and Table Compression

• Oracle E-Business Suite Archive Programs

• Oracle E-Business Suite Purge Programs


http://www.oracle.com/technology/deploy/ilm/index.html

ILM is the synergy of archiving, purging, and partitioning working collectively and it will help improve manageability and performance across the whole spectrum of your applications. Adopting ILM for the Oracle E-Business Suite will encourage you to associate date classes with a lifecycle and optimize your storage costs, and thereby reduce your total cost of ownership.

Using ILM with the Oracle E-Business Suite will allow the management of data

throughout its lifecycle. Archive and purge will help reduce the data volumes but

ensure that you check your data retention requirements.


WHERE TO START? The main challenge as an administrator or DBA responsible for maintaining an E-Business deployment is where do you start? Which archive and purge programs should you run? Most of you will be familiar with the concepts of archiving and purging and its goal to control data growth. By now you will also be familiar with the concept of having a lifecycle method to manage your data. But the next question is, what steps are needed to follow to determine which objects to archive and to purge? And then what steps are needed to perform these actions? The following are steps to take and things to consider:

- Get an idea of the data volumes involved and what are your largest business objects.

- Consider the forecasted growth of these objects.

- Assess the current impact on performance, availability and cost of storing data.

- Define purge/archive rules – What criteria, e.g. business rules, are you going to use, and do you need to consider cross-product dependencies.

- Identify which solution you are going to use; .e.g., standard Oracle E-Business Suite archive/purge programs, third-party vendor, or a customer solution

o If using any of the above, define your archive/purge selection criteria (parameters). If using the standard Oracle E-Business Suite programs, identify which ones you are going to use and the parameters that need to be supplied to them.

Define the validation process and prerequisites for archiving/purging; if using standard Oracle E-Business Suite programs, this step should already be done.

o “What is your purging and archiving architecture? If you will use a custom solution, such using database partitioning to hold the archived data, then how will you delete data? It may be advisable to use the standard Oracle APIs. Also for a custom solution, you will need to consider your reporting requirements.

- Define roles and responsibilities, to specify who does what task. This step includes business users, DBAs and technical resources.

- If you need an audit trail, what are your requirements for it?

o Create structure for archive media tables – for standard Oracle E-Business Suite supplied programs, these will already have been defined.

- What are your reporting requirements? Are there any standard reports available?


One obvious approach would be to start with the largest tables in terms of storage space usage and identify the module that owns the object. Next verify if there is available archiving or purging functionality.

We are all fully aware of the fact that when we purge our data, once it’s gone, it’s really gone. To avoid this scenario, consider archiving. Would it better to archive the data first and hold it with a reduce set of attributes? There are a number of different ways you can archive, such as

- Hold data with a reduced set of attributes.

- Partition old data onto slower disks and compress the data.

- Use a third-party archiving product.

It is therefore important to consider the implications of archiving and/or purging from a functional, technical, and architectural perspective.

Functional/End User Requirements

Functional users should be able to confirm from a business perspective what you can archive or purge; typically they should be able to assist technical resources in

- Identifying the business objects, e.g. sales order, payment, contract, or inventory item that a table holds

- Reviewing needs of the business and the impact on business and end user requirements if an entity is archived or purged

- Forecasting growth - Estimate the growth of the data volume for the business object

- Defining purging criteria (business rules + database integrity)

- Defining purging selection criteria (list of parameters)

- Defining the validation process and prerequisites for purging

- Analyzing cross-product dependencies. How are they handled?

- Checking if the product has archive/purge programs

- What are the business reporting requirements of archived data?

- How can their users access data that has been archived?

o Which reports are run and which screens are accessed for historical data

o Data retention requirements

o Define creation and destruction schedules

- How should the archiving process take into account the differing requirements such as those for governmental compliance?


Before performing any purging, it is well worth investing the time and resources in understanding how any purging or archiving process works, which tables are affected, and what criteria can be given to any of the programs. It is also important to test any purge process before running it on your production instance.

Technical Considerations

Technical resources such as DBAs or solution architects should be able to consider the needs and implications of archiving and purging from a technical/architectural perspective. Typically they should be able to assist the operations/IT organization with:

- Assessing the impact of archiving and purging on performance and system availability

- Considering the tables that need to be examined as potential candidates for archiving or purging

- Helping evaluate the cost of storing data

- Considering database structure/size – What is impact on architecture by actions such as resizing the database files or using table compression?

- Recovery – How and to where will the archived data be recovered ?

- Availability of Archive or Purge features – Which modules have archive/purge features?

- Data access methods and security – Who will have access to the archived information; who purges data?

- Operational: What data can I remove?

For the long term, it is recommended to have a company-wide archive and purge policy. It is also critical that your business, technical, and operations people work together to assess how much of you data you need and what kind of purging or archiving functionality is available with the Oracle E-Business Suite or through a third-party vendor; and it is critical that they build a cohesive archiving and purging architecture for your E-Business deployment.

There are a number of places that you can look for additional information, including the user guide of the module that owns the data you wish to purge, and OracleMetaLink.


CONCLUSION For any organization, data is one of its primary assets. Data within an organization can take several forms, for example, data from ERP systems. For those responsible for maintaining the deployment of an organization’s ERP system, it can be quite challenging to balance cost and complexity. There are also decisions that need to be made around storage, architecture, design, and performance. New business applications, centralized business processes, and the need to meet regulatory requirements will only increase the need for more storage.

Understanding the data needs of an organization is imperative. Part of this process requires understanding the nature of the data being stored and how it has evolved and grown. In addition to this, careful consideration needs to be given to how to monitor usage and changes of data over time. Standards need to be adopted to decide how data long should be kept, while still adhering to all the rules and regulations that now apply to that data. If the data is left unattended, customers may experience runaway database growth. Adopting some kind of ILM strategy is beneficial. By using Oracle ILM customers can create a well-organized and compliant Oracle E-Business suite deployment. At the center of any ILM strategy will be the components that help in the management of data as it moves through its lifecycle. These components include:

- Oracle Database features - Oracle ILM Assistant, database partitioning, table compression

- Oracle E-Business Suite features - Standard archive or purge programs that come with the Oracle E-Business Suite

Customers can also use any appropriate certified third-party solutions that allow for archiving and purging within the Oracle E-Business Suite.

Given that the cost of storage may be decreasing, it is very easy to fall into the trap of just adding more discs to help solve storage requirements. The challenge then comes when you have to upgrade your 13TB Oracle E-Business Suite database to the next release, which contains 8 years worth of data, and your business users only allow you a 48-hour window to perform the upgrade. The strategies discussed in this paper can help you overcome this challenge.


REFERENCES [1] Ahmed Alomari and Mohsin Sameen Oracle OpenWorld (2006):

Partitioning and Purging Best Practices for Oracle E-Business Suite Available from: http://blogs.oracle.com/schan/2006/11/17

[2] OracleMetaLink: 554539.1 Database Partitioning for Oracle E-Business Suite Also available from Steven Chan's blog

[3] Lilian Hoobs: Information Lifecycle Management for Business Data. October 2006

[4] Oracle Corporation: Oracle® General Ledger User Guide Release 11i Chapter 8 Part No.: B12270-03

[5] Oracle Corporation: Oracle® Payables User Guide Release 11i Chapter: 10 Part No.: A81180-07

[6] Oracle Corporation: Oracle® Receivables User Guide Release 11i Chapter: 10 Part No.: A80838-06

[7] Oracle Corporation: Oracle® Cash Management User Guide Chapter 8 – Inquiry and Reporting Part No.: A80839-06

[8] Oracle Corporation: Oracle® Assets User Guide Release 11i Chapters 3,5,11 Part No.: A81359-08

[9] Oracle Corporation: Oracle® Cost Management User’s Guide Release 11i Chapter: 3 Part No.: A75088-04

[10] Oracle Corporation: Oracle® Order Management User’s Guide Release 11i Chapter: 5 Part No.: A88765-06

[11] Oracle Corporation: Oracle® Applications System Administrator’s Guide Release 11i Chapter 2 /Chapter 3 Part No.: B13924-04

[12] OracleMetaLink 138264.1 General Ledger Archive and Purge - Frequently Asked Questions

[13] OracleMetaLink 144431.1 Oracle Assets Archive, Purge and Restore Processes


http://blogs.oracle.com/schan/2006/11/17

[14] OracleMetaLink 136919.1 General Ledger Archive/Purge Setup and Usage

[15] OracleMetaLink 278881.1 Page Access Tracking in Oracle E-Business Suite 11i

[16] OracleMetaLink 277124.1 FAQ on Purging Oracle Workflow Data

[17] OracleMetaLink 337923.1 A closer examination of the Concurrent Program Purge

[18] OracleMetaLink 264191.1 Quick Reference: How To Purge Obsolete Workflow Runtime

[19] OracleMetaLink 315972.1 Workflow Purge Does Not Remove Records From WF_ITEM_ACTIVITY

[20] OracleMetaLink 453137.1 Oracle Workflow Best Practices Release 12 and Release 11i

REVISIONS This white paper was first issued in November 2008.


APPENDIX A: EXAMPLE ARCHIVE & PURGE PROGRAMS (ORACLE E-BUSINESS SUITE REL 11.5.10)

The following are examples of some of the Archive and Purge programs available in Oracle E-Business Suite Release 11i. Not all of the programs listed may be available for customers to be run standalone. Please refer to the product user documentation for specific instructions regarding availability and usage for each program.

Product Shortname Description

Application Object Library Purge Requests and/or Managers Purges Concurrent requests and/or Concurrent Manager data and log/output files

Application Object Library Purge signon audit data Purges all Signon Audit information(FND_LOGINS, FND_LOGIN_RESPONSIBILITIES, FND_LOGIN_RESP_FORMS ) created before a given date

Application Object Library FNDCPCRS Use this program to summarize and purge the request run statistics (use profile option - Concurrent: Collect Statistics - to enable statistics collection)

Application Object Library FNDGFMPR Purge Obsolete Generic File Manager Data Application Object Library FNDLGPRG Purge FND_LOG_MESSAGES debug log table, by date. Application Object Library aflobbld Purge orphaned help documents and rebuild the interMedia search

Application Object Library FNDWFPR Purge Obsolete Workflow Runtime Data Oracle General Ledger GLPURGE Archive and Purge Program Oracle General Ledger GLPURGEC Archive and Purge Child Program Oracle General Ledger GLCPCA Purge Consolidation Audit Oracle Assets FAS826 Mass Additions Purge Report Oracle Assets FARXPRG Purge RX Interface Data Oracle Assets FAPURG Purge accounting tables

Oracle Service CSKBPESA Program to purge temporary data and objects from Knowledge Management

Oracle Payables APXPGLIS Purge Report Listings Oracle Payables APXIIPRG Payables Open Interface Purge Oracle Payables APXP7SUM AP/PO Purge Summarization Routine Oracle Payables APXP7ABT AP/PO Purge Abort Routine Oracle Payables APXP7CFM AP/PO Purge Confirmation Routine Oracle Payables APXP7SEL AP/PO Purge Initiation (Selection) Routine Oracle Payables APXP7DEL AP/PO Purge Deletion Routine Oracle Purchasing POXPOIPR Purge Purchasing Open Interface Processed Data Program Oracle Purchasing POXCDXPG Catalog Data Purge Oracle Purchasing POXSSPG Purge System Saved Requisition Oracle Receivables Auto Invoice Purge Program Purge processed transactions in the Auto Invoice Interface tables Oracle Capacity CYRRCP Purge processed transactions in the Auto Invoice Interface tables Oracle Receivables ARARCALL Call New Archive and Purge Oracle Receivables ARPURGE New Archive and Purge Oracle Receivables ARARCONT Archive and Purge Oracle Receivables ARARCPUR Purge Module Oracle Receivables ARARCONT Purge Oracle Property Manager PNVPURGE Purge Location and Space Allocation Interface Tables Oracle Cash Management CEPURGE Program - Archive/Purge Oracle Order Entry Order Purge Selection Order Purge Selection Oracle Order Entry Order Purge Order Purge Oracle Warehouse Management System PURGE_WMS Purge WMS History Tables Oracle Inventory INCAAP Purge ABC information Oracle Inventory INCTPG Purge transaction history Oracle Inventory INVCORPP Copy Inventory Organization Report Data Purge Oracle Inventory INVISCORP Copy Inventory Organization Interface Data Purge Oracle Inventory INVGIPPG Inventory positions purge all Oracle Inventory INVGIPPG Inventory positions purge by data set, user, creation date Oracle Inventory MTL_CCEOI_PURGE Purge cycle count entries open interface in batch mode Oracle Inventory INCTPG Transaction Purge Oracle Inventory INCRPG Purge replenishment counts



Oracle Inventory Physical Inventory Purge Purge physical inventory information Oracle Inventory INCACP Purge cycle count information Oracle General Ledger Upgrade Encumbrance balances Purge transaction history Operations Intelligence OPI_PMI_INV_DAILY_SUM_PURGE Purge OPM Inventory Daily Summary Table Supply Chain Intelligence ISC_EDW_BACKLOGS_F_PURGE Purges the Backlog Fact given a date range or a period from today. TeleSales AST_IMPORT_PURGE Sales Leads Purge Record from import interface table Oracle Field Sales ASFFRVH Periodically Purge ASF_RECORD_VIEW_HISTORY Oracle Field Sales ASFDLST Purge Deleted Lists Oracle Marketing AMSPILTC Purge Imported List Oracle Marketing AMSPTGPC Purge Target Group Oracle Provisioning XDP_PURGE Program to purge obsolete application data Oracle Process Manufacturing Systems SYPRGENG OPM Purge and Archive Process Oracle Process Manufacturing Inventory GMIPEBAL OPM Purge empty balance Global Accounting Engine AXXPGSLE Sub ledger Archive and Purge by fiscal year accounting period Global Accounting Engine AXXPGLIS Purge Audit Report Oracle Order Management ORDPUR Order Purge Oracle Order Management GENPSETWHERE Order Purge Selection Oracle Order Management GENPSET Create Purge Set Oracle Order Management OEXCEPRG Purge Imported Credit Exposure program Oracle Order Management OEMPRG Purge of OM Processing Messages Oracle Pricing QPXDLDBB Purge Pricing Engine Requests Oracle Release Management RLMPSRP Release Management Purge Schedule Exception Report Oracle Release Management RLMPS Purge Schedule Sales Intelligence BIL_PURGE_TERR_INTF Purge Territory Assignments Interface Tables Call Center Intelligence BIXPURIN Purge Interactions tables Oracle eMail Center IEMADMWP Purge eMail Center Workflow Oracle eMail Center IEMMDTWP Purge eMail Center Standalone Workflow Oracle CRM Gateway for Mobile Services ASG_PURGE_LOG Concurrent program to purge snapshot logs Oracle Alert ALDTCA Purge Standard Cost History Oracle Bills of Material CSTCSPCT Purge Cost Information Oracle Receivables RAXTRX Purge Cost Information Oracle Bills of Material CSTCSPCH Purge Standard Cost History Oracle Bills of Material LIFO Purge Selective LIFO Purge Layers Oracle Bills of Material CSTCMDEL Purge Margin Analysis Run Oracle Bills of Material CSTCSPCU Purge Standard Cost Update History Oracle Bills of Material CSTISPCH Purge Standard Cost History from SRS Oracle Bills of Material BOMCPCFG Purge Configuration Items Oracle Engineering ENCECP Engineering Change Order Purge Program Application Object Library FNDSCETS Purge Designator Oracle Master Scheduling/MRP MRCPRG Purge Designator Oracle Receivables ARGCGP Purge Designator Applications DBA ADXBBBMS Purge Capacity Bill of Resources Oracle Receivables ARXPAR Purge Capacity Bill of Resources Oracle Capacity CRPPSPSS Purge Simulation Sets Oracle Capacity CRPPSPRS Purge Capacity Bill of Resources Oracle Work in Process WIPPURGE WIP Purge Oracle Configurator CZPURGE Purge Configurator Tables Oracle Release Management Integration RLAPURGE Purge Demand Interface Data Oracle Flow Manufacturing FLMCPPG Concurrent Program for Flow Schedule Purge Oracle Flow Manufacturing FLMRFPKB Purge Kanban Pull Sequences Oracle Demand Planning MSDPFCT Purge Fact Data Oracle Demand Planning MSDPUR DP Purge Program Oracle Advanced Supply Chain Planning MSCPRG Purge Designator Oracle Advanced Supply Chain Planning MSCPDCP Planning Data Collection - Purge Staging Tables Oracle Advanced Supply Chain Planning MSCDELDC Purge ODS Data of Collections Oracle Advanced Supply Chain Planning MSCPLID Purge Local ID Tables and Complete Refresh for Legacy Instances Oracle Human Resources PAYLINK Validate,Transfer or Purge BEE batches Oracle Human Resources PAYLINK Purges all records related to a BEE batch



Oracle Payroll PYUGEN Purge Preparation Phase Oracle Payroll PYUGEN Purge Deletion Phase Oracle International Public Sector Finance IGIGIAPR INT:Generic Interface: Archive/Purge/Restore Oracle International Public Sector Finance IGIRDPTD Dunning Letters: Purge Temporary Data Oracle Public Sector Budgeting PSBBRPUR Purge Budget Revisions Oracle Public Sector Budgeting PSBWCPUR Purge Worksheet Oracle Public Sector Budgeting PSBBRPUR Purge Budget Revisions Oracle Public Sector Budgeting PSBSTPDE Purge Data Extract Oracle Student Systems IGSPSJ06 Purge Scheduling Interface Data Oracle Student Systems IGSDAS01 Degree Audit Purge Requests Report CRL Financials Assets FACXTRES Purge Mass External Retirements CRL Financials Assets FACTPURG Purge Mass External Transfers CRL Financials Assets FACHRPRG Purge asset hierarchy batches marked as discarded


APPENDIX B: EXAMPLES ARCHIVE PURGE PROGRAMS (ORACLE E-BUSINESS SUITE RELEASE 12)

The following are examples of some of the Archive and Purge programs available in Oracle E-Business Suite Release 12. Not all of the programs listed may be available for customers to be run standalone. Please refer to the product user documentation for specific instructions regarding availability and usage for each program.


Advanced Benefits BENPDCPG Purge Plan Design Copy Process

Advanced Pricing QPXARCVB Archive Entity

Advanced Pricing QPXDLDBB Purge Pricing Engine Requests

Advanced Pricing QPXPURGB Purge Pricing Entity

Advanced Supply Chain Planning MSCATPPURG Concurrent program purges temporary data generated for each ATP

Advanced Supply Chain Planning MSCCONF Create Component Architecture Flexfields

Advanced Supply Chain Planning MSCDELDC Purge ODS Data of Collections

Advanced Supply Chain Planning MSCPDCP Planning Data Collection - Purge Staging Tables

Advanced Supply Chain Planning MSCPLID Purge Local ID Tables and Complete Refresh for Legacy Instances

Advanced Supply Chain Planning MSCPRG Purge Designator

Advanced Supply Chain Planning MSCXPHS This program purges records from the Collaborative

Application Object Library FNDCPCLN Purge Concurrent Processing setup data for cloning

Application Object Library FNDCPCRS Use this program to summarize and purge the request run statistics

Application Object Library FNDECXPR Purge Obsolete ECX Data

Application Object Library FNDGFMPR Purge Obsolete Generic File Manager Data

Application Object Library FNDLGPRG Purges Logs for expired Transactions and Closed System Alerts data

Application Object Library FNDPGHST Purge FND_STATS History Records

Application Object Library FNDSCETS Purge Designator

Application Object Library FNDWFPR Purge Obsolete Workflow Runtime Data

Application Object Library FNDWFPRVPR Purge Workflow Provisioning Requests

Application Object Library OAMSOAPPUREXE Purge Web Service Audit Data

Application Object Library OAM_BE_PURGE Purges old diagnostic and logged messages related information

Application Object Library Purge Debug Rule Executions Purges the debug rule executions and deletes the corresponding log/out

Application Object Library Purge Requests and/or Managers Purges Concurrent requests and/or Concurrent Manager data and log/output

Application Object Library Purge signon audit data Purges all Signon Audit information ( FND_LOGINS, FND_LOGIN_RESPONSIBITIES

Application Object Library WFPURGE Purge Workflow Transaction Table

Application Object Library aflobbld Purge orphaned help documents and rebuild the interMedia search index

Applications BIS BIS_RSG_PURGE_HISTORY_TABLE Purge Request Set Generator History Tables

Applications DBA ADXBBBMS Purge Capacity Bill of Resources

Assets FAPURG Purge accounting tables

Assets FARXPRG Purge RX Interface Data

Assets FAS826 Mass Additions Purge Report

Bills of Material BOMCPCFG Purge Configuration Items

Bills of Material CSTCMDEL Purge Margin Analysis Run

Bills of Material CSTCSPCT Purge Cost Information

Bills of Material CSTCSPCU Purge Standard Cost Update History

Bills of Material CSTISPCH Purge Standard Cost History from SRS

Bills of Material CTOPURGE Purge Configuration Items



Bills of Material LIFO Purge Selective LIFO Purge Layers

Capacity CRPPSPRS Purge Capacity Bill of Resources

Capacity CRPPSPSS Purge Simulation Sets

Capacity CYRRCP Purge processed transactions in the AutoInvoice Interface tables

Capital Resource Logistics - Assets FACHRPRG Purge asset hierarchy batches marked as discarded

Capital Resource Logistics - Assets FACTPURG Purge Mass External Transfers

Capital Resource Logistics - Assets FACXTRES Purge Mass External Retirements

Cash Management CEFPURGE Purge Cash Forecasts

Cash Management CEPURGE Program - Archive/Purge

Configurator CZIPURGE Purge All Import Tables Completely

Configurator CZIPURGETD Purge All Import Tables Records Older Than The Number Of Days

Configurator CZIPURGETRI Purge All Import Tables Records Less Than Or Equal To The RunID

Configurator CZPURGE Purge Configurator Tables

Contract Commitment IGCBAPRB Commitment Budgetary Control Archive / Purge Program

Contract Commitment IGCBAPRR Commitment Budgetary Control Archive Purge Report

Contract Commitment IGCCAPRB Contract Commitment Archive / Purge Program

Contract Commitment IGCCAPRR Contract Commitment Archive Purge Report

Contracts Core OKCPURARTINF Concurrent Program to purge clause open interface table

Contracts Core OKCQAPUR Purge old Contracts QA error messages

CRM Foundation CACTKCHPUR Child Concurrent Task Purge Program

CRM Foundation CACTKPUR Standalone Task Purge Program

CRM Foundation JTF_FM_PURGE_REQUESTS JTO: Purge Fulfillment Requests

CRM Foundation JTF_FM_PURGE_REQ_WKR JTO: Purge Fulfillment Request (Worker)

CRM Foundation JTF_IH_PURGE Interaction History Data Purge

Demand Planning MSDARCHIVE Archive demand plan

Demand Planning MSDPFCT Purge Fact Data

Demand Planning MSDPUR Purge Interface Tables

Depot Repair CSDEMSGS Depot repair generic messages purge

E-Business Tax ZXSIMPUR Tax Simulator Purge Program

Email Center IEMADMWP Purge Email Center Workflow

Email Center IEMMDTAP Process the archive/purge requests in Email Center

Email Center IEMMDTWP Purge Email Center Workflow

Email Center IEMNGNWP Purge Next Gen Email Center Workflow

Engineering ENCECP Engineering Change Order Purge Program

Enterprise Asset Management EAMPEVLG Purge Event Log

Federal Financials FVPGDTSR Process to show the Treasury Symbols that can be Purged or Purged.

Federal Financials FVXPURTS Purge Cancelled Treasury Symbols to reuse.

Financial Intelligence FII_BUDGET_FORECAST_PURGE Financials Intelligence Purge Budget and Forecast Program

Financial Intelligence FII_CCC_SEC_PURGE Purge Company and Cost Center WebADI Security from Interface Table

Flow Manufacturing FLMCPPG Concurrent Program for Flow Schedule Purge

Flow Manufacturing FLMRFPKB Purge Kanban Pull Sequences

General Ledger GLCPCA Purge Consolidation Audit

General Ledger GLPURGE Archive and Purge Program

General Ledger GLPURGEC Archive and Purge Child Program

General Ledger Upgrade Encumbrance balances Purge transaction history

Global Accounting Engine AXXDWDER Delete ALL archived rules

Global Accounting Engine AXXDWULD Unload from ALL TP to archived rules



Global Accounting Engine AXXPGLIS Purge Audit Report

Global Accounting Engine AXXPGSLE Subledger Archive and Purge by fiscal year accounting period

Human Resources DATAPUMP_PURGE Data Pump tables purge program.

Human Resources DATAPUMP_PURGE_SLAVE Data Pump Purge slave process for multi-threading.

Human Resources HRTCAUNMP Unmerge contacts and other person types, TCA purge only

Human Resources IRC_APL_TRACK_PURGE Process to Purge Old Applicant Tracking Data in iRecruitment

Human Resources IRC_PURGE_OLD_DATA Process to Purge Old Data in iRecruitment

Human Resources PAYLINK Purges all records related to a BEE batch

Human Resources PERDFFPERGE Purge Migrated Person DFF Data

Human Resources PERNLPAC Purge Daily Sick and Recovery Table

Install Base CSIACTARCH Install Base Party Accounts Transaction History purge

Install Base CSIASTARCH Install Base Instance Assets Transaction History purge

Install Base CSIEXTARCH Install Base Extended attributes Transaction History purge

Install Base CSIINSARCH Install Base Item Instances Transaction History purge

Install Base CSIOUARCH Install Base Operating units Transaction History purge

Install Base CSIPRIARCH Install Base Pricing attributes Transaction History purge

Install Base CSIPTYARCH Install Base Instance Party Transaction History purge

Install Base CSIRELARCH Install Base Instance Relationships Transaction History purge

Install Base CSISYSARCH Install Base Systems Transaction History purge

Install Base CSITHPUR Install Base Transaction History purge

Install Base CSIVERARCH Install Base Version labels Transaction History purge

Interaction Center Intelligence BIXPURIN Purge Interactions tables

Inventory INCAAP Purge ABC information

Inventory INCACP Purge cycle count information

Inventory INCRPG Purge replenishment counts

Inventory INCTPG Purge transaction history

Inventory INVCORPP Copy Inventory Organization Report Data Purge

Inventory INVGIPPG Inventory positions purge all

Inventory INVGIPPG Inventory positions purge by data set, user, creation date

Inventory INVHVTPG High Volume Transactions Purge

Inventory INVISCORP Copy Inventory Organization Interface Data Purge

Inventory INVMOPG Program of Move Order Purge

Inventory INVTPGWB Transaction Purge Worker

Inventory INVTXPURG Transaction Purge

Inventory MTL_CCEOI_PURGE Purge cycle count entries open interface in batch mode

Inventory Physical Inventory Purge Purge physical inventory information

Labor Distribution PSPARREP Archive History Report

Labor Distribution PSPENARC Archive Encumbrance Lines

Labor Distribution PSPLDARC Archive Distributions History

Lease Management OKLLRFP Purge Lease Rate Factor Interface Table

Lease Management OKLRVP Purge Residual Values Interface Table

Lease Management OKL_PURGE_PARALLEL_PROCESSES Purge Parallel Processes Table

Lease Management OKL_PURGE_STRM_INTF Purge streams interface tables

Marketing AMSCHBPURG Purge processed chargeback record - Program migrated to Trade Management

Marketing AMSIMPPURGE Claims Import Purge routine- Program migrated to Trade Management (OZF)

Marketing AMSPEWKR AMS: Purge Target Group and List Entries (Worker)



Marketing AMSPILTC Purge Imported List

Marketing AMSPTGPC AMS: Purge Target Group and List Entries

Marketing AMSWMHPE Concurrent Program to purge monitor history

Master Scheduling/MRP MRCPRG Purge Designator

Operations Intelligence OPI_PMI_INV_DAILY_SUM_PURGE Purge OPM Inventory Daily Summary Table

Oracle iProcurement ICXPCIIP Purge Catalog interMedia Index

Oracle Web Analytics IBW_DATA_PURGE This program purges data from the Web Analytics transaction schema.

Order Entry Order Purge Selection Order Purge Selection

Order Management GENPSET Create Purge Set

Order Management GENPSETQTEWHERE Quote Purge selection

Order Management GENPSETWHERE Order Purge Selection

Order Management OEMPRG Purge of OM Processing Messages

Order Management OEXCEPRG Purge Imported Credit Exposure program

Order Management OEXOIPCP Purge procedure for the views used by Order Import and EDI/XML message

Order Management ONTIBYCN_MGR Purge Secured Payment Data

Order Management ONTIBYCN_WKR Purge Secured Payment Data - Worker

Order Management ORDPUR Order Purge

Payables APXIIPRG Payables Open Interface Purge

Payables APXP7ABT AP/PO Purge Abort Routine

Payables APXP7CFM AP/PO Purge Confirmation Routine

Payables APXP7DEL AP/PO Purge Deletion Routine

Payables APXP7SEL AP/PO Purge Initiation (Selection) Routine

Payables APXP7SUM AP/PO Purge Summarization Routine

Payables APXPGLIS Purge Report Listings

Payroll PYNOTTPU Program to purge the tax table data.

Payroll PYSETTPU To Purge the data available in Tax Table for given Dates

Process Manufacturing Inventory GMIPEBAL OPM Purge empty balance

Process Manufacturing Inventory GMIPEBAL Oracle Process Manufacturing Inventory : GMI Purge Empty Balances

Process Manufacturing Inventory OPMTMOPG Purge OPM Txns and Move Order Lines

Process Manufacturing Product Development GMDRSPVL GMD QM Spec and Validity Rule Mass Search and Replacement

Process Manufacturing Systems SYPRGENG Archive and Purge Process

Projects PACCINTP Purge Capitalized Interest Transactions Audit

Projects PAXARPPR Purge Project Data

Projects PAXARPVD PRC: Validate Purge Batches

Projects UNASSIGNED_FI_PURGE Process to Archive/Purge Unassigned Forecast items

Property Manager PNSOIPUR Variable Rent Gateway Purge Process

Property Manager PNVPURGE Purge Location and Space Assignment Interface Tables

Provisioning XDP_PURGE Program to purge obsolete application data

Public Sector Budgeting PSBBRPUR Purge Budget Revisions

Public Sector Budgeting PSBSTPDE Purge Data Extract

Public Sector Budgeting PSBWCPUR Purge Worksheet

Public Sector Financials BCPURGE Budgetary Control History Purge

Public Sector Financials International IGIIMPPI Inflation Accounting : Purge Inflation Accounting Data

Public Sector Financials International IGIIMPPU Inflation Accounting : Purge Implementation Data

Public Sector Financials International IGIRDPTD Dunning Letters: Purge Temporary Data

Purchasing POXCDXPG Catalog Data Purge (Obsolete)

Purchasing POXPOIPR Purge Purchasing Open Interface Processed Data Program



Purchasing POXSSPG Purge System Saved Requisition

Receivables ARARCALL Call New Archive and Purge

Receivables ARARCDNL Archive to File

Receivables ARARCDRP Archive Detail Report

Receivables ARARCHID Archive Detail

Receivables ARARCHIH Archive Header

Receivables ARARCONT Archive Preview

Receivables ARARCONT Archive Restart

Receivables ARARCONT Archive and Purge

Receivables ARARCONT Purge

Receivables ARARCPUR Purge Module

Receivables ARARCSEL Archive Selection

Receivables ARARCSRP Archive Summary Report

Receivables ARGCGP Purge Designator

Receivables ARHIDENTPUR TCA - Identify Purge Parties

Receivables ARHLPURB TCA Import Process to Purge a Batch

Receivables ARPURGE New Archive and Purge

Receivables ARXPAR Purge Capacity Bill of Resources

Receivables AutoInvoice Purge Program Purge processed transactions in the AutoInvoice Interface tables

Receivables RAXTRX Purge Cost Information

Release Management RLMPS Release Management Purge Schedule

Release Management RLMPSRP Release Management Purge Schedule Exception Report

Release Management Integration Kit (Obsolete) RLAPURGE Purge Demand Interface Data

Sales Foundation AMLPRGIMP Purge Leads Import Interface

Sales Foundation ASTPRG Purge AS_ACCESSES_ALL and AS_TERRITORY_ACCESSES tables

Sales Foundation ASXPRGLD Purge Unqualified Sales Leads

Sales Intelligence BIL_BI_PURGE_OBJ Purge BIL Object Data

Sales Online ASFDLST Purge Deleted Lists

Sales Online ASFFRVH Periodically Purge ASF_RECORD_VIEW_HISTORY

Service CSSRPGP Service Request Data Purge Concurrent Program

Service CSSRPGW Service Request Data Purge Worker Thread Concurrent Program

Service CS_KB_SESSION_CLEANUP Program to purge temporary data stored in Knowledge Management

Service Contracts OKSCCPURGE Purge Credit Card Information

Service Contracts OKSUPDCC_HDRH_SUBREQ Purge Credit Card in Header History

Service Contracts OKSUPDCC_HDRRULES_SUBREQ Purge Credit card in Header rules

Service Contracts OKSUPDCC_HDR_SUBREQ Purge Line Credit Card

Service Contracts OKSUPDCC_LINE_SUBREQ Purge Line Credit Card

Shipping Execution WSHPURGE Program to purge shipping entities

Sourcing PurgeInterfaceErrorsCp Purge expired interface errors

Student System IGSDAJ03 Degree Audit Purge Requests

Student System IGSPSJ06 Purge Scheduling Interface Data

Student System IGSPSJ13 Purge Logically Deleted Records

Student System IGSSV03 SEVIS Purge Active Exchange Visitor Information

Student System IGSSV04 SEVIS Purge Active Non Immigrant Information

Student System IGSUCJ39 Purge Completed UCAS data

Subledger Accounting XLAAPPURGE Purge old Transaction Objects Diagnostics related information

Supply Chain Intelligence ISC_EDW_BACKLOGS_F_PURGE Purges the Backlog Fact given a date range or a period from today.



Supply Chain Localizations JMFGTIPG Golden Tax Invoice Purge Adaptor Invoices

Telephony Manager CCT_CLONE_CLEAN_EX Purge Interaction Center related telephony configurations after cloning

Telephony Manager CCT_TRANS_DATA_CLS_EX Purge Advanced Inbound related transactional data after cloning.

TeleSales AST_IMPORT_PURGE Sales Leads Purge Record from import interface table

Trade Management OZFCHBPURG Purge processed resale order records

Trade Management OZFIMPPURGE Claims Import Purge routine

Trade Management OZF_TP_PURGE_BASELINE_LIFT Program to Purge Baseline Sales and Promotional Lift Factor Data

Transportation Planning MSTPRGPL Launch Purge Transportation Plan

Warehouse Management PURGE_WMS Purge WMS History Tables

Warehouse Management PURGE_WMS Purge WMS History tables

Warehouse Management WMSTARCM Archive WMS Tasks

Warehouse Management WMSTARCW Archive WMS Tasks Worker

Warehouse Management WMSTUARM Un-Archive WMS Tasks

Warehouse Management WMSTUARW Un-Archive WMS Tasks Worker

Warehouse Management WMS_LMS_PURGE_SETUP_HISTORY Program to Purge Labor Setup History Records

Warehouse Management WMS_LMS_PURGE_TXNS Program to purge Labor Tracked Transactions

Work in Process WIPPURGE Purge Lot Based Jobs

Work in Process WIPPURGE WIP Purge


Reducing Your E-Business Suite Data Footprint using Archiving, Purging, and Information Lifecycle Management November 2008 Author: Mohsin Sameen Contributing Authors: Andy Tremayne Reviewers: Dimas Chabne, Nancy Lan, Olcay Sarioglu Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. Worldwide Inquiries: Phone: +1.650.506.7000 Fax: +1.650.506.7200 oracle.com Copyright © 2008, Oracle. All rights reserved. This document is provided for information purposes only and the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this document and no contractual obligations are formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written permission. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.

Archive Purge ILM Paper

Documents

Transcript of Archive Purge ILM Paper