Best Practices to Reduce Existing Volume and Limit Future

Growth of Transactional Tables

Oracle Payroll Page 1

Contents

Introduction .................................................................................................................................................. 3

Sparse Matrix/Insignificant Run Results ....................................................................................................... 3

Payroll Purge ................................................................................................................................................. 4

Single Latest Balance Upgrade ...................................................................................................................... 5

Database Compression ................................................................................................................................. 5

Event model .................................................................................................................................................. 6

Run Balances ................................................................................................................................................. 7

Other ............................................................................................................................................................. 7

Oracle Payroll Page 2

Introduction
Payroll database administrators will be aware that over time, Oracle Payroll processes can store
potentially large amounts of information to the database. This can have adverse effect of cost of
supplying larger amounts of database storage media as well as a potential performance impact due to
queries executing against high volume tables.

To ease this overhead, Oracle Payroll delivers multiple features that can reduce the amount of payroll
data held on the database that can be deemed to be legacy and not required for period to period
processing/reporting as per customer requirement. By minimizing this volume and limit the further growth
in volume of data in the transactional tables, performance can also be improved.
The various features are listed below with online references that detail the process and how to
enable/implement the feature if it is available for localizations.

• Sparse Matrix/Insignificant Run Results

• Payroll Purge
• Single Latest Balance Upgrade
• Database Compression
• Event model
• Run Balances

Sparse Matrix/Insignificant Run Results

The Sparse Matrix and Insignificant Run Results features are closely related and it is advised to enable
both if permissible.

Generally speaking, the PAY_RUN_RESULTS and PAY_RUN_RESULT_VALUES tables will create most
data during regular Payroll processing so would be a key area to focus for the maximum significant
overall volume reduction.

Insignificant Run Results prevents creation of both zero/null indirect run results and run result values. It
will prevent creation of the run result in the case where all run result values are null.

Sparse Matrix not only prevents null run result values but can also prevent certain run result values
derived from direct run results.

Both these features can prevent future creation of such data and support to purge any eligible existing
data via an associated upgrade program. This data may have been created prior to the feature being
enabled by the customer.Any results that are referenced by Retropay will not be deleted.

However, if a customer has any custom code that relies on the existence of the run result values being
generated, then it is advised that they carry out a testing cycle with just the Sparse Matrix feature enabled
for prevention of future values and confirm no impact is seen with the custom code prior to running the
Sparse Matrix Null Result Values process which will delete existing null run result values.

After running these processes, it is advised to ensure tables/indexes are rebuilt to reduce potential
fragmentation due to the potentially large amount of data that may be removed.

From Release 12.2 onwards, both of these features are enabled by default.

Oracle Payroll Page 3

For prior releases, availability of Insignificant Run Results is controlled by action parameter setup and/or
legislation rule. Customers can enable Insignificant Run Results suppression themselves via enabling an
action parameter.

As of Release 12.1 the following legislations: US, MX, CA, AU, HK, KR and SG automatically enable this
feature via the overriding legislation rule.

Sparse matrix has been enabled via Generic upgrade process for International Payroll since 12.1 HRMS
RUP7 and over 20 localizations now support this feature.

The following notes provide further information on these two features:

• 368723.1 - How to Avoid the Creation of Null Run Results and Null Run Result Values while
Running Payroll?
This Note details the setup for enabling the Insignificant Run Results and Sparse Matrix features
via the Generic upgrade mechanism.

The Note also contains information on a patch containing a script for 12.0/12.1 for retroactive
deletion of insignificant run results/run result values and for the case of Sparse Matrix, the
retroactive deletion of old null run result values via Generic Upgrade.

The patch can be made available on request for 12.2 customers. The script is generic and
applicable to all code levels.

Of note for US, Canada, India and Norway legislations who refer to jurisdiction results:
Results related to jurisdiction used to be created, patch 20867132:R12.PAY.B now prevents them
being created in future as is proper, as well as providing an update to
the Generic Upgrade to remove existing result values of this type. A one-off can be requested for
12.2 availability.

• 1154523.1 - How To Enable Sparse Matrix Functionality Prior To R12 Upgrade

Details best practice on enabling Sparse matrix - how to test prior to running the upgrade that
deletes existing values as well as checks for custom code and rebuild index operations after the
rows have been deleted to correct the statistics.

Payroll Purge
Legislations can implement Payroll Purge functionality to periodically reduce data held in the Payroll
tables.

Each customer needs to consider their own requirement in terms of how often and for what length of time
legacy data is required to be held for legal reporting purpose.

As a general guidance, customers must consider to run Purge process to remove data 2 years prior to the
current financial year as this is considered a suitable timeframe.

One caveat would be to consider if any retrospective changes might be required in future which would
possibly involve Retropay needing access to this older data so customers should bear that in mind when
to purge data. They may of course have backup/offlining strategies in place to prevent complete loss of
data in tandem but can utilise the Purge feature to ensure regular processing is running against
appropriately streamlined data volume.

Oracle Payroll Page 4

The following 2 notes provide very complete documentation on the background, setup and execution of
this process.
• 1373706.1 - Oracle Payroll 'Purge' Frequently Asked Questions (FAQ)
• 155106.1 - Payroll Purge - white paper explaining in detail the concept of purge, preparation of
purge and actual execution of the process.

Single Latest Balance Upgrade

With release of 12.1.1.HRMS.7 and R12.2.4, this process, which used to be enabled by localization, is
now available generically for all Payroll users.

This is referred in 1937092.1 which also details the SQL for determining for which business groups the
upgrade has not yet run (pygenupgfix.sql). It is enabled via the Generic Upgrade mechanism: "Single
Latest Balance Table"

