1. SecureFilesおよびラージ・オブジェクト開発者ガイド
  2. LOBを使用したアプリケーション設計
  3. アプリケーションでのLOB記憶域

13 アプリケーションでのLOB記憶域

LOB列を含む表が含まれるアプリケーションは、SECUREFILE LOBとBASICFILE LOBの両方を使用できます。機能が、1種類のLOBにのみ適用される場合は、そのように示されます。

内容は次のとおりです。

13.1 LOBを含む表

LOBを含む表を作成する場合、次のガイドラインを使用します。

内容は次のとおりです。

13.1.1 NULLまたは空として初期化された永続LOB

永続LOB(表内のLOB列、またはユーザーが定義したオブジェクト型のLOB属性)を、NULLまたは空に設定できます。

  • 永続LOBをNULLに設定: NULLに設定されたLOBにロケータはありません。NULL値はロケータではなく、表内の行に格納されます。これは、他のすべてのデータ型と同じプロセスです。

  • 永続LOBを空に設定: 対照的に、表に格納された空のLOBは、ロケータを含む長さ0のLOBです。このため、空のLOB列または属性からSELECTする場合、OCIやPL/SQL (DBMS_LOB)などのサポートされているプログラム環境を使用してLOBにデータを移入するために使用できるロケータを取り戻します。

関連項目:

サポートされている環境の詳細は、「LOB APIの概要」を参照してください

13.1.1.1 永続LOBをNULLに設定

行の挿入時に永続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である場合、行内にロケータはありません。

13.1.1.2 永続LOBを空に設定

永続LOBをNULLではなくEMPTYに初期化できます。これにより、LOBにデータを移入せずにLOBインスタンスのロケータを取得できます。

  • 次のように、INSERT文でSQLのEMPTY_BLOB()ファンクションまたはEMPTY_CLOB()ファンクションを使用して、永続LOBをEMPTYに設定します。 

    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;

13.1.2 LOBの初期化

次の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に設定されます。

関連項目:

print_media表については、「LOBの例の表: PMスキーマのprint_media表」を参照してください。

13.1.3 永続LOB列およびLOB属性を値に初期化

LOB列またはLOB属性は、10.2より前のリリースでの上限値4GBよりも大きいデータを含む値に初期化できます。

関連項目:

永続LOB用のデータ・インタフェース

13.1.4 BFILEをNULLまたはファイル名に初期化

BFILEはNULLまたはファイル名に初期化できます。この操作にはBFILENAME()ファンクションを使用できます。

関連項目:

「BFILENAMEと初期化」。

13.1.5 LOBセグメントの最初のエクステントの制限

任意のセグメントの最初のエクステントには、少なくとも2ブロックが必要です(FREELIST GROUPSが0であった場合)。つまり、セグメントの初期エクステント・サイズは少なくとも2ブロックである必要があります。LOBセグメントはこれとは異なります。これは、LOBがBasicFiles LOBである場合は最初のエクステント内に少なくとも3ブロックが必要であり、LOBがSecureFiles LOBである場合は16ブロックが必要であるためです。

初期サイズが2ブロックである永続ディクショナリ管理の表領域でLOBセグメントを作成しようとしても、この作業は有効です。これは、永続ディクショナリ管理の表領域内のセグメントで表領域のデフォルトの記憶域設定を上書きできるためです。

ただし、均一なローカル管理の一時表領域やディクショナリ管理の一時表領域、またはローカル管理の一時表領域内のエクステント・サイズが2ブロックである場合は、これらの表領域内にLOBセグメントを作成できません。これは、これらのタイプの表領域ではエクステント・サイズが固定され、表領域のデフォルト記憶域設定が無視されることはないためです。

13.2 LOB列のデータ型

データ型を選択する場合、次の3項目を考慮します。

13.2.1 LOB型とLONG型およびLONG RAW型との比較

表13-1に、LOB型とLONG型およびLONG RAW型との類似点と相違点を示します。

表13-1 LOBとLONG RAW

LOBデータ型 LONGおよびLONG RAWデータ型

単一の行に複数のLOBを格納できます。

1行当たり1つのLONGまたはLONG RAWのみを格納します。

LOBは、ユーザー定義のデータ型の属性にできます。

LONGとLONG RAWのどちらも、ユーザー定義データ型の属性にはできません。

