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

CHAPTER 14 ■ PARALLEL EXECUTION 647
173 130978
174 130925
175 129863
176 106154
177 140772
178 140778
179 90475
8 rows selected.
It’s not as evenly distributed as the Oracle built-in parallelism in this case, but it’s pretty
good. If you recall, earlier you saw how many rows were processed by each parallel execution
server and, using the built-in parallelism, the row counts were very close to each other (they
were off only by one or two). Here we had a job that processed as few as 90,475 rows and one
that processed as many as 140,778. Most of them processed about 130,000 rows in this case.
Suppose, however, that you do not want to use the rowid processing—perhaps the query
is not as simple as SELECT * FROM T and involves joins and other constructs that make using
the rowid impractical. You can use the primary key of some table instead. For example, say
you want to break that same BIG_TABLE into ten pieces to be processed concurrently by primary
key. You can do that easily using the NTILE built-in analytic function. The process is
rather straightforward:
big_table-ORA10G> select nt, min(id), max(id), count(*)
2 from (
3 select id, ntile(10) over (order by id) nt
4 from big_table
5 )
6 group by nt;
NT MIN(ID) MAX(ID) COUNT(*)
---------- ---------- ---------- ----------
1 1 100000 100000
2 100001 200000 100000
3 200001 300000 100000
4 300001 400000 100000
5 400001 500000 100000
6 500001 600000 100000
7 600001 700000 100000
8 700001 800000 100000
9 800001 900000 100000
10 900001 1000000 100000
10 rows selected.
Now you have ten nonoverlapping primary key ranges—all of nice, equal size—that you
can use to implement the same DBMS_JOB technique as shown earlier to parallelize your
process.