| Oracle Databaseデータ・カートリッジ開発者ガイド 11gリリース1（11.1） E05688-02 |
|
 戻る |
 次へ |
この章では、ドメイン索引の概念とODCIIndexインタフェースについて説明します。さらに、ドメイン索引、パーティション化、適用される制限事項および移行プロシージャの使用方法を示します。
この章の内容は、次のとおりです。
すでにユーザー管理ドメイン索引を使用している場合、実装の詳細は、付録A「ユーザー管理ドメイン索引」を参照してください。
ドメイン索引とは、空間処理やイメージ処理など、特化されたドメイン向けに設計された索引です。設計者が索引タイプを作成した後、ユーザーがタイプを指定してドメイン索引を作成できます。ドメイン索引とは、業界、業務またはその他の特別な用途に固有の動作を持つ索引で、カートリッジ開発中に指定する必要があります。
ドメイン索引へのシステム管理アプローチはOracle Database 11gリリース1で新しく追加された機能で、プログラムの負荷を軽減し、従来のユーザー管理ドメイン索引よりも適切なパフォーマンスを提供します。ユーザー管理アプローチの制限に対処し、次のようなメリットがあります。
中核部分は、ユーザーに代わってより多くのメンテナンス・タスクを実行するため、表およびパーティション・メンテナンス操作に対してプログラムによるサポートをする必要がありません。これらの操作はサーバーで操作すると実装されるので、ユーザーは最小限のセットのユーザー定義インタフェース・ルーチンでコード化できます。カートリッジ・コードは比較的パーティションの問題から影響を受けません。
ローカル・パーティション・ドメイン索引をサポートするために管理する必要のあるオブジェクトの数は、非パーティション索引の場合と同じです。ローカル・パーティション索引の場合、ドメイン索引の索引記憶表は実表とともにパーティション化されるので（システム・パーティション表を使用）、パーティションの数が増加してもドメイン索引の索引記憶表の数は増加しません。
問合せとDML文の1セットがアクセス可能になり、システム・パーティション記憶表を操作し、カーソルの共有を容易にしてパフォーマンスを強化します。
ユーザー管理ドメイン索引は将来のOracle Databaseのリリースでは非推奨となるため、システム管理ドメイン索引を使用して新規アプリケーションを開発することをお薦めします。
索引タイプにより、テキスト、空間およびイメージ処理などの複合ドメインに使用する検索および取出しメソッドがカプセル化されます。索引タイプは、Oracle Databaseで提供される索引に類似しています。ただし、索引タイプを実装するアプリケーション・ソフトウェアを提供するのがユーザーであるという違いがあります。
索引タイプには、次の2つの主要コンポーネントがあります。
索引の作成やスキャンなど、索引タイプの動作を実装するメソッド
Contains()やOverlaps()など、索引タイプでサポートされる演算子
索引タイプを作成する手順は、次のとおりです。
サポートされる演算子を定義し、それを実装するファンクションを作成します。
このコンテキストでの意味は、次のとおりです。
インタフェースは、個別のスキーマ・オブジェクトではなく、記述されたメソッド指定の論理セットを意味します。
ODCIIndexインタフェースは、索引定義、メンテナンスおよびスキャン・ルーチンの指定のセットを意味します。
ODCIIndexインタフェースでは、索引タイプを実装するために提供する必要のあるルーチンがすべて指定されます。各ルーチンは、型のメソッドとして実装する必要があります。
ODCIIndexインタフェースは、次のメソッド・クラスで構成されています。
索引定義メソッド
索引メンテナンス・メソッド
索引スキャン・メソッド
索引メタデータ・メソッド
索引定義メソッドは、ユーザーが索引タイプの索引に対してCREATE、ALTER、DROPまたはTRUNCATE文を発行するとコールされます。
ユーザーが索引タイプを参照するCREATE INDEX文を発行すると、OracleはODCIIndexCreate()メソッドをコールし、CREATE INDEX...PARAMETERS (...)文の一部として指定されたパラメータと索引の説明を渡します。
通常、このメソッドでは、索引データを格納する予定の表またはファイルが作成されます。実表が空でなければ、このメソッドで索引も作成する必要があります。
ユーザーが索引タイプを参照するALTER INDEX文を発行すると、OracleはODCIIndexAlter()メソッドをコールし、指定のパラメータとともに変更対象のドメイン索引の説明を渡します。このメソッドは、REBUILDまたはRENAMEオプションが指定されたALTER INDEXを処理するためにもコールされます。メソッドに必要な動作はドメイン索引の性質に応じて異なるため、詳細は索引タイプの設計者が指定する必要があります。
索引タイプで索引付けされた列またはオブジェクト型の属性を含む表に対して、ユーザーがINSERT、UPDATEおよびDELETE文を発行すると、索引メンテナンス・メソッドがコールされます。
ユーザーがレコードを挿入すると、OracleはODCIIndexInsert()メソッドをコールして、索引付けされた列の新規の値および対応するROWIDを渡します。
ユーザーがレコードを更新すると、OracleはODCIIndexUpdate()メソッドをコールして、索引付けされた列の新旧の値および対応するROWIDを渡します。
索引スキャン・メソッドでは、索引タイプでサポートされる演算子を含む述語を評価するための、索引ベースの実装を指定します。索引スキャンには、初期化、行またはROWIDのフェッチ、すべての行が戻された後のクリーン・アップを行うメソッドが関係します。
演算子述語を評価して結果行セットを戻すには、次の2つのモードがあります。
すべて事前計算: 結果セット全体がODCIIndexStart()で計算されます。ODCIIndexFetch()の各コールからの行バッチを戻して結果全体を反復します。このモードは、結果セット全体を調べて候補の行ごとにランク付けや関連性などを計算する必要のある演算子に適用可能です。また、アプリケーションで必要な場合は、一度に1行ずつ戻すことも可能です。
増分計算: ODCIIndexFetch()の各コールで結果行のバッチを計算します。このモードは、結果セット全体を調べずに候補の行を一度に1つずつ判別できる演算子に適用可能です。また、アプリケーションで必要な場合は、一度に1行ずつ戻すことも可能です。
Oracleは索引スキャンの開始時にODCIIndexStart()メソッドをコールして、索引と演算子の情報を渡します。通常、このメソッドは次の操作を実行します。
スキャンに使用するデータ構造を初期化します。
索引データを格納する表を問い合せるSQL文を解析して実行します。
フェッチおよびクリーン・アップ・メソッドに必要な状態情報を保存し、状態または状態へのハンドルを戻します。
ODCIIndexFetch()の初回起動時に戻される結果行セットを生成する場合があります。
索引と演算子の情報は、フェッチおよびクリーン・アップ・メソッドには渡されません。そのため、ODCIIndexStart()では、索引スキャン・ルーチン間で共有する必要のある状態データを保存し、出力のsctxパラメータを介して戻す必要があります。大量の状態データを共有するには、カーソル時間メモリーを割り当てて、メモリーへのハンドルをsctxパラメータで戻します。
|
関連項目 メモリー・サービスとコンテキストのメンテナンスの詳細は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください。 |
メンバー・メソッドとしてODCIIndexFetch()およびODCIIndexClose()に組込みSELFパラメータが渡され、これを介して状態データにアクセスできます。
Oracleは、ODCIIndexFetch()メソッドをコールし、ODCIIndexStart()または前のODCIIndexFetch()コールから戻された状態データを渡して、演算子述語を満たす次の行バッチのROWIDを戻します。演算子述語は、演算子式（名前と引数）および演算子の戻り値の上限および下限として指定されます。つまり、ODCIIndexFetch()は、演算子の戻り値が指定の範囲内に含まれる行のROWIDを戻す必要があります。索引スキャンの終了を示すには、NULLを戻します。
Oracleは、カーソルがクローズまたは再利用されるときにODCIIndexClose()メソッドをコールして、現在の状態を渡します。ODCIIndexClose()では、索引タイプに必要なクリーン・アップまたはクローズ操作を実行する必要があります。
ODCIIndexGetMetadata()メソッドはオプションです。このメソッドを実装すると、エクスポート・ユーティリティによりコールされ、実装固有のメタデータがエクスポート・ダンプ・ファイルに書き込まれます。このメタデータはポリシー情報、バージョン情報、個別のユーザー設定などで、システム・カタログには格納されません。メタデータは、関連索引が作成される直前のインポート時に実行される無名PL/SQLブロックとしてダンプ・ファイルに書き込まれます。
索引インタフェース・メソッド（索引定義メソッドODCIIndexCreate()、ODCIIndexAlter()およびODCIIndexDrop()以外）は、これらのアクションをトリガーしたものと同じトランザクションでコールされます。したがって、この種のルーチンによる変更はアトミックであり、親トランザクションに基づいてコミットされるか強制終了されます。そのために、各種索引タイプ・ルーチンで実行できるアクションの性質には一定の制限があります。
索引定義ルーチンには、制限はありません。
索引メンテナンス・ルーチンで実行できるのは、データ操作言語（DML）文のみです。この種のDML文では、ドメイン索引の作成に使用された実表を更新できません。
索引スキャン・ルーチンで実行できるのは、SQL問合せ文のみです。
たとえば、INSERT文によりODCIIndexInsert()ルーチンが起動されると、ODCIIndexInsert()はINSERTと同じトランザクションで実行されます。ODCIIndexInsert()ルーチンでは、必要な数のDML文（索引構成表への挿入など）を実行できます。元のトランザクションが強制終了すると、索引タイプ・ルーチンにより行われた変更はすべてロールバックされます。
ただし、索引タイプ・ルーチンによりデータベース外部の変更（外部ファイルへの書込みなど）が行われる場合、トランザクションのセマンティクスは保証されません。
索引定義ルーチンには、そのアクションの性質に関する制限がありません。この違いを理解するためにODCIIndexCreate()を考えてみます。ODCIIndexCreate()で実行される標準的なアクション・セットは次のとおりです。
索引構成表の作成
索引構成表へのデータの挿入
索引構成表の1列での2次索引の作成
ODCIIndexCreate()でDDL文とDML文の任意の順序を実行できるように、各文が独立した操作とみなされます。そのため、ODCIIndexCreate()による変更がアトミックであるという保証はありません。これは、他の索引定義ルーチンの場合も同様です。
この項では、索引タイプを操作するSQL文について説明します。
|
関連項目 各SQL文の詳細は『Oracle Database SQL言語リファレンス』を参照してください。 |
ODCIIndexインタフェースを実装して実装タイプを定義した後、索引タイプでサポートされる演算子のリストを指定し、索引インタフェースを実装するタイプを参照して、新規の索引タイプを作成できます。
例8-1で示すように、情報検索の例では、新規の索引タイプTextIndexTypeを定義するDDL文は次のようになります。この索引タイプはContains演算子をサポートし、その実装は型のTextIndexMethodsで提供されます。
例8-1 索引タイプの作成方法
CREATE INDEXTYPE TextIndexType FOR Contains (VARCHAR2, VARCHAR2) USING TextIndexMethods WITH SYSTEM MANAGED STORAGE TABLES;
実装タイプでは、ODCIIndexインタフェース・ルーチンのみでなくODCIGetInterfaces()ルーチンも実装する必要があります。このルーチンにより実装タイプで実装されたインタフェースのバージョンが戻されます。Oracleは、CREATE INDEXTYPEの実行時にODCIGetInterfaces()ルーチンをコールします。索引タイプでOracle9i以降のバージョンのルーチンが実装される場合は、ODCIGetInterfaces()のOUTパラメータにSYS.ODCIINDEX2を指定する必要があります。Oracle8iルーチンにはODCIEnvパラメータがないので、索引タイプでOracle8iバージョンのルーチンが実装される場合は、ODCIGetInterfaces()のOUTパラメータにSYS.ODCIINDEX1を指定する必要があります。
索引タイプの定義を削除するには、DROP文を使用します。次に例を示します。
DROP INDEXTYPE TextIndexType;
DROPのデフォルト動作はDROP RESTRICTのセマンティクスです。つまり、索引タイプを使用する1つ以上のドメイン索引が存在する場合、DROP操作は禁止となります。ユーザーは、FORCEオプションを使用してデフォルト操作をオーバーライドできます。このオプションを指定すると、索引タイプが削除され、依存ドメイン索引に無効マークが付けられます。
例8-2で示すように、索引タイプまたは演算子に関する情報を提供するには、COMMENT文を使用します。
例8-2 索引タイプをコメント化する方法
COMMENT ON INDEXTYPE Ordsys.TextIndexType IS 'implemented by the type TextIndexMethods to support the Contains operator';
索引タイプに関するコメントは、次のデータ・ディクショナリ・ビューで表示できます。
ALL_INDEXTYPE_COMMENTSには、現在のユーザーがアクセス可能なユーザー定義索引タイプのコメントが表示されます。
DBA_INDEXTYPE_COMMENTSには、データベース内すべてのユーザー定義索引タイプのコメントが表示されます。
USER_INDEXTYPE_COMMENTSには、現在のユーザーが所有するユーザー定義索引タイプのコメントが表示されます。
表8-1ではALL_INDEXTYPE_COMMENTSビュー、DBA_INDEXTYPE_COMMENTSビューおよびUSER_INDEXTYPE_COMMENTSビュー
| 列 | データ型 | 値が必要な場合 | 説明 |
|---|---|---|---|
OWNER |
VARCHAR2(30) |
NOT NULL |
ユーザー定義索引タイプの所有者 |
INDEXTYPE_NAME |
VARCHAR2(30) |
NOT NULL |
ユーザー定義索引タイプ名 |
COMMENT |
VARCHAR2(4000) |
|
ユーザー定義索引タイプのコメント |
索引タイプにコメントを付けるには、その索引タイプが自分のスキーマ内に存在するか、COMMENT ANY INDEXTYPE権限を持っている必要があります。
この項では、ドメイン索引の操作と、ドメイン索引関連のメタデータを取得する方法について説明します。
次の項では、ドメイン索引の作成、変更、切捨ておよび削除について説明します。
ドメイン索引は、Bツリー索引と同様に表の1列に作成できます。ただし、例8-3のように、索引タイプを明示的に指定する必要があります。
例8-3 ドメイン索引の作成方法
CREATE INDEX ResumeTextIndex ON Employees(resume)
INDEXTYPE IS TextIndexType
PARAMETERS (':Language English :Ignore the a an');
INDEXTYPE句には、使用する索引タイプを指定します。PARAMETERS句では、文字列として指定されたドメイン索引のパラメータを識別します。この文字列は解析されずにODCIIndexCreate()ルーチンに渡され、ドメイン索引の作成に使用されます。前述の例では、パラメータ文字列により、テキスト・ドキュメントの言語（および使用する字句アナライザ）とテキスト索引の作成時に無視するストップワードのリストが識別されています。
ドメイン索引は、ALTER INDEX文を使用して変更できます。次に例を示します。
ALTER INDEX ResumeTextIndex PARAMETERS (':Ignore on');
パラメータ文字列は解析されずにODCIIndexAlter()ルーチンに渡され、このルーチンにより適切なアクションが実行されてドメイン索引が変更されます。この例では、テキスト索引内で無視するストップワードを追加指定しています。
ALTER文を使用すると、ドメイン索引の名前を変更できます。
ALTER INDEX ResumeTextIndex RENAME TO ResumeTIdx;
この書式の文を発行すると、OracleによりODCIIndexAlter()メソッドがコールされ、適切なアクションが実行されてドメイン索引の名前が変更されます。
また、ALTER文を使用すると、ドメイン索引を再作成することもできます。
ALTER INDEX ResumeTextIndex REBUILD PARAMETERS (':Ignore off');
前述の例と同じODCIIndexAlter()ルーチンがコールされますが、ALTERオプションに関する情報が追加されています。
エンド・ユーザーが索引構成表（IOT）のドメイン索引に対してALTER INDEX domain_index UPDATE BLOCK REFERENCESを実行すると、AlterIndexUpdBlockRefsビットが設定された状態でODCIIndexAlter()がコールされます。これにより、論理ROWIDのドメイン索引に格納される行のブロック位置に関する不確定要素を更新できます。
ドメイン索引を切り捨てるための明示的な文は存在しません。ただし、対応する実表が切り捨てられる場合は、ドメイン索引の基礎となる記憶表も切り捨てられます。さらに、ODCIIndexAlter()が起動されます。
TRUNCATE TABLE Employees;
alter_option set to AlterIndexRebuildのあるODCIIndexAlter()メソッドをコールしてResumeTextIndexを切り捨てます。
ドメイン索引のインスタンスを削除するには、DROP INDEX文を使用します。次に例を示します。
DROP INDEX ResumeTextIndex;
この例では、ODCIIndexDrop()メソッドがコールされ、索引に関する情報が渡されます。
この項では、索引タイプにより索引構成表にドメイン索引が作成される場合の考慮事項について説明します。ODCIIndexInfo構造内でIndexInfoFlagsのIndexOnIOTビットを使用すると、実表がIOTかどうかを判別できます。
ドメイン索引の実表が索引構成表で、実表のROWIDを独自の表に格納するときに、ROWIDが等価かどうかをテストする場合は、ROWIDをUROWID（ユニバーサルROWID）列に格納する必要があります。
ROWIDがVARCHAR列に格納されている場合、実表と独自の表の間でROWIDのテキスト等価比較を実行すると、ROWIDで同じ行が選択されて失敗することがあります。これは、索引構成表では物理ROWIDのかわりに論理ROWIDが使用され、物理ROWIDとは異なり、同じ行にある複数の論理ROWIDのテキスト表現が異なる場合があるためです。同じ主キーを持つ2つの論理ROWIDは、ともに格納されている不確定要素のデータ・ブロック・アドレス（DBA）に関係なく同一です。
1つのUROWID列に物理ROWIDと論理ROWIDの両方を格納できます。IOTのROWIDをUROWID列に格納すると、主キー情報は同じだが不確定要素DBAの異なる2つの論理ROWIDに対する等価演算子が確実に成功します。
IOTの実表からCREATE TABLE AS SELECTを実行して、ROWID列を持つ索引記憶表を作成すると、適切なサイズのUROWID列が索引表に作成されます。ROWID列を持つ表を作成する場合は、ROWID列をUROWID(x)型として明示的に宣言する必要があります。xはUROWID列のサイズです。実表の任意のROWIDを十分に保持できるサイズ、つまり、実表の主キーのファンクションを選択する必要があります。例8-4で示される問合せを使用すると、UROWID列に適したサイズを判断できます。
例8-4 UROWID列サイズの取得方法
SELECT (SUM(column_length + 3) + 7)
FROM user_ind_columns ic, user_indexes i
WHERE ic.index_name = i.index_name
AND i.index_type = 'IOT - TOP'
AND ic.table_ name = base_table;
記憶表を削除して再作成する場合、索引記憶表に対してALTER INDEX REBUILDを実行すると、CREATE TABLEの実行時と同じ問題が発生します。これに対して、実表がIOTである場合は、記憶表を再利用すると追加作業は不要です。
索引記憶表のUROWID列をメンテナンスする場合は、全種類のROWIDで機能するように、DML INSERT、UPDATEおよびDELETE文でROWIDバインド変数の型を変更する操作が必要になることがあります。渡されるROWID引数をテキスト文字列に変換し、テキスト文字列としてバインドする方法は、物理ROWIDとユニバーサルROWIDの両方で機能します。この方法により、標準の表とIOTの両方を処理する索引タイプをコーディングできます。
Start、FetchおよびCloseの間でコンテキストを渡すために索引スキャン・コンテキスト構造を使用する場合は、この構造を変更する必要があります。特に、この構造のバッファに問合せのROWID定義変数を格納する場合は、実表の主キーのサイズが事前にわかっているか、実行時に判別するのでないかぎり、このバッファ内のUROWIDについて最大サイズ（バイト形式のユニバーサルROWIDの場合は3800バイト、文字形式のユニバーサルROWIDの場合は5072）を割り当てる必要があります。また、FetchではODCIIndexInfoを使用できないため、実表がIOTかどうかを示すビットをコンテキスト内に格納する必要があります。
DML操作と同様に、定義変数をテキスト文字列として設定する方法は、物理ROWIDとユニバーサルROWIDの両方に使用できます。物理ROWIDが索引表からフェッチされる場合は、その長さが18文字であることを確認できます。ただし、ユニバーサルROWIDの場合は長さが最大5072文字になる可能性があるため、文字列長関数を使用して、フェッチされるユニバーサルROWIDの実際の長さを判別する必要があります。
主キー列の値はすべて一意である必要があるため、一意でない表列に定義されたドメイン索引では、この列を索引の格納に使用される基礎的なIOTの主キーとして使用できません。この問題に対処するため、索引データを保持するIOTに1列を追加して、その列に一意の順序番号を保持できます。表に列値が挿入されるときに、一意の順序番号も生成すると、索引付けされた列を順序番号とともにIOTの主キーとして使用できます。（UROWID列をIOTの主キーの一部にすることはできないため、順序番号列をUROWIDにすることはできないことに注意してください。）この方法では、IOTの大きなメリットである主キー列値への高速アクセスも維持されます。
Bツリー索引の場合、ユーザーはUSER_INDEXESビューを問い合せて索引情報を取得できます。ドメイン索引について同様のサポートを提供するために、次の方法でドメイン固有のメタデータを提供できます。
このメタ情報を格納する1つ以上の表を定義します。この表のキー列は、索引の一意識別子である必要があります。この一意キーを索引名（schema.index）に使用できます。残りの列にメタデータを格納できます。
システム定義のメタデータ表を索引メタ表と結合するビューを作成し、ドメイン索引のインスタンスごとに包括的な情報セットを提供します。索引タイプ設計者はビュー定義を提供する必要があります。
Bツリー索引やビットマップ索引と同様に、ドメイン索引は実表のエクスポート時にエクスポートされてからインポートされます。ただし、ドメイン索引には、システム・カタログに格納されていない実装固有のメタデータを関連付けることができます。たとえば、テキスト・ドメイン索引には、ポリシー情報、無関係なワードのリストなどを関連付けることができます。エクスポート/インポート・メカニズムによって、このメタデータがソース・プラットフォームからターゲット・プラットフォームに移動されます。
ドメイン索引のメタデータを移動するには、索引タイプでODCIIndexGetMetadata()インタフェース・メソッドを実装する必要があります。ドメイン索引のエクスポート時に、このメソッドがコールされ、ドメイン索引情報が渡されます。このメソッドは、ダンプ・ファイルに書き込まれてインポート時に実行される、必要な数の無名PL/SQLブロックを戻すことができます。これらの無名PL/SQLブロックが存在する場合は、関連ドメイン索引の作成直前に実行されます。
デフォルトでは、ドメインのセカンダリ・オブジェクトはインポートまたはエクスポートされません。ただし、インタフェースODCIIndexUtilGetTableNames()およびODCIIndexUtilCleanup()が存在する場合、これらが起動され、ドメイン索引に関連付けられているセカンダリ・オブジェクトがエクスポート/インポート操作の一部であるかどうかを判別します。
|
関連項目 エクスポート/インポートの使用方法は、『Oracle Databaseユーティリティ』を参照してください。 |
トランスポータブル表領域機能を使用すると、Oracleデータベース間で表領域を移動できます。ドメイン索引データをエクスポートしてからインポートするかわりに、トランスポータブル表領域を使用して移動できます。
トランスポータブル表領域を使用してデータを移動する方が、データのエクスポートとインポートまたはアンロードとロードを実行するよりも高速な場合があります。これは、表領域をトランスポートするには、データファイルをコピーして表領域の構造情報を統合するだけですむためです。また、ロードまたはインポートした場合のように、後で索引を再作成する必要もありません。ODCIIndexInfo内でTransTblspcフラグの有無を調べると、ODCIIndexCreate()コールがインポートされたドメイン索引の結果であるかどうかを判断できます。
ドメイン索引のセカンダリ表にトランスポータブル表領域を使用するには、実装タイプで2つのODCIインタフェースODCIIndexUtilGetTableNames()およびODCIIndexUtilCleanup()を追加提供する必要があります。
|
関連項目 トランスポータブル表領域の使用方法は、『Oracle Database管理者ガイド』を参照してください。 |
さらに次のビューでは、ユーザーがアクセス可能なドメイン索引に関連付けられているセカンダリ・オブジェクトに関する情報が提供されます。
ALL_SECONDARY_OBJECTSでは、ユーザーがアクセス可能なドメイン索引に関連付けられているセカンダリ・オブジェクトに関する情報が提供されます。
DBA_SECONDARY_OBJECTSでは、データベース内のドメイン索引に関連付けられているすべてのセカンダリ・オブジェクトに関する情報が提供されます。
USER_SECONDARY_OBJECTSでは、現在のユーザーが所有するドメイン索引に関連付けられているセカンダリ・オブジェクトに関する情報が提供されます。
表8-2 ALL_SECONDARY_OBJECTSビュー、DBA_SECONDARY_OBJECTSビューおよびUSER_SECONDARY_OBJECTSビュー
| 列 | データ型 | 値が必要な場合 | 説明 |
|---|---|---|---|
INDEX_OWNER |
VARCHAR2(30) |
NOT NULL |
ドメイン索引の所有者名 |
INDEX_NAME |
VARCHAR2(30) |
NOT NULL |
ドメイン索引名 |
SECONDARY_INDEX_OWNER |
VARCHAR2(30) |
NOT NULL |
ドメイン索引によって作成されたセカンダリ・オブジェクトの所有者 |
SECONDARY_INDEX_NAME |
VARCHAR2(30) |
NOT NULL |
ドメイン索引によって作成されたセカンダリ・オブジェクト名 |
SECONDARY_OBJDATA_TYPE |
VARCHAR2(20) |
NOT NULL |
セカンダリ・オブジェクトが索引タイプまたは統計タイプのいずれかで作成される場合に指定 |
例8-5では、例8-3で作成されたResumeTextIndexにある情報をUSER_SECONDARY_OBJECTSビューを使用して取得する方法を示します。
この項では、ドメイン索引で使用されるオブジェクトに影響する問題について説明します。
各種オブジェクト間には、次のような依存性があります。
ファンクション、パッケージおよびオブジェクト型: 演算子と索引タイプで参照されます。
演算子: 索引タイプ、DMLおよび問合せのSQL文で参照されます。
索引タイプ: ドメイン索引で参照されます。
ドメイン索引: DMLおよび問合せのSQL文で参照（暗黙的に使用）されます。
そのため、これらのオブジェクトを作成したり将来のインポートに備えて定義をエクスポートする場合は、次の順序で行う必要があります。
ファンクション、パッケージおよびオブジェクト型
演算子
索引タイプ
オブジェクトについての削除動作は、次のとおりです。
RESTRICTセマンティクス: 依存オブジェクトが存在する場合、削除操作は禁止されます。
FORCEセマンティクス: 依存オブジェクトが存在する場合にもオブジェクトは削除され、依存オブジェクトには再帰的に無効マークが付けられます。
表8-3に、演算子と索引タイプについてサポートされているデフォルトの削除オプションと明示的削除オプションを示します。その他のスキーマ・オブジェクトは、完全性とコンテキストのために含まれています。
演算子と演算子バインディングを作成するには、CREATE OPERATORまたはCREATE ANY OPERATOR権限に加えて、ファンクション、演算子、パッケージまたは参照される型に対するEXECUTE権限が必要です。
索引タイプを作成するには、CREATE INDEXTYPEまたはCREATE ANY INDEXTYPE権限に加えて、索引タイプを実装する型に対するEXECUTE権限が必要です。また、索引タイプでサポートする演算子に対するEXECUTE権限も必要です。
独自スキーマ内で索引タイプを変更するには、CREATE INDEXTYPEシステム権限が必要です。
他のユーザーのスキーマ内で索引タイプまたは演算子を変更するには、ALTER ANY INDEXTYPEまたはALTER ANY OPERATORシステム権限が必要です。
ドメイン索引を作成するには、CREATE INDEXまたはCREATE ANY INDEX権限に加えて、索引タイプに対するEXECUTE権限が必要です。
ドメイン索引を変更するには、索引タイプに対するEXECUTE権限が必要です。
問合せまたはDML文に演算子を使用するには、演算子と関連ファンクション、パッケージおよび索引タイプに対するEXECUTE権限が必要です。
実装タイプを変更するには、新規の実装タイプに対するEXECUTE権限が必要です。
レンジ・パーティション表のパーティションに対応する個別索引パーティションを持つドメイン索引を作成できます。この種の索引はローカル・ドメイン索引と呼ばれます。これに対して、索引パーティションのない索引は、グローバル・ドメイン索引と呼ばれます。ローカル・ドメイン索引は、それ自体を構成するパーティションではなく、パーティション索引全体を参照します。
ローカル・ドメイン索引は基礎となる表とともに同一レベル・パーティション化され、ローカル・ドメイン索引内のキーはすべて、対応する表パーティションに格納される行を参照します。他のパーティションの行を参照するキーはありません。
例8-6のように、CREATE INDEXTYPE文を使用して、索引タイプでローカル・ドメイン索引を使用するように指定します。
例8-6 索引タイプ内でローカル・ドメイン索引メソッドを使用する方法
CREATE INDEXTYPE TextIndexType FOR Contains (VARCHAR2, VARCHAR2) USING TextIndexMethods WITH LOCAL RANGE PARTITION WITH SYSTEM MANAGED STORAGE TABLES;
この文では、実装タイプTextIndexMethodsでローカル・ドメイン索引を作成して保守できるように指定しています。WITH LOCAL RANGE PARTITION句では、実表のパーティション化方法を指定しています。
例8-7のように、CREATE INDEX文により索引が作成され、パーティション化されます。
例8-7 索引タイプを作成してパーティション化する方法
CREATE INDEX [schema.]index
ON [schema.]table [t.alias] (indexed_column)
INDEXTYPE IS indextype
[LOCAL [PARTITION [partition [PARAMETERS ('string')]]] [...] ]
[PARALLEL parallel_degree]
[PARAMETERS ('string')];
LOCAL [PARTITION]句は、索引がパーティション表のローカル索引であることを示します。パーティション名を指定するか、Oracleに生成させることができます。
PARALLEL句は、索引パーティションをパラレルに作成するように指定します。索引パーティション作成、再作成または移入に対応するODCIIndexAlter()ルーチンが、パラレルにコールされます。
PARAMETERS句で、解析されずに適切なODCI索引タイプ・ルーチンに渡されるパラメータ文字列を指定します。このパラメータ文字列の最大サイズは1000文字です。
この句を構文のトップレベルで指定すると、各パラメータは索引パーティションのデフォルト・パラメータとなります。この句をLOCAL [PARTITION]句の一部として指定すると、デフォルト・パラメータが個別パーティションのパラメータでオーバーライドされます。LOCAL [PARTITION]句では、複数のパーティションを指定できます。
ドメイン索引の作成後に、適切なODCIルーチンが起動されます。ルーチンが正常に値を戻さない場合、ドメイン索引にはFAILEDマークが付けられます。失敗したドメイン索引に対してサポートされている操作は、DROP INDEXおよび（非ローカル索引の場合の）REBUILD INDEXのみです。例8-8では、ローカル・ドメイン索引ResumeIndexが作成されます。
例8-8 ローカル・ドメイン索引の作成方法
CREATE INDEX ResumeIndex ON Employees(Resume) INDEXTYPE IS TextIndexType LOCAL;
索引パーティションを指定して明示的に削除することはできません。ローカル索引パーティションを削除するには、次のようにローカル・ドメイン索引全体を削除する必要があります。
DROP INDEX ResumeIndex;
ALTER INDEX文を使用し、ローカル・ドメイン索引に対して次の操作を実行します。
トップレベル索引の名前変更
すべての索引パーティションのデフォルトのパラメータ文字列の変更
特定のパーティションに関連付けられているパラメータ文字列の変更
索引パーティションの名前変更
索引パーティションの再作成
ALTER INDEXTYPE文を使用すると、索引タイプを削除して再作成した後ですべての依存索引を再作成しなくとも、索引タイプのプロパティと実装タイプを変更できます。
|
関連項目 この項で説明したSQL文の構文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。 |
ドメイン索引と同様に、ローカル・ドメイン索引のパーティションは表8-4に示す1つ以上の状態にすることができます。
表8-4 索引の状態の概要
| 状態 | 説明 |
|---|---|
|
|
索引または索引パーティションがこの状態になるのは、 |
|
|
索引に対してDDL操作を実行する |
|
|
標準索引と同じ。一定のパーティション・メンテナンス操作の結果、パーティション表の索引に |
|
|
索引に |
|
|
索引に |
ローカル・ドメイン索引の索引パーティションがIN_PROGRESS、FAILEDまたはUNUSABLE状態の場合、基礎となる表に対するDML操作は実行できません。ただし、索引にUNUSABLEマークおよびSKIP_UNUSABLE_INDEXES = trueマークが付けられている場合は、索引メンテナンスは実行されていません。
この項の表に、索引の基礎となる表に対して実行できる操作と、索引への影響を示します。表8-5では、表操作がリストされていて、表8-6では、ALTER TABLE操作がリストされています。
表8-5 表操作の概要
| 表操作 | 説明 |
|---|---|
|
|
表を削除します。すべての索引および対応するパーティションが削除されます。 |
|
|
表を切り捨てます。すべての索引と索引パーティションが切り捨てられます。 |
表8-6 パーティションのメンテナンスが関係するALTER TABLE操作の概要
| ALTER TABLE操作 | 説明 |
|---|---|
|
パーティションで使用できないローカル索引の変更 |
表パーティションに関連付けられているローカル索引パーティションに |
|
パーティションの再作成で使用できないローカル索引の変更 |
この表パーティションに関連付けられている |
|
パーティションの追加 |
新規の表パーティションを追加します。新規のローカル索引パーティションも追加されます。 |
|
パーティションの削除 |
表のレンジ・パーティションを削除します。関連するローカル索引パーティションも削除されます。 |
|
パーティションの切捨て |
表パーティションを切り捨てます。関連するローカル索引パーティションも切り捨てられます。 |
|
パーティションの移動 |
実表のパーティションを別の表領域に移動します。対応するローカル索引パーティションに |
|
パーティションの分割 |
表パーティションが2つのパーティションに分割されます。対応するローカル索引パーティションも分割されます。分割後のパーティションが空でない場合は、索引パーティションに |
|
パーティションのマージ |
2つの表パーティションをマージして1つのパーティションにします。対応するローカル索引パーティションもマージする必要があります。マージ後のパーティションにデータが含まれている場合は、索引パーティションに |
|
索引を除くパーティションの交換 |
表パーティションを非パーティション表と交換します。ローカル索引パーティションとグローバル索引には |
|
索引を含むパーティションの交換 |
表パーティションを非パーティション表と交換します。ローカル索引パーティションは、非パーティション表のグローバル索引と交換されます。索引パーティションは |
システムのパーティション化により、複数の物理的パーティションで構成される単一の表を作成できます。システムのパーティション化にはパーティション化キーは使用しません。かわりに、指定された数のパーティションを作成します。したがって、作成されたパーティションには境界（範囲）、値（リスト）またはパーティション化方法は含まれません。
パーティション化キーがないため、分散表の行を該当するパーティションに明示的にマップする必要があります。たとえば行を挿入する場合、パーティション拡張構文を使用して、行がマップされるパーティションを指定する必要があります。
|
関連項目 『Oracle Database SQL言語リファレンス』のSQL構文のサポートに関する項を参照してください。 |
システム・パーティション表の主なメリットは、別の表とともに同一レベル・パーティション化される表の作成およびメンテナンスに使用できることです。たとえば、実表と同じパーティションの数で、依存表をシステム・パーティション表として作成できます。次の理由により、このようなシステム・パーティション表はドメイン索引の索引データの格納に使用できます。
プルーニングは実表のプルーニング・ルールに従うため、実表内で1つのパーティションがアクセスされると、システム・パーティション表の対応するパーティションもアクセス可能になります。
実表のDDLはシステム・パーティション表で複製できます。したがって、実表でパーティションが削除されると、システム・パーティション表の対応するパーティションも自動的に削除されます。
この項では、システムのパーティション化を実装する方法について説明します。
例8-10に、システム・パーティション表にデータを挿入する方法を示します。INSERT文またはMERGE文（ここでは表示されていません）の両方で、パーティション拡張構文を使用して、行を追加するパーティションを識別する必要があります。タプル(4,5)は、例8-9で作成された4つのパーティションのいずれかに挿入されます。例8-11で示されるように、DATAOBJ_TO_PARTITIONも使用できます。
例8-11 DATAOBJ_TO_PARTITIONを使用してシステム・パーティション表にデータを挿入する方法
INSERT INTO SystemPartitionedTable PARTITION (DATAOBJ_TO_PARTITION (base_table, :physical_partid)) VALUES (...);
コードの最初の行には、名前付きパーティションへのデータの挿入方法が示されていて、2行目には、そのデータはパーティションの順序に基づいてパーティションに挿入可能であることが示されていることに注意してください。コードの3行目に示されているバインド変数のサポートは、INSERT文間のカーソルの共有を可能にするため重要です。
次の操作を実行することで、システムのパーティション化によるサポートが継続されます。
パーティション・メンテナンス操作およびその他のDDL操作（次の例外を除く）
ALTER INDEX SPLIT PARTITION
ALTER TABLE SPLIT PARTITION
SELECTでのCREATE TABLE
ローカル索引の作成（パーティション化キーが必要な一意のローカル索引を除く）
ローカル・ビットマップ索引の作成
グローバル索引の作成
すべてのDML操作
次のようなパーティション拡張構文を使用したINSERT AS SELECT操作
INSERT INTO TableName PARTITION ( PartitionName| DATAOBJ_TO_PARTITION(base_table, :physical_partid)) AS SubQuery
システムのパーティション化では、パーティション化方法が使用されないため、パーティションに行が分散されません。そのため、次の操作はシステムのパーティション化のサポート外になります。
CREATE TABLE AS SELECT代替アプローチとして、まず表を作成し、それから行を各パーティションに挿入します。
INSERT INTO TableName AS SubQuery
この項では、1つの例として、ドメイン索引の実表に対して発行されたALTER TABLE SPLIT PARTITIONルーチンについて説明します。
追加または削除されるパーティションの情報を使用して、ODCIIndexUpdPartMetadata()メソッドが起動されます。1対2の分割には、1つのパーティションの削除と2つの新規パーティションの追加が必要です。
影響を受けるパーティションでODCIStatsUpdPartStatistics()が起動されます。
すべてのシステム・パーティション索引および統計記憶表から分割されたパーティションが削除されます。
システム・パーティション表に2つの新規のパーティションが追加されます。
分割されるパーティションが空の場合、最初のODCIIndexAlter()へのコールで分割パーティションが再作成され、2番目のODCIIndexAlter()へのコールで新しく追加されたパーティションが再作成されます。
ALTER TABLE EXCHANGE PARTITIONコマンドは、次の状況下でのみ、ドメイン索引を含む表に対して許可されます。
ドメイン索引が非パーティション表およびパーティション表の両方で定義される場合
非パーティション表およびパーティション表の両方に、同一の関連付けられている索引タイプがある場合
ALTER TABLE EXCHANGE PARTITIONルーチンにより、次のユーザー実装メソッドが起動されます。
影響を受けるパーティションおよび索引に対するODCIIndexExchangePartition()メソッド
統計が収集される場合に影響を受けるパーティションおよび索引に対するODCIStatsExchangePartition()メソッド
この項では、システム管理ドメイン索引の動作および、それらの索引の統計の収集方法および格納方法を説明し、使用上の制限事項をリストします。
システム管理ドメイン索引の動作を検証します。
図8-1に、実表T1の初期設定を示します。T1には次の要素が含まれます。
3つのパーティション
IT1（表の1つの列上のローカル・ドメイン索引）
MT1（メタデータ・オブジェクトに対応する表で、ローカル・ドメイン索引の各パーティションに固有の情報を格納するために索引タイプにより作成されたオプションのメタデータ表）
SPT1（索引データを格納するために索引タイプにより作成されたシステム・パーティション表）
表T1、索引IT1およびシステム・パーティション表SPT1に示した構造には、1対1の関係で同数のパーティションがあります。メタデータ表MT1には、これらの表内のパーティション数と同数の行があります。
図8-2に、次の操作を実行して1つのパーティションを分割した後のT1および関連構造の状況を示します。
ALTER TABLE T1 SPLIT PARTITION P2 INTO P21, P22
実表T1内のパーティションP2をP21およびP22に分割します。
ローカル・ドメイン索引で、パーティションIP2が削除され、2つの新規パーティション、IP21およびIP22が作成されます。
索引タイプにより、メタデータ表MT1を必要に応じて更新するODCIIndexUpdPartMetadata()メソッドが起動されます。
システム・パーティション表SPT1で、パーティションIP2に対応するパーティションは削除され、2つの新規パーティションが作成されます。
分割操作の結果、索引パーティションにUNUSABLEマークが付けられ、USABLEになるように再作成されます。
図8-2 ALTER TABLE SPLIT PARTITIONの後の3つのパーティションの表
非パーティション・ドメイン索引に影響するトップレベルのDDLがコールされると、ユーザー実装のODCIIndexXXX()メソッドおよびODCIStatsXXX()メソッドが起動されます。表8-7に、これらのメソッドを示します。
表8-7 非パーティション・ドメイン索引に対するODCIXXX()メソッド
| DDL | システム管理アプローチに使用されるODCIXXX()メソッド |
|---|---|
CREATE INDEXTYPE |
システム管理アプローチを指定 |
CREATE INDEX |
|
TRUNCATE TABLE |
|
ALTER INDEX |
|
GATHER_INDEX_STATS() （ |
|
DELETE_INDEX_STATS() （ |
|
DROP INDEX （FORCE） |
|
INSERT |
|
DELETE |
|
UPDATE |
|
QUERY |
ローカル・システム管理のドメイン索引に影響するトップレベルのDDLがコールされる場合、ユーザー実装のODCIIndexXXX()メソッドとODCIStatsXXX()メソッドが起動されます。表8-8に、これらのメソッドを示します。要約すると、次のルールが適用されます。
ODCIIndexXXX ()DMLおよび問合せでは、索引パーティションのオブジェクト識別子（ODCIIndexInfo.IndexPartitionIden）および実表パーティションの物理識別子（ODIIndexInfo.IndexCols(1).TablePartitionIden）の両方が必要です。ODCIIndexXXX ()DDLルーチンでは、索引パーティションのオブジェクト識別子と索引パーティション名の両方が提供されます。
CREATE INDEXルーチンでは、ODCIIndexCreate()に対して2つのコール（1つは開始時で、もう1つは終了時）を使用し、alter_option=AlterIndexRebuildのあるODCIIndexAlter()に対してはパーティションの数と同数のコールを使用します。
TRUNCATE TABLEルーチンでは、alter_option=AlterIndexRebuildのあるODCIIndexAlter()に対してパーティションの数と同数のコールを使用します。
すべてのパーティション・メンテナンス操作により、ODCIIndexUpdPartMetadata()が起動され、索引タイプによりパーティション・メタデータ表が適切に更新されます。索引パーティションのリストは、索引パーティション名と索引パーティションのオブジェクト識別子によって指定され、パーティションの追加または削除に関する情報とともに提供されます。これらのコールではDDLは許可されません。各パーティション・メンテナンス操作により、ドメイン索引を使用して作成されたシステム・パーティション記憶表を暗黙的に変換します。新規に生成されたパーティションの名前は索引パーティション名に対応します。
システム・パーティション表がパーティション・レベルの統計の格納に使用される場合、ODCIStatsCollect()が作成し、ODCIStatsDelete()が削除する表および索引は、追跡されて同一レベルのパーティション化がメンテナンスされます。
アプリケーションにユーザー定義のパーティション・レベルの統計が実装されている場合は、パーティション・メンテナンス操作ごとにODCIStatsUpdPartStatistics()が起動されます。これにより、統計タイプによるパーティション・レベルの統計とオプションでのグローバル集計統計の更新が確実になります。これらのコールでは、DDLは許可されません。ODCIStatsUpdPartStatistics()が実装されていない場合は例外はありませんが、かわりに次のプログラムのステップに進みます。
表8-8 ローカル・システム管理ドメイン索引に対するODCIXXX()メソッド
| DDL | システム管理アプローチに使用されるODCIXXX()メソッド |
|---|---|
CREATE INDEXTYPE |
システム管理アプローチを指定 |
CREATE INDEX |
ODCIIndexCreate()へのコール、 |
TRUNCATE TABLE |
|
ALTER INDEX |
|
GATHER_INDEX_STATS() （ |
ODCIStatsCollect()へのコール |
DELETE_INDEX_STATS() （ |
ODCIStatsDelete()へのコール |
DROP INDEX （FORCE） |
ODCIIndexDrop()、またはユーザー定義の統計が収集された場合はODCIStatsDelete() |
ALTER TABLE ADD PARTITION |
ODCIIndexUpdPartMetadata()、 |
ALTER TABLE DROP PARTITION |
ODCIIndexUpdPartMetadata()、統計が収集される場合はODCIStatsUpdPartStatistics() |
ALTER TABLE TRUNCATE PARTITION |
ODCIIndexUpdPartMetadata()、 |
ALTER TABLE SPLIT PARTITION |
ODCIIndexUpdPartMetadata()、結果的にパーティションが空である場合は |
ALTER TABLE MERGE PARTITION |
ODCIIndexUpdPartMetadata()、結果的にパーティションが空である場合は |
ALTER TABLE EXCHANGE PARTITION |
ODCIIndexExchangePartition()、統計タイプが索引タイプに関連付けられていてユーザー定義の統計が収集された場合はODCIStatsExchangePartition() |
ALTER TABLE MOVE PARTITION |
パーティション表に、パーティション |
GATHER_TABLE_STATS() （ |
ODCIStatsCollect()へのコール |
DELETE_TABLE_STATS() （ |
統計タイプが索引タイプに関連付けられていてユーザー定義の統計が収集された場合は、ODCIStatsDelete()へのコール |
ALTER INDEX PARTITION |
|
INSERT |
|
DELETE |
|
UPDATE |
|
QUERY |
CREATE INDEXルーチンには次のステップが実装されています。
システム・パーティション記憶表を作成するには、索引情報を含むODCIIndexCreate()がコールされます。ODCIIndexInfo.IndexPartitionTotal属性にパーティションの数が指定されます。すべてのパーティション記憶表をシステム・パーティション化する必要があることに注意してください。
オブジェクト・レベルのCREATEルーチンはオブジェクト・レベルのパラメータ文字列にのみ渡されます。すべてのパーティションに記憶属性を構成するには、索引タイプにパーティション・レベルのパラメータ文字列が必要です。これらを取得するには、カートリッジによってディクショナリ表のXXX_IND_PARTITIONSビューをプログラム上で問い合せる必要があります。
索引タイプにより、索引パーティション名を使用して記憶表およびそのパーティションに名前を割り当てることをお薦めします。また、XXX_IND_PARTITIONSビューから索引パーティション名をプログラム上で取得する必要があることに注意してください。
各パーティションでは、alter_option=AlterIndexRebuildを含むODCIIndexAlter()メソッドがコールされます。
ODICEnv.IntermediateCallビットが設定されたかどうかを確認することにより、このODCIIndexAlter()コールがCREATE INDEXコールの一部として作成されたかどうかを検証できます。
実表パーティションから各パーティションの索引列の値をプログラム上で選択し、それらを変換し、変換されたデータを対応するシステム・パーティション表に格納します。
DML操作または問合せ操作の間、索引タイプによりメタデータ表を参照する必要がある場合、索引パーティションのオブジェクト識別子をメタデータ表の対応する行に挿入するようにプログラム化する必要があります。
非パーティション表に値を格納するには、各パーティションに作成された初期ODCIIndexCreate()コールのレベル、またはODCIIndexAlter()コールのレベルのいずれかでカートリッジをプログラム化できます。
ODCIIndexCreate()メソッドへの最終コールが作成され、索引タイプにより記憶表に必要なすべての索引が作成できます。
CREATEルーチンでは、中間データの一時的な記憶表が使用される場合があります。オプションで、外部ファイルの使用をアプリケーションにプログラム上で指示できます。ただし、これらのファイルはアプリケーションにより管理されます。
このODCIIndexCreate()コールの完了後、このコールによって作成され、削除されなかったすべてのパーティション表はシステムにより管理されます。
システム・パーティション索引記憶表にある各種グローバル索引の作成には、エラー・フラグが表示されることに注意してください。
DML操作は、次の方法で実装されます。
ODCIIndexInsert()、ODCIIndexDelete()またはODCIIndexUpdate()のうち1つが起動されます。索引パーティションのオブジェクト識別子（メターデータへのアクセス用）および実表パーティションの物理識別子（対応するパーティション内のDML実行用）は、ODICIndexInfo構造の一部として提供されます。
システム・パーティション表にDMLを実装するには、カートリッジ・コードに次の構文を含める必要があります。システムにより、DATAOBJ_TO_PARTITION()関数が提供されます。
INSERT INTO SP PARTITION (DATAOBJ_TO_PARTITION(base_table, :physical_partid)) VALUES(...)
次のステップに従ってローカル・ドメイン索引の問合せを実行します。
オプティマイザがユーザー定義の演算子を含む問合せを受け取るときに、ドメイン索引スキャンを使用して評価するように定義されている場合、ODCIIndexStart()、ODCIIndexFetch()またはODCIIndexClose()が起動されます。
索引パーティションのオブジェクト識別子および実表パーティションの物理識別子はODCIIndexInfo構造の一部として渡されます。
必要な場合は、索引パーティションのオブジェクト識別子を使用してメタデータ表を検索できます。
また、実表パーティションの物理識別子を使用してシステム・パーティション表の対応するパーティションを問い合せることができます。
カートリッジ・コードでは、システム・パーティション表を問い合せるために、次の構文と提供されたDATAOBJ_TO_PARTITION()関数を使用する必要があります。
SELECT FROM SP PARTITION (DATAOBJ_TO_PARTITION(base_table, :physical_partid)) WHERE <..>;
システム管理ドメイン索引付けのアプローチは次の構造をサポートします。
非パーティション・システム管理ドメイン索引
レンジ・パーティション化された表にあるローカル・システム管理ドメイン索引
ローカル・ドメイン索引を作成できるのは、レンジ・パーティション化されたヒープ構成表の場合のみです。ハッシュ・パーティション表、リスト・パーティション表、インターバル・パーティション表またはIOTの場合、ローカル・ドメイン索引は作成できません。
システム管理ドメイン索引で索引付けできるのは1列のみです。
ビットマップ索引または一意ドメイン索引は指定できません。
次のステップに従って、非パーティション・ユーザー管理ドメイン索引をシステム管理ドメイン索引に移行します。
メタデータを変更します。ALTER INDEXTYPEコマンドを発行して索引のプロパティをシステムに登録します。これにより統計タイプが分離されます。
索引にINVALIDマークが付けられます。ALTER INDEX ... COMPILEコマンドを暗黙的に発行し、索引を再検証する必要があります。これにより、alter_option=AlterIndexMigrateを含むODCIIndexAlter()メソッドがコールされます。
ASSOCIATE STATISTICSコマンドを発行してシステム管理統計タイプをシステム管理索引タイプに関連付けます。
次のステップに従って、ローカル・パーティション・ユーザー管理ドメイン索引をシステム管理パーティション・ドメイン索引に移行します。
メタデータを変更します。ALTER INDEXTYPEコマンドを発行して新規の索引ルーチンおよび索引のプロパティを登録すると、システムによる管理が可能になります。この索引タイプのすべての索引にはINVALIDマークが付けられ、次のステップが完了するまで使用できません。これにより統計タイプは分離され、また古い統計を消去します。
索引データを変更します。ALTER INDEX ... COMPILEコマンドが、各索引の新規の索引タイプのために起動されます。これにより、alter_option=AlterIndexMigrateを含むODCIIndexAlter()メソッドがコールされます。このメソッドを実装して非パーティション表にあるグループをシステム・パーティション表に変換する必要があります。パーティション表を表すn表の各セットでは、カートリッジ・コードにより次のアクションが実行される必要があります。移行には索引データの再生成は必要ありませんが、交換操作のみが必要であることに注意してください。
システム・パーティション表の作成
各n非パーティション表では、ALTER TABLE EXCHANGE PARTITION [INCLUDING INDEXES]ルーチンがコールされて非パーティション表をシステム・パーティション表のパーティションに交換します。
すべてのn非パーティション表を削除します。
ASSOCIATE STATISTICSコマンドを発行してシステム管理統計タイプをシステム管理索引タイプに関連付けます。
