Re: Parallel execution strategy

vitalisman_at_gmail.com wrote:
> Hi all,
>
> A customer of mine is facing performance problems caused by bad single
> physical read rates. I'm working on the root cause. In the meanwhile
> I'm going to implement parallel execution since all resources on these
> servers are underused and there are just a few concurrent users all
> day long. With parallel execution enabled, the physical read rate for
> most queries with lots of gets is dramatically increased.
>
> Any advice regarding the strategy to get the best results? Forcing
> parallel query/dml/ddl at the session level is no option (I've tried
> this out on a test plateform with very bad results such as application
> errors and, as expected, very long execution times for queries not
> benefiting from parallel execution.)
> I'm currently identifying every queries with a bad read rate and a
> long execution time and I'm implementing parallel execution on the
> underlying objects (by testing each query on a test plateform). But
> this is somewhat time-consuming. ;-)
>
> TIA,
> Jerome

Warning: ROT ! Warning: ROT!

Try to change "large" table to parallel. You will need to find out what large means in your case; I've never seen anything benefit from parallel queries when less than a couple of hundred thousand records need to be processes.
Anything short of that, and the overhead on parallel processes is more than the benefit.
You may also want to play with the number of parallel processes

Again: Rule-Of-Thumb warning!

DO NOT take this for granted!

-- 

Regards,
Frank van Bortel

Top-posting in UseNet newsgroups is one way to shut me up