HRMS and BEN 11i and R12 Tuning and Health Check

Oracle HCM & Benefits
Tuning & System

Health Check
Release 11i & R12
Prepared by Andrew McGhee
Author:
Andrew McGhee & John Rhodes
Creation Date:
28 December 2006
Last Updated:
21 June 2007
Control Number:
Version:
3.0
Copyright (C) 2006 Oracle Corporation

All Rights Reserved
NOTE: The contents of this document are deemed to be correct

and accurate at time of going to press. If inaccuracies are
discovered then please contact andy.mcghee@oracle.com. Please
also contact me if you have experiences to share that would fit
within the scope of this document. There is no commitment on
content or scheduling for any functionality contained within this
document.
Guidelines made within this document may not hold true for every
HCM implementation at every site. The information must therefore
be thoroughly tested if it is to be followed.
Oracle HCM & Benefits Tuning and System Health Check 11i & R12
Oracle / Client Confidential
Page 1
Contents
Contents............................................................................................................................................... 2
Preface ................................................................................................................................................. 4
Overview.............................................................................................................................................. 5
Key System Health Check Phases ..................................................................................................... 6
Audit Phase....................................................................................................................................... 6
Tuning Phase .................................................................................................................................... 6
Review & Report Phase.................................................................................................................... 7
Management Phase ........................................................................................................................... 7
Tuning Payback ................................................................................................................................ 9
Understanding The Bigger Picture............................................................................................... 12
Multi-Threaded Processes ............................................................................................................... 15
Concurrent Programs...................................................................................................................... 15
Tune The HR Application Setup & Procedures ............................................................................ 16
Security List Maintenance Process (PERSLM).............................................................................. 16
DataPump ....................................................................................................................................... 17
System Extract Process................................................................................................................... 18
System Extract Restart Process ...................................................................................................... 18
System Extract Write Process......................................................................................................... 18
Data Loading Person Records ........................................................................................................ 19
Tune The Payroll Application Setup & Procedures...................................................................... 21
Payroll Run Process........................................................................................................................ 21
QuickPay Process ........................................................................................................................... 23
Payroll Reversal.............................................................................................................................. 23
Balance Adjustment........................................................................................................................ 24
Balance Initialization...................................................................................................................... 25
Payroll Run Rollback ..................................................................................................................... 26
Pre-Payments.................................................................................................................................. 26
QuickPay Pre-Payments ................................................................................................................. 27
Costing............................................................................................................................................ 28
Transfer To GL............................................................................................................................... 30
External & Manual Payments......................................................................................................... 30
Magnetic Tape ................................................................................................................................ 31
Cheque Writer ( U.S. & U.K. )....................................................................................................... 31
Deposit Advice ( U.S. ) .................................................................................................................. 32
Cash Process................................................................................................................................... 32
RetroPay Process ............................................................................................................................ 33
Advance Pay................................................................................................................................... 33
Multi-Threaded Archiver................................................................................................................ 33
Sparse Matrix / Insignificant Run Results ...................................................................................... 34
Consolidation Sets .......................................................................................................................... 34
%_PAYMENTS Balance Database Item ( U.S. Only ).................................................................. 35
Continuous Calculation .................................................................................................................. 35
Hot Payroll Tables ....................................................................................................................... 36
Tune The Benefits Application Setup & Procedures..................................................................... 37
Compensation Object Design ......................................................................................................... 37
Plan Design..................................................................................................................................... 37
Online Processes............................................................................................................................. 38
Page 2
Online Life Events Process ............................................................................................................ 38

Participant Enrollment Process....................................................................................................... 39
Batch Processes .............................................................................................................................. 39
Back-out Life Events Process......................................................................................................... 39
Close Action Items Process ............................................................................................................ 39
Close Enrollments Process ............................................................................................................. 40
Default Enrollment Process ............................................................................................................ 40
Determine Communications Process .............................................................................................. 41
Maintain Designee Eligibility Process............................................................................................ 41
Recalculate Participant Values Process .......................................................................................... 41
Participation Process: Life Events.................................................................................................. 42
Participation Process: Scheduled.................................................................................................... 43
Participation Process: Selection...................................................................................................... 43
Participation Process: Temporal..................................................................................................... 44
Premium Calculation Process ......................................................................................................... 45
INITRANS Table Setting ............................................................................................................... 45
Appendix A - PAY_ACTION_PARAMETERS Settings.............................................................. 46
Action Parameter Values ................................................................................................................ 46
Summary of Action Parameters...................................................................................................... 47
Parallel Processing Parameters ....................................................................................................... 48
QuickPay Parameters...................................................................................................................... 49
Array Select, Update and Insert Buffer Size Parameters................................................................ 50
Costing Specific Parameters........................................................................................................... 51
Magnetic Tape Specific Parameters ............................................................................................... 52
Quantum Specific Parameters ........................................................................................................ 52
Data Pump Parameters.................................................................................................................... 53
Data Migrator / Data Upload Parameters ....................................................................................... 54
Error Reporting Parameters ............................................................................................................ 55
Rollback Specific Parameters ......................................................................................................... 56
Payroll Process Logging................................................................................................................. 56
Logging Categories ........................................................................................................................ 57
Logging Parameters........................................................................................................................ 58
Output Log File .............................................................................................................................. 59
Batch Element Entry Parameters .................................................................................................... 59
Miscellaneous Parameters .............................................................................................................. 60
Appendix B - BEN_ACTION_PARAMETER Settings ................................................................ 66
Summary of Action Parameters...................................................................................................... 66
Appendix C - INITRANS & PCTFREE Settings .......................................................................... 68
INITRANS ..................................................................................................................................... 68
PCTFREE ....................................................................................................................................... 69
Appendix D - Costing Index Determination .................................................................................. 71
Appendix E Diagnostic Scripts..................................................................................................... 73
Oracle Diagnostics.......................................................................................................................... 73
Appendix F - Other Useful References / Sources of Information ................................................ 74
Page 3
Preface
This document is an updated version of the Oracle HCM & Benefits Tuning and System Health Check Release 11i document ( Metalink
Note Number: 226987.1 ). It has been updated to cover the latest
information for Release 11i and Release 12. Any Release 12 specific
information will be highlighted accordingly.
A major change from the previous document is that the sections that are
not specifically about HCM or Benefits have been removed e.g Useful
Network Analysis Utilities / Commands, Utlnstat & Utlestat etc. The
intention is that the document should focus on HCM & Benefits, whilst
other performance and implementation issues can be addressed by
documents to be found on Metalink,, some of which are listed in
Appendix F.
The content of the HCM and Benefits sections is largely unchanged,
however it has been verified against the latest 11i & Release 12
functionality.
Page 4
Overview
This document highlights the key areas and tasks required to perform a
detailed system health check of the Oracle HCM and Benefits
Application.
When talking about health checks we often mean the action or process
of optimizing an application or making it more performant.
To optimize an application implementation it is vital to understand each
of the components of the system and associated subsystems; the
operating system, database, application(s), network and client. By
discovering where each subsystem is being stressed or bottlenecked and
correctly focusing the search, the potential problem causes can be
identified quickly.
Oracle Applications are exceptionally versatile and can be integrated
into a variety of businesses with the minimum of functional setup.
Typically, the approach to tuning applications has concentrated on
optimizing the database and perhaps tuning for unusual data
distributions. Whilst this may be the primary focus of a particular
tuning effort, there may be many more system features can be tuned and
some can return far higher performance gains. A much better tuning
approach is end-to-end tuning. In other words, if the user cannot see
the change the tuning effort was not correctly focused or there is
another overriding major bottleneck still to be corrected.
Page 5
Key System Health Check Phases

A system health check must be undertaken in a structured and
methodical way. You need to be able to establish baselines against
which you can measure any improvements. Having identified
improvements, baselines need to be reestablished and further changes
can be investigated as to their impact on performance. This work is
cyclical and should be repeated as many times as is necessary until you
are satisfied with the results.
There are a number of easily identifiable phases within a system health
check review. Diagram 1 shows these phases with the relationship
between each phase.
Audit Phase
Tuning Phase
Review & Report Phase
Management Phase
Diagram 1 - Key System Health Check Phases
Audit Phase
A full system health check cant be done without an understanding of
the whole application and all of its components and subsystems. This
is best done by bringing together representatives from each business
function involved with the application; users, system administrators,
DBAs, network administrators etc, and discussing what the system is
and does from each of their perspectives.
Any problems must be defined clearly and documented. Performance
targets must be set and agreed. Some may be essential to the business
and others may be nice to have but not essential to support the
business.
Tuning Phase
A baseline of existing operation performance must be established.
There is no point in implementing any performance enhancements
unless a baseline exists against which changes can be measured.
Perform detailed analysis on areas identified within the audit phase. A
methodical approach should be used to investigate each focused area.
Actions and results should be clearly documented. If a major
performance problem is identified and fixed but the resultant effect on
performance is minimal then there may be other overriding bottlenecks
that are being hidden by the previous problem. Baselines should then be
Page 6
reestablished and the focus of investigation redirected to new or

existing highlighted problems.
Review & Report Phase

Reviewing and reporting on the changes that have been made and the
resultant effect on performance is essential. This not only helps future
support and maintenance of the application, it also enables skill and
knowledge transfer to take place.
Management Phase
This takes place when tuning transitions from a reactive mode into a
proactive mode. An essential part of the tuning process is to involve
and possibly transfer necessary skills to the client, advise appropriate
courses and perhaps recommend books. The primary goal is to enable
clients to monitor and manage performance themselves.
This document concentrates on the first 3 phases and doesnt expand
any further on the management phase.
The audit phase should have prioritised which components of the

system needs investigating first. If priorities havent been established
then a possible sequence to tune the various application components is
highlighted in Diagram 2.
Tune Database
Structure
Tune Client
Tune Middle
Tier
Tune Server
Tune
Application
Tune
Network
Diagram 2 - Tuning Components Sequence
Page 7
Although these stages may appear to have some form of order or

sequence, tuning is not always a sequential process and occasionally
areas have to be revisited or cannot be fully investigated as there are
other bottlenecks in the system that need to be dealt with before
returning to that stage.
Tune Client
Tuning the client is a relatively quick and definitive step. It should only
need to be done once. Not only does this remove a major bottleneck but
it also ensures that you have a known basis for comparisons with
benchmarks. Increasing client stability will ensure all tests run
smoothly.
Tune Network
One of the most important aspects is to agree a test area where the
performance targets have to be achieved. A specific networked location
should not have an unacceptable amount of latency or have bandwidth
problems, nor should it be directly connected to the server. The network
analysis is one of the longest stages and can take place in tandem with
the remaining stages.
Tune Server
Block sizing, table, index and redo log placement are all factors that
have a major effect on I/O bottlenecks and resource contention.
Although changing these may not be quick, it can perhaps be scheduled
as part of the Management Phase.
Proper allocation of memory resources can improve cache performance,
reduce parsing of SQL statements and reduce paging and swapping.
Analysis and sizes of SGA, the data dictionary cache and the library
cache are essential. Too large an SGA will cause paging or swapping
that may be reported in trace files as logical rather than physical reads.
Multiple concurrent users may create contention for Oracle resources
causing processes to wait until resources are available. Block, shared
pool, lock and latch contention should all be minimised.
Tune Middle Tier
A middle tier hosts the forms process and for this reason, memory is
most important with CPU speed next and finally disk I/O. Having
separate machines for database and middle tier means that you can add
middle tier machines as necessary, which provides a very scalable
solution; it also simplifies the administration and management of each
machine.
As part of configuration and tuning decisions will need to be made
about the number of Java Virtual Machines (JVMs) and the number of
users to allocate to each, this will depend om the type of applications
being run and the typical user activity. In addition it is necessary to
determine how much memory should be allocated to each JVM, again
this is somewhat dependent on application usage.
Configuration of the various middle tier components should also be
tuned to find the optimum settings.
Page 8
Tune Database Structure

