13 属性クラスタリング
属性クラスタリングは、特定の列の内容に基づいて、物理的に近接しているデータをクラスタリングする表レベルのディレクティブです。論理的に同種のデータを物理的に近接させて格納すると、処理するデータ量を大幅に低減でき、ワークロードに含まれる特定の問合せのパフォーマンスを向上させることができます。
この章の内容は次のとおりです。
13.1 属性クラスタリングについて
属性がクラスタリングされた表では、表中の一群の列、または他の表中の一群の列の値に基づく順序に従って、データをディスク上の近接した位置に格納します。
指定された列の線形順序に応じてクラスタリングすることも、多次元クラスタリングを可能にする機能を使用してクラスタリングすること(インターリーブ・クラスタリング)も可能です。属性クラスタリングは、ゾーン・マップ、Exadata Storage Index、およびインメモリー最小/最大プルーニングの有効性を向上させます。クラスタリングされた列を修飾する問合せは、クラスタリングされたリージョンのみにアクセスします。属性クラスタリングがパーティション表に対して定義されている場合、クラスタリングはすべてのパーティションに適用されます。
属性クラスタリングは、表のディレクティブ・プロパティです。すべてのDML操作に対して強制されるわけではなく、直接パス挿入操作、データ移動または表の作成にのみ影響を及ぼします。表に対する従来のDML操作は、属性クラスタリングの影響を受けません。これは、データをクラスタリングする操作はすべて、現在の作業データ・セットに対してのみ行われる操作であることを意味します。これは、たとえばCTAS操作の一部として発生するような、手動で適用されるORDER
BY
コマンドとは対照的です。
この項では、次の項目について説明します。
13.1.1 データをクラスタリングする方法
データをクラスタリングする方法には次のようなものがあります。
-
属性クラスタリングが定義された表の、1つ以上の列に基づくクラスタリング。
-
属性クラスタリングが定義された表に結合されている、1つ以上の列に基づくクラスタリング。結合された列に基づくクラスタリングは、結合属性クラスタリングと呼ばれます。表は主キーと外部キーの関係を介して接続されますが、外部キーは強制される必要はありません。
通常はスター・クエリーがディメンション階層を修飾するため、ファクト表が1つ以上のディメンション表の列(属性)に基づいてクラスタリングされる場合は有益であることがあります。結合属性クラスタリングを使用すると、1つ以上のディメンション表をファクト表に結合し、その後でディメンション階層列によってファクト表データをクラスタリングできます。1つ以上のディメンション表にある列上でファクト表をクラスタリングする場合、ディメンション表への結合がディメンション表の主キーまたは一意キーの上にある必要があります。表データはディメンション階層によってクラスタリングされるため、スター・クエリーのコンテキストにおける結合属性クラスタリングは階層クラスタリングとも呼ばれますが、その各階層は階層列の順序付きリストからできています(たとえば、
nation
、state
およびcity
の各列がlocation
階層を構成しています)。ノート: Oracle表クラスタとは対照的に、結合属性でクラスタリングされた表は、表のグループからのデータを、同じデータベース・ブロックには格納しません。例として、属性クラスタリングされた表
sales
が、ディメンション表products
と結合されている場合を見てみましょう。sales
表にはsales
表の行のみが含まれますが、行の順序は、products
表から結合された列の値に基づきます。適切な結合は、データ移動、直接パス挿入、およびCTAS操作の際に実行されます。
13.1.2 属性クラスタリングのタイプ
属性クラスタリングはユーザー定義の表ディレクティブで、表内の1つ以上の列に対するデータ・クラスタリングです。ディレクティブは、表の作成または変更時に指定できます。
Oracle Databaseには、次のタイプの属性クラスタリングが用意されています。
データのクラスタリングは、使用されている属性クラスタリングのタイプに関係なく、単一の表に基づいて行うことも、複数の表を結合することによって行うこと(結合属性クラスタリング)もできます。
13.1.2.1 線形順序の属性クラスタリング
線形順序では、指定された列の順序によってデータが格納されます。これがクラスタリングのタイプのデフォルトです。たとえば、表SALES
の(prod_id、channel_id)
列における線形順序では、先にprod_id
を基準にソートされ、その後でchannel_id
を基準にソートされます。ソートされたデータは、近接するクラスタリング済の列のデータとともにディスクに格納されます。
線形順序は、主キーと外部キーの関係を介して接続される単一または複数の表に対して定義できます。
指定した列の順序に基づいて属性クラスタリングを実行するには、CLUSTERING
...
BY
LINEAR
ORDER
ディレクティブを使用します。
列の線形順序に基づく属性クラスタリングは、次のシナリオでの使用が最適です。
-
問合せで、単一の表内の
CLUSTERING
句に含まれている列の接頭辞が指定されているたとえば、
sales
上での問合せで、顧客ID、または顧客IDと製品IDの組合せがよく指定される場合、cust_id
,prod_id
という列の順序を使用して表内のデータをクラスタリングすることが考えられます。 -
CLUSTERING
句で使用される列に、許容できるレベルのカーディナリティがある属性クラスタリングされた表の利点に記載されたシナリオで取得できるデータの削減の程度は、ある列の述語から取得されるデータの削減に正比例します。
ゾーン・マップと線形クラスタリングの組合せは、I/Oの削減に非常に効果的です。
13.1.2.2 インターリーブ順序の属性クラスタリング
インターリーブ順序では、Z次カーブ・フィッティングに基づいて、特別な多次元クラスタリング・テクニックを使用します。その場合、列値(データ・ポイント)の多次元ローカリティを保存しつつ、複数列の属性値(多次元データ・ポイント)を単一の一次元の値にマップします。インターリーブ順序は、単一の表と複数の表のいずれの上でもサポートされます。線形順序とは異なり、クラスタリング定義の先頭列が存在しなくても、属性クラスタリングされた表の利点に記載されているシナリオにおけるI/Oプルーニングの利点を得られます。
列は個別に使用することも、列グループにグループ化することもできます。個別の列または列グループは、クラスタ内の多次元データ・ポイントの1つを構成するためにそれぞれ使用されます。グループ化された列は「(」と「)」で囲まれ、粒度の粗いものから細かいものへと続くディメンション階層に従う必要があります。たとえば、(product_category
, product_subcategory
)のようにします。
インターリーブ順序によってクラスタリングを実行するには、CLUSTERING
...
BY
INTERLEAVED
ORDER
ディレクティブを使用します。
インターリーブ・クラスタリングは、複数の列上にある多様な述語によるSQL操作に最適です。これはしばしば次元モデルに対するスター・クエリーの場合に起こることで、その場合、問合せの述語はディメンション表上にあり、述語の数は様々です。ディメンション表からの列に基づいてファクト表がクラスタリングされる環境では、インターリーブ結合された属性クラスタリングの使用が最も一般的です。ディメンション表からの列は、高い確率で、階層(たとえば、製品カテゴリとサブ・カテゴリの階層)を含みます。この場合、ファクト表のクラスタリングは、階層を構成するディメンション列の上で発生します。スター・スキーマの結合属性クラスタリングが階層クラスタリングと呼ばれることがあるのはこのためです。たとえば、sales
上の問合せで異なるディメンションからの列が指定されている場合、これらのディメンションの列に応じてsales
表内のデータをクラスタリングすることが考えられます。
ゾーン・マップとインターリーブ・クラスタリングの組合せは、スター・スキーマ問合せのI/Oプルーニングに非常に効果的です。また、ゾーン・マップを使用する問合せで非常に効率的なI/Oプルーニングを可能にし、同じ列の値が互いに近接していて簡単に圧縮できるため、圧縮率も向上します。
13.1.3 例: 属性クラスタリングされた表
クラスタリングされた表のようすの一例を、図13-1に示します。表sales
に列(category、country)
があると想定しています。左側の表は、線形順序を使用してクラスタリングされており、右側の表はインターリーブ順序を使用してクラスタリングされています。インターリーブ順序の表では、指定のカテゴリおよび国のデータが含まれるディスク上に連続したリージョンがあることになります。
13.1.4 属性クラスタリングを使用するためのガイドライン
属性クラスタリングされた表を定義する場合の考慮事項を次に示します。
-
ゾーン・プルーニングとそれに関連するI/O削減を容易にするには、属性クラスタリングとゾーン・マップを組み合せて使用します。
-
カーディナリティが中または低い列では、述語を使用して問い合せられることが多い大きな表の使用を検討します。
-
ディメンション階層による問合せが多い場合はファクト表を検討します。
-
パーティション表の場合は、パーティション・キーに相関する列を含めることを検討します(ゾーン・マップのパーティション・プルーニングを容易にするため)。
-
線形順序の場合、列を接頭辞から接尾辞へという順序でリストします。
-
ディメンション階層を構成する列は、まとめてグループ化します。これにより列グループが構成されます。列グループそれぞれの中では、粒度が粗いものから細かいものへという順序で列をリストします。
-
4つ以上のディメンション表がある場合、フィルタで指定されることが最も多いディメンションを含めます。クラスタリングの効果を高くするには、ディメンションの数を2または3に制限します。
-
カーディナリティが中または低い列では、索引のかわりに属性クラスタリングを使用することを検討します。
-
ディメンション表の主キーがディメンション階層の値で構成されている場合(たとえば、主キーが年、四半期、月、日の各値から構成される場合)、対応する外部キーは、ディメンション階層のかわりにクラスタリング列として作成します。
13.1.5 属性クラスタ表の利点
-
索引の使用に関連するコストが不要
-
ゾーン・マップとともに使用すると、ランダムI/Oまたはフル表スキャンを実行せずにクラスタリングされたリージョンにアクセス可能
-
次のいずれかと組み合せて使用することでI/O削減が可能
-
Oracle Exadata Storage Index
-
Oracle In-memory最小/最大プルーニング
-
ゾーン・マップ
属性クラスタリングは、フィルタ述語として使用される属性に基づいたデータ・クラスタリングです。Exadata Storage IndexとOracle In-memory最小/最大プルーニングが各物理リージョンに格納された列の最小値と最大値を追跡するため、クラスタリングすると、データにアクセスするために必要なI/Oが低減されます。
ゾーン・マップを使用してI/Oプルーニングすると、表スキャンと索引スキャンのI/OコストとCPUコストを大幅に削減できます。
-
-
スター・スキーマで、ディメンション列に基づくファクト表のクラスタリングを可能にします。
従来の表クラスタなどのテクニックでは、他の表の列を基準にした順序を使用できません。スター・スキーマでは、大部分の問合せはディメンション表を修飾し、ファクト表を修飾しないため、ファクト表の列を基準にするクラスタリングは効果的ではありません。Oracle Databaseは、ディメンション表の列上でのクラスタリングをサポートしています。
-
データ圧縮率を改善し、それにより間接的に表スキャンのコストを改善します。
クラスタリングを使用すると、同じ値を持つクラスタリングされた列がディスク上で近接している可能性が高くなり、それによりデータベースによる圧縮が容易になるため、圧縮率が改善されることもあります。
-
属性クラスタリングが索引選択基準に関わる場合、索引範囲スキャン操作のための表参照操作と単一のブロックI/O操作が最小になります。
-
OLTPアプリケーションで、接頭辞を修飾し、線形順序の属性クラスタリングを使用する問合せのI/Oを削減します。
-
インターリーブ順序による属性クラスタリングで、クラスタリング列のサブセットにおけるI/O削減を可能にします。
表データが複数の列上で順序づけられている場合(索引で整理された表など)、問合せでI/Oを少なく抑えるには、列の接頭辞を指定する必要があります。対照的に、
BY
INTERLEAVED
表では、問合せが接頭辞でない順序で複数の表から列を指定する場合に、I/Oプルーニングが有益です。
13.1.6 表の属性クラスタリングの定義について
属性クラスタリング情報は、表メタデータの一部です。表の属性クラスタリングを定義できるのは、表が最初に作成されたときか、その後で表定義を変更したときです。
表の属性クラスタリングを定義するには、CREATE TABLE
文のCLUSTERING
句を使用します。属性クラスタリングのタイプを指定するには、BY LINEAR ORDER
またはBY INTERLEAVED ORDER
を含めます。
表の作成時に属性クラスタリングを定義しなかった場合、表定義を変更してクラスタリングを追加できます。既存の表の属性クラスタリングを定義するには、ALTER TABLE ... ADD CLUSTERING
文を使用します。
関連項目:
13.1.7 属性クラスタリングの実行が必須である場合の指定
クラスタリングを実行すると、DML操作の際に表とクラスタリング・データが再編成されるため、コストが高くなる場合があります。Oracle Databaseでは、従来のDML、従来の挿入、更新およびマージにおけるデータのクラスタリングは必須ではありません。
クラスタリングは、次の2つの方法で行うことができます。1つめの方法は、表上での特定のDML操作に対するクラスタリングの自動実行です。これは、クラスタリングがトリガーされる操作を表メタデータの一部として定義することによって行われます。2つめの方法は、ヒントを使用したDML操作の属性クラスタリングの制御およびDDL操作における属性クラスタリングの表レベル設定のオーバーライドの説明に従ってクラスタリングを実行する必要があることを明示的に指定することです。この場合、メタデータ定義にクラスタリングが含まれない場合でも、表のクラスタリングを実行できます。
表定義の一部として、次の操作がトリガーされたときに属性クラスタリングを実行する必要があると指定できます。
-
直接パス挿入操作
直接パス挿入操作の際に属性クラスタリングを実行する必要があると指定するには、
ON LOAD
オプションをYES
に設定します。 -
データ移動操作
データ移動操作時にクラスタリングを実行する必要があることを指定するには、
ON DATA MOVEMENT
オプションをYES
に設定します。これには、表のオンライン再定義と、次のパーティション操作が含まれます:MOVE
、MERGE
、SPLIT
およびCOALESCE
。
ON LOAD
オプションとON DATA MOVEMENT
オプションは、CREATE TABLE
またはALTER TABLE
文にも含めることができます。YES
ON
LOAD
もYES
ON
DATA
MOVEMENT
も指定されない場合、クラスタリングは自動実行されません。
後でゾーン・マップ作成用に使用される可能性がある表の自然クラスタリングを定義するメタデータとしてのみ使用されます。この場合、ロード時にクラスタリングを実行するかどうかはユーザー次第です。
関連項目:
ON LOAD
オプションおよびON DATA MOVEMENT
オプションを使用する例については、既存の表への属性クラスタリングの追加を参照してください。
13.2 属性クラスタリングの操作
この項では、属性クラスタリングを含む一般的なタスクについて、次のように分けて説明します。
13.2.1 属性クラスタリングされた表の権限
表の属性クラスタリングを定義するには、表に対してCREATE
またはALTER
権限がある必要があります。さらに、結合属性クラスタリングの場合、結合された表に対してSELECT
権限かREAD
権限を持っている必要もあります。
関連項目:
CREATE TABLEのCLUSTERING
句の構文とセマンティクスの詳細は、『Oracle Database SQL言語リファレンス』
を参照してください。
13.2.2 線形順序で属性クラスタリングされた表の作成
線形順序では、指定した列の順序によってデータが格納されます。ORDER BY
句と同じです。線形順序は、スター・スキーマで、単一または複数の表の列に対してサポートされます。線形順序の属性クラスタリングの例には、線形順序の属性クラスタリング表の例があげられています。
関連項目:
属性クラスタリングの制限に関する詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
13.2.2.1 線形順序の属性クラスタリングの例
例13-1 線形順序による表の作成
sales
上での問合せで、顧客ID、または顧客IDと製品IDの組合せがよく指定されると想定します。属性クラスタリングされた表を作成して、属性クラスタリングされた表の利点に記載されたシナリオで、問合せにI/O削減の利点がもたらされるようにできます。
次の文は、sales
表を線形順序で作成します。
CREATE TABLE sales ( prod_id NUMBER(6) NOT NULL, cust_id NUMBER NOT NULL, time_id DATE NOT NULL, channel_id CHAR(1) NOT NULL, promo_id NUMBER(6) NOT NULL, quantity_sold NUMBER(3) NOT NULL, amount_sold NUMBER(10,2) NOT NULL ) CLUSTERING BY LINEAR ORDER (cust_id, prod_id);
このクラスタリングされた表は、cust_id
上の述語か、cust_id
とprod_id
両方にある述語を含んでいる問合せに有効です。
例13-2 線形順序の、結合を備えた表の作成
products
ディメンション表において、prod_id
列上に一意キーまたは主キーがあると想定します。この表の他の列には、prod_name
、prod_desc
、prod_category
、prod_subcategory
およびprod_status
が含まれますが、それに限定されるわけではありません。my_sales
ファクト表に対する問合せには、多くの場合、次のいずれかが含まれます。
-
cust_id
上の述語 -
cust_id
およびprod_category
上の述語 -
cust_id
、prod_category
およびprod_subcategory
上の述語
my_sales
表に属性クラスタリングを定義すると、CLUSTERING
句に含まれる述語を含む問合せに有効です。
CREATE TABLE my_sales ( prod_id NUMBER(6) NOT NULL, cust_id NUMBER NOT NULL, time_id DATE NOT NULL, channel_id CHAR(1) NOT NULL, promo_id NUMBER(6) NOT NULL, quantity_sold NUMBER(3) NOT NULL, amount_sold NUMBER(10,2) NOT NULL ) CLUSTERING my_sales JOIN products ON (my_sales.prod_id = products.prod_id) BY LINEAR ORDER (cust_id, prod_category, prod_subcategory);
関連項目:
BY LINEAR ORDER
句の構文とセマンティクスの詳細は、『Oracle Database SQL言語リファレンス』
を参照してください。
13.2.3 インターリーブ順序で属性クラスタリングされた表の作成
インターリーブ順序では、Z次ソートに類似した、特別な多次元クラスタリング・テクニックを使用します。ほとんどの場合によく使用されるが、必ずしもそのすべてを使用するわけではない一群の述語がある場合に特に有効です。インターリーブ順序は、データウェアハウスにおいて、スター・スキーマのディメンション階層に対して有効です。インターリーブ順序の属性クラスタリングの例には、線形順序の属性クラスタリング表の例があげられています。
関連項目:
属性クラスタリングの制限に関する詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
13.2.3.1 インターリーブ順序の属性クラスタリングの例
問合せでゾーン・マップを使用したプルーニングを活用できるように、属性クラスタリングされた表を作成することもできます。属性クラスタリングによるゾーン・マップの作成には、属性クラスタリングを使用したゾーン・マップ定義の例があげられています。
例13-3 インターリーブ順序による表の作成
sales
上での問合せで、時刻ID、または時刻IDと製品IDの組合せがよく指定されると想定します。インターリーブ属性クラスタリングを設定してsales
を作成するには、次のコマンドを使用します。
CREATE TABLE sales ( prod_id NUMBER(6) NOT NULL, cust_id NUMBER NOT NULL, time_id DATE NOT NULL, channel_id CHAR(1) NOT NULL, promo_id NUMBER(6) NOT NULL, quantity_sold NUMBER(3) NOT NULL, amount_sold NUMBER(10,2) NOT NULL ) CLUSTERING BY INTERLEAVED ORDER (time_id, prod_id);
このクラスタリングされた表は、次のいずれかを含む問合せで有効です。
-
time_id
上の述語 -
prod_id
上の述語 -
time_id
およびprod_id
上の述語
例13-4 インターリーブ順序と結合のある表の作成
大規模なデータ・ウェアハウスでは、データがスター・スキーマを使用して組織化されることがよくあります。ディメンション表は親子階層を使用し、外部キーでファクト表に接続されます。ファクト表をインターリーブ順序でクラスタリングすると、表スキャンの際、データベースがディメンション列の値をスキップする特別な機能を使用できるようになります。クラスタリングで外部キー関係が必須でない点に注意してください。ただし、Oracle Databaseでは、ディメンション表上に主キーまたは一意のキーが必要です。
次のコマンドは、sales
ファクト表に対する、インターリーブ順序を使用した属性クラスタリングを定義します。
CREATE TABLE sales ( prod_id NUMBER(6) NOT NULL, cust_id NUMBER NOT NULL, time_id DATE NOT NULL, channel_id CHAR(1) NOT NULL, promo_id NUMBER(6) NOT NULL, quantity_sold NUMBER(3) NOT NULL, amount_sold NUMBER(10,2) NOT NULL ) CLUSTERING sales JOIN products ON (sales.prod_id = products.prod_id) BY INTERLEAVED ORDER ((time_id), (prod_category, prod_subcategory));
このクラスタリングされた表は、次のいずれかを含む問合せで有効です。
-
time_id
上の述語 -
prod_category
上の述語 -
prod_category
およびprod_subcategory
上の述語 -
time_id
およびprod_id
上の述語 -
time_id
、prod_category
およびprod_subcategory
上の述語
関連項目:
CREATE TABLE文とCLUSTERING句の詳細は、Oracle Database SQL言語リファレンス
を参照
13.2.4 属性クラスタリングのメンテナンス
表の属性クラスタリング定義は、いつでも追加、削除および更新できます。変更された定義は既存の表データに影響せず、将来の操作のためのディレクティブとしてのみ使用できます。
次のメンテナンス操作は、表のメタデータを変更します。
実行時に表の属性クラスタリング定義をオーバーライドすることもできます。実行時に属性クラスタリング動作に影響するメンテナンス操作は次のとおりです。
13.2.4.1 既存の表への属性クラスタリングの追加
クラスタリングのある表を作成する場合、デフォルトでゾーン・マップがともに作成されます。ただし、WITHOUT
ZONEMAP
を使用することにより、これを明示的に抑制することができます。こうするのは、クラスタリング列と、クラスタリング列に相関する追加の列に関するゾーン・マップを作成する、デフォルトのものでなく固有のゾーン・マップ・ストレージ・オプションを使用するといった場合です。
現在属性クラスタリングを使用していない既存の表に属性クラスタリングを追加するには、ALTER TABLE ... ADD CLUSTERING
コマンドを使用します。
次のコマンドは、SALES
ファクト表に属性クラスタリングを追加します。変更後の表では、結合されたディメンション表CUSTOMERS
およびPRODUCTS
に基づくインターリーブ・クラスタリングが使用されます。
ALTER TABLE sales ADD CLUSTERING sales JOIN customers ON (sales.cust_id = customers.cust_id) JOIN products ON (sales.prod_id = products.prod_id) BY INTERLEAVED ORDER ((prod_category, prod_subcategory), (country_id, cust_state_province, cust_city)) YES ON LOAD YES ON DATA MOVEMENT WITHOUT MATERLALIZED ZONEMAP;
表にクラスタリングを追加する場合、既存のデータはクラスタリングされません。既存のデータを強制的にクラスタリングするには、ALTER TABLE...MOVE
文を使用する必要があります。その操作はパーティションごとに行います。
次のコマンドは、sales
表内のデータをクラスタリングします。
ALTER TABLE sales MOVE PARTITION sales_1995 UPDATE INDEXES ALLOW CLUSTERING;
ゾーン・マップの詳細は、ゾーン・マップについてを参照してください。
13.2.4.2 属性クラスタリング定義の変更
ALTER TABLE ... MODIFY CLUSTERING
文を使用すると、表に対して属性クラスタリングをいつトリガーするかを変更できます。クラスタリング定義を変更しても、既存の表データには影響ありません。変更された定義は、その後のデータ移動または直接パス挿入操作のみに適用されます。
次のコマンドは、SALES
表のクラスタリング定義を変更し、データ移動時にクラスタリングを有効化します。
ALTER TABLE sales MODIFY CLUSTERING YES ON DATA MOVEMENT;
表定義を変更し、属性クラスタリングに基づいてゾーン・マップを作成したり削除したりすることもできます。次の文は、SALES
表の定義を変更して、ゾーン・マップを追加します。
ALTER TABLE sales MODIFY CLUSTERING WITH MATERIALIZED ZONEMAP;
属性クラスタリングされた表SALES
の定義を変更して、ゾーン・マップを削除するには、次の文を使用します。
ALTER TABLE sales MODIFY CLUSTERING WITHOUT MATERIALIZED ZONEMAP;
13.2.4.4 ヒントを使用したDML操作の属性クラスタリングの制御
ヒントを使用すると、クラスタリングの使用を強制したり、直接パス挿入操作時に使用を抑制したりできます。表に対してクラスタリングを強制するにはCLUSTERING
ヒントを使用し、クラスタリングの使用を抑制するにはNO_CLUSTERING
ヒントを使用します。
次のコマンドは、SALES
表にデータを挿入する際に、属性クラスタリングを無効にします。この表は、YES ON LOAD
オプションで作成されています。
INSERT /*+ APPEND NO_CLUSTERING */ INTO sales SELECT * FROM external_sales;
ヒントの詳細は、ゾーン・マップ使用の制御を参照してください。
13.2.4.5 DDL操作における属性クラスタリングの表レベル設定のオーバーライド
新しいデータ・セグメントの作成(分割またはマージ操作)や、表、パーティションまたはサブパーティションの移動などのデータ移動DDL操作の際に、属性クラスタリング定義をオーバーライドできます。たとえば、表がNO ON DATA MOVEMENT
オプションを使用して定義されている場合、ALTER TABLE ... ALLOW CLUSTERING
文を使用して、データ移動時にこの表のデータをクラスタリングすることができます。
次のコマンドを使用すると、NO ON DATA MOVEMENT
オプションを使用して定義されているSALES
表のsales_2010
パーティションでのデータ移動の際に、クラスタリングが可能になります。
ALTER TABLE sales MOVE PARTITION sales_2010 UPDATE INDEXES ALLOW CLUSTERING;
同様に、YES ON DATA MOVEMENT
オプションを使用して定義されている表のデータ移動の際のクラスタリングを無効にするには、データ移動に使用するALTER TABLE
コマンドにDISALLOW CLUSTERING
句を含めます。
13.2.4.6 表のオンライン再定義時の表データのクラスタリング
表のオンライン再定義を使用すると、表の可用性に大幅に影響を及ぼすことなく表の論理構造または物理構造を変更できます。表は、その再定義プロセスの大部分で、問合せおよびDMLを使用してアクセスできます。
表をオンラインで再定義して、属性クラスタリングを以前に使用したことがない表に属性クラスタリングを追加できます。DBMS_REDEFINITION
パッケージは、表をオンラインで再定義して、属性クラスタリングを追加できるようにします。
関連項目:
DBMS_REDEFINITION
パッケージの詳細は、Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンスを参照してください
例13-5 属性クラスタリングされた表のオンライン再定義
sales
表を再定義して、amount_sold
のデータ型をnumberからfloatに変更し、表に属性クラスタリングを追加し、オンライン再定義時にデータをクラスタリングする場合を考えます。
SH
スキーマのsales
表を再定義し、表のオンライン再定義の際に表のデータをクラスタリングするには、次のステップを使用します。
-
DBMS_REDEFINITION
パッケージのCAN_REDEF_TABLE
プロシージャを起動して、表をオンラインで再定義できることを確認します。次のコマンドは、
sales
表がオンラインで再定義できることを確認します。exec DBMS_REDEFINITION.CAN_REDEF_TABLE('SH','SALES');
-
再定義される表で使用する物理属性と論理属性を持つ仮表を、
SH
スキーマで作成します。次のコマンドは、仮表
sales_interim
を作成します。amount_sold
列のデータ型はbinary_double
で、CLUSTERING
句で属性クラスタリングの実行方法を指定します。CREATE TABLE sales_interim ( PROD_ID NUMBER(6) PRIMARY KEY, CUST_ID NUMBER NOT NULL, TIME_ID DATE NOT NULL, CHANNEL_ID CHAR(1) NOT NULL, PROMO_ID NUMBER(6), QUANTITY_SOLD NUMBER(3) NOT NULL, AMOUNT_SOLD binary_double ) CLUSTERING sales_interim JOIN customers ON (sales_interim.cust_id = customers.cust_id) JOIN products ON (sales_interim.prod_id = products.prod_id) BY INTERLEAVED ORDER ( (prod_category, prod_subcategory), (country_id, cust_state_province, cust_city));
-
DBMS_REDEFINITON.START_REDEF_TABLE
プロシージャを使用して、表のオンライン再定義プロセスを開始します。このプロセスの最中も、sales
表に対する問合せとDMLは可能です。次のコマンドは、
SALES
表の再定義プロセスを開始します。exec DBMS_REDEFINITION.START_REDEF_TABLE(uname => 'SH',orig_table => 'SALES', int_table => 'SALES_INTERIM', options_flag => DBMS_REDEFINITION.CONS_USE_ROWID);
-
オプションで、仮表を元の表と同期化します。
再定義の開始後に、元の表の上で多数のDML文が実行された可能性がある場合、同期をお薦めします。このステップにより、再定義プロセスを完了するための時間が短縮されます。
次のコマンドは、
sales_interim
表を元のsales
表と同期します。exec DBMS_REDEFINITION.SYNC_INTERIM_TABLE('SH', 'SALES', 'SALES_INTERIM');
-
DBMS_REDEFINITION.FINISH_REDEF_TABLE
プロシージャを使用して、表のオンライン再定義を完了します。次のコマンドは、
sales
表のオンライン再定義を完了します。exec DBMS_REDEFINITION.FINISH_REDEF_TABLE('SH', 'SALES', 'SALES_INTERIM');
13.3 属性クラスタリング情報
Oracle Databaseには、属性クラスタリングに関する情報を含むデータ・ディクショナリ・ビュー一式が用意されています。この項では、それらのビューを使用して属性クラスタリングに関する情報を取得する方法を説明します。
この項では、次の項目について説明します。
13.3.1 表に対して属性クラスタリングが定義されているかどうかの判断
表に対して属性クラスタリングが定義されているかどうかは、ビューDBA_TABLES
、USER_TABLES
およびALL_TABLES
のCLUSTERING
列で指定されています。表に属性クラスタリングが定義されている場合、CLUSTERING
列がYES
と表示され、それ以外の場合はNO
と表示されます。
次の問合せは、SH
スキーマの表の名前を表示し、属性クラスタリングを使用しているかどうかを示します。
SELECT TABLE_NAME, CLUSTERING FROM DBA_TABLES WHERE OWNER='SH'; TABLE_NAME CLUSTERING ----------- ------------ SALES YES PRODUCTS NO MY_SALES YES
13.3.2 表の属性クラスタリング情報の表示
表の属性クラスタリングの詳細を取得するには、次のいずれかのデータ・ディクショナリ・ビューを使用します。
-
DBA_CLUSTERING_TABLES
- データベースにあるすべての属性クラスタリングされた表を記述します。 -
ALL_CLUSTERING_TABLES
- ユーザーにアクセスできる、属性クラスタリングされた表を記述します。 -
USER_CLUSTERING_TABLES
- ユーザーが所有する、属性クラスタリングされた表を記述します。
次の問合せは、SALES
表の属性クラスタリングの詳細を表示します。この詳細には、属性クラスタリングのタイプと、その表に対してクラスタリングが有効化されている操作が含まれます。出力はページに収まるようにあらかじめ折り返されています。
SELECT owner, table_name, clustering_type, on_load, on_datamovement, with_zonemap FROM DBA_CLUSTERING_TABLES WHERE table_name='SALES'; OWNER TABLE_NAME CLUSTERING_TYPE ON_LOAD ON_DATAMOVEMENT WITH_ZONEMAP ------ ---------- --------------- -------- --------------- ------------- SH SALES LINEAR YES YES YES
SELECT owner, table_name, clustering_type, on_load, on_datamovement FROM DBA_CLUSTERING_TABLES WHERE table_name='SALES'; OWNER TABLE_NAME CLUSTERING_TYPE ON_LOAD ON_DATAMOVEMENT ------ ---------- --------------- -------- --------------- SH SALES LINEAR YES YES
13.3.3 属性クラスタリングが実行される列に関する情報の表示
表に対して属性クラスタリングが定義されている列に関する情報を取得するには、次のデータ・ディクショナリ・ビューの1つを使用します。
-
DBA_CLUSTERING_KEYS
-
ALL_CLUSTERING_KEYS
-
USER_CLUSTERING_KEYS
たとえば、表SALES
のデータは、線形順序を使用してクラスタリングされています。表がクラスタリングされている列を表示するには、次のコマンドを使用します。出力はページに収まるようにあらかじめ折り返されています。
SELECT detail_owner, detail_name, detail_column, position FROM DBA_CLUSTERING_KEYS WHERE table_name='SALES'; DETAIL_OWNER DETAIL_NAME DETAIL_COLUMN POSITION ------------ -------------- ----------------- --------- SH SALES PROD_ID 2 SH SALES TIME_ID 1
13.3.4 属性クラスタリングが実行されるディメンションと結合に関する情報の表示
ファクト表がクラスタリングされているディメンション表に関する情報を表示するには、DBA_CLUSTERING_DIMENSIONS
、ALL_CLUSTERING_DIMENSIONS
またはUSER_CLUSTERING_DIMENSIONS
データ・ディクショナリ・ビューを問い合せます。
ファクト表とディメンション表の結合に関する詳細を表示するには、DBA_CLUSTERING_JOINS
、ALL_CLUSTERING_JOINS
またはUSER_CLUSTERING_JOINS
ビューを問い合せます。出力はページに収まるようにあらかじめ折り返されています。
次の問合せは、ファクト表SALES
が属性クラスタリングされているディメンション表を表示します。
SELECT * FROM DBA_CLUSTERING_DIMENSIONS WHERE table_name='MY_SALES'; OWNER TABLE_NAME DIMENSION_OWNER DIMENSION_NAME ------ -------------- ------------------- --------------------- SH MY_SALES SH PRODUCTS
次の問合せは、ファクト表my_sales
とディメンション表products
を結合するために使用される列を表示します。出力はページに収まるようにあらかじめ折り返されています。
SELECT tab1_owner, tab1_name,tab1_column FROM DBA_CLUSTERING_JOINS WHERE table_name='MY_SALES'; TAB1_OWNER TAB1_NAME TAB1_COLUMN ----------- ------------- -------------------- SH MY_SALES PROD_ID