この章では、SECUREFILE
およびBASICFILE
パラメータの両方を持つLOB列を含む表に特定の問題について説明します。機能が、2種類のLOBのいずれか1つのみに適用される場合は、そのように示されます。
この章の内容は次のとおりです。
LOBを含む表を作成する場合は、次の項に示すガイドラインを使用してください。
永続LOB(表内のLOB列、またはユーザーが定義したオブジェクト型のLOB属性)を、NULL
または空に設定できます。
永続LOBをNULLに設定: NULL
に設定されたLOBにロケータはありません。NULL
値はロケータではなく、表内の行に格納されます。これは、他のすべてのデータ型と同じプロセスです。
永続LOBを空に設定: 対照的に、表内に格納される空のLOBは、ロケータを持つ、長さがゼロのLOBです。このため、空のLOB列または属性からSELECT
する場合、OCIやPL/SQL (DBMS_LOB
)などのサポートされているプログラム環境を使用してLOBにデータを移入するために使用できるロケータを取り戻します。サポートされている環境の詳細は、第13章「LOB APIの概要」を参照してください。
ここでは、各オプションについて説明します。
永続LOBの値をNULL
に設定するのは、INSERT
時にLOBデータのない行を挿入する場合や、次のようにSELECT
文を使用してLOBにNULL
値を保持するかどうかを指定する場合です。
SELECT COUNT (*) FROM print_media WHERE ad_graphic IS NOT NULL; SELECT COUNT (*) FROM print_media WHERE ad_graphic IS NULL;
NULL
のLOBに対しては、OCI関数やDBMS_LOBファンクションをコールできません。そのため、LOB列をNULL
以外(または空)の値に再設定するには、SQLのUPDATE
文を使用する必要があることに注意してください。
この場合、NULL
のLOB上でサポートされているプログラム環境からファンクション・コールを行うことはできません。これらのファンクションはロケータでのみ動作し、LOB列がNULL
である場合、行内にロケータはありません。
永続LOBをNULL
ではなくEMPTY
に初期化できます。これにより、LOBにデータを移入せずにLOBインスタンスのロケータを取得できます。永続LOBをEMPTY
に設定するには、INSERT
文でSQLのEMPTY_BLOB()
ファンクションまたはEMPTY_CLOB()
ファンクションを使用します。
INSERT INTO a_table VALUES (EMPTY_BLOB());
または、その後SELECT文をコールするかわりに、RETURNING
句を使用して1回の操作でLOBロケータを取得する方法もあります。
DECLARE
Lob_loc BLOB;
BEGIN
INSERT INTO a_table VALUES (EMPTY_BLOB()) RETURNING blob_col INTO Lob_loc;
/* Now use the locator Lob_loc to populate the BLOB with data */
END;
次のINSERT
文を使用して、print_media
の中のLOBを初期化できます。
INSERT INTO print_media VALUES (1001, EMPTY_CLOB(), EMPTY_CLOB(), NULL, EMPTY_BLOB(), EMPTY_BLOB(), NULL, NULL, NULL, NULL);
これにより、ad_sourcetext
、ad_fltextn
、ad_composite
およびad_photo
の値が空の値に設定され、ad_graphic
がNULL
に設定されます。
BFILE
はNULL
またはファイル名に初期化できます。この操作にはBFILENAME()
ファンクションを使用できます。
任意のセグメントの最初のエクステントには、少なくとも2ブロックが必要です(FREELIST GROUPS
が0であった場合)。つまり、セグメントの初期エクステント・サイズは少なくとも2ブロックである必要があります。LOBセグメントは、最初のエクステントに少なくとも3ブロック必要なため、異なっています。初期サイズが2ブロックである永続ディクショナリ管理の表領域でLOBセグメントを作成しようとしても、この作業は有効です。これは、永続ディクショナリ管理の表領域内のセグメントで表領域のデフォルトの記憶域設定を上書きできるためです。
ただし、均一なローカル管理の一時表領域やディクショナリ管理の一時表領域、またはローカル管理の一時表領域内のエクステント・サイズが2ブロックである場合は、これらの表領域内にLOBセグメントを作成できません。これは、これらのタイプの表領域ではエクステント・サイズが固定され、表領域のデフォルト記憶域設定が無視されることはないためです。
データ型を選択する場合、次の3項目を考慮します。
表11-1に、LOB型とLONG型およびLONG RAW型との類似点と相違点を示します。
表11-1 LOBとLONG RAW
LOBデータ型 | LONGおよびLONG RAWデータ型 |
---|---|
単一の行に複数のLOBを格納できます。 |
1行当たり1つの |
|
|
LOBロケータのみ表の列に格納されます。 インラインLOBについては、表列の中に約4000バイトまでのデータが格納されます。 |
|
LOB列にアクセスすると、ロケータまたはデータのフェッチが選択できます。 |
|
LOBのサイズは、ブロック・サイズに応じて128TB以下またはそれ以上です。 |
|
ランダムにピース単位でデータを操作する場合は、LOBを使用する方が柔軟性があります。LOBはランダム・オフセットでアクセスできます。 |
|
ローカルおよび分散環境の両方でLOBをレプリケートできます。 |
|
CLOB
データ型およびNCLOB
データ型の可変幅文字データは、UCS2 Unicodeキャラクタ・セット形式と互換性のある内部形式で格納されます。このため、可変幅形式の文字データの記憶が消失することはありません。また、LOBを使用して可変幅文字データを格納する場合は、次のことに注意してください。
可変幅のCHAR
またはNCHAR
データベース・キャラクタ・セットを使用する場合にも、CLOB
列とNCLOB
列を含む表を作成できます。
可変幅のCHAR
データベース・キャラクタ・セットを使用するかどうかに関係なく、CLOB
属性を持つデータ型を含む表を作成できます。
OCI(Oracle Call Interface)で使用されるCLOB
およびNCLOB
インスタンスや、OCI機能にアクセスするプログラム環境の場合、キャラクタ・セットの変換は1つのキャラクタ・セットから別のキャラクタ・セットに翻訳するとき、暗黙的に実行されます。
DBMS_LOB.LOADCLOBFROMFILE
APIにより、CLOB
またはNCLOB
へのロード時にバイナリ・データから文字データへの暗黙的な変換が実行されます。このDBMS_LOB.LOADCLOBFROMFILE
は例外であり、LOB APIではバイナリ・データから文字データへの暗黙的な変換は実行されません。
たとえば、DBMS_LOB.LOADFROMFILE
APIを使用してCLOB
またはNCLOB
に移入する場合は、BFILE
のバイナリ・データをLOBに移入することになります。この場合は、DBMS_LOB.LOADFROMFILE
をコールする前に、BFILE
データのキャラクタ・セット変換を実行する必要があります。
関連項目: キャラクタ・セットの変換の詳細は、『Oracle Databaseグローバリゼーション・サポート・ガイド』 |
注意: ユーザー定義された移入済のCLOB 列がデータベース表内に存在する場合、データベース・キャラクタ・セットをシングルバイトからマルチバイト・キャラクタに変更することはできません。ユーザー定義された移入済のNCLOB 列がデータベース表内に存在する場合、各国語キャラクタ・セットをAL16UTF16 とUTF8 間で変更することはできません。 |
この項では、LOB記憶域を含む表の設計時に考慮する必要のある、LOB記憶域の特性について説明します。次は、SECUREFILE
パラメータに関する説明です。
LOB列には、実際のLOB値の位置を参照するロケータが格納されます。表の作成時に指定する列のプロパティとLOBのサイズに応じて、実際のLOB値は表の行(インライン)または表の行の外(アウトライン)に格納されます。
LOB値がアウトラインに格納されるのは、次のいずれかの条件に該当する場合です。
列のLOB記憶域プロパティにかかわらず、LOBのサイズが約4000バイト(4000バイトからシステム制御情報を引いたもの)を超える場合。
アウトラインに格納されているLOBを更新した場合は、更新後のLOBが約4000バイトを下回っていても、そのままアウトラインに格納されます。
LOB値がインラインに格納されるのは、次のいずれかの条件に該当する場合です。
指定の行に格納されるLOBのサイズが約4000バイト以下で、表の作成時にLOBのSTORAGE句にENABLE
STORAGE
IN
ROW
を明示的に指定する場合、またはこのパラメータを指定しない(デフォルト)場合。
デフォルトのLOB記憶域プロパティ(インライン記憶域)を使用する方がデータベースのパフォーマンスが向上し、小さいLOB値のためのアウトライン記憶域の作成と管理に伴うオーバーヘッドを回避できます。データベースに格納されるLOB値のサイズが小さいときが多い場合は、インライン記憶域を使用することをお薦めします。
表内のLOBを定義する場合、各永続LOB列の表領域および記憶特性を明示的に指定できます。
BasicFiles LOBを作成するには、BASICFILE
キーワードはオプションですが、次の例に示すように、明確になるように使用することをお薦めします。
CREATE TABLE ContainsLOB_tab (n NUMBER, c CLOB) lob (c) STORE AS BASICFILE segname (TABLESPACE lobtbs1 CHUNK 4096 PCTVERSION 5 NOCACHE LOGGING STORAGE (MAXEXTENTS 5) );
SecureFilesの場合、次の例に示すように(TABLESPACE lobtbs1
がASSM
であることを想定)、SECUREFILE
キーワードが必要です。
CREATE TABLE ContainsLOB_tab1 (n NUMBER, c CLOB) lob (c) STORE AS SECUREFILE sfsegname (TABLESPACE lobtbs1 RETENTION AUTO CACHE LOGGING STORAGE (MAXEXTENTS 5) );
注意: 外部LOB (BFILE )に対して指定できる表領域または記憶特性はありません。これらはデータベースには格納されません。 |
既存のLOB列のLOB記憶域パラメータを変更する必要がある場合は、ALTER
TABLE
... MOVE
文を使用します。変更できるのは、RETENTION
、PCTVERSION
、CACHE
、NOCACHE
LOGGING
、NOLOGGING
またはSTORAGE
の設定です。またALTER TABLE ...MOVE
文を使用してTABLESPACE
を変更できます。
前述の例に示すように、LOBデータ・セグメントに名前を指定すると、作業環境がより明確になります。USER_LOBS
、ALL_LOBS
、DBA_LOBS
のLOBデータ・ディクショナリ・ビューを問い合せた際(『Oracle Databaseリファレンス』を参照)、システムが生成した名前ではなく、選択したLOBデータ・セグメント名が表示されます。
LOB列またはLOB属性に対して指定できるLOB記憶特性は次のとおりです。
TABLESPACE
PCTVERSION
またはRETENTION
指定できるのは、BasicFiles LOBのPCTVERSION
またはRETENTION
のどちらか一方のみであることに注意してください。SecureFilesの場合は、RETENTION
パラメータのみを指定できます。
CACHE
/NOCACHE/CACHE READS
LOGGING / NOLOGGING
CHUNK
ENABLE
/DISABLE
STORAGE
IN
ROW
STORAGE
ほとんどのユーザーには、これらの記憶特性のデフォルトで十分です。LOB記憶域をチューニングする場合は、次のガイドラインを考慮してください。
関連項目: 『Oracle Database SQL言語リファレンス』のSTORAGE句に関する項およびRETENTIONパラメータに関する項 |
LOBに対するパフォーマンスを最適化するには、LOBの記憶域を、そのLOBを含む表に使用されるものとは別の表領域に指定します。多くのLOBが頻繁にアクセスされる場合は、デバイスの競合を避けるために、LOB列またはLOB属性ごとに個別の表領域を指定することも効果的です。
LOB索引は、LOB記憶域に密接に対応付けられている内部構造体です。したがって、ユーザーがLOB索引を削除または再構築することはできません。
注意: LOB索引は変更できません。 |
システムは、LOB STORAGE句内のユーザー指定に従って、LOBデータおよびLOB索引に使用する表領域を決定します。
LOBデータ用の表領域を指定しない場合は、その表の表領域がLOBデータおよびLOB索引に使用されます。
LOBデータ用の表領域を指定した場合は、指定した表領域がLOBデータとLOB索引の両方に使用されます。
表の作成時に非パーティション表のLOB索引用の表領域を指定すると、表領域指定は無視され、LOB索引はLOBデータと同じ位置に格納されます。パーティション化されたLOBに、LOB索引構文は含まれません。
LOB記憶域セグメントには別の表領域を指定すると、表の表領域での競合を削減できます。
BasicFiles LOBが変更されると、新しいバージョンのBasicFiles LOBページが作成され、前のバージョンのBasicFiles LOB値の読取り一貫性がサポートされます。
PCTVERSION
は、使用中のBasicFiles LOBデータ領域全体のうち、旧バージョンのBasicFiles LOBデータ・ページが占めることのできる割合です。旧バージョンのBasicFiles LOBデータ・ページの占める割合が使用中のBasicFiles LOB領域に対してPCTVERSION
量を超え始めると、すぐにOracle Databaseにより旧バージョンの部分が解放され再利用されます。つまり、PCTVERSION
は、使用中のBasicFiles LOBデータ・ブロックのうち古いBasicFiles LOBデータのバージョニングに使用できる割合と言い換えることができます。
PCTVERSIONのデフォルトは、10(%)で、最小値は0(%)、最大値は100(%)です。
PCTVERSION
に設定する値を決定するには、次のことを考慮します。
BasicFiles LOBの更新頻度
更新されたBasicFiles LOBを読み取る頻度
表11-2「推奨されるPCTVERSION設定」に、適切なPCTVERSION
値を決定するためのガイドラインを示します。
表11-2 推奨されるPCTVERSION設定
BasicFiles LOB更新パターン | BasicFiles LOB読取りパターン | PCTVERSION |
---|---|---|
X%のLOBデータを更新する |
更新されたLOBを読み取る |
X% |
X%のLOBデータを更新する |
LOBを読み取るが更新されたLOBは読み取らない |
0% |
X%のLOBデータを更新する |
更新されたLOBおよび更新されていないLOBの両方を読み取る |
2X% |
LOBを更新しない |
LOBを読み取る |
0% |
アプリケーションで大量のBasicFiles LOB列を読み取ると同時に複数のBasicFiles LOBを更新する必要がある場合は、PCTVERSION
の値を20%などに大きくすることを考慮してください。
PCTVERSION
をデフォルトの2倍の値に設定すると、旧バージョンのデータ・ページに使用できる空きページが増えます。大量の問合せを行う場合、BasicFiles LOB列の読取り一貫性が必要となるため、旧バージョンのBasicFiles LOBページを保持しておく必要があります。この場合、データベースは空きページを積極的には再利用しないため、BasicFiles LOB記憶域は大きくなります。
アプリケーションで永続BasicFiles LOBインスタンスが作成されて1回のみ書き込まれ、その後は主に読取り専用となる場合、更新頻度は低くなります。この場合は、PCTVERSION
に5%以下などの小さい値を使用することを考慮してください。
BasicFiles LOBの更新をほとんど行わず、更新する部分が非常に少ない場合は、旧バージョンのBasicFiles LOBデータ用に必要とする領域も少なくなります。既存のBasicFiles LOBが読取り専用とわかっている場合は、旧バージョンのデータにはページが必要ないため、PCTVERSION
を0%に設定しても問題ありません。
PCTVERSION
パラメータを指定するかわりに、CREATE TABLE
文またはALTER TABLE
文のLOB STORAGE句にRETENTION
パラメータを指定できます。その場合は、表領域の割合を使用するかわりに、LOB列にLOBデータの旧バージョンを格納する期間を設定します。次に例を示します。
CREATE TABLE ContainsLOB_tab (n NUMBER, c CLOB) lob (c) STORE AS BASICFILE segname (TABLESPACE lobtbs1 CHUNK 4096 RETENTION NOCACHE LOGGING STORAGE (MAXEXTENTS 5) );
RETENTION
パラメータは、フラッシュバック・バージョン問合せなど、データベースのUNDO
機能と併用するように設計されています。LOB列にRETENTION
プロパティが設定されている場合、LOBデータの旧バージョンはUNDO_RETENTION
パラメータで指定した期間のみ保持されます。
RETENTION
パラメータには、次の注意事項があります。
他のデータ型と同様、LOB列にはUNDO
SQLを使用できません。LOBデータにUndo SQLを使用するには、LOB列にRETENTION
プロパティを設定する必要があります。
RETENTION
パラメータの値は明示的に設定できません。LOBバージョンの保存期間はUNDO_RETENTION
パラメータにより決定されます。
RETENTION
パラメータの使用がサポートされるのは、自動UNDO管理モードの場合のみです。LOB列にRETENTION
を設定する前に、自動UNDO管理に使用する表を構成する必要があります。LOB RETENTION
をBasicFiles LOBで有効にするには、ASSMが必要です。BasicFiles LOBがMSSM表領域にある場合、SQLのRETENTION
パラメータ(STORE
AS
文)は暗黙的に無視されます。
LOB STORAGE句で指定できるのは、RETENTION
またはPCTVERSION
のどちらか一方のみです。
関連項目:
|
SecureFilesにRETENTION
パラメータを指定すると、データベースで、データベースのUNDO
モードなどの要素を考慮に入れて、SecureFiles記憶域の読取り一貫性のあるデータが動的に管理されます。
データベースがFLASHBACK
モードの場合、LOB UNDO
の保存サイズのバイト数を制限するには、MAX
を指定します。MAX
を指定する場合は、storage_clause
のMAXSIZE
句も指定する必要があります。
読取り一貫性の目的に十分なUNDO
を維持する場合は、AUTO
を指定します。これはデフォルトです。
読取り一貫性またはフラッシュバックのいずれの目的でもUNDO
が必要とされない場合は、NONE
を指定します。
SecureFilesのデフォルトのRETENTION
は、AUTO
です。
LOBを含む表を作成する場合は、表11-3「CACHE、NOCACHEおよびCACHE READSの使用時期」のガイドラインに従ってキャッシュ・オプションを使用します。
表11-3 CACHE、NOCACHEおよびCACHE READSの使用時期
キャッシュ・モード | 読取り | 書込み |
---|---|---|
|
頻繁 |
1回または時々 |
|
頻繁 |
頻繁 |
|
1回または時々 |
なし |
CACHE: Oracleは、アクセスを高速化するために、バッファ・キャッシュにLOBページを置きます。
NOCACHE: STORE AS
句のパラメータとしてNOCACHE
が指定された場合は、LOB値はバッファ・キャッシュには入りません。
CACHE READS: LOB値は、読取り中のみバッファ・キャッシュに入れられ、書込み中には入れられません。
NOCACHE
は、SecureFilesとBasicFiles LOBの両方に関してデフォルトです。
注意: CACHE オプションを使用すると、LOB列からのデータの読取りおよび書込み時のパフォーマンスが向上します。ただし、LOBでない他のページが通常より早くバッファ・キャッシュからページ・アウトされる可能性があります。 |
[NO
] LOGGING
は、LOBの使用に関しては他の表操作と同様に適用されます。通常、[NO
]LOGGING
句が省略されている場合は、NO
LOGGING
またはLOGGING
のどちらも指定されていないことを意味し、その場合は表または表のパーティションのロギング属性は、置かれている表領域のロギング属性にデフォルトで設定されます。
LOBには、CACHE
の指定によっては他にも指定方法があります。
CACHEが指定される場合、[NO
]LOGGING
句は省略されます。LOGGING
が自動的に実装されます(CACHE
NOLOGGING
がないためです)。
CACHEが指定されない場合、[NO
]LOGGING
句は省略されます。プロセスのデフォルトは、表およびパーティション化された表と同じ方法になります。[NO
]LOGGING
値はLOBセグメントの置かれている表領域から取得されます。
ただし、次の事項を考慮する必要があります。
LOGGING
またはNOLOGGING
が設定されているかどうかにかかわらず、古いLOBデータはバージョンごとに格納されるため、LOBではLOBデータ・ページのロールバック情報(UNDO)は生成されません。LOBについて作成されるロールバック情報は、LOBの索引ページの変更専用であるため、サイズが小さくなります。
NOLOGGING
またはLOGGING
は、SecureFilesの使用に関してはLOGGING
/NOLOGGING
による他の表操作と同様に適用されます。通常、logging_clause
が省略されている場合、SecureFilesではロギング属性を、置かれている表領域から継承します。ここで、NOLOGGING
がデフォルト値の場合、SecureFilesはデフォルトでFILESYSTEM_LIKE_LOGGING
になります。
注意: CACHE オプションを使用すると、LOB列からのデータの読取りおよび書込み時のパフォーマンスが向上します。ただし、LOBでない他のページが通常より早くバッファ・キャッシュからページ・アウトされる可能性があります。 |
SecureFilesには、CACHE
の指定によっては他にも指定方法があります。
CACHE
が指定されると、LOGGING
句が省略され、LOGGING
が使用されます。
CACHE
が指定されないと、logging_clauseが省略されます。プロセスのデフォルトは、表およびパーティション化された表と同じ方法になります。LOGGING
値はLOB値の置かれている表領域から取得されます。表領域がNOLOGGING
の場合、SecureFilesはデフォルトでFILESYSTEM_LIKE_LOGGING
に設定されます。
ただし、次の事項を考慮する必要があります。
チャンクとは1つまたは複数のOracleブロックです。LOBを含む表を作成する場合に、BasicFiles LOB用のチャンク・サイズを指定できます。これは、LOB値に対してアクセスまたは変更を行うときに、Oracle Databaseが使用するデータ・サイズに対応します。チャンクの一部はシステム関連の情報を格納し、残りはLOB値を格納します。使用するAPIには、LOBチャンク内で使用され、LOB値を格納している領域の量を戻すファンクションがあります。PL/SQLでは、DBMS_LOB.GETCHUNKSIZE
を使用します。OCIでは、OCILobGetChunkSize()
を使用します。
注意: 表ブロック・サイズがデータベース・ブロック・サイズと同じ場合、CHUNK は、データベース・ブロック・サイズの倍数でもあります。CHUNK のデフォルト・サイズは、1つの表領域ブロックのサイズと同じで、最大値は32KBです。 |
LOB列の作成時にCHUNK
の値を選択した後は、値を変更できません。したがって、記憶域およびパフォーマンスの要件に最適な値を選択することが重要です。SecureFilesでは、CHUNK
は、アドバイザ・サイズで、後方互換性のために使用します。
CHUNK
の値は、インラインに格納されるLOBには関係ありません。ENABLE
STORAGE
IN
ROW
が設定され、LOBロケータおよびLOBデータのサイズが約4000バイトを下回る場合には、LOBはインラインに格納されます。ただし、LOBデータがアウトラインに格納される場合には、必ずCHUNK
パラメータの倍数の領域が使用されます。これは、データが小さいのにCHUNK
が大きな数字に設定されている場合は、領域をかなり無駄に使用することになります。表11-4「データ・サイズとCHUNKサイズ」で、この点について示します。
ENABLE
| DISABLE
STORAGE
IN
ROW
句を使用して、LOBをインライン(行内)またはアウトラインに格納するかどうかを指定します。
注意: これは一度指定すると、変更できません。ENABLE STORAGE IN ROW からDISABLE STORAGE IN ROW にも、またその逆にも変更できません。 |
デフォルトは、ENABLE
STORAGE
IN
ROW
です。
インラインに格納されるLOBデータの最大サイズは、最大VARCHAR2
サイズ(4,000バイト)です。この最大値には、LOB値および制御情報が含まれます。LOBをインラインに格納するように指定しても、LOB値および制御情報が約4000バイトを超えると、LOB値は自動的にアウトラインに移動されます。
このため、次のようなガイドラインが必要になります。
次の理由から、通常、デフォルトのENABLE STORAGE IN ROWが最適です。
小さいLOB: LOBサイズが小さい(約4000バイト未満)場合、余分なディスクI/Oなしで行の読取り時にLOB全体を読み取ることができます。
大きいLOB: LOBが大きい(約4000バイトを超える)場合、行の外部にLOBデータを移動した後でも、ENABLE STORAGE IN ROWが設定されていれば、制御情報は行に格納されたままです。この制御情報によって、アウトラインLOBデータを高速で読み取ることができます。
ただし、DISABLE STORAGE IN ROWの方が適している場合もあります。LOBをインラインに格納すると、行のサイズが大きくなるためです。行サイズが大きいと、ユーザーが全表スキャン、複数行アクセス(レンジ・スキャン)、LOB列以外の列への多数のUPDATE/SELECTなどの実表の処理を頻繁に行う場合、パフォーマンスが低下します。
この項では、LOB列の索引付けに使用できる各種の方法について説明します。
ドメイン専用の索引を作成すると、問合せのパフォーマンスを改善できる場合があります。データベースに用意されている拡張性のあるインタフェースによって、そのようなドメイン固有の索引を実装するための枠組みである、ドメイン索引作成機能を利用できます。
関連項目: ドメイン固有の索引作成の詳細は、『Oracle Databaseデータ・カートリッジ開発者ガイド』を参照してください。 |
LOB列の内容の性質によっては、Oracle Textオプションの1つを使用して索引を作成することもできます。たとえば、テキスト・ドキュメントがCLOB
列に格納されている場合、テキスト索引を作成して、CLOB
列に対するテキストベースの問合せのパフォーマンスを向上させることができます。
関連項目: Oracle Textオプションの詳細は、『Oracle Textリファレンス』を参照してください。 |
ファンクション索引とは、式に対して作成される索引です。これによって、列のみの場合より索引機能が拡張されます。ファンクション索引により、データ・アクセスの方法が多様化します。
ファンクション索引は、ネストした表やLOB列には作成できません。ただし、VARRAYには作成できます。
DML操作がLOB列で実行されると、LOB列の拡張索引およびドメイン索引と同様に、ファンクション索引も自動的に更新されます。拡張索引が更新されると、ファンクション索引も更新されます。
関連項目: ファンクション索引の使用方法の詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。 |
データベースには、必要に応じて新規索引タイプを定義できる拡張索引作成機能が用意されています。これは、データ・カートリッジおよびデータベースがOLAP (On-line-Analytical Processing)などのためにテキストや空間などのデータ型の索引を構築および保持するという協調索引の概念に基づいています。
カートリッジは、索引構造の定義、ロード操作および更新操作中の索引内容のメンテナンス、問合せ処理中の索引の検索を行います。索引構造は、ヒープ構成表または索引構成表としてOracleに格納するか、OSファイルとして外部に格納できます。
この構造をサポートするために、データベースには索引タイプが用意されています。索引タイプの目的は、データ・カートリッジを使用して、テキスト、空間、イメージ、OLAPなどの複合ドメインを効率的に検索および取出しできるようにすることです。索引タイプは、Oracleサーバーに組み込まれているソート済の索引またはビットマップ索引に似ています。相違点は、組込み索引はOracleカーネルによって実装されますが、索引タイプはデータ・カートリッジの開発者によって実装されることです。データ・カートリッジの開発者が新しい索引タイプを実装すると、データ・カートリッジのエンド・ユーザーは、組込み索引タイプと同様にその索引タイプを使用できます。
データベース・システムがドメイン索引の物理的な格納を処理する場合、データ・カートリッジは次のことを行います。
索引のフォーマットおよび内容の定義。これによって、カートリッジが複合データ・オジェクトを保存できる索引構造を定義できます。
ドメイン索引の作成、削除および更新。カートリッジは、索引構造の構築およびメンテナンスを処理します。これは、単純なSQLデータ型用に提供されている医療業界向け索引付け機能から大幅に発展した機能です。また、索引は一定の数の要素で構成される集合として作成されるため、インプレース更新が直接サポートされます。
索引の内容へのアクセスおよび解析。この機能を持つデータ・カートリッジは、問合せの処理に不可欠なコンポーネントです。データベースへの問合せの内容に関連する句は、データ・カートリッジが処理します。
データベースでは、拡張索引作成機能がサポートされるため、LOBなどの複合データ型にアクセスするパフォーマンスの高いソリューションを非常に簡単に開発できます。
ユーザー定義ファンクションおよび索引の作成者は、拡張可能オプティマイザの機能を使用して、統計集計ファンクション、選択ファンクションおよびコスト・ファンクションを作成できます。オプティマイザは、この情報を使用して問合せ計画を選択します。コストベース・オプティマイザは、ユーザーが提供する情報を使用するように拡張されています。
拡張索引作成機能を使用すると、新しい演算子、索引タイプおよびドメイン索引を定義できます。これらのユーザー定義演算子およびドメイン索引については、拡張可能オプティマイザの機能を使用して、オプティマイザが実行計画を選択するために使用する3つの主な構成要素(統計、選択性、コスト)を制御できます。
関連項目: 『Oracle Databaseデータ・カートリッジ開発者ガイド』 |
LOB列を含む表をパーティション化できます。この結果、次のように、パーティション化のすべてのメリットをLOBでも利用できます。
LOBセグメントをいくつかの表領域に分散して、I/O負荷を均衡化させ、バックアップおよびリカバリの管理をより簡単にできます。
パーティション表内のLOBがメンテナンスしやすくなります。
LOBを論理グループにパーティション化し、グループとしてアクセスされるLOBの操作を高速化できます。
この項では、パーティション表内のLOBの操作方法をいくつか説明します。
LOBは、レンジ・パーティション表、リスト・パーティション表およびハッシュ・パーティション表でサポートされます。コンポジット・ヒープ構成表にも、LOBを含めることができます。
LOB列を含む表をパーティション化するには、次の方法があります。
CREATE TABLE
文のPARTITION BY ...
句を使用して表を作成します。
ALTER TABLE ...ADD PARTITION
句を使用して既存の表にパーティションを追加します。
ALTER TABLE ...EXCHANGE PARTITION
句を使用して、パーティション化されたLOB列を含む表とパーティションを交換します。EXCHANGE PARTITION
を使用できるのは、両方の表でLOBをアウトラインに格納する場合など、両方の表の記憶域属性が同一の場合のみであることに注意してください。
(CREATE TABLE
文で)表の作成と同時にLOBパーティションを作成することをお薦めします。表の作成時にLOB列にパーティションを作成すると、その列にインラインLOBまたはアウトラインLOBを保持できます。
表の作成後は、アウトラインに格納されたLOB列にのみ新規LOBパーティションを作成できます。また、パーティション・メンテナンス操作SPLIT PARTITION
およびMERGE PARTITIONS
は、LOBをアウトラインに格納するLOB列にのみ機能します。
表の作成後は記憶域属性を変更できないことに注意してください。LOB記憶域属性の詳細は、「LOB記憶域パラメータ」を参照してください。
問合せのパフォーマンスを改善するために、パーティション化されたLOB列に対して索引を作成できます。次に例を示します。
CREATE INDEX index_name ON table_name (LOB_column_1, LOB_column_2, ...) LOCAL;
LOB列でサポートされるのは、ドメイン索引とファンクション索引のみであることに注意してください。一意索引など、他のタイプの索引はLOBでサポートされません。
LOBパーティションを別の表領域に移動できます。この移動が役立つのは、表領域が小さすぎてパーティションを保持できなくなった場合です。移動には、ALTER TABLE ...MOVE PARTITION
句を使用します。次に例を示します。
ALTER TABLE current_table MOVE PARTITION partition_name TABLESPACE destination_table_space LOB (column_name) STORE AS (TABLESPACE current_tablespace);
ALTER TABLE ...SPLIT PARTITION
句を使用すると、LOBを含むパーティションを同じサイズの2つのパーティションに分割できます。これにより、一方または両方の新規パーティションを新規の表領域に配置できます。次に例を示します。
ALTER TABLE table_name SPLIT PARTITION partition_name AT (partition_range_upper_bound) INTO (PARTITION partition_name, PARTITION new_partition_name TABLESPACE new_tablespace_name LOB (column_name) STORE AS (TABLESPACE tablespace_name) ... ;
ALTER TABLE ...MERGE PARTITIONS
句を使用すると、LOB列を含むパーティションをマージできます。この方法は、使用されていないパーティション領域を再生する場合に役立ちます。次に例を示します。
ALTER TABLE table_name MERGE PARTITIONS partition_1, partition_2 INTO PARTITION new_partition TABLESPACE new_tablespace_name LOB (column_name) store as (TABLESPACE tablespace_name) ... ;
現在、索引構成表(IOT)は内部LOB列および外部LOB列をサポートしています。ほとんどの場合、IOT内のLOBに対するSQLのDDL、DMLおよびピース単位操作は、従来の表での操作と同様の結果をもたらします。作成時のLOBのデフォルトのセマンティクスのみが異なります。主な違いは次のとおりです。
表領域のマッピング: デフォルトで、または別に指定されていないかぎり、LOBデータおよび索引セグメントは、索引構成表の主キー索引セグメントが作成された表領域の中に作成されます。
インライン記憶域とアウトライン記憶域: オーバーフロー・セグメントなしで作成された索引構成表内のすべてのLOBは、デフォルトでアウトラインに格納されます。つまり、索引構成表がオーバーフロー・セグメントなしで作成された場合、この表内のLOBのデフォルト記憶域属性はDISABLE
STORAGE
IN
ROW
になります。このようなLOBに対して強制的にENABLE
STORAGE
IN
ROW
句を指定しようとすると、SQLはエラーを表示します。
一方、オーバーフロー・セグメントが指定されている場合、索引構成表内のLOBは従来の表と同様のセマンティクスで動作します(「永続LOBに対する表領域および記憶特性の定義」を参照)。
LOB列を含む索引構成表(IOT)の例
次の例について考えてみます。
CREATE TABLE iotlob_tab (c1 INTEGER PRIMARY KEY, c2 BLOB, c3 CLOB, c4 VARCHAR2(20)) ORGANIZATION INDEX TABLESPACE iot_ts PCTFREE 10 PCTUSED 10 INITRANS 1 MAXTRANS 1 STORAGE (INITIAL 4K) PCTTHRESHOLD 50 INCLUDING c2 OVERFLOW TABLESPACE ioto_ts PCTFREE 10 PCTUSED 10 INITRANS 1 MAXTRANS 1 STORAGE (INITIAL 8K) LOB (c2) STORE AS lobseg (TABLESPACE lob_ts DISABLE STORAGE IN ROW CHUNK 16384 PCTVERSION 10 CACHE STORAGE (INITIAL 2M) INDEX lobidx_c1 (TABLESPACE lobidx_ts STORAGE (INITIAL 4K)));
これらの文を実行すると、次の要素を持つ索引構成表iotlob_tab
が作成されます。
表領域iot_ts
内の主キー索引セグメント
表領域ioto_ts
内のオーバーフロー・データ・セグメント
オーバーフロー・データ・セグメント内に明示的に格納される、C3
から始まる列
表領域lob_ts
内のBLOB
(列C2
)データ・セグメント
表領域lobidx_ts
内のBLOB
(列C2
)索引セグメント
表領域iot_ts
内のCLOB
(列C3
)データ・セグメント
表領域iot_ts
内のCLOB
(列C3
)索引セグメント
IOTにオーバーフロー・セグメントがあるためにインラインに格納されるCLOB
(列C3
)
明示的にアウトラインに強制格納されるBLOB
(列C2
)
注意: オーバーフローが指定されていない場合、C2とC3の両方がデフォルトでアウトラインに格納されます。 |
BFILE
や可変幅文字LOBなどの他のLOB機能も索引構成表でサポートされ、その使用方法も従来の表の場合と同じです。
LOB列はレンジ・パーティション化、リスト・パーティション化およびハッシュ・パーティション化された索引構成表でサポートされますが、次の制限があります。
コンポジットでパーティション化された索引構成表はサポートされません。
リレーショナルおよびオブジェクト・パーティション化された(レンジ、ハッシュまたはリスト・パーティション化された)索引構成表には、次のようにLOBを格納できます。ただし、MOVE
、SPLIT
およびMERGE
などのパーティション・メンテナンス操作はサポートされません。
LOBデータ型として格納されているVARRAYデータ型
LOB属性を持つ抽象データ型
LOB型を持つネストした表
ネストした表内のLOBを更新するには、LOBを含む行を明示的にロックする必要があります。そのためには、LOB値を更新する前に、副問合せでFOR UPDATE句を指定します。
親表の行をロックしても、LOB列を含むネストした表の行はロックされないことに注意してください。
注意: LOB列を含むネストした表は、LOBのコレクション作成のためにサポートされている唯一のデータ構造です。LOBデータ型のVARRAYは作成できません。 |