LOBロケータのみ表の列に格納されます。BLOBデータおよびCLOBデータは、別々の表領域に格納でき、BFILEデータは外部ファイルとして格納されます。

インラインLOBについては、表列の中に約4000バイトまでのデータが格納されます。

LONGまたはLONG RAWの場合、値全体が表の列に格納されます。

LOB列にアクセスすると、ロケータまたはデータのフェッチが選択できます。

LONGまたはLONG RAWにアクセスすると、値全体が戻ります。

LOBのサイズは、ブロック・サイズに応じて128TB以下またはそれ以上です。

LONGまたはLONG RAWインスタンスの最大サイズは2GBです。

ランダムにピース単位でデータを操作する場合は、LOBを使用する方が柔軟性があります。LOBはランダム・オフセットでアクセスできます。

LONGまたはLONG RAWデータは、ランダムな、ピース単位でのデータ操作に対して柔軟性がありません。LONGの場合、目的の位置へは先頭からアクセスする必要があります。

Oracle Golden Gateを使用してLOBをレプリケートできます。

レプリケーションはLONGまたはLONG RAWで実行できません。

13.2.2 LOBへの可変幅文字データの格納

CLOBデータ型およびNCLOBデータ型の可変幅文字データは、UCS2 Unicode文字セット形式と互換性のある内部形式で格納されます。このため、可変幅形式の文字データの記憶が消失することはありません。また、LOBを使用して可変幅文字データを格納する場合は、次のことに注意してください。

  • 可変幅のCHARまたはNCHARデータベース文字セットを使用する場合にも、CLOB列とNCLOB列を含む表を作成できます。

  • 可変幅のCHARデータベース文字セットを使用するかどうかに関係なく、CLOB属性を持つデータ型を含む表を作成できます。

13.2.3 LOBを使用した文字セットの暗黙的な変換

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間で変更することはできません。

13.3 LOB記憶域パラメータ

LOB記憶域を含む表の設計時には、特定のLOB記憶域の特性について考慮する必要があります。次は、SECUREFILEパラメータに関する説明です。

関連項目:

内容は次のとおりです。

13.3.1 インラインLOB記憶域とアウトラインLOB記憶域

LOB列には、実際のLOB値の位置を参照するロケータが格納されます。

表の作成時に指定する列のプロパティとLOBのサイズに応じて、実際のLOB値は表の行(インライン)または表の行の外(アウトライン)に格納されます。

LOB値がアウトラインに格納されるのは、次のいずれかの条件に該当する場合です。

  • 表の作成時に、LOBのSTORAGE句にDISABLE STORAGE IN ROWを明示的に指定した場合。

  • 列のLOB記憶域プロパティにかかわらず、LOBのサイズが約4000バイト(4000バイトからシステム制御情報を引いたもの)を超える場合。

  • アウトラインに格納されているLOBを更新した場合は、更新後のLOBが約4000バイトを下回っていても、そのままアウトラインに格納されます。

LOB値がインラインに格納されるのは、次のいずれかの条件に該当する場合です。

  • 指定の行に格納されるLOBのサイズが約4000バイト以下で、表の作成時にLOBのSTORAGE句にENABLE STORAGE IN ROWを明示的に指定する場合、またはこのパラメータを指定しない(デフォルト)場合。

  • 列のLOB記憶域プロパティにかかわらず、LOB値がNULLの場合。

デフォルトのLOB記憶域プロパティ(インライン記憶域)を使用する方がデータベースのパフォーマンスが向上し、小さいLOB値のためのアウトライン記憶域の作成と管理に伴うオーバーヘッドを回避できます。データベースに格納されるLOB値のサイズが小さいときが多い場合は、インライン記憶域を使用することをお薦めします。

ノート:

  • LOBロケータは常に行に格納されます。

  • LOB記憶域プロパティやLOB値(NULL、空またはそれ以外)に関係なく、LOBインスタンスには常にLOBロケータがあります。

  • LOBがDISABLE STORAGE IN ROWプロパティを指定して作成され、BasicFiles LOBにデータが保持される場合は、LOBのサイズがCHUNKのサイズより小さくても、アウトライン記憶域の1つ以上のCHUNKが使用されます。

  • LOB列がEMPTY_CLOB()またはEMPTY_BLOB()で初期化された場合、LOB値はNULLでさえ存在しません。行にはLOBロケータのみが保持されます。追加のLOB記憶域は使用されません。

  • LOB記憶域プロパティは、BFILE列には影響しません。BFILEデータは、常にデータベース外のオペレーティング・システム・ファイルに格納されます。

