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 621 ■Note The ROWS, BYTES, and TIME columns were removed from this plan output to allow it to fit on the page. The aggregate time for the query, however, was 00:00:54 as opposed to the previous estimate of 00:06:29 for the serial plan. Remember, these are estimates, not promises! Also, this is the plan output from Oracle 10g—the plan output from Oracle9i would have less detail (four steps instead of seven), but the net effect is identical. If you read this plan from the bottom up, starting at ID=6, it shows the steps described in Figure 14-1. The full table scan would be split up into many “smaller scans” (step 5). Each of those would aggregate their COUNT(STATUS) values (step 4). These subresults would be transmitted to the parallel query coordinator (steps 2 and 3), which would aggregate these results further (step 1) and output the answer. If you were to actually execute this query on a freshly started system (where no other parallel execution had been done), you might observe the following. Here we are using the Linux ps command to find processes that represent parallel query processes (we expect to find none), running the query with parallel execution enabled, and then looking for those processes again: big_table@ORA10GR1> host ps -auxww | grep '^ora10gr1.*ora_p00._ora10g' big_table@ORA10GR1> select count(status) from big_table; COUNT(STATUS) ------------- 10000000 big_table@ORA10GR1> host ps -auxww | grep '^ora10gr1.*ora_p00._ora10g' ora10gr1 3411 35.5 0.5 1129068 12200 ? S 13:27 0:02 ora_p000_ora10gr1 ora10gr1 3413 28.0 0.5 1129064 12196 ? S 13:27 0:01 ora_p001_ora10gr1 ora10gr1 3415 26.0 0.5 1129064 12196 ? S 13:27 0:01 ora_p002_ora10gr1 ora10gr1 3417 23.3 0.5 1129044 12212 ? S 13:27 0:01 ora_p003_ora10gr1 ora10gr1 3419 19.5 0.5 1129040 12228 ? S 13:27 0:01 ora_p004_ora10gr1 ora10gr1 3421 19.1 0.5 1129056 12188 ? S 13:27 0:01 ora_p005_ora10gr1 ora10gr1 3423 19.0 0.5 1129056 12164 ? S 13:27 0:01 ora_p006_ora10gr1 ora10gr1 3425 21.6 0.5 1129048 12204 ? S 13:27 0:01 ora_p007_ora10gr1 As we can see, there are now eight parallel execution servers that have been started by Oracle. If we are curious enough to want to “watch” parallel query, we can easily do so using two sessions. In the session we will run the parallel query in, we’ll start by determining our SID: big_table@ORA10GR1> select sid from v$mystat where rownum = 1; SID ---------- 162

622 CHAPTER 14 ■ PARALLEL EXECUTION Now, in another session, we get this query ready to run: ops$tkyte@ORA10GR1> select sid, qcsid, server#, degree 2 from v$px_session 3 where qcsid = 162 Shortly after starting the parallel query in the session with SID=162, we come back to this second session and run the query: 4 / SID QCSID SERVER# DEGREE ---------- ---------- ---------- ---------- 145 162 1 8 150 162 2 8 147 162 3 8 151 162 4 8 146 162 5 8 152 162 6 8 143 162 7 8 144 162 8 8 162 162 9 rows selected. We see here that our parallel query session (SID=162) is the query coordinator SID (QCSID) for nine rows in this dynamic performance view. Our session is “coordinating” or controlling these parallel query resources now. We can see each has its own SID; in fact, each is a separate Oracle session and shows up as such in V$SESSION during the execution of our parallel query: ops$tkyte@ORA10GR1> select sid, username, program 2 from v$session 3 where sid in ( select sid 4 from v$px_session 5 where qcsid = 162 ) 6 / SID USERNAME PROGRAM ---------- ------------------------------ ------------------------------- 143 BIG_TABLE oracle@dellpe (P005) 144 BIG_TABLE oracle@dellpe (P002) 145 BIG_TABLE oracle@dellpe (P006) 146 BIG_TABLE oracle@dellpe (P004) 147 BIG_TABLE oracle@dellpe (P003) 150 BIG_TABLE oracle@dellpe (P001) 151 BIG_TABLE oracle@dellpe (P000) 153 BIG_TABLE oracle@dellpe (P007) 162 BIG_TABLE sqlplus@dellpe (TNS V1-V3) 9 rows selected.

CHAPTER 14 ■ PARALLEL EXECUTION 621<br />

■Note The ROWS, BYTES, <strong>and</strong> TIME columns were removed from this plan output to allow it to fit on the<br />

page. The aggregate time for the query, however, was 00:00:54 as opposed to the previous estimate of<br />

00:06:29 for the serial plan. Remember, these are estimates, not promises! Also, this is the plan output from<br />

<strong>Oracle</strong> 10g—the plan output from <strong>Oracle</strong>9i would have less detail (four steps instead of seven), but the net<br />

effect is identical.<br />

If you read this plan from the bottom up, starting at ID=6, it shows the steps described in<br />

Figure 14-1. The full table scan would be split up into many “smaller scans” (step 5). Each of<br />

those would aggregate their COUNT(STATUS) values (step 4). These subresults would be transmitted<br />

to the parallel query coordinator (steps 2 <strong>and</strong> 3), which would aggregate these results<br />

further (step 1) <strong>and</strong> output the answer.<br />

If you were to actually execute this query on a freshly started system (where no other parallel<br />

execution had been done), you might observe the following. Here we are using the Linux<br />

ps comm<strong>and</strong> to find processes that represent parallel query processes (we expect to find<br />

none), running the query with parallel execution enabled, <strong>and</strong> then looking for those<br />

processes again:<br />

big_table@ORA10GR1> host ps -auxww | grep '^ora10gr1.*ora_p00._ora10g'<br />

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

COUNT(STATUS)<br />

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

10000000<br />

big_table@ORA10GR1> host ps -auxww | grep '^ora10gr1.*ora_p00._ora10g'<br />

ora10gr1 3411 35.5 0.5 1129068 12200 ? S 13:27 0:02 ora_p000_ora10gr1<br />

ora10gr1 3413 28.0 0.5 1129064 12196 ? S 13:27 0:01 ora_p001_ora10gr1<br />

ora10gr1 3415 26.0 0.5 1129064 12196 ? S 13:27 0:01 ora_p002_ora10gr1<br />

ora10gr1 3417 23.3 0.5 1129044 12212 ? S 13:27 0:01 ora_p003_ora10gr1<br />

ora10gr1 3419 19.5 0.5 1129040 12228 ? S 13:27 0:01 ora_p004_ora10gr1<br />

ora10gr1 3421 19.1 0.5 1129056 12188 ? S 13:27 0:01 ora_p005_ora10gr1<br />

ora10gr1 3423 19.0 0.5 1129056 12164 ? S 13:27 0:01 ora_p006_ora10gr1<br />

ora10gr1 3425 21.6 0.5 1129048 12204 ? S 13:27 0:01 ora_p007_ora10gr1<br />

As we can see, there are now eight parallel execution servers that have been started by<br />

<strong>Oracle</strong>. If we are curious enough to want to “watch” parallel query, we can easily do so using<br />

two sessions. In the session we will run the parallel query in, we’ll start by determining<br />

our SID:<br />

big_table@ORA10GR1> select sid from v$mystat where rownum = 1;<br />

SID<br />

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

162

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

Saved successfully!

Ooh no, something went wrong!