これは最も単純な方法です。2つの表が両方とも結合列によってパーティション化されます。例では、customers
表とsales
表の両方がcust_id
列でパーティション化されます。このパーティション化方法では、表をcust_id
(両方とも同じ顧客ID番号を表す)で結合するフル・パーティション・ワイズ結合が有効になります。このシナリオは、レンジ - レンジ、リスト - リストおよびハッシュ - ハッシュ・パーティション化に対応します。時間隔 - レンジおよび時間隔 - 時間隔のフル・パーティション・ワイズ結合もサポートされ、レンジ - レンジと比較できます。
シリアルでは、この結合は、ハッシュ・パーティションの一致する組の間で、1回ずつ順番に実行されます。1組のパーティションが結合されると、別の組の結合が開始されます。すべてのパーティションの組が処理されると、結合が完了します。作業負荷を均等に分散するためには、要求した並列度よりも多数のパーティションを使用するか、要求した並列度と同数の同一サイズ・パーティションを使用する必要があります。同一サイズ・パーティションを作成するには、パーティション数を2の累乗として、一意の列(またはほぼ一意の列)に対してハッシュ・パーティション化を使用することをお薦めします。
注意:
一致する1組のハッシュ・パーティションは、同じパーティション番号を持つ各表のパーティションとして定義されています。たとえば、ハッシュ・パーティション化に基づくフル・パーティション・ワイズ結合では、sales
のパーティション0とcustomers
のパーティション0、sales
のパーティション1とcustomers
のパーティション1のように結合されます。
参照パーティション化は、2つの表をともにパーティション化する簡単な方法です。これにより、文で表が結合される際に、オプティマイザがフル・パーティション・ワイズ結合を常に検討できるようになります。
フル・パーティション・ワイズ結合のパラレル実行は、シリアル実行を単にパラレル化したものです。パーティションが1組ずつ結合されるかわりに、問合せサーバーによってパーティションの複数の組がパラレルに結合されます。図3-1に、フル・パーティション・ワイズ結合のパラレル実行を示します。
次の例は、同数のパーティションを含むようにハッシュで同等にパーティション化されたsales
とcustomers
の実行計画を示します。この計画はフル・パーティション・ワイズ結合を示しています。
explain plan for SELECT c.cust_last_name, COUNT(*) FROM sales s, customers c WHERE s.cust_id = c.cust_id AND s.time_id BETWEEN TO_DATE('01-JUL-1999', 'DD-MON-YYYY') AND (TO_DATE('01-OCT-1999', 'DD-MON-YYYY')) GROUP BY c.cust_last_name HAVING COUNT(*) > 100; ------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Pstart| Pstop| TQ |IN-OUT| PQ Distrib| ------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 46 | 1196 | | | | | | | 1 | PX COORDINATOR | | | | | | | | | | 2 | PX SEND QC (RANDOM) | :TQ10001 | 46 | 1196 | | | Q1,01 | P->S | QC (RAND) | |* 3 | FILTER | | | | | | Q1,01 | PCWC | | | 4 | HASH GROUP BY | | 46 | 1196 | | | Q1,01 | PCWP | | | 5 | PX RECEIVE | | 46 | 1196 | | | Q1,01 | PCWP | | | 6 | PX SEND HASH | :TQ10000 | 46 | 1196 | | | Q1,00 | P->P | HASH | | 7 | HASH GROUP BY | | 46 | 1196 | | | Q1,00 | PCWP | | | 8 | PX PARTITION HASH ALL| | 59158 | 1502K| 1 | 16 | Q1,00 | PCWC | | |* 9 | HASH JOIN | | 59158 | 1502K| | | Q1,00 | PCWP | | | 10 | TABLE ACCESS FULL | CUSTOMERS | 55500 | 704K| 1 | 16 | Q1,00 | PCWP | | |* 11 | TABLE ACCESS FULL | SALES | 59158 | 751K| 1 | 16 | Q1,00 | PCWP | | ------------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 3 - filter(COUNT(SYS_OP_CSR(SYS_OP_MSR(COUNT(*)),0))>100) 9 - access("S"."CUST_ID"="C"."CUST_ID") 11 - filter("S"."TIME_ID"<=TO_DATE(' 1999-10-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "S"."TIME_ID">=TO_DATE(' 1999-07-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
注意:
Cost (%CPU)
列とTime
列は、この例の計画表の出力では削除されています。
超並列処理(MPP)プラットフォームで実行されているOracle RAC環境で適切なスケーラビリティを得るには、パーティションをノード上に配置することが重要です。リモートI/Oを回避するには、一致する2つのパーティションが、同じノードに対してアフィニティを持っている必要があります。ボトルネックを回避し、システムで使用可能なすべてのCPUリソースを使用するために、パーティションの組がすべてのノードに分散される必要があります。
ノードの数よりパーティションの組の数が多い場合は、ノードで複数の組を管理できます。たとえば、ノード数が8のシステムでパーティションが16組ある場合は、各ノードが2組のパーティションに対応します。
関連項目:
データ・アフィニティの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。