13.3.2 永続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を変更できます。

13.3.2.1 LOBデータ・セグメント名の割当て

前述の例に示すように、LOBデータ・セグメントに名前を指定すると、作業環境がより明確になります。USER_LOBS、ALL_LOBS、DBA_LOBSのLOBデータ・ディクショナリ・ビューを問い合せた際、システムが生成した名前ではなく、選択したLOBデータ・セグメント名が表示されます。

関連項目:

初期化パラメータの詳細は、Oracle Databaseリファレンスを参照

13.3.3 LOB列またはLOB属性の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句

  • 『Oracle Database SQL言語リファレンス』 のRETENTIONパラメータ

13.3.4 TABLESPACEおよびLOB索引

LOB索引は、LOB記憶域に密接に対応付けられている内部構造体です。したがって、ユーザーがLOB索引を削除または再構築することはできません。

ノート:

LOB索引は変更できません。

システムは、LOB STORAGE句内のユーザー指定に従って、LOBデータおよびLOB索引に使用する表領域を決定します。

  • LOBデータ用の表領域を指定しない場合は、その表の表領域がLOBデータおよびLOB索引に使用されます。

  • LOBデータ用の表領域を指定した場合は、指定した表領域がLOBデータとLOB索引の両方に使用されます。

13.3.4.1 非パーティション表のLOB索引に対する表領域

表の作成時に非パーティション表のLOB索引用の表領域を指定すると、表領域指定は無視され、LOB索引はLOBデータと同じ位置に格納されます。パーティション化されたLOBに、LOB索引構文は含まれません。

LOB記憶域セグメントには別の表領域を指定すると、表の表領域での競合を削減できます。

13.3.5 PCTVERSION

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を読み取る頻度

表13-2に、更新率としてXが与えられたときに適切なPCTVERSION値を決定するためのガイドラインを示します。

表13-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%に設定しても問題ありません。

13.3.6 BasicFiles LOB用のRETENTIONパラメータ

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のどちらか一方のみです。

    関連項目:

    • データベースのフラッシュバック機能の詳細は、『Oracle Database開発ガイド』を参照してください。

    • LOB STORAGE句の構文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

13.3.7 SecureFiles LOB用のRETENTIONパラメータ

SecureFilesにRETENTIONパラメータを指定すると、データベースで、データベースのUNDOモードなどの要素を考慮に入れて、SecureFiles記憶域の読取り一貫性のあるデータが動的に管理されます。

  • データベースがFLASHBACKモードの場合、LOB UNDOの保存サイズのバイト数を制限するには、MAXを指定します。MAXを指定する場合は、storage_clauseでMAXSIZE句も指定する必要があります。

  • 読取り一貫性の目的に十分なUNDOを維持する場合は、AUTOを指定します。これはデフォルトです。

  • 読取り一貫性またはフラッシュバックのいずれの目的でもUNDOが必要とされない場合は、NONEを指定します。

SecureFilesのデフォルトのRETENTIONは、AUTOです。

13.3.8 CACHE/NOCACHE/CACHE READS

LOBを含む表を作成する場合は、表13-3のガイドラインに従ってキャッシュ・オプションを使用します。

表13-3 CACHE、NOCACHEおよびCACHE READSの使用時期

キャッシュ・モード 読取り 書込み

CACHE READS

頻繁

1回または時々

CACHE

頻繁

頻繁

NOCACHE (デフォルト)

1回または時々

行わない
13.3.8.1 CACHE/NOCACHE/CACHE READS: LOB値とバッファ・キャッシュ

  • CACHE: アクセスの高速化を目的としてバッファ・キャッシュにLOBページが配置されます。

  • NOCACHE: STORE AS句のパラメータとしてNOCACHEが指定された場合は、LOB値はバッファ・キャッシュには入りません。

  • CACHE READS: LOB値は、読取り中のみバッファ・キャッシュに入れられ、書込み中には入れられません。

NOCACHEは、SecureFilesとBasicFiles LOBの両方に関してデフォルトです。

ノート:

CACHEオプションを使用すると、LOB列からのデータの読取りおよび書込み時のパフォーマンスが向上します。ただし、LOBでない他のページが通常より早くバッファ・キャッシュからページ・アウトされる可能性があります。

