Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

618
CHAPTER 14 ■ PARALLEL EXECUTION
Here you would hold the meeting, review the process, assign the work, act as the coordinator,
collect the results, bind up the finished report, and deliver it. It would not have been done in
one-tenth the time, but perhaps one-eighth or so. Again, I say this with the proviso that you
have sufficient free resources. If you have a large staff that is currently not actually doing anything,
then splitting up the work makes complete sense.
However, consider that as the manager, your staff is multitasking and they have a lot on
their plates. In that case, you have to be careful with that big project. You need to be sure not
to overwhelm your staff; you don’t want to work them beyond the point of exhaustion. You
can’t delegate out more work than your resources (your people) can cope with, otherwise
they’ll quit. If your staff is already fully utilized, adding more work will cause all schedules to
slip and all projects to be delayed.
Parallel execution in Oracle is very much the same. If you have a task that takes many
minutes, hours, or days, then the introduction of parallel execution may be the thing that
makes it run eight times faster. But then again, if you are already seriously low on resources
(the overworked team of people), then the introduction of parallel execution would be something
to avoid, as the system will become even more bogged down. While the Oracle server
processes won’t “quit” in protest, they could start running out of RAM and failing, or just
suffer from such long waits for I/O or CPU as to make it appear as if they were doing no
work whatsoever.
If you keep that in mind, remembering never to take an analogy to illogical extremes,
you’ll have the commonsense guiding rule to see if parallelism can be of some use. If you
have a job that takes seconds, it is doubtful that parallel execution can be used to make it go
faster—the converse would be more likely. If you are low on resources already (i.e., your
resources are fully utilized), adding parallel execution would likely make things worse, not
better. Parallel execution is excellent for when you have a really big job and plenty of excess
capacity. In this chapter, we’ll take a look at some of the ways we can exploit those resources.
Parallel Query
Parallel query allows a single SQL SELECT statement to be divided into many smaller queries,
with each component query being run concurrently, and then the results from each combined
to provide the final answer. For example, consider the following query:
big_table@ORA10G> select count(status) from big_table;
Using parallel query, this query could use some number of parallel sessions; break the
BIG_TABLE into small, nonoverlapping slices; and ask each parallel session to read the table
and count its section of rows. The parallel query coordinator for this session would then
receive each of the aggregated counts from the individual parallel sessions and further aggregate
them, returning the final answer to the client application. Graphically, it might look like
Figure 14-1.
The P000, P001, P002, and P003 processes are known as parallel execution servers, sometimes
also referred to as parallel query (PQ) slaves. Each of these parallel execution servers is a
separate session connected as if it were a dedicated server process. Each one is responsible for
scanning a nonoverlapping region of BIG_TABLE, aggregating their results subsets, and sending
back their output to the coordinating server—the original session’s server process—which will
aggregate the subresults into the final answer.