Oracle でのジオデータベースの BLOB データ格納
BLOB は Binary Large Object の略語で、DBMS（データベース管理システム）で使用されます。BLOB 列は、LONG RAW テクノロジにかわりバイナリ データを格納する技術として数年前に Oracle 社によって導入されました。
BLOB データ タイプのアーキテクチャはBLOB 列、LOB セグメント、および LOB インデックスの 3 つの基本要素に分けられます。もしデータが 3,965 バイト未満で、この列におけるインライン格納が無効になっていない場合は、BLOB 列は LOB ロケータ（36 バイト）とバイナリ データを行内に格納します。
注意:Esri のテストではインライン格納でベスト パフォーマンスが得られるという結果が出ているため、インライン格納を無効にしないことをお勧めします。
バイナリ データが 3,964 バイトを超えている場合は、BLOB 列のインライン格納領域は割り当てられず、LOB ロケータは LOB セグメントに格納されたバイナリ データを参照します。
つまり、インライン格納が有効な BLOB 列に格納される値は常に 36 バイト以上（LOB ロケータに割り当てられる領域）となり、最大でも約 4,000 バイト（LOB ロケータに割り当てられる領域と、インライン格納されるバイナリ データに割り当て可能な最大領域を結合した領域）になります。
LOB セグメントはチャンクに分割されます。チャンクは Oracle データ ブロック サイズの倍数にする必要があります。たとえば、データ ブロック サイズが 8K の場合、LOB セグメントは最小チャンク サイズを 8K として作成できます。LOB セグメント内に格納されるデータ長が 5,000 バイトの場合、このデータは 3,964 バイトを超えているため、データは LOB セグメントに格納され、チャンク サイズは 8K つまり 8,192 バイトとなります。このケースでは、LOB セグメント チャンクの 3,192 バイトが未使用のままになります。LONG RAW から BLOB へデータを変換すると、LOB セグメントに存在するこの未使用領域のために、必要な格納領域がさらに増加（最大で 30%）する場合があります。データが BLOB 列のインライン格納閾値である 3,964 バイトを超える場合、この問題は避けられません。
8K チャンク サイズは I/O のベスト パフォーマンスを実現すると同時に、未使用のデータ格納領域を最小限に抑えることができます。16K チャンク サイズの場合は、8K チャンク サイズよりも多くの領域が未使用のままになる可能性があります。このため、領域の損失を避けるためには、現在は 16K のデータ ブロック サイズであるデータベースを 8K のデータ ブロック サイズで再度作成するか、それが不可能な場合は、すでに作成されている表領域に 8K のブロック サイズで LOB セグメントを作成します。これを実行するには、Oracle SGA（System Global Area）に 8K のバッファ キャッシュを割り当てる必要があります。
4K および 2K のチャンク サイズでは未使用となるデータ格納領域がさらに少なくなりますが、I/O に与える影響が大きくなるため、これらのサイズの使用はお勧めしません。
LOB インデックスは、LOB ロケータで指定されるチャンクの数が 12 を超えた場合のみ使用されます。それ以外の場合は、最初の 12 個のチャンクが LOB ロケータによって指定されます。
次の 3 つの図は、BLOB 列に格納されるバイナリ データの 3 つのケースを表しています。1 番目のケースでは、バイナリ データがインライン格納閾値である 3,965 バイトを下回っている（この場合は 3,000 バイト）ため、バイナリ データがインライン格納されています。インライン格納が BLOB 列で無効になっていない場合、LOB セグメントと LOB インデックスは使用されません。一般に、この場合は I/O 操作の数が減るため BLOB データのフェッチが速くなります。Oracle が LOB セグメントまたは LOB インデックスにアクセスする必要がないためです。
 |
