I would start with reading Doug Burns' papers on Parallelism (http://oracledoug.com/serendipity/index.php?/archives/835-PX-and-the-Magic-of-2.html)
Just because you are waiting on I/O does not necessarily mean that the I/O subsystem is the bottleneck. What is the average duration and duration spread for the reads? If the duration is small and the SAN is not maxing out it's throughput, then it may have unused capacity that can be used for parallel processing.
Are the underlying tables and data parallel 'friendly'? If you are running in parallel, but each process is wanting to read the same data, you can induce contention waits (read by other session). If each parallel process is accessing different data/index blocks, you can reduce the likelihood of contention. Better still if the underlying objects are partitions and the parallel processes read different partitions.
This sounds like a great opportunity to benchmark and test the changes. Test, trace, profile, report.
Charlotte Hammond wrote:
We've got a long running batch job. Tracing shows 95% of the time is I/O waits (mostly scattered reads steming from hash joins) against our SAN. Our architect wants to split it into several parallel streams but I'm dubious. Surely the SAN won't serve up data any faster just because we're running in parallel. Is there any benefit in this strategy? I would expect parallelism to come into play if there's significant non-I/O time (e.g. busy on CPU) where other sessions could take advantage of the burstiness, or if the database was accessing multiple disks directly, not virtualised over a big SAN cache. I reckon we just need a faster SAN (and/or some SQL tuning). Any comments? Many thanks Charlotte-- //www.freelists.org/webpage/oracle-l
-- //www.freelists.org/webpage/oracle-l
