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

CHAPTER 14 ■ PARALLEL EXECUTION 643
8 /
48250 rows created.
ops$tkyte-ORA10G> commit;
Commit complete.
Just to see what happened here, we can query the newly inserted data out and group by
SESSION_ID to see first how many parallel execution servers were used, and second how many
rows each processed:
ops$tkyte-ORA10G> select session_id, count(*)
2 from t2
3 group by session_id;
SESSION_ID COUNT(*)
---------- ----------
241 8040
246 8045
253 8042
254 8042
258 8040
260 8041
6 rows selected.
Apparently, we used six parallel execution servers for the SELECT component of this parallel
operation, and each one processed about 8,040 records each.
As you can see, Oracle parallelized our process, but we underwent a fairly radical rewrite
of our process. This is a long way from the original implementation. So, while Oracle can
process our routine in parallel, we may well not have any routines that are coded to be parallelized.
If a rather large rewrite of your procedure is not feasible, you may be interested in the
next implementation: DIY parallelism.
Do-It-Yourself Parallelism
Say we have that same process as in the preceding section: the serial, simple procedure. We
cannot afford a rather extensive rewrite of the implementation, but we would like to execute it
in parallel. What can we do? My approach many times has been to use rowid ranges to break
up the table into some number of ranges that don’t overlap (yet completely cover the table).
This is very similar to how Oracle performs a parallel query conceptually. If you think of a
full table scan, Oracle processes that by coming up with some method to break the table into
many “small” tables, each of which is processed by a parallel execution server. We are going to
do the same thing using rowid ranges. In early releases, Oracle’s parallel implementation actually
used rowid ranges itself.
We’ll use a BIG_TABLE of 1,000,000 rows, as this technique works best on big tables with
lots of extents, and the method I use for creating rowid ranges depends on extent boundaries.
The more extents used, the better the data distribution. So, after creating the BIG_TABLE with
1,000,000 rows, we’ll create T2 like this: