| Oracle® Databaseデータ・ウェアハウス・ガイド 12c リリース1 (12.1) B71318-06 |
|
 前 |
 次 |
属性クラスタリングは、特定の列の内容に基づいて、物理的に近接しているデータをクラスタリングする表レベルのディレクティブです。論理的に同種のデータを物理的に近接させて格納すると、処理するデータ量を大幅に低減でき、ワークロードに含まれる特定の問合せのパフォーマンスを向上させることができます。
この章の内容は次のとおりです。
属性がクラスタリングされた表では、表中の一群の列、または他の表中の一群の列の値に基づく順序に従って、データをディスク上の近接した位置に格納します。
指定された列の線形順序に応じてクラスタリングすることも、多次元クラスタリングを可能にする機能を使用してクラスタリングすること(インターリーブ・クラスタリング)も可能です。属性クラスタリングは、ゾーン・マップ、Exadata Storage Index、およびインメモリー最小/最大プルーニングの有効性を向上させます。クラスタリングされた列を修飾する問合せは、クラスタリングされたリージョンのみにアクセスします。属性クラスタリングがパーティション表に対して定義されている場合、クラスタリングはすべてのパーティションに適用されます。
属性クラスタリングは、表のディレクティブ・プロパティです。すべてのDML操作に対して強制されるわけではなく、直接パス挿入操作、データ移動または表の作成にのみ影響を及ぼします。表に対する従来のDML操作は、属性クラスタリングの影響を受けません。これは、データをクラスタリングする操作はすべて、現在の作業データ・セットに対してのみ行われる操作であることを意味します。これは、たとえばCTAS操作の一部として発生するような、手動で適用されるORDER BYコマンドとは対照的です。
この項には次のトピックが含まれます:
データをクラスタリングする方法には次のようなものがあります。
属性クラスタリングが定義された表の、1つ以上の列に基づくクラスタリング。
属性クラスタリングが定義された表に結合されている、1つ以上の列に基づくクラスタリング。結合された列に基づくクラスタリングは、結合属性クラスタリングと呼ばれます。表は主キーと外部キーの関係を介して接続されますが、外部キーは強制される必要はありません。
通常はスター・クエリーがディメンション階層を修飾するため、ファクト表が1つ以上のディメンション表の列(属性)に基づいてクラスタリングされる場合は有益であることがあります。結合属性クラスタリングを使用すると、1つ以上のディメンション表をファクト表に結合し、その後でディメンション階層列によってファクト表データをクラスタリングできます。1つ以上のディメンション表にある列上でファクト表をクラスタリングする場合、ディメンション表への結合がディメンション表の主キーまたは一意キーの上にある必要があります。表データはディメンション階層によってクラスタリングされるため、スター・クエリーのコンテキストにおける結合属性クラスタリングは階層クラスタリングとも呼ばれますが、その各階層は階層列の順序付きリストからできています(たとえば、nation、stateおよびcityの各列がlocation階層を構成しています)。
注意: Oracle表クラスタとは対照的に、結合属性でクラスタリングされた表は、表のグループからのデータを、同じデータベース・ブロックには格納しません。例として、属性クラスタリングされた表salesが、ディメンション表productsと結合されている場合を見てみましょう。sales表にはsales表の行のみが含まれますが、行の順序は、products表から結合された列の値に基づきます。適切な結合は、データ移動、直接パス挿入、およびCTAS操作の際に実行されます。
属性クラスタリングはユーザー定義の表ディレクティブで、表内の1つ以上の列に対するデータ・クラスタリングです。ディレクティブは、表の作成または変更時に指定できます。
Oracle Databaseには、次のタイプの属性クラスタリングが用意されています。
データのクラスタリングは、使用されている属性クラスタリングのタイプに関係なく、単一の表に基づいて行うことも、複数の表を結合することによって行うこと(結合属性クラスタリング)もできます。
線形順序では、指定された列の順序によってデータが格納されます。これがクラスタリングのタイプのデフォルトです。たとえば、表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の削減に非常に効果的です。
インターリーブ順序では、Z次カーブ・フィッティングに基づいて、特別な多次元クラスタリング・テクニックを使用します。その場合、列値(データ・ポイント)の多次元ローカリティを保存しつつ、複数列の属性値(多次元データ・ポイント)を単一の一次元の値にマップします。インターリーブ順序は、単一の表と複数の表のいずれの上でもサポートされます。線形順序とは異なり、クラスタリング定義の先頭列が存在しなくても、属性クラスタリングされた表の利点に記載されているシナリオにおけるI/Oプルーニングの利点を得られます。
列は個別に使用することも、列グループにグループ化することもできます。個別の列または列グループは、クラスタ内の多次元データ・ポイントの1つを構成するためにそれぞれ使用されます。グループ化された列は「(」と「)」で囲まれ、粒度の粗いものから細かいものへと続くディメンション階層に従う必要があります。たとえば、(product_category, product_subcategory)のようにします。
インターリーブ順序によってクラスタリングを実行するには、CLUSTERING ... BY INTERLEAVED ORDERディレクティブを使用します。
インターリーブ・クラスタリングは、複数の列上にある多様な述語によるSQL操作に最適です。これはしばしば次元モデルに対するスター・クエリーの場合に起こることで、その場合、問合せの述語はディメンション表上にあり、述語の数は様々です。ディメンション表からの列に基づいてファクト表がクラスタリングされる環境では、インターリーブ結合された属性クラスタリングの使用が最も一般的です。ディメンション表からの列は、高い確率で、階層(たとえば、製品カテゴリとサブ・カテゴリの階層)を含みます。この場合、ファクト表のクラスタリングは、階層を構成するディメンション列の上で発生します。スター・スキーマの結合属性クラスタリングが階層クラスタリングと呼ばれることがあるのはこのためです。たとえば、sales上の問合せで異なるディメンションからの列が指定されている場合、これらのディメンションの列に応じてsales表内のデータをクラスタリングすることが考えられます。
ゾーン・マップとインターリーブ・クラスタリングの組合せは、スター・スキーマ問合せのI/Oプルーニングに非常に効果的です。また、ゾーン・マップを使用する問合せで非常に効率的なI/Oプルーニングを可能にし、同じ列の値が互いに近接していて簡単に圧縮できるため、圧縮率も向上します。
クラスタリングされた表のようすの一例を、図12-1に示します。表salesに列(category、country)があると想定しています。左側の表は、線形順序を使用してクラスタリングされており、右側の表はインターリーブ順序を使用してクラスタリングされています。インターリーブ順序の表では、指定のカテゴリおよび国のデータが含まれるディスク上に連続したリージョンがあることになります。
属性クラスタリングされた表を定義する場合の考慮事項を次に示します。
ゾーン・プルーニングとそれに関連するI/O削減を容易にするには、属性クラスタリングとゾーン・マップを組み合せて使用します。
カーディナリティが中または低い列では、述語を使用して問い合せられることが多い大きな表の使用を検討します。
ディメンション階層による問合せが多い場合はファクト表を検討します。
パーティション表の場合は、パーティション・キーに相関する列を含めることを検討します(ゾーン・マップのパーティション・プルーニングを容易にするため)。
線形順序の場合、列を接頭辞から接尾辞へという順序でリストします。
ディメンション階層を構成する列は、まとめてグループ化します。これにより列グループが構成されます。列グループそれぞれの中では、粒度が粗いものから細かいものへという順序で列をリストします。
4つ以上のディメンション表がある場合、フィルタで指定されることが最も多いディメンションを含めます。クラスタリングの効果を高くするには、ディメンションの数を2または3に制限します。
カーディナリティが中または低い列では、索引のかわりに属性クラスタリングを使用することを検討します。
ディメンション表の主キーがディメンション階層の値で構成されている場合(たとえば、主キーが年、四半期、月、日の各値から構成される場合)、対応する外部キーは、ディメンション階層のかわりにクラスタリング列として作成します。
索引の使用に関連するコストが不要
ゾーン・マップとともに使用すると、ランダム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プルーニングが有益です。
属性クラスタリング情報は、表メタデータの一部です。表の属性クラスタリングを定義できるのは、表が最初に作成されたときか、その後で表定義を変更したときです。
表の属性クラスタリングを定義するには、CREATE TABLE文のCLUSTERING句を使用します。属性クラスタリングのタイプを指定するには、BY LINEAR ORDERまたはBY INTERLEAVED ORDERを含めます。
表の作成時に属性クラスタリングを定義しなかった場合、表定義を変更してクラスタリングを追加できます。既存の表の属性クラスタリングを定義するには、ALTER TABLE ... ADD CLUSTERING文を使用します。
関連項目:
クラスタリングを実行すると、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オプションを使用する例については、既存の表への属性クラスタリングの追加を参照してください。
この項では、属性クラスタリングを含む一般的なタスクについて、次のように分けて説明します。
表の属性クラスタリングを定義するには、表に対してCREATEまたはALTER権限がある必要があります。さらに、結合属性クラスタリングの場合、結合された表に対してSELECT権限かREAD権限を持っている必要もあります。
関連項目:
CREATE TABLEのCLUSTERING句の構文とセマンティクスの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
線形順序では、指定した列の順序によってデータが格納されます。ORDER BY句と同じです。線形順序は、スター・スキーマで、単一または複数の表の列に対してサポートされます。線形順序の属性クラスタリングの例には、線形順序の属性クラスタリング表の例があげられています。
関連項目:
属性クラスタリングの制限に関する詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
例12-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両方にある述語を含んでいる問合せに有効です。
例12-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言語リファレンス』を参照してください。
インターリーブ順序では、Z次ソートに類似した、特別な多次元クラスタリング・テクニックを使用します。ほとんどの場合によく使用されるが、必ずしもそのすべてを使用するわけではない一群の述語がある場合に特に有効です。インターリーブ順序は、データウェアハウスにおいて、スター・スキーマのディメンション階層に対して有効です。インターリーブ順序の属性クラスタリングの例には、線形順序の属性クラスタリング表の例があげられています。
関連項目:
属性クラスタリングの制限に関する詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
問合せでゾーン・マップを使用したプルーニングを活用できるように、属性クラスタリングされた表を作成することもできます。属性クラスタリングによるゾーン・マップの作成には、属性クラスタリングを使用したゾーン・マップ定義の例があげられています。
例12-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上の述語
例12-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言語リファレンスを参照
表の属性クラスタリング定義は、いつでも追加、削除および更新できます。変更された定義は既存の表データに影響せず、将来の操作のためのディレクティブとしてのみ使用できます。
次のメンテナンス操作は、表のメタデータを変更します。
実行時に表の属性クラスタリング定義をオーバーライドすることもできます。実行時に属性クラスタリング動作に影響するメンテナンス操作は次のとおりです。
クラスタリングのある表を作成する場合、デフォルトでゾーン・マップがともに作成されます。ただし、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;
ゾーン・マップの詳細は、ゾーン・マップについてを参照してください。
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;
ヒントを使用すると、クラスタリングの使用を強制したり、直接パス挿入操作時に使用を抑制したりできます。表に対してクラスタリングを強制するにはCLUSTERINGヒントを使用し、クラスタリングの使用を抑制するにはNO_CLUSTERINGヒントを使用します。
次のコマンドは、SALES表にデータを挿入する際に、属性クラスタリングを無効にします。この表は、YES ON LOADオプションで作成されています。
INSERT /*+ APPEND NO_CLUSTERING */ INTO sales SELECT * FROM external_sales;
ヒントの詳細は、ゾーン・マップ使用の制御を参照してください。
新しいデータ・セグメントの作成(分割またはマージ操作)や、表、パーティションまたはサブパーティションの移動などのデータ移動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句を含めます。
表のオンライン再定義を使用すると、表の可用性に大幅に影響を及ぼすことなく表の論理構造または物理構造を変更できます。表は、その再定義プロセスの大部分で、問合せおよびDMLを使用してアクセスできます。
表をオンラインで再定義して、属性クラスタリングを以前に使用したことがない表に属性クラスタリングを追加できます。DBMS_REDEFINITIONパッケージは、表をオンラインで再定義して、属性クラスタリングを追加できるようにします。
関連項目:
DBMS_REDEFINITIONパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
例12-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');
Oracle Databaseには、属性クラスタリングに関する情報を含むデータ・ディクショナリ・ビュー一式が用意されています。この項では、それらのビューを使用して属性クラスタリングに関する情報を取得する方法を説明します。
この項には次のトピックが含まれます:
表に対して属性クラスタリングが定義されているかどうかは、ビュー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
表の属性クラスタリングの詳細を取得するには、次のいずれかのデータ・ディクショナリ・ビューを使用します。
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
表に対して属性クラスタリングが定義されている列に関する情報を取得するには、次のデータ・ディクショナリ・ビューの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
ファクト表がクラスタリングされているディメンション表に関する情報を表示するには、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
