DB2：32 KBのデータページを使用するようにインデックステーブルスペースを作成することは良いですか
私たちのDB2サーバーは、すべてのインデックスを1つのテーブルスペースに構成することがわかりました。そして、32kbのデータページを使用するためのテーブルスペースを定義します。これはいいですか？それを判断する方法は？どんなアドバイスでも大歓迎です。
私が読んだ内容（DB2の理解：例を使用して視覚的に学習を確認）から、データ、インデックス、および長いデータ（LOBタイプのデータとLONG VARCHARなどの非推奨のタイプを意味する）を配置することをお勧めします）独自のテーブルスペースに。
主な理由は、メンテナンスとサポートのためです。データが異なるテーブルスペースにある場合は、必要に応じてバックアップ/復元できます。たとえば、テーブルデータはインデックスよりも「重要」です（インデックスにはテーブル内のデータがなければ目的がないため）。したがって、インデックスが別のテーブルスペースにあり、破損したり、復元が必要になったりした場合、テーブル全体ではなく、インデックスを復元するだけで済みます（もちろん、インデックスが最新であることを確認するためにreorgとrunstatsを実行する必要がある場合があります） ）。
LOBについて-それらがINLINEと宣言されていない限り、それらはテーブルデータと共に直接格納されません（そしてINLINEは特定のサイズのLOBに対してのみ機能します）。 LOBで発生する更新アクティビティが多すぎないことを願っています（LOBはバッファプールにキャッシュされず、常にディスクから取得されるため、少しコストがかかる可能性があります）。したがって、それらを別のテーブルスペースに置くと、そこでも役立ちます。データを格納するための別のスペースがあり、テーブルデータが破損している/復元が必要な場合でも、LOBに問題がない場合は、LOBを失うことなくテーブルデータのみを復元できます。
したがって、IBMの推奨事項について考えてみてください。彼らはあなたがそのようにあなたのテーブルを作ることを勧めます：
CREATE TABLE MY_TABLE (
ID BIGINT NOT NULL GENERATED BY DEFAULT AS IDENTITY,
TEXT VARCHAR(100),
...
primary key (ID))
IN TS_DAT
INDEX in TS_IND
LONG in TS_LOB; --or TS_LONG if you wish.
サイズについては、テーブルとインデックス、および長い/ LOBデータのみを適切なサイズのページに配置することをお勧めします。インデックスに32Kのテーブルスペースが必要ない場合、なぜそこに置くのですか？ページを浪費するだけで（ページ上の多くのスペースがunsunedになります）、ディスクを浪費します。後でインデックス、テーブル、またはlong/lobをより大きなページサイズのテーブルスペースに移動する必要がある場合、後でそれを行うことはそれほど難しくありません。 （もちろん、それを実行するためにメンテナンスウィンドウが必要になる場合がありますが、ディスクが「安価」であるにもかかわらず...なぜお金を無駄にするのですか？）.
以前はテーブルを必要なサイズに配置し、インデックスを4Kにのみ配置していましたが、それらを大きくする必要がない限り、後でいつでも変更できると考えました。しかし、最近、インデックスがテーブルデータおよびLOBデータと同じテーブルスペースサイズであることを確認するようになりました。理由は、テーブルの作成後にテーブルスペースを変更できないためです。データを移動するには、基本的に新しいテーブルを作成し、すべてのデータを一方から他方に移動する必要があります。
他のテーブルにあるいくつかのLOBについても同様です。私はそれらのサイズを計算し、適切なサイズのテーブルスペースに入れました。
ストレージのスペース要件 の次のページを見つけました。必要なページサイズ（およびテーブルスペース）を決定するテーブルとLOBのサイズを理解するのに非常に役立ちます。 インデックスのスペース要件 リンクはインデックスに役立ちます。注：これはDB2 9.7用です。別のバージョンが必要な場合は、リンクの番号を変更するか、IBMのメインページから開始してください。