05.11.2015 Views

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

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

620<br />

CHAPTER 14 ■ PARALLEL EXECUTION<br />

That is a typical serial plan. No parallelism is involved because we did not request parallel<br />

query to be enabled, <strong>and</strong> by default it will not be.<br />

We may enable parallel query in a variety of ways, including use of a hint directly in the<br />

query or by altering the table to enable parallel execution paths to be considered (which is the<br />

option we use here).<br />

We can specifically dictate the degree of parallelism to be considered in execution paths<br />

against this table. We can tell <strong>Oracle</strong>, “We would like you to use parallel degree 4 when creating<br />

execution plans against this table,” for example:<br />

big_table@ORA10GR1> alter table big_table parallel 4;<br />

Table altered.<br />

I prefer to just tell <strong>Oracle</strong>, “Please consider parallel execution, but you figure out the<br />

appropriate degree of parallelism based on the current system workload <strong>and</strong> the query itself.”<br />

That is, let the degree of parallelism vary over time as the workload on the system increases<br />

<strong>and</strong> decreases. If we have plenty of free resources, the degree of parallelism will go up; in times<br />

of limited available resources, the degree of parallelism will go down. Rather than overload<br />

the machine with a fixed degree of parallelism, this approach allows <strong>Oracle</strong> to dynamically<br />

increase or decrease the amount of concurrent resources required by the query.<br />

Therefore, we simply enable parallel query against this table via the following ALTER TABLE<br />

comm<strong>and</strong>:<br />

big_table@ORA10GR1> alter table big_table parallel;<br />

Table altered.<br />

That is all there is to it—parallel query will now be considered for operations against this<br />

table. When we rerun the explain plan, this time we see the following:<br />

big_table@ORA10GR1> explain plan for<br />

2 select count(status) from big_table;<br />

Explained.<br />

big_table@ORA10GR1> select * from table(dbms_xplan.display);<br />

PLAN_TABLE_OUTPUT<br />

-----------------------------------------<br />

Plan hash value: 1651916128<br />

----------------------------------------------------------------------------<br />

|Id | Operation | Name |Cost(%CPU)| TQ |IN-OUT|PQ Distrib |<br />

----------------------------------------------------------------------------<br />

| 0| SELECT STATEMENT | | 4465 (1)| | | |<br />

| 1| SORT AGGREGATE | | | | | |<br />

| 2| PX COORDINATOR | | | | | |<br />

| 3| PX SEND QC (RANDOM) | :TQ10000 | |Q1,00| P->S |QC (RAND) |<br />

| 4| SORT AGGREGATE | | |Q1,00| PCWP | |<br />

| 5| PX BLOCK ITERATOR | | 4465 (1)|Q1,00| PCWC | |<br />

| 6| TABLE ACCESS FULL| BIG_TABLE| 4465 (1)|Q1,00| PCWP | |<br />

----------------------------------------------------------------------------

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

Saved successfully!

Ooh no, something went wrong!