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.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つの |
|
|
LOBロケータのみ表の列に格納されます。 インラインLOBについては、表列の中に約4000バイトまでのデータが格納されます。 |
|
LOB列にアクセスすると、ロケータまたはデータのフェッチが選択できます。 |
|
LOBのサイズは、ブロック・サイズに応じて128TB以下またはそれ以上です。 |
|
ランダムにピース単位でデータを操作する場合は、LOBを使用する方が柔軟性があります。LOBはランダム・オフセットでアクセスできます。 |
|
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
間で変更することはできません。
ノート:
コンテナ・データベースのルートおよびプラガブル・データベースが異なる文字セットである場合、LOBはサポートされません。詳細は、CREATE PLUGGABLE DATABASEを使用したPDBの再配置を参照してください。13.3 LOB記憶域パラメータ
LOB記憶域を含む表の設計時には、特定のLOB記憶域の特性について考慮する必要があります。次は、SECUREFILE
パラメータに関する説明です。
関連項目:
内容は次のとおりです。
13.3.1 インラインLOB記憶域とアウトラインLOB記憶域
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値(
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記憶域をチューニングする場合は、次のガイドラインを考慮してください。
13.3.4 TABLESPACEおよびLOB索引
LOB索引は、LOB記憶域に密接に対応付けられている内部構造体です。したがって、ユーザーがLOB索引を削除または再構築することはできません。
ノート:
LOB索引は変更できません。
システムは、LOB STORAGE句内のユーザー指定に従って、LOBデータおよび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管理に使用する表を構成する必要があります。LOBRETENTION
をBasicFiles LOBで有効にするには、ASSMが必要です。BasicFiles LOBがMSSM表領域にある場合、SQLのRETENTION
パラメータ(STORE
AS
文)は暗黙的に無視されます。 -
LOB STORAGE句で指定できるのは、
RETENTION
またはPCTVERSION
のどちらか一方のみです。関連項目:
-
LOB STORAGE句の構文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
13.3.7 SecureFiles LOB用のRETENTIONパラメータ
SecureFilesにRETENTION
パラメータを指定すると、データベースで、データベースのUNDO
モードなどの要素を考慮に入れて、SecureFiles記憶域の読取り一貫性のあるデータが動的に管理されます。
-
データベースが
FLASHBACK
モードの場合、LOBUNDO
の保存サイズのバイト数を制限するには、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の使用時期
キャッシュ・モード | 読取り | 書込み |
---|---|---|
|
頻繁 |
1回または時々 |
|
頻繁 |
頻繁 |
|
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
句が省略されている場合は、NO
LOGGING
または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.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.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.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をインライン(行内)またはアウトラインに格納するかどうかを指定します。LOBがIN
ROW
で保存されている場合、
-
Exadataのプッシュダウンは、圧縮および暗号化されていないLOBおよびSecureFiles圧縮を使用したLOBに対して有効です。
-
インメモリーは、圧縮および暗号化されていない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列の索引付けに使用できる方法は各種用意されています。
内容は次のとおりです。
13.4.1 LOB列のドメイン索引付け
ドメイン専用の索引を作成すると、問合せのパフォーマンスを改善できる場合があります。データベースに用意されている拡張性のあるインタフェースによって、そのようなドメイン固有の索引を実装するための枠組みである、ドメイン索引作成機能を利用できます。
関連項目:
ドメイン固有の索引作成の詳細は、『Oracle Databaseデータ・カートリッジ開発者ガイド』を参照してください。
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つの主な構成要素(統計、選択性、コスト)を制御できます。
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列にのみ機能します。
ノート:
表の作成後は記憶域属性を変更できません
関連項目:
-
LOB記憶域属性の詳細は、「LOB記憶域パラメータ」を参照してください
-
LOBの制限に関する追加情報は、「パーティション化された索引構成表のLOBに対する制限」 を参照してください
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列を含む索引構成表(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のルールと制限」を参照してください。
-