インライン格納される 3,965 バイト未満のサイズの BLOB データ |
次の図は 2 番目のケースを示しています。このケースではバイナリ データが 3,964 バイトを超えている（この場合は 81,920 バイト）ため、インライン格納できません。このため、LOB ロケータは LOB セグメントに格納されているバイナリ データを参照します。LOB セグメント内のバイナリ データのチャンクは 12 個を超えないため、LOB ロケータがそのアドレスを格納します。このケースでは、LOB インデックスは使用されません。
 |
ライン外格納される 3,964 バイトを超えるサイズの BLOB データテーブル内の LOB ロケータは、データが格納されている LOB セグメントを示します。 |
3 番目の図では、バイナリ データが大容量（106,496 バイト）であるため、LOB インデックスが必要です。このケースでは、バイナリ データはインライン格納サイズを超えており、格納するにはさらに LOB セグメント内に 12 個を超えるチャンクが必要になります。データがこれほど大容量な場合は、LOB ロケータが LOB インデックスを参照して LOB セグメント内のチャンクの場所を特定します。このケースはベクタ データでは非常にまれであり、ラスタ データでも避けることは可能です。
 |
ライン外格納され、LOB インデックスを必要とする BLOB データ |
BLOB 列を格納するための DBTUNE パラメータの設定
DBTUNE テーブルの格納パラメータは、ArcGIS による Oracle のテーブルおよびインデックスの作成を制御します。格納パラメータの中には、テーブルの作成時に使用するデータ タイプを指定するものもあります。DBTUNE テーブルの詳細については、「DBTUNE テーブルとは」をご参照ください。DBTUNE 格納パラメータの詳細については、「DBTUNE コンフィグレーション キーワードおよびパラメータとは」をご参照ください。
DBTUNE 格納パラメータの GEOMETRY_STORAGE、RASTER_STORAGE、および ATTRIBUTE_BINARY によって、データの格納に使用される Oracle データ タイプが決まります。
GEOMETRY_STORAGE パラメータは、フィーチャクラスにベクタ データを格納する方法を制御します。RASTER_STORAGE パラメータは、ラスタ データセット、ラスタ カタログまたはラスタ属性にラスタ データを格納する方法を制御します。最後の ATTRIBUTE_BINARY パラメータは、ベクタまたはラスタではないその他すべてのバイナリ データの格納を制御します。
BLOB 列を作成するには、任意の DBTUNE キーワード内でパラメータを次のように設定する必要があります。
GEOMETRY_STORAGE SDELOB
RASTER_STORAGE BLOB
ATTRIBUTE_BINARY BLOB
ベクタ データおよびラスタ データには次のような LOB 格納パラメータをお勧めします。
- ほとんどの GIS（地理情報システム）のデータは 3,964 バイトのインライン閾値を超えないため、常にインライン格納を有効にします。パフォーマンスは、データをインライン格納した場合が最も高くなります。
- ジオデータベースのデータは頻繁に読み取られるため、キャッシュを有効にします。
- ArcGIS は BLOB データの更新は実行せず、挿入および削除のみを実行するため、PCT_VERSION を 0 に設定します。これは、LOB セグメント内の古いバージョンのデータを維持する必要がないためです。
- 8K より小さいチャンク サイズは使用しないでください。2K および 4K のチャンク サイズでは、Oracle サーバ プロセスがフェッチしなければならないチャンク数が増えるため、I/O の量が増加します。8K のチャンク サイズで無駄になる格納領域は、16K のチャンク サイズよりも少なくなります。2K または 4K のチャンク サイズを使用すると無駄になる格納領域はさらに減りますが、ほとんどのラスタおよびベクタ データで、データの表示に要する時間が 8K のチャンク サイズに格納する場合を大きく上回ることが、テストで明らかになっています。チャンク サイズは常にデータ ブロック サイズの倍数となるため、BLOB に GIS データを格納するために使用する最適なデータ ブロック サイズは 8K になります。
次に示す例では、BLOB データ タイプでラスタ ブロック テーブルを格納するために、ラスタ DBTUNE 格納パラメータが変更されている様子を示します。
RASTER_STORAGE "BLOB"
BLK_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE RASTER
LOB (BLOCK_DATA) STORE AS
(TABLESPACE RASTER_LOB_SEGMENT
CACHE PCTVERSION 0)"
AUX_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE RASTER
LOB (OBJECT) STORE AS
(TABLESPACE RASTER
CACHE PCTVERSION 0)"
RASTER_STORAGE "ST_RASTER"
BLK_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE RASTER
LOB (BLOCK_DATA) STORE AS
(TABLESPACE RASTER_LOB_SEGMENT
CACHE PCTVERSION 0)"
ラスタ ブロック ピクセル データが 3,965 バイト未満の場合は、RASTER 表領域の BLOCK_DATA 列内に格納されます。ただし、この閾値を超える場合は、RASTER_LOB_SEGMENT 表領域の LOB セグメントに格納されます。LOB インデックスは、チャンク数が 12 を超える場合のみ使用されますが、これはジオデータベースのデータではほとんどの場合において発生しません。たとえば LOB セグメントのチャンク サイズが 8K である場合は、ArcSDE バイナリ データが 96K を超えてから、LOB インデックスが使用されます。
次に示す例では、BLOB データ タイプでフィーチャ テーブルを格納するために、ベクタの DBTUNE 格納パラメータが変更されています。
GEOMETRY_STORAGE "SDELOB"
F_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE VECTOR
LOB (POINTS) STORE AS
(TABLESPACE VECTOR_LOB_SEGMENT
CACHE PCTVERSION 0)"
GEOMETRY_STORAGE "ST_GEOMETRY"
フィーチャのバイナリ データが 3,965 バイト未満の場合は、VECTOR 表領域の POINTS 列内に格納されます。ただし、この閾値を超える場合は、VECTOR_LOB_SEGMENT 表領域の LOB セグメントに格納されます。
ATTRIBUTE_BINARY "BLOB"
B_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE BIZZTABS
LOB (DOCUMENT) STORE AS
(TABLESPACE BIZZ_LOB_SEGMENT
CACHE PCTVERSION 0)"
A_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE BIZZTABS
LOB (DOCUMENT) STORE AS
(TABLESPACE BIZZ_LOB_SEGMENT
CACHE PCTVERSION 0)"
この例では、ビジネス テーブルのバイナリ データが 3,965 バイト未満の場合は、BIZZTABS 表領域のビジネス テーブルの BLOB 列内に格納されます。ただし、この閾値を超える場合は、BIZZ_LOB_SEGMENT 表領域の LOB セグメントに格納されます。この例の BLOB 列は DOCUMENT です。上記の B_STORAGE DBTUNE パラメータが、DOCUMENT 列を持たないテーブルの作成に使用されると、次のようなエラーが Oracle から返されます。
ORA-00904: "DOCUMENT": invalid identifier
このため、特定の BLOB 列を参照する B_STORAGE または A_STORAGE のパラメータを DEFAULTS キーワードに追加するのは賢明ではありません。ビジネス テーブルにこれらの列が含まれている必要があるからです。代わりに、個別の DBTUNE キーワードを作成して、これらの格納パラメータをキーワードに追加します。格納パラメータを含むキーワードはテーブルの作成中に参照されます。DEFAULTS キーワードの格納パラメータは、特定のキーワードに格納パラメータが含まれていない場合に使用されることにも注意してください。このため、特定の格納パラメータの構成文字列が DEFAULTS キーワードの格納パラメータと同一の場合は、その格納パラメータをキーワード内に追加する必要はありません。たとえば、新規キーワード ROADS の B_STORAGE および A_STORAGE 以外のすべての格納パラメータが、DEFAULTS キーワードの格納パラメータと同じ構成文字列を持つ場合、ROADS キーワード下に作成する必要があるのは B_STORAGE および A_STORAGE のパラメータのみです。その他のすべての格納パラメータは、ROADS キーワードにはないため、DEFAULTS キーワードから読み取られます。