Refer bug 12889150 requesting for documentation which is added to Release Notes for R12.2.4/R12.1.7.
- see section 3.3 in 1662347.1 - Oracle Payroll Release Notes for Release 12.1 HRMS RUP7
- see section 3.3 in 1906518.1 - Oracle Payroll Release Notes for Release 12.2.4

The following 3 tables can be truncated after running the upgrade as all data is moved to
PAY_LATEST_BALANCES:

PAY_PERSON_LATEST_BALANCES
PAY_ASSIGNMENT_LATEST_BALANCES
PAY_BALANCE_CONTEXT_VALUES

This would be a manual step required by the DBA. Indexes etc on the PAY_LATEST_BALANCES should
also be rebuilt as per normal guidance after the migration of potentially large amounts of data to this
table.

Database Compression
First introduced in 9g, now a mainstream feature as Advanced compression in 11g and further extended
in 12c.

Simply put compression is where data values in a column that are repeated in different rows and stored in
the same data block are only stored once. Thus you need fewer blocks for storing the same data. There
is some additional CPU overhead to process the compressed blocks but far more significantly there is
less physical I/O because you visit fewer blocks.

Note, Oracle provide basic block compression feature as standard whereas some more advanced
compression features are only available with a license.

Some Payroll tables lend themselves well for consideration of compression. For example, tables relating
to Payroll result data are mostly static as soon as the pay period is closed. Also, legacy data used in
reporting can be considered.

The following Payroll specific tables may well lend to compression and were considered as part of an
internal compression benchmarking project:

Oracle Payroll Page 5

PAY_ACTION_INFORMATION
PAY_ASSIGNMENT_ACTIONS
PAY_ASSIGNMENT_LATEST_BALANCES*
PAY_COSTS
PAY_ELEMENT_ENTRIES_F
PAY_ELEMENT_ENTRY_VALUES_A
PAY_ELEMENT_ENTRY_VALUES_F
PAY_PAYROLL_ACTIONS
PAY_PERSON_LATEST_BALANCES*
PAY_PROCESS_EVENTS
PAY_RUN_BALANCES
PAY_RUN_RESULTS
PAY_RUN_RESULT_VALUES

* Note: PAY_LATEST_BALANCES should be considered in place of

PAY_ASSIGNMENT_LATEST_BALANCES, PAY_PERSON_LATEST_BALANCES
if Single Latest Balance Table upgrade is enabled.

References:
Internal Oracle Vision compression with Payroll processing benchmark:
Oracle E-Business Suite Release 12.1 with Oracle Database 11g Advanced Compression (Doc ID
1110648.1)
- Highlights: Payroll performance improved up to 25%, Up to 68% compression

For more detailed information on Compression options for tables, see the section in the Oracle DBA
guide

For further general information:

• Getting Optimal Performance from Oracle E-Business Suite presentation.pdf
(https://community.oracle.com/docs/DOC-894516#)
• Oracle Information Lifecycle Management (ILM) Assistant - covers partitioning and table
compression strategies

Event model
The Event model is an architecture used by Retropay, Continuous Calculation, Proration, and some other
processes.

Its function is to capture run-time changes (known as events) caused by manual changes recorded by
users, for example: compensation, manager, or location changes. Over time, the number of records held
can grow significantly in certain cases and thus Oracle Payroll provides facilities to purge this information
as described in the references below:
• Overview of Event Model: Payroll Event Model - section within Enhanced RetroPay white paper
(373148.1)
• Purge: Oracle Payroll Release Notes, Release 12.1.2 (970458.1)
- see section 3.1 which also details the 2 operating parameters used by this process and their
impact on the performance of the purge in terms of commit units/bulk fetch.
- rows archived into PAY_PROCESS_EVENTS_SHADOW based on those created prior to the
given "Purge Date"

Oracle Payroll Page 6

Best advice on "Purge Date" - generally where reporting is legacy (for example 2 years) and rows are
deemed OK to leave in the shadow table which is offline from Payroll processing transactions.

Run Balances
Adjust Run Balance Dates process

The Adjust Run Balance Dates process will adjust the balance start date of all valid run balances.
It also acts as a purge process by truncating run balance data prior to the start date selected at run time.
Thus this process itself can be used to purge balance data that is deemed legacy in sense of not needing
to be retained on live tables for reporting purposes.

Again, as with the Payroll Purge section above, determination of this start date would be at the discretion
of the customer but general guidance would suggest a date of 12 months prior to the start of the financial
year would in most cases be appropriate. A date further back than this date may make the process non-
performing due to the amount of processing.
The following Notes will be of interest:
• How to SetUp and Use process_timeout for the Generate Run Balance Process(377887.1)
- to detail control of the timeout (whereby process ARBD/GRB) can later be retried
• How to Maintain 'Run Balances' at a Specific Point in Time in the Past (Doc ID 299561.1)
- some examples of cases by which to determine for how long the run balance data needs to be
retained to be reported on
• Best Practices: Generate Run Balance Payroll (Doc ID 335950.1)

Other
Purging Strategies for E-business Suite (https://community.oracle.com/docs/DOC-912284#)
- mentions: Using the standard Oracle E-Business Suite archive and purge programs.

Oracle Payroll Page 7

 Oracle Corporation, World Headquarters Worldwide Inquiries
500 Oracle Parkway Phone: +1.650.506.7000
Redwood Shores, CA 94065, USA Fax: +1.650.506.7200

CONNECT W ITH US

blogs.oracle.com/oracle
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. This
facebook.com/oracle
document is provided for information purposes only, and the contents hereof
twitter.com/oracle are subject to change without notice. This document is not warranted to be
error-free, nor subject to any other warranties or conditions, whether
oracle.com 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 Payroll Page 8