Presentation is loading. Please wait.

Presentation is loading. Please wait.

Global Payroll Performance Optimisation - II

Similar presentations


Presentation on theme: "Global Payroll Performance Optimisation - II"— Presentation transcript:

1 Global Payroll Performance Optimisation - II
Row Migration can Aggravate Contention on Cache Buffer Chains Latch 06/04/2017 Global Payroll Performance Optimisation - II David Kurtz Go-Faster Consultancy Ltd. ©2011 Go-Faster Consultancy Ltd.

2 Row Migration can Aggravate Contention on Cache Buffer Chains Latch
06/04/2017 06/04/2017 Who Am I? Oracle Database Specialist Independent consultant Performance tuning PeopleSoft ERP Oracle RDBMS Book UKOUG Director Server Tech & PeopleSoft Oak Table Global Payroll Performance Optimisation ©2011 ©2011 Go-Faster Consultancy Ltd. ©2011 Go-Faster Consultancy Ltd. 2

3 Agenda ‘Streaming’ –Parallel processing Data Volume Read Consistency
Partitioning Reporting Archiving Global Payroll Performance Optimisation ©2011

4 Warning This is an unashamedly technical session.
I am going to talk about database internals. Global Payroll Performance Optimisation ©2011

5 Row Migration can Aggravate Contention on Cache Buffer Chains Latch
06/04/2017 Size matters! Specifications (H-4) Performance specifications are projected. Pratt & Whitney R-4360 Wasp Major General characteristics Crew: 3 Length: 218 ft 8 in (66.65 m) Wingspan: 319 ft 11 in (97.54 m) Height: 79 ft 4 in (24.18 m) Fuselage height: 30 ft (9.1 m) Loaded weight: 400,000 lb (180,000 kg) Powerplant: 8× Pratt & Whitney R-4360 Wasp Major radial engines, 4,000 hp (2,640 kW) each Propellers: four-bladed Hamilton Standard, prop, 1 per engine Propeller diameter: 17 ft 2 in (5.23 m) Performance Cruise speed: 250 mph (407.98 km/h) Range: 3,000 mi (4,800 km) Service ceiling: 20,900 ft (6,370 m) Global Payroll Performance Optimisation ©2011 ©2011 Go-Faster Consultancy Ltd.

6 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

7 Database Parallelism All objects in the PeopleSoft schema are explicitly set NOPARALLEL Indexes are built parallel, but later reset. Can invoke parallel query with PARALLEL hint Parallel insert in direct path model Parallel DML only works on partitioned objects 1 PQ slave per partition Global Payroll Performance Optimisation ©2011

8 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

9 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. Maximum number of streams determined by hardware. Global Payroll Performance Optimisation ©2011

10 Streamable Processes COBOL Application Engine Database Intensive
Payroll Calculation Application Engine Banking Preparation GL Preparation EDI Preparation Payslip Preparation Database Intensive Global Payroll Performance Optimisation ©2011

11 Payroll ‘Streaming’ Challenges
Payroll isn’t over until the last stream completes. Streams need to be evenly balanced. Employee churn? One global definition of streams Balance for largest payroll? Inter-stream contention Shared working storage tables in COBOL Global Payroll Performance Optimisation ©2011

12 Payroll Calculation Process Phases
Identify Populate working storage and some result tables Database Intensive Calculation COBOL Intensive Cancellation Delete results Global Payroll Performance Optimisation ©2011

13 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

14 How Many Streams? First GP I ever worked on Maximum number of streams?
20 CPUs on Application/Batch server 20 CPUs on Database server Maximum number of streams? 20 / 1/3 = 60 on database server 20 / 2/3 = 30 on Application server So we used 30 streams Application server fully utilised during payroll calc Database about 50% during calc, Probably overloaded during identification. Global Payroll Performance Optimisation ©2011

15 How Many Streams? Optimise number of streams for calculation phase.
Restrict concurrency of database intensive process on process scheduler. To limit CPU consumption, and possibly also I/O contention. Consider use of Oracle Resource Manager Mainly for Payroll identification I’ve never had to do this myself. Cancellation will be restricted by I/O Global Payroll Performance Optimisation ©2011

16 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

17 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 Periodically rebalance the streams Global Payroll Performance Optimisation ©2011

18 Bulk Churn Effects Migration
If migrated to GP in tranches then order of migration could affect stream balance Company merger/divestment history can affect balance of payroll. Global Payroll Performance Optimisation ©2011

19 Rebalancing the streams?
Calculate new stream range values Allow space for estimated future growth Rebuild all range partitioned tables Half the I/O of partition merge/split About 42 tables in UK tables. Need working storage space to do this Global Payroll Performance Optimisation ©2011

20 Reversing the EMPLID Reverse the EMPLID
Instead of EMPLID Use EMPLID Streams stay balanced because new employees hired across range Improved search performance across HCM BUT you must do this before you go live! Global Payroll Performance Optimisation ©2011

21 Reversing the EMPLID Global Payroll Performance Optimisation ©2011

22 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

23 Working Storage Tables
COBOL One shared instance of each working storage table Shared SQL Candidate for Global Temporary Table so one instance per session Application Engine PeopleSoft Temporary Record One instance of record per process Different SQL Still consider GTT to reduce redo Global Payroll Performance Optimisation ©2011