Tuning application SQL is usually dependent on realistic data volumes
and data-distribution; this is particularly true when using the cost-based
optimizer in Applications Release 11i. Although the best solution is for
test to be a copy of production, in Release 11i, you can export the
statistics from production and import them into your test environment,
so that the generated SQL execution plans will accurately reflect
production regardless of data volumes.
Several database factors are critical for Oracle Applications. For
example, periodically gathering statistics, database block size, pinning
strategy, the amount of literal SQL and adherence to Oracle Flexible
Architecture (OFA) can all have a major effect on memory, I/O
bottlenecks, and resource contention.
Tune Application SQL Access Path
The first stage of any application performance analysis has to be to
check that the code is efficient. There are multitudes of documents,
White papers and manuals devoted to all aspects of SQL tuning. The
SQL Trace utility is invaluable for this stage. Assuming that the SQL
code is efficiently written, the next step is to look at the anomalous data
volumetric and data distribution identified during the audit phase.
For example, 50,000 organizations would be considered a large number
in any implementation. Investigate using the cost based statistical
information or indexes. Pinning frequently accessed packages in the
correct order can change response times dramatically.
Tune Application Setup & Procedures
The way that the application has been set up can affect the operational
performance of the system. The more complex the set up of the
application ( in terms of elements, element inputs, formulas, formula
results, user defined functions, pro-ration, retropay, eligibility rules etc
) the greater the chance of performance problems. This does not
however mean that all complex Payrolls should in fact be slow, but the
greater the complexity, the more work is required to fine tune all of the
influencing components.
As well as application set up, another potential cause of performance
problems is the way the application is operated i.e. operational
procedures during the Payroll cycle. For example, doing constant /
frequent payroll runs and rollbacks just to see the effect of changes
could possibly be better managed by just marking specific individuals
for retry and re-processing only them.
Tuning Payback
Tuning can take place within different parts of an application.
Identifying the 6 main steps to tune an application, there is diminishing
return at each subsequent step. Tuning early in a development cycle
returns the highest gains. Significantly more effort is required in the
later stages and, in practice, it is almost impossible to tune a poorly
designed application. Diagram 3 shows the potential return on effort for
tuning at each stage.
Page 9
1000000
1000000
100000
10000
1000
1000
1000
100
100
10
10
1
Optimise
Data
Design
Tune SQL
Statements
Tune
Application
@ DBA
Level
Tune
Memory
Allocation
Tune Disk
I/O
Tune
Memory
Contention
Diagram 3 - Tuning Return On Effort
Step 1: Optimise Data Design

The data design for Applications has already been done and should be
considered static. A considerable amount of effort has been expended
in tuning the design. When working with most performance problems,
design changes have not been found to be necessary at all. It is
important to ensure architectural data designs are as performant as
possible.
Custom applications and extensions to application product functionality
should be tuned to ensure optimum performance. If poor performance is
detected then custom code should be disabled and the tests performed
again to determine whether the application code is at fault.
Step 2: Tune SQL Statements
There are several rules that can be used to write efficient SQL
statements, for example:
Place the most selective table at the right hand end of the list of
tables in the from clause
Use the clauses with the highest restriction first in the where
clause
Release 11i and 12 take advantage of the CBO ( Cost Based Optimizer
) database features to ensure that the access path for SQL statements is
based on the data population of the tables being referenced and their
join conditions. This requires tables to be analyzed.
There are two main reasons why problems occur:
1. Mistakes are sometimes made. The solution here is to create a
bug with Oracle Support.
2. Statements are assumed to work in environments with a similar
data distribution to a development environment, however this is
not always the case, and using CBO should greatly reduce these
types of errors.
In the second of these cases, in an environment with an unusual or
anomalous data distribution, the customer relies on the performance
expert for optimisation. A useful tool for investigating and evaluating
SQL statements is the SQL Trace utility. It reports on the optimisation
path chosen by the optimizer and provides statistics which measure the
performance and efficiency of the chosen route.
Page 10
Step 3: Tune The Application

There are two aspects to Application tuning:
1. Functional Usage
The system can be setup correctly but with all sorts of things
that affect performance. For example, a large number of Payroll
processes can be run in multi-threaded ( parallel ) mode. If such
processes are run in serial mode, and the machine being used
supports multiple processors, then processors are being under
utilised.
2. System Setup
Generally, most system parameters are defined during the setup
stage and are never monitored for effectiveness or changed. For
example, having many User Defined Functions ( which havent
been tuned ) repetitively called from within formulas will affect
performance.
Step 4: Tuning Memory Allocation
There is no point in tuning memory if a SQL statement is behaving
badly. Whilst Tuning memory allocation, the caches and System
Global Area, for example, can produce some very high returns, some
are insignificant. Some areas of memory can only be tuned as a whole
and there are various tools, such as using extended statistics, to predict
the change in memory usage before the change is made. Major factors
in this area are the size of the shared pool, the library caches the redo
log buffer and the sort area.
Step 5: Disc I/O
There are several standard Oracle texts, including the Oracle Flexible
Architecture, that discuss how best to optimise and equalise the I/O to
each disk. Datafile distribution, and considerations of the use of disk
striping, RAID, raw partitions, operating system and Oracle block sizes
are all essential considerations. The goal of any I/O subsystem is
throughput optimisation and a high data transfer rate.
There are Oracle processes in play, such as the LGWR and DBWR that
can be tuned. Other processes, such as CKPT, can be activated
affecting the way that Oracle caches the writes to disk.
When investigating performance in this areas, expect only a few
percent at best as most systems are reasonably well laid out.
Step 6: Tuning Memory Contention
The four areas of contention that need review are:
1. CPU
2. Memory
3. Network
4. Disk resources
Page 11
Understanding The Bigger Picture

Prior to starting any health check engagement, it is necessary to get a
good appreciation of the whole system ( including subsystems and
interfaces ). This is best done by bringing together individuals
responsible for each of the key areas of the system:
Client ( PC ) Technicians
Network Administrators
Server Administrators
Database Administrators
Application Administrators
Application Users
The purpose of such a meeting is to find out as much as you can about
exactly what the system is and how all of its components operate. Table
1 contains a list of the types of questions that should be asked during
any initial system information gathering meeting which is part of the
audit phase.
Functions & Operations

What business operation(s) / functions does the system support ?
What work is done; by whom and at what times ?
What is the daily workload on the system ?
Are there any periods of increased / decreased system activity e.g.
month end ?
What real time, batch and reporting operations take place ?
Applications
What application(s) are used ( Oracle & non-Oracle )
How do applications interact with the Oracle Application ?
Exactly what part(s) of the Oracle Application is used ?
How exactly has the application been set up ( formulas, elements,
costing etc ) ?
What custom processes / procedures have been created ? Provide
explicit details.
Describe a typical Payroll run cycle / sequence of steps
performed.
Page 12
Are any HCM Application tables being audited ? If so, which

ones and why ?
Have any additional User Defined Functions or Database Items
been created ?
Are User Defined Tables being used within the application ?
Is the Update Recurring element functionality being used ?
How many defined balances have been set up ?
What does the data distribution ( no. of rows ) look like for each
functional area used ?
What customizations ( if any ) have been made to the Oracle
Application ?
Technical Architecture & Software

What does the enterprise architecture look like ?
What client and server machines do they use ( what is the exact
specification of these ) ?
What networks are used and how do these interconnect ( get
network diagrams )
How is software configured and managed; locally on each
client/server, or via file servers ?
Is database on-line archiving switched on ? If so, why ?
What other processes / functions run on the machine that
processes the Payroll ? Do these other functions use the machine
whilst the Payroll run is processing ?
Have any custom / bespoke indexes / triggers been added to the
system ? If so, provide details.
Exactly what versions of software and patches have been applied.
Is there any table extent fragmentation ?
Provide a listing of the contents of the
PAY_ACTION_PARAMETERS table.
How has the database been set up on the machine ( location for
tablespace files, control files etc ).
Provide row counts of the 30 largest tables on the system.
How was the data originally loaded in to the application ( APIs,
balance initialization process, BEE process, datapump ) ?
Provide a copy of the database init.ora file.
Page 13
Is RAID or disk mirroring / striping implemented ? If so, how ?

Is RAC being used ? If so, please provide details.
Provide details of how your concurrent manager(s) have been set
up.
Infrastructure
What teams support the application ?
What is the backup and recovery strategy ?
What is the disaster recovery strategy ?
What service level agreements exists ?
What capacity planning ( hardware sizing ) has taken place ?
What system performance monitoring and workload optimization
( tuning ) takes place ?
What resource management and accounting takes place ?
Miscellaneous
What are peoples performance perceptions of the system ( users
and administrators )
Table 1 - Appropriate System Information Gathering Questions
During this initial knowledge gathering and understanding meeting it is

beneficial to gather customer profile information. Including:
Company details ( addresses of all relevant offices )
Contact details ( with contact numbers )
Names of Oracle people involved in the account ( with their
roles and responsibilities )
Software installed
Background of project to date
Current issues ( if any )
Details of education attended / needed
Experiences with Oracle support
Experiences with Oracle consultancy
Whether the customer is willing to be a reference site
Page 14
Multi-Threaded Processes
Concurrent Programs
In Oracle Applications, concurrent processing simultaneously executes
programs running in the background with online operations. Using the
System Administrator responsibility, you can manage when programs
are run and how many operating system processes Oracle Applications
devotes to running programs in the background.
A concurrent manager is itself a concurrent program that starts other
concurrent programs running. When an application user submits a
request to run a program, the request is entered into a database table
that lists all of the requests. Concurrent managers read requests from
the table and start programs running.
You can define as many concurrent managers as you want. When you
define a manager, you:
-
Assign a predefined library of immediate concurrent programs

to your manager.
Immediate concurrent programs are subroutines associated
with concurrent managers. All other concurrent programs are
spawned as independent processes at run time.
Assign work shifts to your manager, which determines what

days and times the manager works as well as the maximum
number of operating system processes you want your work
shift to run simultaneously. Each process can run a concurrent
request.
Note: The maximum number of operating system processes
parameter is very important for those HCM & Benefits
programs that can be controlled using the THREADS
parameter ( as set in the PAY_ACTION_PARAMETERS or
BEN_BATCH_PARAMETER tables ). You need to ensure
that the concurrent manager that will be executing such
programs is able to handle the sub-processes which will be
created.
For each work shift, you define the maximum number of

operating system processes the manager can run concurrently
to read requests (start programs) during the work shift.
Specialize your manager to read only certain kinds of requests.
For further details of how to set up and administer concurrent

manager, look in the Oracle Applications System Administrators
Guide.
Page 15
Tune The HR Application Setup & Procedures

A well set up, thought through and configured application will always
give better performance and response than one that has been deployed
without any consideration
Security List Maintenance Process (PERSLM)

This process maintains the lists of organizations, positions, employees
and applicants that security profile holders can access. You should
schedule it to run every night to take account of changes made during
the day. If a disruption, such as a power cut, occurs while the process is
running, you can manually restart it from the Submit Request window.
Single / Multi Threaded
Multi threaded.
Key PAY_ACTION_PARAMETERS Settings
THREADS
CHUNK_SIZE
CHUNK SHUFFLE
Observations
To take advantage of the multi-threaded performance

enhancements, dont forget to ensure that you have set the
THREADS parameter setting in the
PAY_ACTION_PARAMETERS table. You will also need to
ensure that that your concurrent manager can handle the number of
child processes that will be spawned off due to the THREADS
setting.
If you are just running HR ( without Payroll ), please ensure that

the following tables, and their associated indexes, have INITRANS
set correctly ( based on your THREADS setting value ):
PER_ALL_PEOPLE_F
PER_ALL_ASSIGNMENTS_F
PER_PERSON_LIST
PER_POSITION_LIST
PER_ORGANIZATION_LIST
PER_ASSIGNMENT_LIST
PER_SECURITY_PROFILES
PAY_POPULATION_RANGES
See Appendix C for further details regarding INITRANS settings.
Tuning of the contents of the Security Profile can have significant

benefits, in particular the code that can be entered in the Custom
tab. Limiting security profiles to named organizations or named
people will ensure that the profile does not result in large amounts
of memory being used to cache the access list.
Page 16
DataPump
The Oracle HCM Data Pump supports rapid implementation by
simplifying and standardizing the common tasks associated with
loading batch data into the Oracle HCM tables. This is done by
providing a set of predefined batch tables and standard processes that
simplify the tasks of data-loading using the supported APIs.
Multi threaded.
THREADS
CHUNK_SIZE
MAX_ERRORS_ALLOWED
PUMP_DEBUG_LEVEL
DATA_PUMP_DISABLE_CONT_CALC
DATA_PUMP_NO_FND_AUDIT
DATA_PUMP_NO_LOOKUP_CHECKS
DATA_PUMP_PURGE_CHUNK_SIZE
DATA_MIGRATOR_MODE
PUMP_DT_ENFORCE_FOREIGN_LOCKS
Observations
Datapump has built in parallelization which enables it to make use

of multiple CPU processors (if available on the machine). This is
activated using the THREADS parameter. If you make use of this
option, ensure that the tables being manipulated via the APIs have
their INITRANS settings set accordingly (depending on the values
of the THREADS parameter). If you experience performance
problems running in parallel mode and a trace file shows process
waits then this may be because of inadequate INITRANS settings
on the specific tables and indexes.
When running the hr_pump_meta_mapper.help procedure, make

sure that you set serveroutput before hand. E.g.
set serveroutput on size 1000000;
Datapump uses published APIs to load / update data in the

database. If API user hooks have been enabled and set up then
slow performance in running a datapump process may be the result
of poorly written API hook code.
Page 17
The datapump interface tables are like any other type of interface
table. They will grow in size over time depending on use. You
should periodically clean down these tables to aid performance.
System Extract Process

This process creates results for an extract definition that will be used to
send necessary information to 3rd party carriers, payroll providers, or
other benefit vendors.
Multi threaded
Key BEN_BATCH_PARAMETER Settings
THREADS
CHUNK_SIZE
MAX_ERRORS_ALLOWED
Observations
Formulas will slow down process
System Extract Restart Process

This process re-processes the records that are marked as errors by the
system extract process.
Multi threaded
THREADS
CHUNK_SIZE
MAX_ERRORS_ALLOWED
Observations
These BEN_BATCH_PARAMETER values are inherited from the

