Parallel Execution against Normal Execution

Question

Hi,
Can someone explain why in this case Serial Execution is faster although enabling parallel dml at session level , What are the possibilities to improve speed of executoin for parallel execution as i need to populate for 139 stores data having around half a million rows for each store , i will have to run a cursor on the distinct value of store to achieve this , just to test i got the following Results , can anyoe guide where i am going Wrong?
This is the Script
set timing on
insert into r8_win_store
select * from win_store@rms8 where store=99;
commit;
alter session enable parallel dml;
insert /*+ Parallel(t,8) */ into r8_win_store t
select /*+ parallel(e,8)*/ * from win_store@rms8 e where e.store=99;
commit;
alter session disable parallel dml;
OUtput
SQL> @test1.sql
299666 rows created.
Elapsed: 00:03:48.12
Commit complete.
Elapsed: 00:00:00.01
Session altered.
Elapsed: 00:00:00.00
299666 rows created.
Elapsed: 00:08:02.81
Commit complete.
Elapsed: 00:00:01.31
Session altered.
Elapsed: 00:00:00.00

Answer 1

Parallel processing in Oracle is intended to reduce I/O latency. When you tell the kernel to do an I/O, you need to wait for that call to complete - disk platters to spin, disk controller heads to move, etc.
If you need to make a bunch of I/O calls after one another, you will spend up to 90% of the elapsed time waiting for that I/O to actually put the data into your buffer to process.
Now imagine doing a million I/Os.. and 90% of the time spend waiting for I/O to complete. A big performance knock and a frustrating one - as you cannot make that actual I/O any faster. It is simply slow. The slowest operation you can do on the computer and you're doing a million of them.
Parallel processing in Oracle addresses this problem. There can be sufficient I/O bandwidth to make a 100 I/O calls per second. But your process that does an I/O call, wait, process, and does an I/O call, wait, process, can only reach a speed of 10 I/O calls per second.
Which means 90% of the I/O pipe is free to do I/O in parallel. So instead of a single process doing that million I/Os (using 10% I/O bandwidth/thruput), Oracle spawns 10 process each doing a 100K I/Os each - thus making better use of the I/O thruput.
So Oracle PQ is useless if you scan small volumes of data - it is intended for large volumes of data. There are overheads in PQ as the parallel processes have to be coordinated in order to work together. When each only needs to do 10 I/Os, the time spend on coordination alone can be more than what the time would have been to simply do a 100 I/Os using a single process.
It is also a fallacy that number of CPUs determine the just how many parallel processes you can start. The real determining factor is the load you can put on your I/O subsystem.
Bottom line is that PQ is nothing "special" or "magic". It is simply a method to reduce I/O latency by performing parallel I/O. And it is only sensible to use when the amount of I/O to be done warrants parallel processing.
Oh yeah - and the CBO is very capable in deciding when to use PQ and not. So rather than force PQ down the CBO's throat using the PARALLEL clause and hardcoding the degrees and instances, it should rather make those decisions (as informed decisions) itself. Which means using the PARALLEL clause on tables and not as SQL hints. The DBA can easily tune that by altering the PARALLEL clause if a table.. The DBA cannot by any means do the same thing when dealing with SQLs that insists on a specific number of PQ processes on a specific number of instances.