Can anyone guide me to ideas on basics of parallel processing in SQL

Question

Hi all,
Can anyone guide me to ideas on basics of parallel processing in SQL and its usage in the the performance tuning of the query. If so what's the syntax to be followed and how to arrive at the optimized query after tuning

Answer 1

My 2'c on the subject.
Don't break your head over parallel query (PQ) processing. It should be something that is of concern to the DBA/Oracle architect - not the developer.
Yes, it is good to be aware of how it works. But you should not write hints in your code that forces PQ processing.
Simple example. You use hints to force a PQ of degrees 5 (meaning 5 PQ processes will be used). It works great on development. In production, 10 users are running that query round about the same time. The PQ ceiling is 20 PQ processes. The 1st 4 users each gets 5 PQs processes and the remaining 6 get none. Or another developer did the same thing, only he was very greedy and coded a PQ of degrees 20 into his SQL. So his SQL is now consuming all available PQ processes. So how did forcing PQ in your code addressed performance? It did just for a couple of users with the majority of users now facing even worse performance.
The DBA is the one that should be tuning this. He/she can set the degree of PQ per table. Control the size of the PQ etc.
And it does not stop there. The primary reason for PQ in Oracle is to lower the latency of I/O. Let's say Oracle needs to reads 100MB worth of data (full table scan or fast full index scan for example). It uses multi block (sequential) reads to read bigger chunks at a time. Still, a single process can only read I/O so fast - the speed of which is entirely dependant on the I/O subsystem and hardware.
Using a second process to assist with the I/O can reduce the overall time. Instead of 1 process reading 100MB data, there are now 2 processes only having to read 50MB each.
But as I mentioned, the actual I/O thruput is a lower level function. Let's say you start a 100 processes. Great - each only have to read 1MB worth of data. Response should be fast.
Wrong. Those 100 processes seriously overload the I/O subsystem and throttle it so badly that the complete platform's performance is degraded severely. So instead of these 100 process speeding up I/O performance, they trash the performance of the entire platform.
Sure, this is an extreme example. But the basic concepts are usually illustrated much better using such an example.
So, you as developer deciding on just whether to use PQ and just how many PQ processes to use...? Wrong. It is not your decision, not your area of responsibility and usually not your area of expertise.
Know what PQ is. Know how PQ works. But think long and hard before forcing PQ via your code (using hints) on a production platform.