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

624
CHAPTER 14 ■ PARALLEL EXECUTION
need ample free resources such as CPU, I/O, and memory. If you are lacking in any of these,
then parallel query may well push your utilization of that resource over the edge, negatively
impacting overall performance and runtime.
In the past, parallel query was considered mandatory for many data warehouses simply
because in the past (say, in 1995) data warehouses were rare and typically had a very small,
focused user base. Today in 2005, data warehouses are literally everywhere and support user
communities that are as large as those found for many transactional systems. This means that
you may well not have sufficient free resources at any given point in time to enable parallel
query on these systems. That doesn’t mean parallel execution in general is not useful in this
case—it just might be more of a DBA tool, as we’ll see in the section “Parallel DDL,” rather
than a parallel query tool.
Parallel DML
The Oracle documentation limits the scope of the term DML (PDML) to include only INSERT,
UPDATE, DELETE, and MERGE (it does not include SELECT as normal DML does). During PDML,
Oracle may use many parallel execution servers to perform your INSERT, UPDATE, DELETE, or
MERGE instead of a single serial process. On a multi-CPU machine with plenty of I/O bandwidth,
the potential increase in speed may be large for mass DML operations.
However, you should not look to PDML as a feature to speed up your OLTP-based applications.
As stated previously, parallel operations are designed to fully and totally maximize the
utilization of a machine. They are designed so that a single user can completely use all of the
disks, CPU, and memory on the machine. In certain data warehouses (with lots of data and
few users), this is something you may want to achieve. In an OLTP system (with a lot of users
all doing short, fast transactions), you do not want to give a user the ability to fully take over
the machine resources.
This sounds contradictory: we use parallel query to scale up, so how could it not be scalable?
When applied to an OLTP system, the statement is quite accurate. Parallel query is not
something that scales up as the number of concurrent users increases. Parallel query was
designed to allow a single session to generate as much work as 100 concurrent sessions would.
In our OLTP system, we really do not want a single user to generate the work of 100 users.
PDML is useful in a large data warehousing environment to facilitate bulk updates to
massive amounts of data. The PDML operation is executed in much the same way as a distributed
query would be executed by Oracle, with each parallel execution server acting like a
process in a separate database instance. Each slice of the table is modified by a separate
thread with its own independent transaction (and hence its own undo segment, hopefully).
After they are all done, the equivalent of a fast 2PC is performed to commit the separate, independent
transactions. Figure 14-2 depicts a parallel update using four parallel execution
servers. Each of the parallel execution servers has its own independent transaction, in which
either all are committed with the PDML coordinating session or none commit.
We can actually observe the fact that there are separate independent transactions created
for the parallel execution servers. We’ll use two sessions again, as before. In the session with
SID=162, we explicitly enable parallel DML. PDML differs from parallel query in that regard;
unless you explicitly ask for it, you will not get it.
big_table@ORA10GR1> alter session enable parallel dml;
Session altered.