13.3.9 BasicFiles LOB用のLOGGING/NOLOGGINGパラメータ

[NO]LOGGINGパラメータは、他の表パラメータの場合と同じように、LOBの使用に適用されます。通常、[NO]LOGGING句が省略されている場合は、NOLOGGINGまたはLOGGINGのどちらも指定されていないことを意味し、その場合は表または表のパーティションのロギング属性は、置かれている表領域のロギング属性にデフォルトで設定されます。

LOBには、CACHEの指定によっては他にも指定方法があります。

  • CACHEが指定されており、[NO]LOGGING句が省略されている場合。LOGGINGが自動的に実装されます(CACHE NOLOGGINGがないためです)。

  • CACHEが指定されておらず、[NO]LOGGING句が省略されている場合。プロセスのデフォルトは、表およびパーティション化された表と同じ方法になります。[NO]LOGGING値はLOBセグメントの置かれている表領域から取得されます。

ただし、次の事項を考慮する必要があります。

13.3.9.1 LOBは、常にLOB索引ページに対してUNDOを生成する

LOGGINGまたはNOLOGGINGが設定されているかどうかにかかわらず、古いLOBデータはバージョンごとに格納されるため、LOBではLOBデータ・ページのロールバック情報(UNDO)は生成されません。

LOBについて作成されるロールバック情報は、LOBの索引ページの変更専用であるため、サイズが小さくなります。

13.3.9.2 LOGGINGが設定されている場合、LOBデータ・ページの完全なREDOが生成される

NOLOGGINGは、メディア・リカバリを必要としない場合に使用されます。

したがって、ディスク、テープ、ストレージなどのメディアに障害が発生した場合、変更のログは作成されていないため、ログから変更をリカバリできません。

13.3.9.2.1 NOLOGGINGはバルク・ロードまたは挿入に効果的。

たとえば、LOBにデータをロードする際、REDOを必要とせず、ロードが失敗してもロードを簡単に再開できる場合は、LOBデータ・セグメントの記憶特性をNOCACHE NOLOGGINGに設定します。これによって、データの初期ロードのパフォーマンスが向上します。

データのロードが完了すると、ALTER TABLEを使用して、永続LOB操作に対するLOBデータ・セグメントのLOB記憶特性を、CACHEやNOCACHE LOGGINGに変更できます。

ノート:

CACHEを設定すると、LOGGINGも行われます。

13.3.10 SecureFiles LOB用のLOGGING/FILESYSTEM_LIKE_LOGGING

NOLOGGINGおよびLOGGINGパラメータは、他の表パラメータの場合と同じように、LOBの使用に適用されます。

通常、logging_clauseが省略されている場合、SecureFilesではロギング属性を、置かれている表領域から継承します。ここで、NOLOGGINGがデフォルト値の場合、SecureFilesはデフォルトでFILESYSTEM_LIKE_LOGGINGになります。

ノート:

CACHEオプションを使用すると、LOB列からのデータの読取りおよび書込み時のパフォーマンスが向上します。ただし、LOBでない他のページが通常より早くバッファ・キャッシュからページ・アウトされる可能性があります。

13.3.10.1 CACHEによって決まるLOGGING

SecureFilesには、CACHEの指定によっては他にも指定方法があります。

  • CACHEが指定され、LOGGING句が省略されている場合、LOGGINGが使用されます。

  • CACHEが指定されておらず、LOGGING句が省略されている場合。プロセスのデフォルトは、表およびパーティション化された表と同じ方法になります。LOGGING値はLOB値の置かれている表領域から取得されます。表領域がNOLOGGINGの場合、SecureFilesはデフォルトでFILESYSTEM_LIKE_LOGGINGに設定されます。

次のことに注意してください。

13.3.10.2 SecureFilesおよび効率的なREDOおよびUNDO生成の方法

これは、Oracle Databaseが、ヒープ・ブロックと同様に、ブロックへの変更のためにREDOおよびUNDOを生成する方がより効率的か、または、BasicFiles LOBと同様に、バージョンおよび新規ブロックの完全なREDOを生成するかどうかを判断することを意味します。

13.3.10.3 バルク・ロードまたは挿入に効果的なFILESYSTEM_LIKE_LOGGING

