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

CHAPTER 14 ■ PARALLEL EXECUTION 623
■Note If a parallel execution is not occurring in your system, do not expect to see the parallel execution
servers in V$SESSION. They will be in V$PROCESS, but will not have a session established unless they are
being used. The parallel execution servers will be connected to the database, but will not have a session
established. See Chapter 5 for details on the difference between a session and a connection.
In a nutshell, that is how parallel query—and, in fact, parallel execution in general—works.
It entails a series of parallel execution servers working in tandem to produce subresults that
are fed either to other parallel execution servers for further processing or to the coordinator
for the parallel query.
In this particular example, as depicted, we had BIG_TABLE spread across four separate
devices, in a single tablespace (a tablespace with four data files). When implementing parallel
execution, it is generally “optimal” to have your data spread over as many physical devices as
possible. You can achieve this in a number of ways:
• Using RAID striping across disks
• Using ASM, with its built-in striping
• Using partitioning to physically segregate BIG_TABLE over many disks
• Using multiple data files in a single tablespace, thus allowing Oracle to allocate extents
for the BIG_TABLE segment in many files
In general, parallel execution works best when given access to as many resources (CPU,
memory, and I/O) as possible. However, that is not to say that nothing can be gained from parallel
query if the entire set of data were on a single disk, but you would perhaps not gain as
much as would be gained using multiple disks. The reason you would likely gain some speed
in response time, even when using a single disk, is that when a given parallel execution server
is counting rows it is not reading them, and vice versa. So, two parallel execution servers may
well be able to complete the counting of all rows in less time than a serial plan would.
Likewise, you can benefit from parallel query even on a single CPU machine. It is doubtful
that a serial SELECT COUNT(*) would use 100 percent of the CPU on a single CPU machine—it
would be spending part of its time performing (and waiting for) physical I/O to disk. Parallel
query would allow you to fully utilize the resources (the CPU and I/O, in this case) on the
machine, whatever those resources may be.
That final point brings us back to the earlier quote from Practical Oracle8i: Building
Efficient Databases: parallel query is essentially nonscalable. If you allowed four sessions to
simultaneously perform queries with two parallel execution servers on that single CPU machine,
you would probably find their response times to be longer than if they just processed serially.
The more processes clamoring for a scarce resource, the longer it will take to satisfy all requests.
And remember, parallel query requires two things to be true. First, you need to have a
large task to perform—for example, a long-running query, the runtime of which is measured
in minutes, hours, or days, not in seconds or subseconds. This implies that parallel query is
not a solution to be applied in a typical OLTP system, where you are not performing longrunning
tasks. Enabling parallel execution on these systems is often disastrous. Second, you