corresponding System Extract Process.
System Extract Write Process

This process saves the extract process output to the directory and file
specified in the extract definition. The process also allows the output to
be viewed in the concurrent manager based on the definition. This can
also be executed along with Extract Process or independently.
Page 18

Single threaded
Data Loading Person Records

All HCM engagements will involve the loading of legacy data in to the
newly defined Oracle HCM Application. Person data is likely to
account for a fairly large percentage of the data to be loaded. When
setting up the application you have to decide what method of employee
number generation should be used within the application; either manual
(i.e. users have to enter the number) or automatic (the system creates
the number from a system defined sequence). The method chosen needs
to satisfy the requirements of the organization but this choice can also
affect data load performance for person records.
Automatic Number Generation
Employee and applicant automatic number generation is controlled via
the PER_NUMBER_GENERATION_CONTROLS table. For each
business group defined, there are two rows in this table; one for
Employee sequences (type = EMP) and the other for Applicant
sequence numbers (type = APL). The next sequence value for an
employee or applicant record is determined as follows:
1.
2.
3.
Find the next sequence value ( next_value ) from the

PER_NUMBER_GENERATION_CONTROLS table for the
appropriate business group and sequence type ( either EMP or
APL ).
Lock the row found in 1 ( above ).
Increase the next_value for the locked row by 1.
This mechanism is suitable when you have just got a single processor
accessing this table but if your loading mechanism supports parallel
processors ( like datapump ) you are likely to experience locking issues
from within your data loading API ( as more than one process tries to
access a sequence at the same time ). This does assume that you are
using published APIs for the creation of person details.
A way to get around this problem is to define your business group as
having manual employee and applicant number generation methods.
Your loading routine must then specify suitable values for these
attributes. Because youre using manual number generation, the create
employee / applicant API knows not to check the number generation
controls table.
Having loaded all of your data, you may need to set the number
generation method for your business group back to automatic. The form
will not allow you to do this! You have to make the change via
SQL*Plus. The following is an example of how to set the employee and
applicant number generation methods to automatic:
UPDATE HR_ORGANIZATION_INFORMATION
SET ORG_INFORMATION2 = A,
ORG_INFORMATION3 = A
WHERE ORGANIZATION_ID = < Id for business group >
AND ORG_INFORMATION_CONTEXT = Business Group
Information;
You will also have to set the next sequence value within the
PER_NUMBER_GENERATION_CONTROLS table.
Page 19
UPDATE PER_NUMBER_GENERATION_CONTROLS
SET NEXT_VALUE = < max(employee_number) + 1 >
WHERE BUSINESS_GROUP_ID = < Id for business group >
AND TYPE = EMP;
UPDATE PER_NUMBER_GENERATION_CONTROLS
SET NEXT_VALUE = < max(applicant_number) + 1 >
WHERE BUSINESS_GROUP_ID = < Id for business group >
AND TYPE = APL;
Page 20
Tune The Payroll Application Setup & Procedures

This section looks at specific HCM Application features and processes
and tries to give some guidance and lessons learnt about their setup and
ideas of things to try or to avoid in order to improve performance.
As well as recommendations made in this document, there are a number
of HCM Technical Essays that provide additional information and
guidance in to the use of specific features and processes within the
HCM application. These can be found on Metalink in the HRMS Core
Payroll Knowledge Browser Product Page (267505.1).
Payroll Run Process

The Payroll Run process calculates the gross to net payment for
employees.
Payroll Run uses payroll actions to represent each payroll run. It
identifies which assignments have payroll actions performed on them (
that action is an assignment action of the type payroll ).
The results from processing each element for an assignment are
identified as the run result values. These individual results are
accumulated into balances that summarize gross to net, and in particular
the payment balances. Payment balances are taken forward by the next
process in the regular pay cycle, PrePayments.
Multi threaded.
BAL BUFFER SIZE
EE BUFFER SIZE
RRV BUFFER SIZE

RR BUFFER SIZE
THREADS
If running with a multi-processor

machine, consider setting this to at least
the number of processors available ( the
maximum setting is 2 times the number
of processors ). Experiment to
determine the optimal setting for your
site. Whenever a value of greater than 1
is defined, you need to review the
INITRANS setting for some key HCM
tables and indexes ( see Appendix C INITRANS & PCTFREE Settings ).
Note:
Affects array fetch processing within

the Payroll run. If trace files show
differences between execute and
fetch timings, then worth having a
look at buffer sizes.
Try setting each of these to 100.
When setting THREADS to a value

greater than 1, the concurrent manager
must be defined to allow the required
Page 21
number of sub-processes to run in

parallel.
CHUNK_SIZE
Has effects on rollback segment size (

especially when running with multiple
THREADS ).
CHUNK SHUFFLE
Randomizes the order in which the

chunks are processed ( to minimize
contention between database blocks ). A
last resort setting but has been shown to
make improvements in certain
circumstances.
Observations
The payroll run process doesnt require large amounts of TEMP

tablespace ( which is usually used for sorting records ). There is an
element entry fetch statement within the Payroll processing code
that will use the TEMP tablespace but this shouldnt cause a large
overhead for TEMP space.
Be VERY careful when defining update recurring elements and

only use this feature if absolutely necessary. This will have a
substantial performance overhead on the Payroll Run process as it
is having to correct / update elements as it processes the Payroll.
This will also have sizing implications. Some Payroll processes e.g.
reversal, rollbacks, cannot undo updates done as part of update
recurring work.
If rollbacks or mark for retrys have been done / specified then the
Payroll run process is unable to use the latest balance values and
therefore has to recalculate balances. Having to recalculate the
latest balance values can have a significant affect on the Payroll
run timings. Release 11i stores the latest and latest minus 1 balance
values. This protects you from single rollbacks but multiple ones
will still cause the removal of the balance.
Within the U.S. legislation, when defining elements you are able to
specify whether the element generates a separate cheque or
whether it needs to be taxed separately. This causes additional
spawned Payroll runs to be initiated after the main Payroll run
process. Therefore, the more elements that are defined in this
manner and the more people who are assigned to these elements,
the more processing the Payroll engine has to perform .
If you require a latest balance to be calculated within the Payroll

run process, all you have to do is to reference the required defined
balance from within a formula ( that is processed by the Payroll
run). This will ensure that the latest balance value will always be
calculated during the Payroll run and this can improve the
subsequent future retrieval of the balance value.
The access of User Defined Tables ( UDT ) from within formulas

is known to have caused performance problems in the past. This is
because of the formula function to retrieve table values. Because
UDTs are very generic table definitions, it is not possible to create
individual indexes to support each UDT structure defined. This
Page 22
therefore limits the indexes that can be placed on the underlying

tables. Alternatives include using globals, creating custom tables
(with associated database items and user defined functions ) or
coding values within the formula itself. The selected solution will
obviously depend on the amount of data involved.
The use of User Defined Functions can have an affect on Payroll

run processing time if the SQL code associated with the functions
has not been tuned thoroughly.
If additional user defined database items have been created and the
associated SQL has not been thoroughly tuned then performance
problems may be experienced.
QuickPay Process
QuickPay enables you to carry out payroll processing for individual
employees. You can use QuickPay to pay employees who are leaving
and who require payment by cash or cheque. If an employee asks you
what his or her net pay will be this month, you can run QuickPay to
find the answer, then roll it back to remove all results from the
database.
Single threaded.
As for the Payroll Run process ( excluding THREADS parameter )
plus:
QUICKPAY_INTERVAL_WAIT_SEC
QUICKPAY_MAX_WAIT_SEC
Observations
Long delays between submitting a quickpay and the concurrent

manager actually executing the process could be because of the
setup of the concurrent manager being used. Check the sleep time
of the concurrent manager, by default this is set to 60 seconds.
Reducing the sleep time for the concurrent manager will improve
the elapsed time for the quickpay run.
Consider creating a separate concurrent manager just for quickpay

runs.
Payroll Reversal
You can retry an employee or a run only when no postrun processing
has occurred. You use reversals when you need to correct run results
after postrun actions have already occurred.
Page 23
In other words, reversals are useful when you need to correct run
results some time after the run has occurred. The reversal process
creates negative run results that cancel out previous entries.
Single threaded.
None apply.
Observations
Reversals cant undo any Payroll updates done as part of update

recurring element processing.
Latest balances are removed.
The reversal process can only be run for a single assignment at a

time and is executed via a Form.
Balance Adjustment
Oracle Payroll balances do not normally need direct adjustment by
users. The most frequent cause of an incorrect balance when you have
paid the wrong amount to an employee is remedied by carrying out a
QuickPay run for the employee. How far you can manually adjust other
balances depends on whether the balance is a predefined startup
balance or is userdefined.
You can freely adjust all user balances. However, the only predefined
balances that you can adjust are those which are not above other
balances in the balance hierarchy. You can adjust a pretax deduction
balance but not the Total Deductions balance. This is to protect the
integrity of predefined balances, by preventing users from adjusting
high level balances in isolation. To ensure balance integrity, whenever
you adjust a low level predefined balance, Oracle Payroll automatically
adjusts all related higher level balances as well.
Single threaded.
None apply.
Observations
.Can only perform balance adjustments for a single assignment at a
time.
Page 24
Balance Initialization
Enables the transfer of seeded and user balance values in to Oracle
Payroll for use by implementations which begin processing midfinancial year.
Single threaded but you can submit multiple balance initialization
batches ( which enables it to take advantage of multiple processors ).
None apply.
Observations
Creates balance adjustments within the system and also creates the
necessary latest balances.
Creates lots of Payroll and assignment action records. For each

payroll action created, there is a corresponding assignment action.
Therefore, the more data being loaded, the greater the number of
assignment action rows created. This has been known to create
problems with data distribution within the assignment actions table.
This could then have knock on affects to other Payroll processes
e.g. Payroll Run.
Good practice to break batch sizes up to about 10,000 lines per

batch. This needs to be experimented with but changing this value (
either up or down ) may affect the use and benefit of the internal
cache.
Can only be run once per assignment. All values therefore need to
be loaded at the same time.
If future Payroll actions exist then youre prevented from running

this process.
One of the slower Payroll processes ( because of the amount of

work its having to do ). Development has been able to get about
10,000 batch lines through per processor per hour.
Advisable to analyze statistics following the loading of large

batches.
Check out the Oracle Metalink Note 60057.1 for an excellent

summary of whats involved in setting up the balance initialization
process.
Page 25
Payroll Run Rollback

Payroll run rollbacks are useful when you have no need to keep any
record that a run occurred. When you roll the run back, the process
removes all the assignments and the run results. You cannot roll back
payroll processing for individuals or payrolls for which postrun
processing has occurred.
You can roll back a run for an employee when, for example, you should
never have processed the employee in the run. A rollback completely
removes an employee from a run, as if the processing had never
occurred.
Multi threaded when initiated via the SRS process, otherwise its a
single threaded process ( when initiated via the Form ).
THREADS
CHUNK_SIZE
CHUNK SHUFFLE
MAX_SINGLE_UNDO
Rollback of specific payroll processes

can be executed in two ways. A batch
process can be submitted from the
Submit Requests window. Alternatively,
you can rollback a specific process by
deleting it from the Payroll Process
Results or Assignment Process Results
windows. When you rollback from a
window this parameter controls the
commit unit size ( used to prevent the
form from locking up for too long ).
Observations
Removes all traces that the run actually took place ( removes run
results, assignment actions and latest balances etc ).
Can execute using a core process ( via concurrent manager ) or can

just delete the payroll action via the appropriate form. The
execution method determines whether the process is multi-threaded
or single threaded ( see above ).
The Payroll application stores latest balances and latest balance

minus one. If a payroll is rolled back over two or more consecutive
periods then latest balances will be lost.
Pre-Payments
The PrePayments process prepares the payments generated by the
Payroll Run for payment. It prepares payments for each assignment and
Page 26
inserts the results into PAY_PRE_PAYMENTS for each payment

method for an assignment.
The PrePayments process also:
Calculates the amount of money to pay through each payment

method for an assignment, and converts any currency if the
payment method is in a foreign currency.
Handles the preparation of third party payments.

For example, garnishments, court orders and child maintenance.
Third party payments are managed through the definition of special
payment methods for the employee.

Multi threaded.
THREADS
CHUNK_SIZE
CHUNK SHUFFLE
Observations
Not aware of any issues to do with this process.
QuickPay Pre-Payments
The PrePayments process prepares the payments generated by the
Quickpay for payment. It prepares payments for each assignment and
inserts the results into PAY_PRE_PAYMENTS for each payment
method for an assignment.
The PrePayments process also:
Calculates the amount of money to pay through each payment

method for an assignment, and converts any currency if the
payment method is in a foreign currency.
Handles the preparation of third party payments.

For example, garnishments, court orders and child maintenance.
Third party payments are managed through the definition of special
payment methods for the employee.

Single threaded.
Page 27

THREADS
CHUNK_SIZE
CHUNK SHUFFLE
Observations
Costing
The Costing process accumulates results for transfer to the General
Ledger and other systems. This process sorts the run results in
accordance with the information you have selected from the Cost
Allocation flexfield at all levels, by the following:
Company
Set of books
Cost centre
General Ledger
Labour distribution accounts
A major performance fix to the costing routine was introduced part of