たとえば、LOBにデータをロードする際、REDOを必要とせず、ロードが失敗してもロードを簡単に再開できる場合は、LOBデータ・セグメントの記憶特性をFILESYSTEM_LIKE_LOGGINGに設定します。これによって、データの初期ロードのパフォーマンスが向上します。

データのロードが完了したら、必要に応じて、ALTER TABLEを使用して、通常のLOB操作用のLOBデータ・セグメントのLOB記憶域の特性を変更します。たとえば、CACHEまたはNOCACHE LOGGINGに変更します。

13.3.11 CHUNK

チャンクとは1つまたは複数のOracleブロックです。

LOBを含む表を作成する場合に、BasicFiles LOB用のチャンク・サイズを指定できます。これは、LOB値に対してアクセスまたは変更を行うときに、Oracle Databaseが使用するデータ・サイズに対応します。チャンクの一部はシステム関連の情報を格納し、残りはLOB値を格納します。使用するAPIには、LOBチャンク内で使用され、LOB値を格納している領域の量を戻すファンクションがあります。PL/SQLでは、DBMS_LOB.GETCHUNKSIZEを使用します。OCIでは、OCILobGetChunkSize()を使用します。

ノート:

表ブロック・サイズがデータベース・ブロック・サイズと同じ場合、CHUNKは、データベース・ブロック・サイズの倍数でもあります。CHUNKのデフォルト・サイズは、1つの表領域ブロックのサイズと同じで、最大値は32KBです。

関連項目:

最大LOBサイズの詳細は、「サイズがTBのLOBのサポート」を参照してください

13.3.11.1 CHUNKの値

LOB列の作成時にCHUNKの値を選択した後は、値を変更できません。

CHUNKの値は変更できないため、記憶域およびパフォーマンスの要件に最適な値を選択することが重要です。SecureFilesでは、CHUNKは、アドバイザ・サイズで、後方互換性のために使用します。

13.3.11.1.1 領域に関する考慮事項

CHUNKの値は、インラインに格納されるLOBには関係ありません。

ENABLE STORAGE IN ROWが設定され、LOBロケータおよびLOBデータのサイズが約4000バイトを下回る場合に、インラインへの格納が行われます。ただし、LOBデータがアウトラインに格納される場合には、必ずCHUNKパラメータの倍数の領域が使用されます。これは、データが小さいのにCHUNKが大きな数字に設定されている場合は、領域をかなり無駄に使用することになります。表13-4にこの点について示します。

表13-4 データ・サイズとCHUNKサイズ

データ・サイズ CHUNKサイズ LOB格納に使用されるディスク領域 領域使用率(%)

3500(ENABLE STORAGE IN ROW)

関連なし

3500行

100

3500(DISABLE STORAGE IN ROW)

32 KB

32 KB

10

3500(DISABLE STORAGE IN ROW)

4 KB

4 KB

90

33 KB

32 KB

64 KB

51

2 GB +10

32 KB

2 GB + 32 KB

99+
13.3.11.1.2 パフォーマンスに関する考慮事項

LOBへのアクセスは、大きいデータ・チャンクで行う方が効率的です。

CHUNKは、最も頻繁にアクセスまたは書込みが行われるデータ・サイズに設定できます。たとえば、一度に1ブロックのみのLOBデータにアクセスする場合は、CHUNKをその1ブロックのサイズに設定します。LOBが大きく、読取り/書込みのデータ量が多い場合は、CHUNKに大きな値を選択します。

13.3.11.2 CHUNKよりも大きいサイズにINITIALおよびNEXTを設定する

LOBの記憶特性を明示的に指定する場合、LOBデータ・セグメントの記憶域のINITIALおよびNEXTを、必ずCHUNKサイズより大きい値に設定します。

たとえば、データベース・ブロックのサイズが2KBで、CHUNKを8KBに指定する場合、INITIALおよびNEXTを8KBよりも十分に大きい値(16KB以上)に設定します。

つまり、INITIAL、NEXT、またはLOBのCHUNK のサイズの値を指定する場合は、必ず次の条件に従って設定してください。

  • CHUNK <= NEXT

  • CHUNK <= INITIAL

13.3.12 ENABLE句またはDISABLE STORAGE IN ROW句

ENABLE | DISABLE STORAGE IN ROW句を使用して、LOBをインライン(行内)またはアウトラインに格納するかどうかを指定します。

ノート:

これは一度指定すると、変更できません。ENABLE STORAGE IN ROWからDISABLE STORAGE IN ROWにも、またその逆にも変更できません。

