DB2 LUWでは、32Kのテーブルスペースを作成してそれを使用するのではなく、4K、8K、または16Kのテーブルスペースをいつ使用すればよいですか？
彼の回答に関連する場合に備えて、WindowsおよびLinuxシステムではDB2 LUW 10.5および11.1を使用しています。
質問：32Kではなく4Kを使用するのが適切な時期はありますか？もしそうなら、なぜですか？ （使用できる場合はパフォーマンスが向上しますか？）または、4Kがちょうどページサイズだった先史時代の古い付属物ですか？
背景：DB2データベースを作成するときに、4K、8K、16K、および32Kのテーブルスペースと関連するバッファプールを常に作成しました。
私のマネージャーはこれに私に挑戦しています。 （彼にとっては良い-私はこれを知っているべきです！）彼は私たちが32Kのテーブルスペースを作成してそれで終わらせるべきだと考えています。
たとえば、行のサイズが許す場合は、XYZであるため、32Kではなく4Kを使用する必要があることを示すものは何も見つかりません。 [〜＃〜] can [〜＃〜]これを行うことはわかりますが、その必要はありません。
それは良い質問ですが、答えは残念ながら存在しない本の章全体に値します。 EmberリンクしているCrooksの記事は良い概要です。ここでは、テーブルスペースのページサイズを決定するときに考慮に入れたいランダムな要素をいくつか追加します。
TL; DR。
以下の点を考慮して、データに最適な1つのページサイズを選択してください。パフォーマンステストで、一部のテーブルを異なるページサイズのテーブルスペースに移動することで対処できる問題が示された場合は、慎重に行ってください。
決定要因
あなたが述べたように、テーブルの行幅はそれらを収容するために必要な最小ページサイズを決定します。ただし、常に「データで機能する最小のもの」が必要であるとは限りません。
まず、「不要なI/Oを回避する」および「一度に少ないデータを処理する」という、ページサイズが小さいという通常の議論は、少し見当違いです。テーブルスペースコンテナーが、回転ディスクまたはSSDを使用する可能性のある不明な数のRAID6デバイス上のCephボリューム上のVMWare仮想ディスク上のLVMボリューム上のZFSファイルシステム上にある場合、4Kの物理I/Oの量は本当にわかりますか（または32K）読み取り要求が発生しますか？
他の方法では解決できないテーブルスペースホットスポット（ほとんどのI/O要求が限られた数のページに送信される）をワークロードが作成する場合、ページサイズを小さくすると確かに役立ちます。このような状況では、ページを小さくすると、バッファプールの効率が向上し、同じページへのアクセスを競合するエージェント間のページラッチ待機が減少します。一方、ページサイズが小さいと、LRUチェーンが長くなるため、ページクリーニングの効率が低下する可能性があります。
より大きなページサイズに対する議論もあります。
LOBデータの存在。
通常、LOBデータは、テーブルの行の外側に、いくつかのパフォーマンス上の欠点がある個別のデータ構造で格納されます。
- データベースバッファープールをバイパスする同期直接読み取りと書き込みを介してのみアクセスできます。使用可能な唯一のキャッシングは、テーブルスペースで有効になっている場合、基礎となるファイルシステムのキャッシングです。直接読み取りも、ページのプリフェッチを利用しません。
- LOBはバッファー・プールにロードされないため、同じデータに繰り返しアクセスすると、直接読み取り要求が繰り返されます。
- テーブルの圧縮が有効になっていても、圧縮されません。
ほとんどのLOB値が比較的小さく、ページサイズが大きい場合に行自体に収まる可能性がある場合（多くの場合）、それらをインラインで格納して、これらの欠点を軽減できます。
圧縮。
ページサイズが大きいほど、適応型（ページレベル）圧縮の効率が向上します。多くの場合、データ圧縮によるI/Oの削減は、CPUコストを上回ります。
一時テーブルスペースを忘れないでください。
各テーブルを個別に4Kテーブルスペースに配置できる場合でも、より大きなページサイズのシステム一時テーブルスペース（および対応するバッファプール）が必要になる場合があります。クエリが2つ以上のテーブルのサブ4K行を結合する場合、結果セットの幅は4Kの制限を超える可能性があり、スピルが必要な場合は、適切なサイズのテーブルスペースが必要になります。
あなたが言ったように、それぞれが専用のバッファプールを必要とし、複数のバッファプールは、必要でない限り、ほとんど常に（効率的ではない）一つの大きなもの。
私はようやく適切なGoogle検索にヒットし、Ember Crooks（ https://datageek.blog/2013/07/09/db2-luw -what-is-a-page / ）OLTPまたはeコマースサイトではより小さなページが優先されるため、より少量のデータを処理します。それが答えだと思います次に、データで機能する最小のものを使用して、ページに複数の行を取得することを認識します。
他の誰かが探しに来た場合に備えて、単に削除するのではなく、答えを残しておきます。
このような選択は通常、システムのワークロードのタイプによって異なります。簡単に：
トランザクションシステムは通常、リクエストごとに数レコードずつデータを読み取ります。 Db2のストレージの最小のチャンクはデータページです。単一のデータ行を読み取るには、Db2がディスクからデータページ全体を読み取る必要があります。通常のリクエストで必要な行は、データページにランダムに常駐することが多いため、ディスクIOの数が、そのようなシステムで通常のクエリによって返されるレコードの数に近いことは珍しいことではありません。つまり、1行/ IO読み取りあたり4K対32Kです。より大きなページサイズで同じ結果セットを返すには、より不必要ですIO.
DSSシステムは通常、大量のデータをスキャンします。これは、一般的にIOリクエストごとに大きな読み取りを行うことでより効率的に実行できます。