データベースに対して選択したページ・サイズが、データベースのパフォーマンスに影響することがあります。通常、ページ・サイズが小さいと、ランダムな場所から比較的少ない数のローを取り出す操作に有利な傾向があります。反対に、大きなページは、特にローがインデックスを使用して取り出される順序でページに保管されている場合に、逐次テーブル・スキャンを実行するクエリに有利な傾向があります。この場合、メモリに 1 ページを読み込んで 1 つのローの値を取得すると、次のいくつかのローの内容をメモリにロードできるという 2 次的な効果があります。通常は、ディスクの物理的な設計のために、大きなブロックを少数取り出す方が、小さなブロックを多数取り出す場合よりも効率的です。

SQL Anywhere では、DB 領域ファイル全体での各テーブル・ページの位置を示すビットマップがテーブルごとに作成されます。データベース・サーバでは、テーブル・ページが 1 ページずつ読み込まれるのではなく、このビットマップを使用して大きなブロック (64 KB) で読み込まれます。「グループ読み込み」と呼ばれるこの方法で、ディスクへの I/O 操作の合計数が減り、パフォーマンスが向上します。ユーザは、ビットマップの作成や使用に関するデータベース・サーバの条件を制御できません。

8 KB などの大きなページ・サイズ選択すると、同じサイズのキャッシュに収まるページ数が少なくなるので、キャッシュ・サイズを大きくする必要がある場合があります。たとえば、1 MB のメモリには、1 ページを 2 KB とすると 512 ページ格納できますが、1 ページ 8 KB であれば 128 ページしか格納できません。ページ・サイズのキャッシュ・サイズに対する適切なページ比は、データベースと、アプリケーションで実行されるクエリの性質によって異なります。さまざまなキャッシュ・サイズで、パフォーマンス・テストを実行できます。キャッシュに十分なページを格納できない場合、データベース・サーバは頻繁に使用されるページをディスクにスワップし始めるため、パフォーマンスが低下します。これは、Windows Mobile デバイスで SQL Anywhere を使用する場合に重要です。ページ・サイズが大きいと、内部の断片化が増える可能性があります。

SQL Anywhere は、ページをできるだけ埋めようとします。空き領域が累積するのは、新しいオブジェクトが大きすぎて既存のページの空き領域に収まらない場合だけです。したがって、ページ・サイズを調整しても、データベース全体のサイズに大きく影響することはありません。

ページ・サイズは、インデックスにも影響を与えます。各インデックス・ルックアップでは、インデックスのレベルごとに 1 ページを読み込み、さらにテーブル・ページについて 1 ページを読み込む必要があります。また、1 回のクエリには数千のインデックス・ルックアップが必要になることがあります。ページのサイズはファンアウトにかなりの影響を与え、またテーブルに必要なインデックスの深さに影響します。大きなファンアウトは、通常、必要なインデックス・レベル数が少ないことを意味し、検索パフォーマンスを大幅に向上できます。テーブル内のローの数が多い大規模なデータベースでは、高パフォーマンスのために 1 ページを 8 KB にできます。ページ・サイズを選択するときは、パフォーマンスとその他の動作をテストすることを強くおすすめします。そして、満足できる結果を得られた最小のページ・サイズを選択します。同じサーバで複数のデータベースが起動される場合は、正しく適切なページ・サイズを選択することが重要です。

参照

• 適切なページ・サイズの使用
• 初期化ユーティリティ (dbinit)
• CREATE DATABASE 文