デフォルトはENABLE STORAGE IN ROWです。

13.3.13 ENABLEまたはDISABLE 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バイト超)、ENABLE STORAGE IN ROWが設定されると、LOBデータが行の外部に移動された後でも制御情報が行に格納されます。この制御情報によって、アウトラインLOBデータを高速で読み取ることができます。

ただし、DISABLE STORAGE IN ROWの方が適している場合もあります。LOBをインラインに格納すると、行のサイズが大きくなるためです。この場合、全表スキャン、複数行アクセス(レンジ・スキャン)、LOB列以外の列への多数のUPDATE/SELECTなどの実表の処理を頻繁に行う場合、パフォーマンスが低下します。

13.4 LOB列の索引付け

LOB列の索引付けに使用できる方法は各種用意されています。

ノート:

LOB列の移動後、表の既存の索引を再作成する必要があります。

内容は次のとおりです。

13.4.1 LOB列のドメイン索引付け

ドメイン専用の索引を作成すると、問合せのパフォーマンスを改善できる場合があります。データベースに用意されている拡張性のあるインタフェースによって、そのようなドメイン固有の索引を実装するための枠組みである、ドメイン索引作成機能を利用できます。

ノート:

LOB列には、Bツリーまたはビットマップ索引を構築できません。

関連項目:

ドメイン固有の索引作成の詳細は、『Oracle Databaseデータ・カートリッジ開発者ガイド』を参照してください。

13.4.2 LOB列のテキスト索引

LOB列の内容の性質によっては、Oracle Textオプションの1つを使用して索引を作成することもできます。

たとえば、テキスト・ドキュメントがCLOB列に格納されている場合、テキスト索引を作成して、CLOB列に対するテキストベースの問合せのパフォーマンスを向上させることができます。

関連項目:

CLOB列を使用してテキスト・データを格納する例の詳細は、『Oracle Textアプリケーション開発者ガイド』を参照してください

13.4.3 LOBに対するファンクション索引付け

ファンクション索引とは、式に対して作成される索引です。これによって、列のみの場合より索引機能が拡張されます。ファンクション索引により、データ・アクセスの方法が多様化します。

ファンクション索引は、ネストした表やLOB列には作成できません。ただし、VARRAYには作成できます。

DML操作がLOB列で実行されると、LOB列の拡張索引およびドメイン索引と同様に、ファンクション索引も自動的に更新されます。拡張索引が更新されると、ファンクション索引も更新されます。

関連項目:

ファンクション索引の使用方法の詳細は、『Oracle Database開発ガイド』を参照してください。

13.4.4 LOB列に対する拡張索引作成機能

データベースには、必要に応じて新規索引タイプを定義できる拡張索引作成機能が用意されています。これは、データ・カートリッジおよびデータベースがOLAP (On-line-Analytical Processing)などのためにテキストや空間などのデータ型の索引を構築および保持するという協調索引の概念に基づいています。

カートリッジは、索引構造の定義、ロード操作および更新操作中の索引内容のメンテナンス、問合せ処理中の索引の検索を行います。索引構造は、ヒープ構成表または索引構成表としてOracleに格納するか、オペレーティング・システム・ファイルとして外部に格納できます。

この構造をサポートするために、データベースには索引タイプが用意されています。索引タイプの目的は、データ・カートリッジを使用して、テキスト、空間、イメージ、OLAPなどの複合ドメインを効率的に検索および取出しできるようにすることです。索引タイプは、Oracleサーバーに組み込まれているソート済の索引またはビットマップ索引に似ています。相違点は、組込み索引はOracleカーネルによって実装されますが、索引タイプはデータ・カートリッジの開発者によって実装されることです。データ・カートリッジの開発者が新しい索引タイプを実装すると、データ・カートリッジのエンド・ユーザーは、組込み索引タイプと同様にその索引タイプを使用できます。

データベース・システムがドメイン索引の物理的な格納を処理する場合、データ・カートリッジは次のことを行います。

  • 索引のフォーマットおよび内容の定義。これによって、カートリッジが複合データ・オブジェクトを保存できる索引構造を定義できます。

  • ドメイン索引の作成、削除および更新。カートリッジは、索引構造の構築およびメンテナンスを処理します。これは、単純なSQLデータ型用に提供されている医療業界向け索引付け機能から大幅に発展した機能です。また、索引は一定の数の要素で構成される集合として作成されるため、インプレース更新が直接サポートされます。

  • 索引の内容へのアクセスおよび解析。この機能を持つデータ・カートリッジは、問合せの処理に不可欠なコンポーネントです。データベースへの問合せの内容に関連する句は、データ・カートリッジが処理します。

