has anybody found any performance issues after the upgrade to FP K (we are upgrading from 8.1.7 to 9.2 at the same time)? We are having long delays when querying data on screens like payroll processes results on our dev environment...and I'm wondering if the same will happen in Prod! (Schema Stats were run last Monday)...

Jairo

Hello Jairo

Might something have trashed the latest balances?

Are your schema stats up to date?

Also, I am given to understand that one needs to apply a patch 4745996 which improves the performance of pay_balance_pkg. Possibly this might help - but then again....

Also, apparently there's a new action parameter: range_person_id - this should be set to "Y" ... dunno what it actually does tho

Also...(yawn)... There is apparently a concurent program called "Run Balance Architecture Diagnostic Report" - give that some welly

Hope at least some of these ideas help!

Hi Jairo,

We attempted to do the same upgrade last year but hit several performance issues both online and with the payroll runs. Oracle supplied several patches but as soon as one was resolved another appeared. The problem was attributed to the 9i cost based optimiser. In the end Oracle agreed to extend 8i cover for another year and we decided to wait and migrate stright to 10i (which we are in the process of doing). If you need any specifics let me know and I'll see if our DBA's can dig out the answers.

Pat

OK. Before anyone states the obvious, we were trying to upgrade to the latest release available - not FP K. What I was trying to say is that it might have nothing to do with FP K.

Pat

Clive, Pat,

Thanks very much for your reply. Pat, I'd be interested in the details from the DBA please. Simple things like querying data on the standard payroll processes window is taking minutes instead of seconds, which is worrying.

Thanks,

Jairo


Thanks,

Jairo

Jairo,

Should point out that we were attempting to move from 8i to 9i, up to 11.5.9 and apply FP H so any of these could have been a factor and have hopefully been resolved in the interim. The main roblems we encountered were:

ELEMENT ENTRIES FORM PERFORMANCE PROBLEM (took almost 1 hr to return) - Patch 3946911 provided

Payroll Run UK elapse time went from 2 hours to 5 hours - had to run Gather Schema Stats but I remember there were problems re. running them.
Subquent runs slow due to a select statement in a User defined function - had to add a hint to override the CBO.

Performance issues running public api from custom process - Patch 3980784 provided

Prepayments went from 20 mins elapse (8i) to 2hours+ (9i) - Set low_volume parameter = 'Y' to forces all balance routes to use the RULE hint.

PAYWSACT SLOW SINCE UPGRADE TO 9I - think this was resolved by setting low_volume parameter = 'Y'

POOR PERFORMANCE PAYWSRQP.FMX

SERIOUS PERFORMANCE PROBLEM WITH END OF YEAR PROCESS - we gave up before getting this one resolved.

ROLLBACK PAYROLL WORKER PROCESSES ERRORING - we gave up before getting this one resolved.

PERFORMANCE PROBLEM IN ADJUST BALANCE FORM (went less than a min to 15 mins) - we gave up before getting this one resolved.


Pat

Pat

The interesting thing is Oracle says that Family Pack K includes the above patches you mention or in other terms Family Pack K supersedes or includes the above patches.

One performance patch that Oracle released post FP K was
4745996

PERF: PYBALEUX: PAY_BALANCE_PKG RUNS SLOW AFTER 11.5.10.2 AND 11I.HR_PF.K

Jairo, is the above patch applied on your site.

cheers
vin

Jairo

More performance related patches to watch for post family pack K.

Patch 4762713
P11D performance fixes for 2005/06 P11D Release

Patch 4731193
The People form is hung-up after appling the HR_PF.K

Patch 4556903
Performance issue: applying hrglobal.drv after HRMS FP.K (pyusgeou.sql )

We had same issues here at NHS. The screen would take eons to come back unless to completed all of the find criteria. The patch did the trick and now everything is as fast as it was before FP.K

Vinoo,

Good to here from you.

It doesn't surprise me that the patches I mentioned have been rolled up into FP K - I believe this is standard practice. We gave up in the end because the 9i database cost based optimiser (CBO) kept making the wrong decissions for a database of our size and development had to keep supplying patches with hints to override the CBO - we also had to get a working solution in before Tax Year End. As Oracle extended their support of 8i we decided to bypass 9i, wait until 10i was certified for HR Apps and migrate to this level (in the process of doing this now).

Pat