Re: Parallel Application Processing

From: Holger Baer <holger.baer_at_science-computing.de>
Date: Mon, 08 Aug 2005 15:14:12 +0200
Message-ID: <dd7lr5$2ia$1@news.BelWue.DE>

Billy wrote:
> Mladen Gogala wrote:
>
>

>>>Does this method make sense? Are there better methods to consider?
>>
>>Partitioning it by hash (or range, if you can do that) and then acessing
>>different partitions in parallel would seem like the perfect way.

>
>
> Oracle SE. Partitioning is not available.
>
> Not that this partitioning is actually a solution in itself. One can
> simply specify the partition range as part of the predicate without
> needing to have partitioning. e.g.
> select * from table where datetime between :date_from and :date_to
>
> The problem with this is that the process now needs to go and determine
> what ranges of values it can process. Which date ranges ara valid
> candidates? Which date ranges are currently busy being processed? Which
> has not yet been processed? Which has been processed but failed
> processing?
>
> How do you deal with these management complexities? Writing additional
> code? Adding tables to manage the processing? The more moving parts
> there are, the bigger the chance of failure. The slower performance.
>
> Versus simply telling the process find *any* n number of rows that
> needs processing and doing its process & update thing. And running
> potentially 100's of these in parallel.
>
> Sorry, I cannot see your suggestion as a viable solution.
>
> --
> Billy
>

If you have "Effective by Design", Tom Kyte describes a possible solution to your problem using rowids and a number of jobs for parallel processing.

It is also briefly covered here:

http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:10498431232211

However, running 100's of them in parallel would mean you need to have the horse power to do so. According to Cary Milsap (read Batch Queue discipline and Batch Queue and the magic of 2 available at hotsos.com after registration) you shouldn't run more jobs than 2 times the number of CPUs in parallel. But if you have such a beast (with SE? noway) you'll be fine, else you'll just set job_queue_processes accordingly.

Regards,
Holger Received on Mon Aug 08 2005 - 08:14:12 CDT