データベースでは、拡張索引作成機能がサポートされるため、LOBなどの複合データ型にアクセスするパフォーマンスの高いソリューションを非常に簡単に開発できます。

13.4.4.1 拡張可能オプティマイザ

ユーザー定義ファンクションおよび索引の作成者は、拡張可能オプティマイザの機能を使用して、統計集計ファンクション、選択ファンクションおよびコスト・ファンクションを作成できます。オプティマイザは、この情報を使用して問合せ計画を選択します。コストベース・オプティマイザは、ユーザーが提供する情報を使用するように拡張されています。

拡張索引作成機能を使用すると、新しい演算子、索引タイプおよびドメイン索引を定義できます。これらのユーザー定義演算子およびドメイン索引については、拡張可能オプティマイザの機能を使用して、オプティマイザが実行計画を選択するために使用する3つの主な構成要素(統計、選択性、コスト)を制御できます。

関連項目:

『Oracle Databaseデータ・カートリッジ開発者ガイド』

13.4.5 Oracle TextによるXMLへの索引付けのサポート

CLOB列にOracle Textの索引を作成し、XMLデータで問合せを実行できます。

関連項目:

13.5 パーティション表内のLOBの操作

LOB列を含む表をパーティション化できます。

内容は次のとおりです。

13.5.1 パーティション表内のLOBの操作について

この結果、次のように、パーティション化のすべてのメリットをLOBでも利用できます。

  • LOBセグメントをいくつかの表領域に分散して、I/O負荷を均衡化させ、バックアップおよびリカバリの管理をより簡単にできます。

  • パーティション表内のLOBがメンテナンスしやすくなります。

  • LOBを論理グループにパーティション化し、グループとしてアクセスされるLOBの操作を高速化できます。

この項では、パーティション表内のLOBの操作方法をいくつか説明します。

13.5.2 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列にのみ機能します。

ノート:

表の作成後は記憶域属性を変更できません

関連項目:

13.5.3 パーティション化されたLOB列を含む表に対する索引の作成

問合せのパフォーマンスを改善するために、パーティション化されたLOB列に対して索引を作成できます。次に例を示します。 

CREATE INDEX index_name 
   ON table_name (LOB_column_1, LOB_column_2, ...) LOCAL;

LOB列でサポートされるのは、ドメイン索引とファンクション索引のみであることに注意してください。一意索引など、他のタイプの索引はLOBでサポートされません。

13.5.4 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);

13.5.5 LOBを含むパーティションの分割

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)
         ... ;

13.5.6 LOBを含むパーティションのマージ

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)
     ... ;

13.6 索引構成表内のLOB

現在、索引構成表(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機能も索引構成表でサポートされ、その使用方法も従来の表の場合と同じです。

13.7 パーティション化された索引構成表内のLOBに対する制限

LOB列はレンジ・パーティション化、リスト・パーティション化およびハッシュ・パーティション化された索引構成表でサポートされますが、次の制限があります。

  • コンポジットでパーティション化された索引構成表はサポートされません。

  • リレーショナルおよびオブジェクト・パーティション化された(レンジ、ハッシュまたはリスト・パーティション化された)索引構成表には、次のようにLOBを格納できます。ただし、MOVE、SPLITおよびMERGEなどのパーティション・メンテナンス操作はサポートされません。

    • LOBデータ型として格納されているVARRAYデータ型

    • LOB属性を持つ抽象データ型

    • LOB型を持つネストした表

      関連項目:

      LOB列全般に関するその他の制限については、「LOBのルールと制限」を参照してください。

13.8 ネストした表内のLOBの更新

ネストした表内のLOBを更新するには、LOBを含む行を明示的にロックする必要があります。そのためには、LOB値を更新する前に、副問合せでFOR UPDATE句を指定します。

親表の行をロックしても、LOB列を含むネストした表の行はロックされないことに注意してください。

ノート:

LOB列を含むネストした表は、LOBのコレクション作成のためにサポートされている唯一のデータ構造です。LOBデータ型のVARRAYは作成できません。