Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005
Share Embed Flag
Download ePaper

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

rekharaghuram
from rekharaghuram More from this publisher
05.11.2015 Views

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.

648 CHAPTER 14 ■ PARALLEL EXECUTION Summary In this chapter, we explored the concept of parallel execution in Oracle. I started by presenting an analogy to help frame where and when parallel execution is applicable, namely when we have long-running statements or procedures and plenty of available resources. Then we looked at how Oracle can employ parallelism. We started with parallel query and how Oracle can break large serial operations, such as a full scan, into smaller pieces that can run concurrently. We moved on to parallel DML (PDML) and covered the rather extensive list of restrictions that accompany it. Then we looked at the sweet spot for parallel operations: parallel DDL. Parallel DDL is a tool for the DBA and developer alike to quickly perform those large maintenance operations typically done during off-peak times when resources are available. We briefly touched on the fact that Oracle provides parallel recovery before we moved on to discuss procedural parallelism. Here we saw two techniques for parallelizing our procedures: one where Oracle does it and the other where we do it ourselves. If we’re designing a process from scratch, we might well consider designing it to allow Oracle to parallelize it for us, as the future addition or reduction of resources would easily permit the degree of parallelism to vary. However, if we have existing code that needs to quickly be “fixed” to be parallel, we may opt for do-it-yourself (DIY) parallelism, which we covered by examining two techniques, rowid ranges and primary key ranges, both of which use DBMS_JOB to carry out the job in parallel in the background for us.

648<br />

CHAPTER 14 ■ PARALLEL EXECUTION<br />

Summary<br />

In this chapter, we explored the concept of parallel execution in <strong>Oracle</strong>. I started by presenting<br />

an analogy to help frame where <strong>and</strong> when parallel execution is applicable, namely when we<br />

have long-running statements or procedures <strong>and</strong> plenty of available resources.<br />

Then we looked at how <strong>Oracle</strong> can employ parallelism. We started with parallel query <strong>and</strong><br />

how <strong>Oracle</strong> can break large serial operations, such as a full scan, into smaller pieces that can<br />

run concurrently. We moved on to parallel DML (PDML) <strong>and</strong> covered the rather extensive list<br />

of restrictions that accompany it.<br />

Then we looked at the sweet spot for parallel operations: parallel DDL. Parallel DDL is a<br />

tool for the DBA <strong>and</strong> developer alike to quickly perform those large maintenance operations<br />

typically done during off-peak times when resources are available. We briefly touched on the<br />

fact that <strong>Oracle</strong> provides parallel recovery before we moved on to discuss procedural parallelism.<br />

Here we saw two techniques for parallelizing our procedures: one where <strong>Oracle</strong> does<br />

it <strong>and</strong> the other where we do it ourselves.<br />

If we’re designing a process from scratch, we might well consider designing it to allow<br />

<strong>Oracle</strong> to parallelize it for us, as the future addition or reduction of resources would easily permit<br />

the degree of parallelism to vary. However, if we have existing code that needs to quickly<br />

be “fixed” to be parallel, we may opt for do-it-yourself (DIY) parallelism, which we covered by<br />

examining two techniques, rowid ranges <strong>and</strong> primary key ranges, both of which use DBMS_JOB to<br />

carry out the job in parallel in the background for us.

logo

products

Resources

Company

Terms of service
Privacy policy
Cookie policy
Cookie settings
Imprint
Change language
Made with love in Switzerland
© 2024 Yumpu.com all rights reserved

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!