Transcript Global Payroll Performance Optimisation

Global Payroll Performance
Optimisation - I
David Kurtz
Go-Faster Consultancy Ltd.
[email protected]
www.go-faster.co.uk
Who Am I?
• Oracle Database Specialist
– Independent consultant
• Performance tuning
– PeopleSoft ERP
– Oracle RDBMS
• Book
– www.psftdba.com
• UKOUG Director
• Server Tech & PeopleSoft
•
Oak Table
•
Global Payroll Performance Optimisation
©2011 www.go-faster.co.uk
2
Caveat
• I am going to simplify some of the technical
concepts in this presentation.
Global Payroll Performance Optimisation
©2011 www.go-faster.co.uk
3
Agenda
•
•
•
•
•
•
‘Streaming’ –Parallel processing
Data Volume
Read Consistency
Partitioning
Reporting
Archiving
Global Payroll Performance Optimisation
©2011 www.go-faster.co.uk
4
Parallel processing
• All modern machines
have multiple
processors,
– most of the processors
have multiple cores.
– Even the CPU in my 4
year old laptop has a 2
core CPU.
Global Payroll Performance Optimisation
©2011 www.go-faster.co.uk
5
PeopleSoft Batch Programs
• Only run on one CPU at any one time.
• Client Server processes
– Program (COBOL or Application Engine)
– Database (eg. Oracle)
• Either busy executing COBOL or waiting
for the database.
– If your payroll calculation is a single process
you are not getting value for money!
Global Payroll Performance Optimisation
©2011 www.go-faster.co.uk
6
Payroll ‘Streaming’
• Several GP processes can be split up.
– Each piece processes a distinct set of
employees
• Range of EMPLID
– The pieces can be run concurrently.
– Only one global definition of streams.
– Maximum number of streams determined by
hardware.
Global Payroll Performance Optimisation
©2011 www.go-faster.co.uk
7
Streamable Processes
•
•
•
•
•
Payroll Calculation
Banking Preparation
GL Preparation
EDI Preparation
Payslip Preparation
Global Payroll Performance Optimisation
©2011 www.go-faster.co.uk
8
Payroll ‘Streaming’ Challenges
• Payroll isn’t over until the last stream
completes.
– Streams need to be evenly balanced.
– Employee churn?
• Inter-stream contention
– Shared working storage tables
Global Payroll Performance Optimisation
©2011 www.go-faster.co.uk
9
How Many Streams?
• In a well tuned systems, the payroll calculation
phase spends about
– 2/3 of its time in COBOL
– 1/3 on the database.
• Number of streams should not exceed
– 3 * CPU on database server
– 1.5 * CPU on Process Scheduler server
• Payroll identification process is database
intensive.
Global Payroll Performance Optimisation
©2011 www.go-faster.co.uk
10
Employee Churn
• EMPLID is allocated as an accession
number.
• Streams are a range of EMPLIDs
– New employees are hired into the last stream
– Employees are terminated across all streams
• Over time the streams will go out of balance
– Last stream will take longest
Global Payroll Performance Optimisation
©2011 www.go-faster.co.uk
11
Balancing Streams
• Balance employees across streams on basis
of
– 80% number of payroll segments per stream
– 20% number of JOB history rows
• Longer serving employees in earlier streams likely
to have more payroll segment and job history.
– Make allowance for employee churn.
• You will need to periodically rebalance the streams.
– Balance for the largest payroll.
Global Payroll Performance Optimisation
©2011 www.go-faster.co.uk
12
Reversing the EMPLID
• Reverse the EMPLID
– Instead of EMPLID 0000012345
– Use EMPLID 543210000
• Streams stay balanced because new
employees hired across range
• BUT you must do this before you go live!
Global Payroll Performance Optimisation
©2011 www.go-faster.co.uk
13
Reversing the EMPLID
•
•
•
•
•
•
•
•
0000012345
0000012346
0000012347
0000012348
0000012349
0000012350
0000012351
0000012352
Global Payroll Performance Optimisation
•
•
•
•
•
•
•
•
5432100000
6432100000
7432100000
8432100000
9432100000
0532100000
1532100000
2532100000
©2011 www.go-faster.co.uk
14
Inter-stream Contention
• Streams are just ranges of EMPLIDs.
• Oracle inserts data into the first available block (roughly
speaking)
• Multiple streams insert data simultaneously into the same
data blocks in result tables.
• Payroll cancel/recalculation deletes from result tables.
• Multiple transactions concurrently update different rows in
the same block.
– On Oracle/SQL Server >=2005: No locking, streams continue to
run, but read consistency processing is expensive
– Other database can experience page level locking
Global Payroll Performance Optimisation
©2011 www.go-faster.co.uk
15
Read Consistency
• The data set that you query remains the same
throughout the life of your query.
– If somebody else updates data that you are reading (and
commits), after your query starts, then you see the
original value.
•
•
•
•
Thus, readers do not block writers or vice versa.
Oracle has always done this since 1990.
SQL Server 2005 has ‘multi-versioning’ option
Other databases either block or can permit ‘dirty
read’.
Global Payroll Performance Optimisation
©2011 www.go-faster.co.uk
16
Read Consistency
• Oracle achieves this by storing ‘undo’
information for every change
– Recovers ‘read-consistent’ in-memory copy of
data block to point in time when query started.
– A good reason for buying Oracle
– Resource intensive process
– Performance problem if abused.
• Global Payroll is the perfect storm!
Global Payroll Performance Optimisation
©2011 www.go-faster.co.uk
17
Avoiding Inter-stream Contention
• Prevent different streams accessing the same data
blocks
– Range Partition result tables to match stream ranges
– Use Global Temporary Tables (Oracle) for working
storage tables
– Partition these also on other platforms.
• Now different streams access different partitions.
• No code change, a job for the DBA
– licensed option on most platforms
Global Payroll Performance Optimisation
©2011 www.go-faster.co.uk
18
Partitioning
• Partitioned Table
– Different physical components
• Value of data determines physical location
– Logically still one table
– Transparent to application
– Rather like a multi-part encyclopaedia.
Global Payroll Performance Optimisation
©2011 www.go-faster.co.uk
19
Global Temporary Tables
• A temporary object
– Save some of overheads associated with regular
tables
– Each session gets its own physical copy.
Global Payroll Performance Optimisation
©2011 www.go-faster.co.uk
20
Group Lists
• Specify a list of individual EMPLIDs for
whom to run pay calc or another process.
• Some customers have experienced problems
when run groups shortly before or during
larger batch payroll calculations.
• Why?
Global Payroll Performance Optimisation
©2011 www.go-faster.co.uk
21
Cost Based Optimizer
• SQL Execution Plan Caching
• Bind Variable Peeking during Parse
• Different Plan for Group List
– Because different bind variables
• But plan cached and gets used for main pay
calculation which then runs longer than
usual!
Global Payroll Performance Optimisation
©2011 www.go-faster.co.uk
22
Plan Stability
• Remember the good plan used by large
payroll.
• Force it to be used for all payrolls including
group list.
– Data Volumes small so poor plan won’t really
matter.
• Oracle Stored Outline
– No code change, DBA can implement.
Global Payroll Performance Optimisation
©2011 www.go-faster.co.uk
23
Data Volume
• Payroll generates a lot of data.
• Every pay period it generates more data.
• Partitioning can offer ways of accessing the
data you want quickly
– Without having to trawl through data you don’t
want.
• Need to consider how long you need data
– Do you still need data from last tax year?
Global Payroll Performance Optimisation
©2011 www.go-faster.co.uk
24
Archiving
• Put the data you do need to keep into a reporting
table
– Remove data from the live result tables
– Partitioning can help you move/delete this data
efficiently
– May need to rebuild tables where you have to use
DELETE
• Reduced data volumes should improve
performance of reports.
Global Payroll Performance Optimisation
©2011 www.go-faster.co.uk
25
Reporting
• Payroll result tables delivered with single
index
– Not suitably indexed for all reporting
requirements
• Particularly single PIN queries
– Adding more indexes would degrade
calculation performance
– Consider generating reporting table
• Subset of data, and indexed as necessary.
Global Payroll Performance Optimisation
©2011 www.go-faster.co.uk
26
Conclusion
Global Payroll Performance Optimisation
©2011 www.go-faster.co.uk
27
Questions?