24 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, like this since 1990. SQL Server 2005 has ‘read committed snapshot’ option Other databases either block or can permit ‘dirty read’. Global Payroll Performance Optimisation ©2011

25 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

26 Read Consistency Query @ 10023 Update @ 10024
Global Payroll Performance Optimisation ©2011

27 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

28 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. Partition Elimination Global Payroll Performance Optimisation ©2011

29 What is Partitioning? Typically used in DSS
But can also be effective in OLTP (From Oracle documentation) Global Payroll Performance Optimisation ©2011

30 Partitioning Keep similar things together Keep different things apart
Employees for one stream in on partition Keep different things apart Only one transaction in each block of each segment No need for read consistency Global Payroll Performance Optimisation ©2011

31 Partitioning GP Recommendation
Range Partitioning EMPLID – to match streams List Sub-partition CAL_RUN_ID – calendar group ID. Global Payroll Performance Optimisation ©2011

32 Secondary Benefits CAL_RUN_ID list sub-partition Historical partitions
Easier to archive later Historical partitions Different Tablespaces Different Data Files Old data on slower disk Read Only Less frequent back-up of read-only tables Faster Backup Global Payroll Performance Optimisation ©2011

33 Global Temporary Tables
Global because the data is private Temporary because the definition is permanent Global because everyone can see the definition Temporary because physical existance of the table is temporary so it does not need to be recovered. Global Payroll Performance Optimisation ©2011

34 Global Temporary Tables
A temporary object No redo generation But there is undo, and there is redo on the undo! Each session gets its own physical copy. Again no read consistency problems No high water mark issues Lower high water marks – less I/O Global Payroll Performance Optimisation ©2011

35 Building the DDL Demonstrate GFCBUILD utility.
Global Payroll Performance Optimisation ©2011

36 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

37 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

38 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

39 Plan Stability Collect and applied stored outline with database trigger Use Active Session History to demonstrate the problem and solution Global Payroll Performance Optimisation ©2011

40 Capture Stored Outline
CREATE OR REPLACE TRIGGER sysadm.gfc_create_stored_outlines BEFORE UPDATE OF runstatus ON sysadm.psprcsrqst FOR EACH ROW WHEN (new.prcsname = 'GPPDPRUN' AND (new.runstatus = 7 OR old.runstatus = 7)) DECLARE l_sql VARCHAR2(100); BEGIN l_sql := 'ALTER SESSION SET create_stored_outlines = '; IF :new.runstatus = 7 THEN EXECUTE IMMEDIATE l_sql||:new.prcsname; ELSIF :old.runstatus = 7 THEN EXECUTE IMMEDIATE l_sql||'FALSE'; END IF; --because I dont want to crash the process scheduler EXCEPTION WHEN OTHERS THEN NULL; END; / Global Payroll Performance Optimisation ©2011

41 Apply Stored Outline CREATE OR REPLACE TRIGGER sysadm.gfc_use_stored_outlines BEFORE UPDATE OF runstatus ON sysadm.psprcsrqst FOR EACH ROW WHEN (new.prcsname = 'GPPDPRUN' AND (new.runstatus = 7 OR old.runstatus = 7)) DECLARE l_sql VARCHAR2(100); BEGIN l_sql := 'ALTER SESSION SET use_stored_outlines = '; IF :new.runstatus = 7 THEN EXECUTE IMMEDIATE l_sql||:new.prcsname; ELSIF :old.runstatus = 7 THEN EXECUTE IMMEDIATE l_sql||'FALSE'; END IF; --because I dont want to crash the process scheduler EXCEPTION WHEN OTHERS THEN NULL; END; / Global Payroll Performance Optimisation ©2011

42 Three Scenarios Compared Large / Small / Plan Stable Small
SQL_ID SCENARIO ASH_SECS SCENARIO ASH_SECS SCENARIO ASH_SECS 4uzmzh74rdrnz **SAME** 4n482cm7r9qyn **SAME** 2f66y2u54ru1v **SAME** 1n2dfvb3jrn2m **SAME** 652y9682bqqvp **SAME** d8gxmqp2zydta **SAME** 2np47twhd5nga **SAME** 4ru0618dswz3y 4ru0618dswz3y **SAME** 4ru0618dswz3y 4ru0618dswz3y gnnu2hfkjm2yd **SAME** fxz4z38pybu3x 2xkjjwvmyf99c **SAME** a05wrd51zy3kj **SAME** Global Payroll Performance Optimisation ©2011

43 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

44 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

45 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

46 GFC_GPRPTGEN Reporting Table for Single Pin Queries
List Partitioned by Pin One Partition for each Pin Incremental Maintenance by Application Engine Uses Parallel DML to maintain reporting table. Sub-Paritioned GP Result Tables may still be faster for single employee, single calendar group ID queries! Global Payroll Performance Optimisation ©2011

47 Further Reading Configuring and Operating Streamed Processing in PeopleSoft Global Payroll Managing Oracle Table Partitioning in PeopleSoft Applications with GFC_PSPART Package Use of Oracle Plan Stability (Stored Outlines) in PeopleSoft Global Payroll Global Payroll Performance Optimisation ©2011

48 Row Migration can Aggravate Contention on Cache Buffer Chains Latch
06/04/2017 Questions? ©2011 Go-Faster Consultancy Ltd.


Download ppt "Global Payroll Performance Optimisation - II"

Similar presentations


Ads by Google