Database Reference
In-Depth Information
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 two-phase commit 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 commits.
Figure 14-2.
Parallel update (PDML) depiction
We can actually observe the fact that there are separate independent transactions created for the parallel
execution servers. We'll use two sessions again. In the session with
SID=258
, we explicitly enable parallel DML. PDML
differs from parallel query in that regard; unless you explicitly ask for it, you will
not
get it:
EODA@ORA12CR1> alter session enable parallel dml;
Session altered.
