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

640
CHAPTER 14 ■ PARALLEL EXECUTION
There is one obvious thing you could do here: use array processing for the UPDATE/INSERT
after the complex process. However, that isn’t going to give you a 50 percent reduction or more
in runtime, and often that is what you are looking for. Don’t get me wrong, you definitely want
to implement array processing for the modifications here, but it won’t make this process run
two, three, four, or more times faster.
Now, suppose this process runs at night on a machine with four CPUs, and it is the only
activity taking place. You have observed that only one CPU is partially used on this system,
and the disk system is not being used very much at all. Further, this process is taking hours,
and every day it takes a little longer as more data is added. You need to reduce the runtime by
many times—it needs to run four or eight times faster—so incremental percentage increases
will not be sufficient. What can you do?
There are two approaches you can take. One approach is to implement a parallel pipelined
function, whereby Oracle will decide on appropriate degrees of parallelism (assuming
you have opted for that, which is recommended). Oracle will create the sessions, coordinate
them, and run them, very much like the previous example with parallel DDL where, by using
CREATE TABLE AS SELECT OR INSERT /*+APPEND*/, Oracle fully automated parallel direct path
loads for us. The other approach is DIY parallelism. We’ll take a look at both approaches in the
sections that follow.
Parallel Pipelined Functions
We’d like to take that very serial process PROCESS_DATA from earlier and have Oracle execute
it in parallel for us. To accomplish this, we need to turn the routine “inside out.” Instead of
selecting rows from some table, processing them, and inserting them into another table, we
will insert into another table the results of fetching some rows and processing them. We will
remove the INSERT at the bottom of that loop and replace it in the code with a PIPE ROW clause.
The PIPE ROW clause allows our PL/SQL routine to generate table data as its output, so we’ll
be able to SELECT from our PL/SQL process. The PL/SQL routine that used to procedurally
process the data becomes a table, in effect, and the rows we fetch and process are the outputs.
We’ve seen this many times throughout this book every time we’ve issued the following:
Select * from table(dbms_xplan.display);
That is a PL/SQL routine that reads the PLAN_TABLE; restructures the output, even to the
extent of adding rows; and then outputs this data using PIPE ROW to send it back to the client.
We’re going to do the same thing here in effect, but we’ll allow for it to be processed in parallel.
We’re going to use two tables in this example: T1 and T2. T1 is the table we were reading
previously, and T2 is the table we need to move this information into. Assume this is some sort
of ETL process we run to take the transactional data from the day and convert it into reporting
information for tomorrow. The two tables we’ll use are as follows:
ops$tkyte-ORA10G> create table t1
2 as
3 select object_id id, object_name text
4 from all_objects;
Table created.
ops$tkyte-ORA10G> begin
2 dbms_stats.set_table_stats