Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005
CHAPTER 14 ■ PARALLEL EXECUTION 625 Figure 14-2. Parallel update (PDML) depiction The fact that the table is “parallel” is not sufficient, as it was for parallel query. The reasoning behind the need to explicitly enable PDML in your session is the fact that PDML has certain limitations associated with it, which I list after this example. In the same session, we do a bulk UPDATE that, because the table is “parallel enabled,” will in fact be done in parallel: big_table@ORA10GR1> update big_table set status = 'done'; In the other session, we’ll join V$SESSION to V$TRANSACTION to show the active sessions for our PDML operation, as well as their independent transaction information: ops$tkyte@ORA10GR1> select a.sid, a.program, b.start_time, b.used_ublk, 2 b.xidusn ||'.'|| b.xidslot || '.' || b.xidsqn trans_id 3 from v$session a, v$transaction b 4 where a.taddr = b.addr 5 and a.sid in ( select sid 6 from v$px_session 7 where qcsid = 162 ) 8 order by sid 9 /
626 CHAPTER 14 ■ PARALLEL EXECUTION SID PROGRAM START_TIME USED_UBLK TRANS_ID ---- -------------------------- -------------------- ---------- ------------ 136 oracle@dellpe (P009) 08/03/05 14:28:17 6256 18.9.37 137 oracle@dellpe (P013) 08/03/05 14:28:17 6369 21.39.225 138 oracle@dellpe (P015) 08/03/05 14:28:17 6799 24.16.1175 139 oracle@dellpe (P008) 08/03/05 14:28:17 6729 15.41.68 140 oracle@dellpe (P014) 08/03/05 14:28:17 6462 22.41.444 141 oracle@dellpe (P012) 08/03/05 14:28:17 6436 20.46.46 142 oracle@dellpe (P010) 08/03/05 14:28:17 6607 19.44.37 143 oracle@dellpe (P007) 08/03/05 14:28:17 1 17.12.46 144 oracle@dellpe (P006) 08/03/05 14:28:17 1 13.25.302 145 oracle@dellpe (P003) 08/03/05 14:28:17 1 1.21.1249 146 oracle@dellpe (P002) 08/03/05 14:28:17 1 14.42.49 147 oracle@dellpe (P005) 08/03/05 14:28:17 1 12.18.323 150 oracle@dellpe (P011) 08/03/05 14:28:17 6699 23.2.565 151 oracle@dellpe (P004) 08/03/05 14:28:17 1 16.26.46 152 oracle@dellpe (P001) 08/03/05 14:28:17 1 11.13.336 153 oracle@dellpe (P000) 08/03/05 14:28:17 1 2.29.1103 162 sqlplus@dellpe (TNS V1-V3) 08/03/05 14:25:46 2 3.13.2697 17 rows selected. As we can see, there is more happening here than when we simply queried the table in parallel. We have 17 processes working on this operation, not just 9 as before. This is because the plan that was developed includes a step to update the table and independent steps to update the index entries. Looking at an edited explain plan output from DBMS_XPLAN (trailing columns were removed to permit the output to fit on the page), we see the following: ---------------------------------------------- | Id | Operation | Name | ---------------------------------------------- | 0 | UPDATE STATEMENT | | | 1 | PX COORDINATOR | | | 2 | PX SEND QC (RANDOM) | :TQ10001 | | 3 | INDEX MAINTENANCE | BIG_TABLE | | 4 | PX RECEIVE | | | 5 | PX SEND RANGE | :TQ10000 | | 6 | UPDATE | BIG_TABLE | | 7 | PX BLOCK ITERATOR | | | 8 | TABLE ACCESS FULL| BIG_TABLE | ---------------------------------------------- As a result of the pseudo-distributed implementation of PDML, certain limitations are associated with it: • Triggers are not supported during a PDML operation. This is a reasonable limitation in my opinion, since triggers would tend to add a large amount of overhead to the update, and you are using PDML to go fast—the two features don’t go together.
- 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 666 and 667: CHAPTER 14 ■ PARALLEL EXECUTION 6
- Page 668 and 669: 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
- Page 716 and 717: CHAPTER 15 ■ DATA LOADING AND UNL
- Page 718 and 719: CHAPTER 15 ■ DATA LOADING AND UNL
626<br />
CHAPTER 14 ■ PARALLEL EXECUTION<br />
SID PROGRAM START_TIME USED_UBLK TRANS_ID<br />
---- -------------------------- -------------------- ---------- ------------<br />
136 oracle@dellpe (P009) 08/03/05 14:28:17 6256 18.9.37<br />
137 oracle@dellpe (P013) 08/03/05 14:28:17 6369 21.39.225<br />
138 oracle@dellpe (P015) 08/03/05 14:28:17 6799 24.16.1175<br />
139 oracle@dellpe (P008) 08/03/05 14:28:17 6729 15.41.68<br />
140 oracle@dellpe (P014) 08/03/05 14:28:17 6462 22.41.444<br />
141 oracle@dellpe (P012) 08/03/05 14:28:17 6436 20.46.46<br />
142 oracle@dellpe (P010) 08/03/05 14:28:17 6607 19.44.37<br />
143 oracle@dellpe (P007) 08/03/05 14:28:17 1 17.12.46<br />
144 oracle@dellpe (P006) 08/03/05 14:28:17 1 13.25.302<br />
145 oracle@dellpe (P003) 08/03/05 14:28:17 1 1.21.1249<br />
146 oracle@dellpe (P002) 08/03/05 14:28:17 1 14.42.49<br />
147 oracle@dellpe (P005) 08/03/05 14:28:17 1 12.18.323<br />
150 oracle@dellpe (P011) 08/03/05 14:28:17 6699 23.2.565<br />
151 oracle@dellpe (P004) 08/03/05 14:28:17 1 16.26.46<br />
152 oracle@dellpe (P001) 08/03/05 14:28:17 1 11.13.336<br />
153 oracle@dellpe (P000) 08/03/05 14:28:17 1 2.29.1103<br />
162 sqlplus@dellpe (TNS V1-V3) 08/03/05 14:25:46 2 3.13.2697<br />
17 rows selected.<br />
As we can see, there is more happening here than when we simply queried the table in<br />
parallel. We have 17 processes working on this operation, not just 9 as before. This is because<br />
the plan that was developed includes a step to update the table <strong>and</strong> independent steps to<br />
update the index entries. Looking at an edited explain plan output from DBMS_XPLAN (trailing<br />
columns were removed to permit the output to fit on the page), we see the following:<br />
----------------------------------------------<br />
| Id | Operation | Name |<br />
----------------------------------------------<br />
| 0 | UPDATE STATEMENT | |<br />
| 1 | PX COORDINATOR | |<br />
| 2 | PX SEND QC (RANDOM) | :TQ10001 |<br />
| 3 | INDEX MAINTENANCE | BIG_TABLE |<br />
| 4 | PX RECEIVE | |<br />
| 5 | PX SEND RANGE | :TQ10000 |<br />
| 6 | UPDATE | BIG_TABLE |<br />
| 7 | PX BLOCK ITERATOR | |<br />
| 8 | TABLE ACCESS FULL| BIG_TABLE |<br />
----------------------------------------------<br />
As a result of the pseudo-distributed implementation of PDML, certain limitations are<br />
associated with it:<br />
• Triggers are not supported during a PDML operation. This is a reasonable limitation in<br />
my opinion, since triggers would tend to add a large amount of overhead to the update,<br />
<strong>and</strong> you are using PDML to go fast—the two features don’t go together.
Change language