RE: PeopleSoft query
From: David Kurtz <info_at_go-faster.co.uk>
Date: Tue, 14 Jul 2009 11:51:24 +0100
Message-ID: <3553923280F949019DF8657ABD0F13E8_at_GOFASTER4>
>-----Original Message-----
>> - Are you running multiple concurrent payroll calculation processes?
>
>
>This seems to be a complete no-no in our installation.
>Single pay calcs work like a charm nowadays. Even full
>monthly pay calcs rarely take more than 5 minutes. As soon as
>someone starts two of them, even if they are just for one week
>and half a dozen temps, all heck breaks lose and we get huge
>blow-ups in runtimes.
>
>
>
You can get contention caused by consistent read because the Cobol processes, unlike most Application Engine programs, share working storage tables. One option is to convert these tables into Global Temporary Tables (though I have had to use leading hints on a couple of statements in the identification phase).
Date: Tue, 14 Jul 2009 11:51:24 +0100
Message-ID: <3553923280F949019DF8657ABD0F13E8_at_GOFASTER4>
>-----Original Message-----
>> - Are you running multiple concurrent payroll calculation processes?
>
>
>This seems to be a complete no-no in our installation.
>Single pay calcs work like a charm nowadays. Even full
>monthly pay calcs rarely take more than 5 minutes. As soon as
>someone starts two of them, even if they are just for one week
>and half a dozen temps, all heck breaks lose and we get huge
>blow-ups in runtimes.
>
>
>
You can get contention caused by consistent read because the Cobol processes, unlike most Application Engine programs, share working storage tables. One option is to convert these tables into Global Temporary Tables (though I have had to use leading hints on a couple of statements in the identification phase).
In GP systems where they want to run 'streamed' processing you also end up physical partitioning the tables to match the logical stream definitions.
You can get also changes in execution plans because the range of EMPLIDs being processed is very wide, but the number of rows involved are small. Oracle miscalculates the cardinality because the group list is a skewed sample of the whole population.
-- http://www.freelists.org/webpage/oracle-lReceived on Tue Jul 14 2009 - 05:51:24 CDT