Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005
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.
- Page 616 and 617: CHAPTER 13 ■ PARTITIONING 571 PAR
- Page 618 and 619: CHAPTER 13 ■ PARTITIONING 573 35
- Page 620 and 621: CHAPTER 13 ■ PARTITIONING 575 If
- Page 622 and 623: CHAPTER 13 ■ PARTITIONING 577 We
- Page 624 and 625: CHAPTER 13 ■ PARTITIONING 579 14
- Page 626 and 627: CHAPTER 13 ■ PARTITIONING 581 ops
- Page 628 and 629: CHAPTER 13 ■ PARTITIONING 583 In
- Page 630 and 631: CHAPTER 13 ■ PARTITIONING 585 ops
- Page 632 and 633: CHAPTER 13 ■ PARTITIONING 587 | S
- Page 634 and 635: CHAPTER 13 ■ PARTITIONING 589 12
- Page 636 and 637: CHAPTER 13 ■ PARTITIONING 591 ops
- Page 638 and 639: CHAPTER 13 ■ PARTITIONING 593 •
- Page 640 and 641: CHAPTER 13 ■ PARTITIONING 595 Now
- Page 642 and 643: CHAPTER 13 ■ PARTITIONING 597 the
- Page 644 and 645: CHAPTER 13 ■ PARTITIONING 599 imp
- Page 646 and 647: CHAPTER 13 ■ PARTITIONING 601 OLT
- Page 648 and 649: CHAPTER 13 ■ PARTITIONING 603 5 s
- Page 650 and 651: CHAPTER 13 ■ PARTITIONING 605 Sur
- Page 652 and 653: CHAPTER 13 ■ PARTITIONING 607 On
- Page 654 and 655: CHAPTER 13 ■ PARTITIONING 609 Row
- Page 656 and 657: CHAPTER 13 ■ PARTITIONING 611 So,
- Page 658 and 659: CHAPTER 13 ■ PARTITIONING 613 Aud
- Page 660 and 661: CHAPTER 14 ■ ■ ■ Parallel Exe
- Page 662 and 663: CHAPTER 14 ■ PARALLEL EXECUTION 6
- Page 664 and 665: CHAPTER 14 ■ PARALLEL EXECUTION 6
- Page 668 and 669: CHAPTER 14 ■ PARALLEL EXECUTION 6
- Page 670 and 671: CHAPTER 14 ■ PARALLEL EXECUTION 6
- Page 672 and 673: CHAPTER 14 ■ PARALLEL EXECUTION 6
- Page 674 and 675: CHAPTER 14 ■ PARALLEL EXECUTION 6
- Page 676 and 677: CHAPTER 14 ■ PARALLEL EXECUTION 6
- Page 678 and 679: CHAPTER 14 ■ PARALLEL EXECUTION 6
- Page 680 and 681: CHAPTER 14 ■ PARALLEL EXECUTION 6
- Page 682 and 683: CHAPTER 14 ■ PARALLEL EXECUTION 6
- Page 684 and 685: CHAPTER 14 ■ PARALLEL EXECUTION 6
- Page 686 and 687: CHAPTER 14 ■ PARALLEL EXECUTION 6
- Page 688 and 689: CHAPTER 14 ■ PARALLEL EXECUTION 6
- Page 690 and 691: CHAPTER 14 ■ PARALLEL EXECUTION 6
- Page 692 and 693: CHAPTER 14 ■ PARALLEL EXECUTION 6
- Page 694 and 695: CHAPTER 15 ■ ■ ■ Data Loading
- Page 696 and 697: CHAPTER 15 ■ DATA LOADING AND UNL
- Page 698 and 699: CHAPTER 15 ■ DATA LOADING AND UNL
- Page 700 and 701: CHAPTER 15 ■ DATA LOADING AND UNL
- Page 702 and 703: CHAPTER 15 ■ DATA LOADING AND UNL
- Page 704 and 705: CHAPTER 15 ■ DATA LOADING AND UNL
- Page 706 and 707: CHAPTER 15 ■ DATA LOADING AND UNL
- Page 708 and 709: CHAPTER 15 ■ DATA LOADING AND UNL
- Page 710 and 711: CHAPTER 15 ■ DATA LOADING AND UNL
- Page 712 and 713: CHAPTER 15 ■ DATA LOADING AND UNL
- Page 714 and 715: CHAPTER 15 ■ DATA LOADING AND UNL
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