the way through the Release 10 cycle ( see bug #653719 ). The new
version of the process resolves some known performance and deadlock
limitations of the original code. The change involved some redesign of
the costing process code as well as to make use of the AOL PL/Sql API
to perform flexfield validation. The previous version of the code made
use of the AOL C interface API for flexfield validation.
The new PL/Sql routine has been written so that it can coexist with the
original C code routine. A new parameter, COST_PLS_VAL, has been
created to control which version of the code is executed when running
the costing process ( see below ). When using the PL/Sql version of the
code, you have to create a suitable index on the
PAY_COST_ALLOCATION_KEYFLEX table. Appendix D - Costing
Index Determination, details how to do this.
Multi threaded.
THREADS
CHUNK_SIZE
CHUNK SHUFFLE
Page 28
COST_PLS_VAL
A new parameter used to control which

costing process is to be executed. If null
or N then the old C costing code is
executed otherwise the new PL/Sql
costing code is executed.
COST BUFFER SIZE
Determines the costing buffer size. This

parameter affects all cursors within the
costing code. A recommended setting
for this would be the maximum number
of run result values being costed for an
assignment. Of course, this would have
to be tested on a site by site basis.
Observations
When using the C version of the costing code, as long as your

costing flexfield definition has some required segments then the
process will make use of any indexes.
If the PL/Sql version of the code is run and no additional indexes

are created on the PAY_COST_ALLOCATION_KEYFLEX table
then the process may run slower than the C version of the process.
Appendix D - Costing Index Determination, details how to choose
what segments to index in this table.
In Release 11i the costing code has been combined in to the same
module. The determination whether to use the C or PL/Sql flexfield
logic is controlled by the setting of COST_PLS_VAL. By default
this will use the C code.
At one site using the new PL/Sql version of the code, a trace of the
costing process showed some timing differences between the CPU
and elapsed time when trying to retrieve a sequence value from the
PAY_COSTS_S sequence. This site had THREADS set to 36 ( 1.5
times the number of CPUs on the machine ). It was suggested that
the site increase the cache size for the sequence so as to alleviate
possible contention between processes. Increasing the cache size
improved performance but did not completely resolve the CPU to
elapsed timing differences. Other things to try include:
1.
Put SYS.SEQ$ in cache. This will prevent high reads of the

SEQ$ table.
2.
Maybe consider making the sequence noorder. This is just a

suggestion and I currently have nothing to be able to back this
up.
The PL/Sql version of the code uses the AOL PL/Sql flexfield
routines for validation of the new costing flexfields to be created.
This performs exactly the same validation as if you were entering
the structure via one of the application forms. What this means is
that all costing flexfield segment validation will be executed. It is
therefore important to ensure that any user defined table value set
validation has been correctly tuned. This is especially important if
the validation references a user defined view.
Page 29
Transfer To GL
If your installation includes Oracle General ledger, you can run the
transfer to GL process to transfer the results of the Costing process for
a payroll to the Accounting flexfield of Oracle General Ledger.
Multi threaded.
THREADS
CHUNK_SIZE
CHUNK SHUFFLE
TGL_DATE_USED
Observations
Whilst the main part of this process runs multi-threaded there is a

single-threaded phase at the end of processing
External & Manual Payments

Manual payments made to a specific employee can be recorded. This
has the effect of marking the prepayment as paid. The Payment process
take the unpaid prepayment values allocated to each payment type and
produce the required payment file.
Payments can be made externally using the External Payments form. If
you make a payment external to the system, the Magnetic Tape process
does not pay these.
Single threaded.
None apply.
Observations
Process creates a payroll and assignment action for the payment.
Created for one assignment at a time ( via the Form ).
Page 30
Magnetic Tape
The Magnetic Tape process generates the payment due and writes the
data to a file on magnetic tape. It is this tape that is taken to the bank for
payment.
First half of the process ( creating assignment actions ) multi threaded.
Second half of the process ( creating tape file ) single threaded.
THREADS
CHUNK_SIZE
CHUNK SHUFFLE
ADD_MAG_REP_FILES
The maximum number of additional

audit or report files the magnetic tape
process can produce.
Observations
Cheque Writer ( U.S. & U.K. )

Cheque Writer creates cheque assignment actions for each of the target
prepayments, subject to the restrictions of the parameters specified.
The target prepayments must be unpaidthat is, they never have been
paidor if they have been paid, then voided.
Multi threaded.
THREADS
CHUNK_SIZE
CHUNK SHUFFLE
Observations
Customers can decide on order of cheques and can modify SQL

statement in package. This could introduce performance problems.
The process executes an Oracle Report Writer report. This can be

modified by customers. This could introduce performance
problems.
Page 31
In the U.S. the Deposit Advice report is attached with the cheque.
This means a lot of balance retrieval is taking place ( performance
overhead ). The U.S. Deposit Advice report is very detailed and
contains lots of balance details.
Deposit Advice ( U.S. )

Prints deposit advices and statements of earnings for employees
receiving payments through NACHA.
Multi threaded.
THREADS
CHUNK_SIZE
CHUNK SHUFFLE
Observations
The deposit advice is an Oracle Report Writer report that makes

extensive use of PL/Sql procedures / functions.
Cash Process
Oracle Payroll enables you to choose Cash as a payment method and to
record cash payments to employee assignments. Oracle Payroll
automatically analyses cash payments into the largest denomination
notes and coins as part of the PrePayments process.
Multi threaded.
THREADS
CHUNK_SIZE
CHUNK SHUFFLE
Observations
Creates Payroll and assignment actions.
Page 32
RetroPay Process
The RetroPay process reruns the payroll calculations for all the periods
affected by the retroactive change. This payroll processing is held in
memory only and the results are not saved to the database. Instead, the
system calculates the difference between the original results and the
results using the new information. There are 3 versions of RetroPay.
Multi threaded.
Same as payroll run process.
Observations
The more periods having to be re-processed, the more work has to

be done and subsequently the longer the processing time.
Advance Pay
The Advance Pay process enables you to pay employees in advance for
holidays or other events. The process performs payroll runs for the
periods to be advanced, using all date effective information in place,
and stores the final net figure as the amount to be advanced. There are 2
versions of Advance Pay.
Multi threaded.
Same as payroll run process.
Observations
The more periods having to be re-processed, the more work has to

be done and subsequently the longer the processing time.
Multi-Threaded Archiver
A process to extract values within the database to archive tables that
can then be reported against. Is used in EOY processing globally.
FastFormulas define what data to extract snapshot values for.
Multi threaded.
Page 33

THREADS
CHUNK_SIZE
CHUNK SHUFFLE
Observations
May be able to help with user reporting ( if multiple reports need to

access common balance values ).
Sparse Matrix / Insignificant Run Results

In the payroll process the creation and accumulation of null run result
values can seriously affect the performance of the payroll tables.
In order to overcome this the Payroll Run can be configured so that it
does not create a Run Result for an Indirect Element Entry and its Run
Result Values if the Run Result Values are deemed to be 'Insignificant'.
By 'Insignificant' we mean run results or run result values which are
null, a number/money with a value 0 or 0.0, or it is a 'jurisdiction_code'
result value. (The 'jursidiction_code' result value is a special case in that
the run result can be treated as insignificant if the only run result value
that isn't insignificant is the jurisdiction_code result value.)
Insignificant Run Result Suppression
This is where if ALL of the result values calculated for an INDIRECT
run result are null or 0 (ignoring the jurisdiction_code result value) then the Run will not create that Run Result and its Run Result Values.
Sparse Matrix
This is where the run will not create a result value if its value is null.
Sparse Matrix is NOT a replacement for Insignificant Run Result
Suppression. They work independently from one another - although
Sparse Matrix will in effect avoid the creation of the result values that
'Suppress Indirect Run Results' would have avoided creating, but not
the RUN RESULTS.
For more details about this functionality and how to enable it please
refer to Metalink Note 368723.1.
Consolidation Sets
Consolidation sets are the means by which you label payroll runs for
further processing. This enables you to process the results from more
than one payroll in a single action. You need only produce one tape per
payment method for several payrolls, one set of reports and one set of
costing for the whole set.
Page 34
Observations
At some sites, the use of this feature has shown visible

performance improvements after a few payroll runs.
%_PAYMENTS Balance Database Item ( U.S. Only )

The U.S. payroll localization provides forms for the definition of
earnings and deduction elements. These in turn generate template
formulas which can be further enhanced by customers. In the past,
some of these formulas made reference to %_PAYMENTS balance
database items. Most of these references are no longer required in the
formulas and the earnings and deduction forms have been changed
accordingly. This does however mean that you may have existing
formulas which continue to make reference to these database items.
If any formulas make reference to %_PAYMENTS balance database
items in the default line or the assignment line within the formula
and, for assignment line references, the local variable is not used
anywhere else within the formula then it is okay to completely remove
the lines. This will prevent the payroll run flushing Run Result Values
from memory to the database when it doesnt need to. This will impact
on payroll performance.
For example, looking at the MEDICAL_OPTION_B_WITHHOLDING
formula the following lines can be removed:
DEFAULT for MEDICAL_OPTION_B_PAYMENTS
is 0
SOE_PAY = MEDICAL_OPTION_B_PAYMENTS
This is because SOE_PAY is not referenced anywhere else within the

formula and there are no remarks in the formula description indicating
that % _PAYMENTS have been used to force the flushing of Run
Result Values from memory to the database.
If you are in any doubt about which lines can be safely removed then
please contact Oracle support.
Continuous Calculation
The continuous calculation functionality allows payroll administrators
to spread the processing of a payroll over the payroll period. This
functionality is typically suited to those payrolls which remain fairly
static from period to period ( e.g. director payrolls and payrolls where
employee entitlements do not change much from period to period and
there are no time entry feeds ). Under the continuous calculation model
you could run your payroll at the start of the period. Any changes to a
persons data, made after the initial run and before the end of the
period, which would affect their salary entitlement will cause triggers to
fire which will mark the person for retry. The payroll can them be resubmitted later in the period to re-process all of those people who have
been marked for retry. This model means that you no longer have to
wait to run your main payroll at the end of your period. The triggers
Page 35
will be seeded by the localization teams but customers will be able to

add their own triggers ( using the Dynamic Trigger Definition form ).
When a person who is marked for retry is re-processed, the payroll run
will rollback their information and then re-calculate their entitlements.
If most of a payroll population have been marked for re-try then this
model of processing is probably not suitable ( e.g. for payrolls which
require regular time entry feeds which can differ from period to period
).
Hot Payroll Tables

Below are details of frequently accessed tables by action and process. It
is advisable to carefully consider the settings given to these tables in
order to ensure the optimal system performance.
Heavy Insert
Run Results ( Payroll Run )

Run Balances ( Payroll Run )
Balance Context Values ( Payroll Run )
Assignment Actions ( All Processes )
Payments ( Payments Process )
Costs ( Costing Process )
Heavy Update
Assignment Actions ( All Processes )

Latest Balances ( Payroll Run )
Heavy Read
Element Entries ( Payroll Run )

Latest Balances ( Payroll Run & Reports )
Balance Context Values ( All Processes )
Action Interlocks ( All Processes )
Heavy Select For Update
People ( All Processes )

Periods of Service ( All Processes )
Assignments ( All Processes )
Page 36
Tune The Benefits Application Setup & Procedures

A well set up, thought through and configured application will always
give better performance and response than one that has been deployed
without any consideration to the affects of design and implementation
decisions on other processes ( all other things, hardware etc, remaining
equal ).
Decisions made at the design stage of an implementation may sound
perfectly reasonable and could satisfy specific requirements, but unless
these are reviewed in the light of the whole system ( what associated /
subsequent processes may be affected by the way in which the system
is being set up ) then problems may be experienced by other parts of
the application.
This section looks at specific Benefits Application features and
processes and tries to give some guidance and lessons learnt about their
setup and ideas of things to try or to avoid in order to improve
performance.
As well as recommendations made in this document, there are a number
of useful documents on Oracle Metalink (
http://www.metalink.oracle.com ) under Top Tech Docs, Benefits (
Human Resource Management Systems section ), White Papers:
Self-Service Benefits Enrollment with Standard and Advanced

Benefits
Compensation Workbench Sample Setup
Practice Solution for Basic Enrollment Setup
Frequently Asked Questions About Implementing Oracle

HCM R11i Benefits
Converting Election Data to Oracle Standard and Advanced

Benefits
NOTE: Benefits has its own controlling batch process table

BEN_BATCH_PARAMETER. The HCM processes us
PAY_ACTION_PARAMETERS.
Compensation Object Design

Plan Design
Program/Plan Hierarchy
Try and minimize the number of plans not in program. By putting a
plan in a program you can minimize the hits to the database by
including business requirements at the program level which will
cascade to the lower levels.
Page 37
Eligibility/Electability
If you are NOT using derived factor MINIMUMs for participant
eligibility then you should leave the track ineligible flag off for
performance purposes. This prevents multiple writes for ineligible
compensation objects within the same program.
Eligibility has a top down hierarchy so by defining the broadest criteria
at the top and refining the criteria as you drill down you can find the
highest population ineligible at the highest level in the hierarchy to
reduce processing for participants.
Electability has a bottoms up determination. Define the most general at
highest level and restrict at the lowest levels.
Rates
Define rates at the highest possible common level to minimize
calculation and write processing. Avoid option in plan in program
(lowest level) as this has the highest processing times.
Rules
Create these at the lowest level possible. A person level rule, i.e. a
derived factor, will be fired off for every person processed verses a rate
or coverage rule that would only be fired once for the associated
compensation level.
One Business Group, Multiple Organizations
If you have a corresponding plan for each organization you will be
evaluating each plan regardless because the application stripes by
Business Group. To get around this define a role type for an
organization as Owner and attach this to a program. This allows
programs that have a corresponding organization owner to be pulled
only and not all the others.
Online Processes
Online Life Events Process
This process allows the benefits administrator to process life events in
real-time. If this processed life event results in the creation of electable
benefit choices for this person you can then enroll them into one or
more benefit plans for which they are eligible based on the processed
life event.
Single threaded
Observations
Links to Participant Management process
Page 38
Links to Participant Enrollment Process
Participant Enrollment Process

This process registers employees and other eligible participants into
benefit plans and options. It includes recording contribution rates and
coverage amounts and entering dependents and beneficiaries of the
primary participant into the system.
Single threaded
Observations
Make sure the CBO statistics are updated on a regular basis.
Batch Processes
Back-out Life Events Process
This process marks all electable choices and related information, such
as payroll contributions, dependent designations and communications
with a status of backed-out. Life events that have a status of started or
processed can be backed out.
Multi threaded.
THREADS
CHUNK_SIZE
MAX_ERRORS_ALLOWED
Observations
Close Action Items Process

This process closes any required or optional action items that have not
been completed by the participant. It also deletes any suspended
enrollments for the persons who meet the criteria you specify.
Page 39

Single threaded.
Observations
Close Enrollments Process

This process closes a persons enrollment after elections have been
made and to resolve any incomplete election information.
Multi threaded
THREADS
CHUNK_SIZE
MAX_ERRORS_ALLOWED
Observations
Default Enrollment Process

This process enrolls a participant into a plan when the participant fails
to make an election by a certain date and default enrollments have been
defined for a plan or option. This process will also enroll a participant
in a plan or option that has been defined as mandatory if the participant
fails to elect this required plan or option.
Multi threaded
THREADS
CHUNK_SIZE
MAX_ERRORS_ALLOWED
Page 40
Observations
Determine Communications Process

This process generates communications that are not automatically
generated based on the rules of the plan design.
Multi threaded
THREADS
CHUNK_SIZE
MAX_ERRORS_ALLOWED
Observations
Maintain Designee Eligibility Process

This process determines weather a designee has aged out of a benefit.
If so, they become ineligible for the benefits coverage based on an age
change.
Single threaded
Observations
Recalculate Participant Values Process

This process recalculates benefit amounts, participant rates, premiums
and element entries for a group of participants based on the new setup
that is effective as of the date the process is run. This process is for
Standard Benefits customers only. Oracle Advanced Benefits customers
can configure an Administrative life event to achieve the same
functionality.
Page 41

Multi threaded
THREADS
CHUNK_SIZE
MAX_ERRORS_ALLOWED
Observations
Person based fast formula can dramatically impact through put

when running large populations
Setting logging to yes, from the submission form, creates large

amounts of data and will cause extent and rollback errors when
running more than a couple of people through. Setting this to yes
also dramatically slows down the process because of the writes to
the log file. This should be set to no unless you are trying to debug
specific issues.
Performance is intimately tied to plan design discussed above.
May want to update statistics every 10-15 minutes during on an

initial run in a fresh database. This will allow the process to utilize
up to date cost effective access paths.
Participation Process: Life Events

This process determines eligibility and electability based on predefined
criteria for participants who have had a defined life event triggered.
This process also determines eligibility for dependents and beneficiaries
of eligible participants. Rates, Coverage, Premiums and certifications
are determined within this process as well.
Multi threaded
THREADS
CHUNK_SIZE
MAX_ERRORS_ALLOWED
Observations


Page 42

specific issues.

Participation Process: Scheduled

This process determines eligibility and electability based on predefined
criteria for participants at a scheduled time (i.e. open enrollment). This
process also determines eligibility for dependents and beneficiaries of
eligible participants. Rates, Coverage, Premiums and certifications are
determined within this process as well.
Multi threaded
THREADS
CHUNK_SIZE
MAX_ERRORS_ALLOWED
Observations


specific issues.

Participation Process: Selection

This process determines eligibility for select participants for selected
compensation objects, but does not create electable choices. You can
choose to save or rollback the eligibility results.
Page 43

Multi threaded
THREADS
CHUNK_SIZE
MAX_ERRORS_ALLOWED
Observations


specific issues.

Participation Process: Temporal

This process determines temporal life events based on the derived
factors of compensation level, percent of full-time employment, hours
worked in period, age, length of service and combination age and
length of service.
Multi threaded
THREADS
CHUNK_SIZE
MAX_ERRORS_ALLOWED
Observations


Page 44

specific issues.

Premium Calculation Process

This process calculates the amount paid by the benefit plan sponsor to
the supplier of a benefit. The premiums are calculated on a perparticipant basis or based on the total participants enrolled in a plan or
the total volume of elected coverage.
Multi threaded
THREADS
CHUNK_SIZE
MAX_ERRORS_ALLOWED
Observations
INITRANS Table Setting

Running Benefits Batch Processes using multiple processes ( a
THREADS setting of more than 1 ) requires you to also amend the
INITRANS definition accordingly for some key tables and indexes.
Without doing this, you may experience locking contention
between sub-processes and differences between CPU and elapsed
timings for certain benefits processing SQL statements.
Details of the specific Benefits tables that are affected by can be
found in Appendix C - INITRANS & PCTFREE Settings.
Page 45
Appendix A - PAY_ACTION_PARAMETERS Settings

Payroll action parameters are system level parameters that control
aspects of the Oracle Payroll batch processes. It is important to
recognize that the effects of setting values for specific parameters may
be system wide. The text indicates where parameters are related to
specific processes.
Action Parameter Values

Predefined values for each parameter are supplied with the system, but
you can override these values as part of your initial implementation and
for performance tuning.
Action parameter values are specified by inserting the appropriate rows
into the following table: PAY_ACTION_PARAMETERS, which has
two columns:
PARAMETER_NAME NOT NULL VARCHAR2(30)
PARAMETER_VALUE NOT NULL VARCHAR2(80)
The payroll batch processes read values from this table on startup, or
provide appropriate defaults, if specific parameter values are not
specified.
Page 46
Summary of Action Parameters

The following table shows user enterable action parameters and values
with any predefined default value.
Parameter
Parameter
Value
Default
ADD_MAG_REP_FILES
BAL BUFFER SIZE
BEE_INTERVAL_WAIT_SEC
Additional Magnetic Files

Bal Buffer Size
Batch Element Entry
Polling Interval
BEE Database Lock Polling
Interval
BEE Database Lock Timeout
Batch Element Entry
Timeout
Shuffle Chunk processing
Chunk Size
Cost Buffer Size
Use ID Mode of KeyFlex
API in Costing
Costing Process use
flexfield validation api
Data Migrator Mode
Data Pump Disable
Continuous Calculation
Triggers
Data Pump Disable Oracle
Applications Auditing
Data Pump Disable Lookup
Checks
Data Pump Purge Chunk
Size
EE Buffer Size
FastFormula Maximum Open
Formula Cursors
Sleep time for Disable
HCM Access
Data Migrator Debug Level
for Logfle Output
1 or more
1 or more
1 or more
4
30
2
0 or more
0 or more
1 or more
0
600
Y
1
1
Y
N
20 (10)
20
N
Max
Value
BEE_LOCK_INTERVAL_WAIT_SEC
BEE_LOCK_MAX_WAIT_SEC
BEE_MAX_WAIT_SEC
CHUNK SHUFFLE
CHUNK_SIZE
COST BUFFER SIZE
COST_API_IMODE
COST_PLS_VAL
DATA_MIGRATOR_MODE
DATA_PUMP_DISABLE_CONT_CALC
DATA_PUMP_NO_FND_AUDIT
DATA_PUMP_NO_LOOKUP_CHECKS
DATA_PUMP_PURGE_CHUNK_SIZE
EE BUFFER SIZE
FF_MAX_OPEN_CURSORS
HRLEGDEL_SLEEP
HR_DM_DEBUG_LOG
HR_DM_DEBUG_PIPE
HR_DU_DEBUG_LOG
HR_DU_DEBUG_PIPE
HR_GL_SYNC_DEBUG
INTERLOCK
JP_DIM_EXC_REV_FLAG
JRE_LIBRARY
LOGGING
LOG_AREA
LOG_ASSIGN_END
LOG_ASSIGN_START
LOW_VOLUME
MAX SINGLE UNDO
MAX_ERRORS_ALLOWED
Data Migrator Debug Level

for Pipe Output
Data Uploader Debug Level
for Logfle Output
Data Uploader Debug Level

for Pipe Output
HR Auto Orgs Debug Level
Interlock
JP Balance Dimension :
Exclude Reversal/Reversed
Results
JRE Library Path
Logging Category
Logging Area
Assignment ID for End of
Logging
Assignment ID for Start
of Logging
Low Volume Optimizer
Setting
Max. no. of asg. actions
for form rollback of
payroll action
Maximum Errors Allowed
or N
16000
or more
or N
1000
16000
1000
Y or N
P, Y or N
Y or N
N
N
Y or N
Y or N
1 5000
500
5000
1 or more
32 - 128
40
128
1000
128
0 or more
10
:INFO
:SUMM
:ROUT
:PARA
:FAIL
:SUMM
:FAIL
:INFO
:SUMM
:ROUT
:PARA
:FAIL
:SUMM
:FAIL
NORMAL or
DEBUG
Y or N
Y or N
NORMAL
N
N
See Later
See Later
See Later
See Later
Y or N
1 or more
0 or more
N (for DB
9.0 and
above)
50
CHUNK_SIZ
E or 20
(if no
chunk
Page 47
MAX_ITERATIONS
Maximum Iterations
allowed per Run Action
Print Files
Process Timeout
PRINT_FILES
PROCESS_TIMEOUT
PUMP_DEBUG_LEVEL
PUMP_DT_ENFORCE_FOREIGN_LOCK
S
PURGE_SKIP_TERM_ASG
PURGE_TIMEOUT
RANGE_PERSON_ID
REMOVE_ACT
REPORT_URL
RESET_PTO_ACCRUALS
RETRO_DELETE
RR BUFFER SIZE
RRV BUFFER SIZE
RUN_XDO
RR Buffer Size
RRV Buffer Size
Run XML Publisher for
Report Generation
Standard Payroll File
Names
STD_FILE_NAME
SUPPRESS_INSIG_INDIRECTS
Suppress Insignificant
Indirect Results
Quantum Cache Size
Override Quantum Version
Checking
Storage area for Taxation
Details (Quantum)
Quantum Debugging Flag
Override Location for Tax
Libraries (Quantum)
TAX_CACHE_SIZE
TAX_CHECK_OVERRIDE
TAX_DATA
TAX_DEBUG_FLAG
TAX_LIBRARIES
TGL_DATE_USED
TGL_REVB_ACC_DATE
THREADS
TRACE
TRACE_LEVEL
TR_BUFFER_SIZE
USER_MESSAGING
US_ADVANCED_WAGE_ATTACHMENT
UTF8_RESTRICTION_MODE
Data Pump Debug Level

Enforce Date-Track
Foreign Key Locking When
Running Data Pump
Skip Terminated
Assignments in Purge
Purge Timeout
QuickPay Polling Interval
QuickPay Timeout
Process utilize person id
in Range table
Remove Report Assignment
Actions
URL of Reports
Reset PTO Accruals
Delete Internal Retropay
Results
Transfer to GL Process
transfer on date earned
Accounting Date used for
Reversals and Balance
Adjustments
Threads
Trace
Trace Level
Taxability Rules Buffer
Size
User Messaging
Advanced Wage Attachment
Enabled
UTF8 Restriction Mode
0 or more
Y or N
0 or more
size)
(20)
15
Y
No
Timeout
See Later
Y or N
Y or N
0
1
1
Y
0
2
300
N
or
or
or
or
more
more
more
N
Y or N
Y or N
Now a
legislation
rule
1 or more
1 or more
Y or N
Y or N
20
30
Y
Y or N
N (if not
overridde
n by
legislati
ve rule)
N
0 or more
Y or N
0
N
1000
1000
See Later
Y or N
N
$PAY_TOP/
vendor/qu
antum/lib
E
C or P
1 or more
Y or N
1 (3)
N
100 or
above
Y or N
Y or N
500
BYTE or
CHAR or
UNRESTRICTE
D
BYTE
Parallel Processing Parameters

Threads
Parameter Name: THREADS
Parameter Value: 1 or more
Default Value: 1
Oracle Payroll is designed to take advantage of multiprocessor
machines. This means that you can improve performance of your batch
Page 48
processes by splitting the processing into a number of threads. These

threads, or subprocesses will run in parallel.
When you submit a batch process to a concurrent manager the
THREADS parameter will determine the total number of subprocesses
that will run under the concurrent manager. The master process will
submit (THREADS 1) subprocesses.
Set this parameter to the value that provides optimal performance on
your server. The default value, 1, is set for a single processor machine.
On multiprocessor machines set THREADS to be less than or equal to
the number of processors available.
Attention: The concurrent manager must be defined to allow the
specified number of subprocesses to run concurrently. This is a task
for your Applications System Administrator.
Chunk Size
Parameter Name: CHUNK_SIZE
Parameter Value: 1 16000
Default Value: 20
Size of each commit unit for the batch process. This parameter
determines the number of assignment actions that are inserted during
the initial phase of processing and the number of assignment actions
that are processed at one time during the main processing phase.
Note: This does not apply to the Cheque Writer/Check Writer,
Magnetic Tape or RetroPay processes.
During the initial phase of processing this parameter defines the array
size for insert. Large chunk size values are not desirable and the default
value has been set as a result of benchmark tests.
Each thread processes one chunk at a time.
Shuffle Chunk processing
Parameter Name: CHUNK SHUFFLE
Parameter Value: Y or N
Default Value: N
Randomizes the processing order of chunks of assignment actions to be
processed rather than processing them sequentially.
QuickPay Parameters
QuickPay Polling Interval
Parameter Name: QUICKPAY_INTERVAL_WAIT_SEC
Default Value: 2
QuickPay Polling Interval.
QuickPay Timeout
Page 49
Parameter Name: QUICKPAY_MAX_WAIT_SEC

Default Value: 300
QuickPay Timeout.
Array Select, Update and Insert Buffer Size Parameters

The following parameters control with buffer size used for in
memory array processing. The value determines the number of rows
the buffer can hold.
Note: These parameters apply to the Payroll Run process only.
When you set values for these parameters you should note that there is
a tradeoff between the array size, performance and memory
requirements. In general, the greater the number of rows fetched,
updated or inserted at one time, the better the performance. However,
this advantage declines at around 20 for the CHUNK_SIZE parameter.
Therefore, the improvement between values 1 and 20 is large, while
between 20 and 100, it is small. Note also that a higher value means
greater memory usage. For this reason, it is unlikely that you will gain
any advantage from altering the default value.
Chunk Size
Default Value: 20
Size of each commit unit for the batch process. As before.
RR Buffer Size
Parameter Name: RR BUFFER SIZE
Default Value: 20
Size of the Run Result buffer used for array inserts and updates: one
row per Run Result.
RRV Buffer Size
Parameter Name: RRV BUFFER SIZE
Default Value: 30
Size of the Run Result Value buffer used for array inserts and updates:
one row per Run Result Value. Typically this will be set to (RR
BUFFER SIZE * 1.5).
Bal Buffer Size
Parameter Name: BAL BUFFER SIZE
Default Value: 30
Size of the Latest Balance buffer used for array inserts and updates: 1
row per Latest Balance.
Page 50
EE Buffer Size
Parameter Name: EE BUFFER SIZE
Default Value: 40
Size of the buffer used in the initial array selects of Element Entries,
Element Entry Values, Run Results and Run Result Values per
assignment.
Taxability Rules Buffer Size
Parameter Name: TR_BUFFER_SIZE
Parameter Value: 100 or above
Default Value: 500
Size of the buffer used in array selects from the
PAY_TAXABILITY_RULES table within the Run process.
Costing Specific Parameters

Cost Buffer Size
Parameter Name: COST BUFFER SIZE
Default Value: 20
Size of the buffer used in the array inserts and selects within the
Costing process.
Transfer to GL Process transfer on date earned
Parameter Name: TGL_DATE_USED
Parameter Value: E
Default Value:
As part of the transfer to GL Process, accounting date set to Date
Earned ( if E ) otherwise will default to effective date.
Use ID Mode of KeyFlex API in Costing
Parameter Name: COST_API_IMODE
Default Value: N
If the COST_API_IMODE is set to 'Y' the FND_FLEX_KEYVAL API
is called in 'I' mode which means that all (enabled) segments are passed
to the Costing API.
Costing Process use flexfield validation api
Parameter Name: COST_PLS_VAL
Default Value: Y
There are now 2 alternative implementations of the flexfield validation
routines:
pycosaolplsql() - uses the aol fnd_flex_keyval pl/sql api.
Page 51
pycosaolcint() - uses the aol fdfkfa C interface.
By default the pycosaolplsql() routine is used to perform the flexfield

validation. The customer can tune the costing process to use the
pycosaolcint() routine (instead of the pycosaolcint() routine) by setting
COST_PLS_VAL to N in pay_action_parameters.
Magnetic Tape Specific Parameters

Additional Magnetic Files
Parameter Name: ADD_MAG_REP_FILES
Default Value: 4
The maximum number of additional audit or report files the magnetic
tape process can produce.
Quantum Specific Parameters

Override Quantum Version Checking
Parameter Name: TAX_CHECK_OVERRIDE
Default Value: N
Override Quantum Version Checking.
Storage area for Taxation Details (Quantum)
Parameter Name: TAX_DATA
Parameter Value:
Default Value:
Storage area for Taxation Details (Quantum).
Quantum Debugging Flag
Parameter Name: TAX_DEBUG_FLAG
Default Value: N
Quantum Debugging Flag.
Quantum Cache Size
Parameter Name: TAX_CACHE_SIZE
Default Value: 0
Quantum Cache Size
Override Location for Tax Libraries (Quantum)
Parameter Name: TAX_LIBRARIES
Parameter Value:
Default Value: $PAY_TOP/vendor/quantum/lib
Location of Quantum Tax Libraries
Page 52
Data Pump Parameters

Data Pump Debug Level
Parameter Name: PUMP_DEBUG_LEVEL
Parameter Value: AMD, RRP, GID, MSG, ROU,
WCD, STK, EXT, RRI
Default Value: No Data Pump Debugging
Set Use this parameter to turn on logging for tracking errors generated
by the Data Pump process.
Data Pump Logging Categories
Suggestion: These first three options are likely to be the most useful to
you.
- AMD API Module Debug (enables trace output from API).
- RRP Range Row Processing logging (logs the number of errors that
occurred for each unit of work, or range)
- GID Get_id function failure information (logs failures in func-tions
that map user values to IDs)
- MSG Output specific logging messages
- ROU Routing information (entry to and exit from procedures)
- WCD Wrapper cache debug logging
- STK Stack dump logging (trace information on failure)
- EXT Exit information (trace information on success)
- RRI Range row insert logging
- CLF send messages to concurrent log file
- BLI show batch_line information
You can combine any number of these options by concatenating the
values, separated by a colon. For example:
update pay_action_parameters
set
parameter_value = MSG:RRI:RRP
where parameter_name = PUMP_DEBUG_LEVEL;
Note: When you enable data pump logging options, output is produced
for every thread that may be running. Use the PYUPIP command to
view this output (for more information see Using PYUPIP - Oracle
HRMS Metalink Note: 130374.1).
Data Pump Disable Continuous Calculation Triggers
Parameter Name: DATA_PUMP_DISABLE_CONT_CALC
Default Value: N
Page 53
This parameter is used to disable the Continuous Calculation

functionality during Data Pump processing.
Data Pump Disable Oracle Applications Auditing
Parameter Name: DATA_PUMP_NO_FND_AUDIT
Default Value: N
This parameter is used to disable the Auditing functionality during Data
Pump processing. This can be used to improve the throughput of the
data pump.
Data Pump Disable Lookup Checks
Parameter Name: DATA_PUMP_NO_LOOKUP_CHECKS
Default Value: N
This parameter is used to disable the Lookup Checks during Data Pump
processing. This can be used to improve the throughput of the data
pump.
Data Pump Purge Chunk Size
Parameter Name: DATA_PUMP_PURGE_CHUNK_SIZE
Default Value: 500
See Chunk Size above.
Data Migrator Mode
Parameter Name: DATA_MIGRATOR_MODE
Parameter Value: P, Y or N
Default Value: N
This parameter can be used to override the Data Migrator mode used in
Data Pump, this only takes effect if the Data Migrator mode is
originally set to N.
Enforce Date-Track Foreign Key Locking When Running Data
Pump
Parameter Name: PUMP_DT_ENFORCE_FOREIGN_LOCKS
Default Value: Y
This parameter is used to control whether Foreign Key Locking is
enforced when an api is called from a Data Pump session.
Data Migrator / Data Upload Parameters

Data Migrator Debug Level for Logfle Output
Parameter Name: HR_DM_DEBUG_LOG
Parameter Value: :INFO,
:SUMM,
:ROUT,
Page 54
:FAIL,
:PARA
Default Value:
:SUMM,
:FAIL
This parameter is used to control the level of output in the Data

Migrator process. The : character is used to delimit the debug level
values. Valid values are as follows:
-
INFO Detailed information written to the log file
SUMM Summary information written to the log file
ROUT Location in code from where the log entry was raised
is written to the log file
PARA Parameter values written to the log file
FAIL Error messages written to the log file
Data Migrator Debug Level for Pipe Output

Parameter Name: HR_DM_DEBUG_PIPE
Parameter Value:
Default Value:
No longer used
Data Uploader Debug Level for Logfle Output
Parameter Name: HR_DU_DEBUG_LOG
Parameter Value: :INFO,
:SUMM,
:ROUT,
:FAIL,
:PARA
Default Value:
:SUMM,
:FAIL
See Data Migrator Debug Level for Logfle Output.

Data Uploader Debug Level for Pipe Output
Parameter Name: HR_DU_DEBUG_PIPE
Parameter Value:
Default Value:
No longer used
Error Reporting Parameters

In every pay cycle you would expect some errors to occur in processing
individual assignments, especially in the Payroll Run. These errors are
usually caused by incorrect or missing data in the employee record. For
practical reasons, you would not want the entire run to fail on a single
assignment failure. However, if many assignments generate error
conditions one after the other, this will usually indicate a serious
problem, and you will want to stop the entire process to investigate the
Page 55
cause. For processes that support assignment level errors you can use
the MAX_ERRORS_ALLOWED parameter to control the point at
which you want to stop the entire process to investigate these errors.
The processes that use this feature are:
Payroll Run
PrePayments
Costing
Rollback
Parameter Name: MAX_ERRORS_ALLOWED
Default Value: CHUNK_SIZE or 20 (if no chunk size)
The number of consecutive actions that may have an error before the
entire process is given a status of Error.
Note: This parameter affects each thread. For example, if
MAX_ERRORS_ALLOWED is set to 10 and THREADS is set to 3,
this could result in the whole process raising up to 27 errors without
terminating with status error. The first thread to reach 10 errors will
cause the whole process to terminate.
Rollback Specific Parameters

Rollback of specific payroll processes can be executed in two ways. A
batch process can be submitted from the Submit Requests window.
Alternatively, you can roll back a specific process by deleting it from
the Payroll Process Results window or the Assignment Process Results
window. When you roll back from a window this parameter controls
the commit unit size.
Max. no. of asg. actions for form rollback of payroll action
Parameter Name: MAX_SINGLE_UNDO
Default Value:50
The maximum number of assignment actions that can be rolled back in
a single commit unit when rollback is executed from a form. Although
you can change the default limit, you would usually use the Rollback
process from the SRS screen if it is likely to be breached.
Payroll Process Logging

During installation and testing of your Oracle Payroll system you may
need to turn on the detailed logging options provided with the product.
Use the LOGGING parameter to provide a large volume of detailed
information that is useful for investigating problems.
Detailed logging options should only be switched on when you need to
investigate problems that are not easily identified in other ways. The
logging activities will have an impact on the overall performance of the
process you are logging. Usually, this feature is needed during your
Page 56
initial implementation and testing before you go live. In normal

operation you should switch off detailed logging.
Attention: If you need to contact Oracle Support for assistance in
identifying or resolving problems in running your payroll processes,
you should prepare your log file first. Define the Logging
Category, Area and range of Assignments and then resubmit the
problem process.
Logging Categories
Logging categories define the type of information included in the log.
This lets you focus attention on specific areas that you consider may be
causing a problem. You can set any number of these by specifying
multiple values:
- G General (no specific category) logging information.
Output messages from the PY_LOG macro for general information.
This option does not sort the output and you should normally choose a
list of specific categories.
M Entry or exit routing information
Output information to show when any function is entered and exited,
with messages such as In: pyippee, Out : pyippee. The information
is indented to show the call level, and can be used to trace the path
taken through the code at function call level. Often, this would be
useful when attempting to track down a problem such as a core dump.
P Performance information
Output information to show the number of times certain operations take
place at the assignment and run levels and why the operation took
place. For example, balance buffer array writes.
E Element entries information
Output information to show the state of the inmemory element entry
structure, after the entries for an assignment have been fetched, and
when any item of the structure changes; for example, addition of
indirects or updates. This also shows the processing of the entry.
L Balance fetching information
Output information to show the latest balance fetch and subsequent
expiry stage.
B Balance maintenance information
Output information to show the creation and maintenance of in
memory balances
- I Balance output information
Output information to show details of values written to the database
from the balance buffers.
Page 57
R Run results information

Output information to show details of run results and run result values
written to the database from the Run Results or Values buffer.
F Formula information
Output information to show details of formula execution. This includes
formula contexts, inputs and outputs.
C C cache structures information.
Output information to show details of the payroll cache structures and
changes to the entries within the structure.
Q C cache query information
Output information to show the queries being performed on the payroll
cache structures.
S C Cache ending status information
Output information to show the state of the payroll cache before the
process exits, whether ending with success or error. Since much of the
logging information includes id values, this can be used to give a cross
reference where access to the local database is not possible.
V Quantum ( U.S. Tax ) Information
Output Quantum logging information.
T PL/SQL Output
Output shows more detail related to PL/SQL calls.
Z PL/SQL Output
Output shows breakout of PL/SQL calls.
Logging Parameters
Logging Category
Parameter Name: LOGGING
Parameter Value: G, M, P, E, L, B, I, R, F,
C, Q, V, S, Z, T
Default Value: No logging
During installation and testing of your Oracle Payroll system you may
need to turn on the detailed logging options provided with the product.
Use the LOGGING parameter to provide a large volume of detailed
information that is useful for investigating problems.
Detailed logging options should only be switched on when you need to
investigate problems that are not easily identified in other ways. The
logging activities will have an impact on the overall performance of the
process you are logging. Usually, this feature is needed during your
Page 58
initial implementation and testing before you go live. In normal

operation you should switch off detailed logging.
Logging Area
Parameter Name: LOG_AREA
Parameter Value: Function to start logging
Default Value: No default
Specifies the area of code logging takes place for. The values
correspond to c-code entries in the form PY_ENTRY(env, "pyipppr");
where "pyipppr" is the functional area that will have logging enabled.
Assignment ID for Start of Logging
Parameter Name: LOG_ASSIGN_START
Parameter Value: Assignment to start logging
Default Value: All assignments
Specifies the Assignment id that logging starts on.
Assignment ID for End of Logging
Parameter Name: LOG_ASSIGN_END
Parameter Value: Assignment to end logging,
including this one
Default Value: All assignments
Specifies the Assignment id that logging ends on.
Output Log File

When you enable the logging option the output is automatically
included in the log file created by the concurrent manager. You can
review or print the contents of this log file.
Except for the General category the log file will contain information in
a concise format using id values. This keeps the size of the log file to a
minimum while providing all the technical detail you need.
To help you understand the output for each logging category, other than
G and M, the log file will contain a header indicating the exact
format.
Batch Element Entry Parameters

Batch Element Entry Polling Interval
Parameter Name: BEE_INTERVAL_WAIT_SEC
Default Value: 2
This parameter controls the amount of time between polling the BEE
Concurrent manager to detect its status.
Page 59
Batch Element Entry Timeout

Parameter Name: BEE_MAX_WAIT_SEC
Default Value: 600
This parameter controls the amount of time allowed for polling the BEE
Concurrent manager to detect its status before the polling times out.
BEE Database Lock Polling Interval
Parameter Name: BEE_LOCK_INTERVAL_WAIT_SEC
Default Value: 0
This parameter controls the interval between attempts to update or
insert element entries via the BEE process.
BEE Database Lock Timeout
Parameter Name: BEE_LOCK_MAX_WAIT_SEC
Default Value: 0
This parameter controls the amount of time allowed before the BEE
update or insert of element entries times out.
Miscellaneous Parameters
User Messaging
Parameter Name: USER_MESSAGING
Parameter Value: Y/N
Default Value: N
Set this to parameter to Y to enable detailed logging of user readable
information to the pay_message_lines table. This information includes
details about the elements and overrides that are processed during the
Payroll Run.
Note: This information is useful when you are investigating problems,
but you may find that it is too detailed for normal working.
Maximum Iterations allowed per Run Action
Parameter Name: MAX_ITERATIONS
Parameter Value:
Default Value:
Used within the iterative engine to determine the number of iterations
to do before making the best guess.
Standard Payroll File Names
Parameter Name: STD_FILE_NAME
Default Value: N
Standard Payroll File Names.
Page 60
- Y If standard file names are required i.e. want output files to be in the
format p<request_id>.<extension>
- N If file names do not need to be standard i.e. file names can be in the
format <requestor>.<request_id>
Trace
Parameter Name: TRACE
Parameter Value: Y/N
Default Value: N
Set this parameter to Y to enable the database trace facility. Oracle
trace files will be generated and saved in the standard output directory
for your platform. Trace only applies to application C processes. The
following processes arent covered by this parameter:
Reversals
Balance Adjustments
External / Manual Payments
Payroll Rollback via Form
Mark For Retry
Warning: Only use the trace facility to help with the investigation of
problems. Setting the value to Y will cause a significant deterioration
in database performance. If you experience a significant problem with
the performance of your payroll processes, you should always check
that you have reset this parameter to the default value N.
HR Auto Orgs Debug Level
Parameter Name: HR_GL_SYNC_DEBUG
Parameter Value: NORMAL or DEBUG
Default Value: NORMAL
This parameter controls the debug level in the process that synchronizes
organizations between GL and HR. Set the value to DEBUG to turn
debugging on.
Sleep time for Disable HCM Access
Parameter Name: HRLEGDEL_SLEEP
Default Value: 10
When HRGLOBAL is being run the system functionality is temporarily
disabled. This parameter controls the frequency with which the system
is polled to determine whether HRGLOBAL is complete. It specifies
the number of seconds between two successive loops of the program to
reduce CPU usage.
FastFormula Maximum Open Formula Cursors
Parameter Name: FF_MAX_OPEN_CURSORS
Parameter Value: 32 - 128
Default Value: 128
This parameter defines the maximum number of formula cursors that
are kept open within Fast Formula caches.
Page 61
Interlock
Parameter Name: INTERLOCK
Default Value: N
If this parameter is set to Y the assignment action creation phase of the
payroll processes will produce output for each assignment showing the
list of assignments belonging to the payroll that will and will not be
processed.
Enabling this parameter results in more work being performed - and
hence impacts performance. For this reason we only recommend
setting this parameter for debugging purposes.
JP Balance Dimension : Exclude Reversal/Reversed Results
Parameter Name: JP_DIM_EXC_REV_FLAG
Default Value: N
Used in JP sql script (run after perlegjp.pdt ) that deletes
PAY_DIMENSION_ROUTES entries, if this parameter is set to Y the
script does not delete entries that use the Exclude Reversal dimension.
JRE Library Path
Parameter Name: JRE_LIBRARY
Parameter Value:
Default Value:
Low Volume Optimizer Setting
Parameter Name: LOW_VOLUME
Default Value: N (for DB 9.0 and above)
If this parameter is set to Y then the balance user exit and database item
definitions are forced to use a RULE optimizer hint.
Setting this parameter should ensure that balance statements are
executed with optimum explain plans.
Print Files
Parameter Name: PRINT_FILES
Default Value: Y
Process Timeout
Parameter Name: PROCESS_TIMEOUT
Default Value: No Timeout
Used in the Run Balance generation process to determine how long (in
minutes) to allow before the process times out. If no value is entered
then there will be no timeout limit.
Page 62
Skip Terminated Assignments in Purge

Parameter Name: PURGE_SKIP_TERM_ASG
Default Value: N
This parameter determines whether the purge process includes
terminated assignments.
Purge Timeout
Parameter Name: PURGE_TIMEOUT
Default Value: 0
Time allowed (in seconds) before the purge process times out.
Process utilize person id in Range table
Parameter Name: RANGE_PERSON_ID
Default Value: N
If this parameter is set to Y then various processes will use the
person_id column in pay_population_ranges which should result in
improved performance in the assignment action creation phase of those
processes
Remove Report Assignment Actions
Parameter Name: REMOVE_ACT
Default Value: Y
This parameter is used in magnetic tape process to control whether
Magnetic Tape Report Actions are removed once processing has
completed, if the value is Y then the actions will be removed.
This keeps the number of rows held in pay_assignment_actions to a
minimum.
URL of Reports
Parameter Name: REPORT_URL
Parameter Value:
Default Value:
URL location where payroll process report output files will be written.
Reset PTO Accruals
Parameter Name: RESET_PTO_ACCRUALS
Default Value: N
This parameter determines whether the PTO accruals for an assignment
should be recalculated from the beginning.
Delete Internal Retropay Results
Page 63
Parameter Name: RETRO_DELETE

Parameter Value: Now a legislation rule
Default Value:
If this parameter is set the retropay process updates run results to a
status of B rather than deleting them. This is to improve performance of
the process.
No longer used replaced with a legislation rule.
Run XML Publisher for Report Generation
Parameter Name: RUN_XDO
Default Value: Y
Suppress Insignificant Indirect Results
Parameter Name: SUPPRESS_INSIG_INDIRECTS
Default Value: N
If this parameter is set indirect run results with no significant result
values (e.g. all null or zero) are not created.
There is a corresponding legislation rule that if set will override this
action parameter.
Accounting Date used for Reversals and Balance Adjustments
Parameter Name: TGL_REVB_ACC_DATE
Parameter Value: C or P
Default Value: P
This parameter determines whether the Transfer to GL process uses
effective_date of the costing process as the accounting_date for balance
adjustments and reversals rather than the effective_date of the balance
adjustment/reversal. This avoids costs for balance
adjustments/reversals being posted in closed GL periods.
Trace Level
Parameter Name: TRACE_LEVEL
Parameter Value:
Default Value:
This parameter sets the level of db trace information generated if
tracing has been enabled for the process.
Advanced Wage Attachment Enabled
Parameter Name: US_ADVANCED_WAGE_ATTACHMENT
Default Value:
This parameter controls whether Advanced Wage Attachment
functionality has been enabled.
UTF8 Restriction Mode
Page 64
Parameter Name: UTF8_RESTRICTION_MODE

Parameter Value: BYTE or CHAR or UNRESTRICTED
Default Value: BYTE
This parameter is used to control the behavior of a script that modifies
UTF8 triggers.
Page 65
Appendix B - BEN_ACTION_PARAMETER Settings

BEN Batch parameters are system level parameters that control aspects
of the Oracle Benefits batch processes. The parameters are set for each
individual benefits process through the Batch Process Parameters form.
N.B. Oracle Benefits batch process parameters are held separately from
Pay Action Parameters.
Summary of Action Parameters

The following table shows user enterable action parameters and values
with any predefined default value.
Parameter
Parameter
Value
Default
Max
CHUNK_SIZE
MAX_ERRORS_ALLOWED
THREADS
Chunk Size
Threads
1 16000
0 or more
1 or more
10
20
3
16000
Value
Threads
Parameter Name: THREADS
Default Value: 3
Oracle Benefits is designed to take advantage of multiprocessor
machines. This means that you can improve performance of your batch
processes by splitting the processing into a number of threads. These
threads, or subprocesses will run in parallel.
When you submit a batch process to a concurrent manager the
THREADS parameter will determine the total number of subprocesses
that will run under the concurrent manager. The master process will
submit (THREADS 1) subprocesses.
The recommended setting is 1 for each CPU.
Attention: The concurrent manager must be defined to allow the
specified number of subprocesses to run concurrently. This is a task
for your Applications System Administrator.
Chunk Size
Default Value: 10
Size of each commit unit for the batch process. Each thread processes
one chunk at a time.
Recommended settings are:
Low for heavy transactional jobs i.e benmngle. Recommend 1

to 5.
High for read intensive jobs i.e extract. Recommend 50 or 100.
Page 66

Parameter Name: MAX_ERRORS_ALLOWED
Default Value: 20
The number of consecutive actions that may have an error before the
entire process is given a status of Error.
Page 67
Appendix C - INITRANS & PCTFREE Settings

INITRANS
The INITRANS parameter is specified when creating a table or index to
specify the amount of space to be pre-allocated for an initial number of
transaction entries to access rows in the data block concurrently. Space
is reserved in the headers of all blocks in the associated data or index
segment. For HCM application tables the default value is 10 for tables
(because 10*23 bytes = 230 bytes) and 11 for clusters and indexes.
Running Payroll transactions using multiple processes (a THREADS
setting of more than 1) requires you to also amend the INITRANS
definition accordingly for some key tables and indexes. Without doing
this, you may experience locking contention between sub-processes and
differences between CPU and elapsed timings for certain Payroll
processing SQL statements.
In addition, if different processes that are accessing the same records
could be run concurrently it will also be necessary to increase the
INITRANS setting accordingly.
Key HCM tables to alter INITRANS settings
PAY_ACTION_CONTEXTS
PAY_ACTION_INFORMATION
PAY_ASSIGNMENT_ACTIONS
PAY_ASSIGNMENT_LATEST_BALANCES
PAY_BALANCE_CONTEXT_VALUES
PAY_BALANCE_VALIDATION
PAY_BATCH_LINES
PAY_COSTS
PAY_ELEMENT_ENTRIES_F
PAY_ELEMENT_ENTRY_VALUES_F
PAY_ENTRY_PROCESS_DETAILS
PAY_GL_INTERFACE
PAY_INPUT_VALUES_F
PAY_LATEST_BALANCES
PAY_PAYROLL_ACTIONS
PAY_PERSON_LATEST_BALANCES
PAY_POPULATION_RANGES
PAY_PRE_PAYMENTS
PAY_PROCESS_EVENTS
PAY_PURGE_ROLLUP_BALANCES
PAY_RECORDED_REQUESTS
PAY_RETRO_ENTRIES
PAY_RUN_BALANCES
PAY_RUN_RESULT_VALUES
PAY_RUN_RESULTS
PAY_TEMP_OBJECT_ACTIONS
PAY_US_RPT_TOTAL
PER_ALL_ASSIGNMENTS_F
PER_ALL_PEOPLE_F
PER_ORGANIZATION_LIST
PER_PERIODS_OF_SERVICE
PER_PERSON_LIST
PER_POSITION_LIST
Page 68
Key Advance Benefits tables to alter INITRANS settings

BEN_BATCH_ELIG_INFO
BEN_BATCH_RANGES
BEN_ELIG_PER_F
BEN_ELIG_PER_OPT_F
BEN_ENRT_BNFT
BEN_ENRT_PREM
BEN_ENRT_RT
BEN_EXT_CHG_EVT_LOG
BEN_EXT_RSLT_DTL
BEN_PERSON_ACTIONS
BEN_PRTT_ENRT_RSLT_F
BEN_PRTT_RT_VAL
BEN_REPORTING
Key OTA tables to alter INITRANS settings
Key OTL Tables To Alter INITRANS Settings
Key iRecruitment tables to alter INITRANS settings
As well as changing the INITRANS setting for the above tables, you
must also change the INITRANS setting for the indexes associated with
the tables.
Note: In order to set the INITRANS parameter for tables that already
contain data you MUST:
1.
Export the contents of the table
2.
Recreate the table and associated index(s) with the correct

INITRANS settings
3.
Re-import the table data
Application Auditing & INITRANS Settings

If you have switched on auditing for any of the above tables, you also
need to ensure that the INITRANS is also set correctly for the audit
shadow table ( _A ).
PCTFREE
PCTFREE enables you to manage how the space within data blocks is
used. If you are running the application with a large number of
THREADS then there may not be enough room in the block header to
allocate to variable transactions if there are a lot of processes trying to
access the same data block at the same time.
Page 69
For example,
INITRANS = 10
PCTFREE = 10
Block Size = 8K
THREADS = 36
Given these figures, the fixed block size is 287 bytes (57 bytes general
block information + 23 bytes for the first transaction locks (Interested
Transaction List (ITL)), leaving 790 bytes ((8192-287)*10%) of free
space for row and dynamically created ITL growth.
Given the THREADS setting of 36, it is possible that 36 separate
transactions may be trying to lock records in the same block in which
case the space required to hold information about the locks is 828
(36*23), in other words an additional 598 bytes. This will be consumed
from the available freespace, however as there is only 790 bytes
available, some of which may have been used for data growth, it is
possible that contention will occur due to the system being unable to
acquire the space it needs to take out the ITL locks.
The additional space required can be pre-allocated by increasing the
INITRANS to 36 (although this reduces the amount of freespace
available for growth in the row data.)
Alternatively the PCTFREE can be increased to cater for the additional
dynamically allocated ITL, for instance if the PCTFREE was increased
to 20 then there would be an additional 790 bytes available.
INITRANS
PCTFREE
Block Header
ITL pre-allocated
Remaining Space
Free Space based on PCTFREE
Space required for dynamic growth in
ITL (36 THREADS)
Space remaining for data growth
% remaining for data growth
Default
Setting
Increase
INITRANS
Increase
PCTFREE
10
10
57
230
7905
790
598
36
10
57
828
7307
730
0
10
20
57
230
7905
1581
598
192
2.3%
730
8.9%
983
12.0%
Page 70
Appendix D - Costing Index Determination

This work must be done on a database that you intend to run the PL/Sql
version of the costing routine on. The results from this work is
dependent on the data you have within the
PAY_COST_ALLOCATION_KEYFLEX table. These steps must be
performed on the database ( test or production ) that the PL/Sql version
of the code will be run on. It may not be sufficient to perform this
analysis on a test environment in the hope to take the results and apply
them to the production environment. This analysis is very dependent on
the data within the tables and therefore unless the test environment is
an identical copy of the production environment, the results will be
invalid applied to the production environment.
The purpose of this work is to create an effective index on the
PAY_COST_ALLOCATION_KEYFLEX table that the PL/Sql process
can use. By 'effective index', we mean one which provides a
satisfactory 'selectivity'. The general theory is that an index is only
'worthwhile' if it has a selectivity of 10% or greater. For example, on a
table of 1000 rows, the index can uniquely identify at least 100
different combinations of those rows.
To calculate the selectivity of an index ( in percentage terms ) we use
the following algorithm:
100 * no. rows in candidate index / no. rows in table
To identify possible indexes for the
PAY_COST_ALLOCATION_KEYFLEX table, do the following:
(1). Find the total number of rows in the table:
select count(*)
from pay_cost_allocation_keyflex;
(2). Calculate the 'use' for each segment used in the table:
Determine which segments in the table are part of the costing flexfield
and run the following SQL for each of the identified segments:
select count(*)
from pay_cost_allocation_keyflex
where segment<n> is not null;
E.G.
select count(*)
where segment1 is not null;
(3). For each segment identified in 2 ( above ), calculate the
selectivity ( uniqueness ) of the values in this column in the
table:
select count(distinct segment<n>)
where segment<n> is not null;
E.G.
select count(distinct segment1)
Page 71
where segment1 is not null;

(4). Calculate the percentage selectivity for each of the segments
identified in 2 ( above ) :
Selectivity (in %) = 100 * (3) / (1)
An ideal index will have 100% selectivity which means the result of (3)
= result of (2) = result of (1) above. It is extremely unlikely that you'll
find such an effective index. What we require is the most effective
index available, and that index needs to have a selectivity of more than
10%, and whose columns are used near enough thought the key
flexfield table (i.e. (2)=(1) or very close to it) - there is no point having
an index that uniquely selects half the rows in the table, but doesn't
cover any of the remaining half ( hence the "is not null" checks ).
Please note that a composite index ( one that contains more than one
column ) may also provide very good selectivity. It is therefore also
worth working out the selectivity of possible composite index
combinations as follows:
(5). Uniqueness of composite index (segmentm, segmentn)
select count(distinct(segmentm || segmentn))
where segmentm is not null
and segmentn is not null;
E.G.
select count(distinct(segment1 || segment2))
where segment1 is not null
and segment2 is not null;
(6). Calculate the percentage selectivity of the composite index:
selectivity of composite index = 100 * (5) / (1)
Because the costing process may cause the creation of additional

PAY_COST_ALLOCATION_KEYFLEX records, it is important to
repeat the above exercise at regular intervals ( to make sure that you're
still using the most suitable indexes ). After a period of time the
likelihood of creating new distinct
PAY_COST_ALLOCATION_KEYFLEX entries may become very
small so there wouldn't be a need to do the above checks quite as often.
Page 72
Appendix E Diagnostic Scripts

Oracle Diagnostics
Oracle Support Diagnostics are designed to improve:
Problem Avoidance - resolving configuration and data issues

that would cause processes to fail
Self Service Resolution - resolving problems without the need

to contact Oracle Support
Reduction in Resolution Time - minimising the time spent to

resolve an issue
The diagnostic tests provided as part of the Oracle Support Diagnostics

patch gather and analyse information from your eBusiness Suite. The
results display the information gathered, the findings of the analysis and
appropriate actions to take if necessary. The tests do not alter data or
setup.
The purpose for this automation is to ensure customers are successful at
installing, using and upgrading Oracle eBusiness products. The goal of
this program is to create tools that will increase customer problem
avoidance, customer self-service and support engineer efficiency.
Oracle Support Diagnostic tests are updated and released on a regular
basis and include the latest updates to existing tests and all new tests
that are available.
It is now very common for support to ask customers to run specific
diagnostic tests and to upload the results in to Service Requests as part
of the problem identification process.
Key items to note:
Diagnostic tools do not alter the data or setup in your system
Diagnostic tools are organized into three categories:

o
Setup Diagnostic Tests assist in resolving product

setup issues
Activity Diagnostic Tests assist in resolving

problems related to a particular function or activity
Data Collection Tests collect and display application

data
For more information please see Metalink Note 342459.1 - eBusiness

Suite Support - Diagnostic Tools.
Page 73
Appendix F - Other Useful References / Sources of Information

Oracle Human Resources Management Systems Implementation
Guide Release 11i Part No. B14466-02
The technical Essays have a wealth of low level detailed information
about the operation of key Payroll processes.
Oracle Human Resources Management Systems Implementation
Guide Release 12 Part No.: B31617-02
The technical Essays have a wealth of low level detailed information
about the operation of key Payroll processes.
HCM Trace Options Metalink Note: 242552.1
This note is currently Internal Only.
Useful Troubleshooting Utilities and Trace Options in HCM
Metalink Note: 217471.1
Oracle Troubleshooting Benefits Performance Issues Metalink

Note: 364333.1
Oracle Applications System Administrators Guide

Configuration Release 11i Part No.: B13925-01
Review the chapter on the Cost Based Optimizer in Oracle
Applications.
Oracle Applications System Administrators Guide
Configuration Release 11i Part No.: B31453.01
Review the chapter on the Cost Based Optimizer in Oracle
Applications.
Managing Payroll Performance using the Cost Based Optimizer
(CBO) Metalink Note: 133320.1
This is an old note but it still contains some good guidance about how
frequently you should analyse schema stats.
Using PYUPIP - Oracle HRMS Metalink Note: 130374.1
This document provides information about how to enable PYUPIP trace
for debugging HCM code.
Demonstration of Running PYUPIP trace Metalink Note:
339169.1
The attached file contains a demonstration viewlet on enabling and
running PYUPIP trace and locating the resulting file.
Page 74
eBusiness Suite Support - Diagnostic Tools - Metalink Note:

342459.1
This note is the launch point for finding information about applications
diagnostics including HCM diagnostics.
What is SPARSE Matrix and How does it Help to Minimise Size
and Growth of Run Results and Run Result Values Tables.
Metalink Note: 368723.1
This note provides information about how to enable the Sparse Matrix
and Suppress Insignificant Run Result functionality.
Page 75

HRMS and BEN 11i and R12 Tuning and Health Check

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

HRMS and BEN 11i and R12 Tuning and Health Check

Diunggah oleh

Hak Cipta:

Format Tersedia

Oracle HCM & Benefits

Tuning & System

Andrew McGhee & John Rhodes

Copyright (C) 2006 Oracle Corporation

NOTE: The contents of this document are deemed to be correct

Oracle / Client Confidential

Oracle / Client Confidential

Online Life Events Process ............................................................................................................ 38

Oracle / Client Confidential

Oracle / Client Confidential

Oracle / Client Confidential

Key System Health Check Phases

Review & Report Phase

Diagram 1 - Key System Health Check Phases

Oracle / Client Confidential

reestablished and the focus of investigation redirected to new or

Review & Report Phase

The audit phase should have prioritised which components of the

Diagram 2 - Tuning Components Sequence

Oracle / Client Confidential

Although these stages may appear to have some form of order or

Oracle / Client Confidential

Tune Database Structure

Oracle / Client Confidential

Diagram 3 - Tuning Return On Effort

Step 1: Optimise Data Design

Oracle / Client Confidential

Step 3: Tune The Application

Oracle / Client Confidential

Understanding The Bigger Picture

Functions & Operations

Oracle / Client Confidential

Are any HCM Application tables being audited ? If so, which

Technical Architecture & Software

Oracle / Client Confidential

Is RAID or disk mirroring / striping implemented ? If so, how ?

Table 1 - Appropriate System Information Gathering Questions

During this initial knowledge gathering and understanding meeting it is

Oracle / Client Confidential

Assign a predefined library of immediate concurrent programs

Assign work shifts to your manager, which determines what

For each work shift, you define the maximum number of

Specialize your manager to read only certain kinds of requests.

For further details of how to set up and administer concurrent

Oracle / Client Confidential

Tune The HR Application Setup & Procedures

Security List Maintenance Process (PERSLM)

To take advantage of the multi-threaded performance

If you are just running HR ( without Payroll ), please ensure that

Tuning of the contents of the Security Profile can have significant

Oracle / Client Confidential

Datapump has built in parallelization which enables it to make use

When running the hr_pump_meta_mapper.help procedure, make

Datapump uses published APIs to load / update data in the

Oracle / Client Confidential

System Extract Process

Formulas will slow down process

System Extract Restart Process

These BEN_BATCH_PARAMETER values are inherited from the

System Extract Write Process

Oracle / Client Confidential

Single / Multi Threaded

Data Loading Person Records

Find the next sequence value ( next_value ) from the