選択したページサイズが、データベースのパフォーマンスに影響することがあります。大きいページサイズにも小さいページサイズにも、それぞれ利点と欠点があります。

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

ページサイズを選択するときは、パフォーマンスとその他の動作をテストすることを強くおすすめします。そして、満足できる結果を得られた最小のページサイズを選択します。同じサーバーで複数のデータベースが起動される場合は、正しく適切なページサイズを選択することが重要です。

小さいページは保持できる情報量が少ないため、特に、ページの半分よりも少し大きいサイズのローを挿入する場合に領域の使用効率が低下します。ただし、ページサイズが小さいと、同じサイズのキャッシュにより多くのページを格納できるため、SQL Anywhere をより少ないリソースで実行できます。メモリが限られている小型のコンピューターでデータベースを実行する場合に便利です。また、不特定のロケーションから少量の情報を取得するためにデータベースを使う場合にも便利です。

ページサイズが大きいと、SQL Anywhere はデータベースをより効率的に読み込めます。データベースの規模が大きい場合や、逐次テーブルスキャンを実行するクエリの場合にパフォーマンスが高くなる傾向があります。通常は、ディスクの物理的な設計のために、大きなブロックを少数取り出す方が、小さなブロックを多数取り出す場合よりも効率的です。大きいページサイズには、他の利点もあります。インデックスのファンアウトを改善することによってインデックスレベル数を減らし、カラム数の多いテーブルが作成できます。大きなページサイズ選択すると、同じサイズのキャッシュに収まるページ数が少なくなるので、キャッシュサイズを大きくする必要がある場合があります。キャッシュに十分なページを格納できない場合、データベースサーバーは頻繁に使用されるページをディスクにスワップし始めるため、パフォーマンスが低下します。

ページサイズが大きいと、メモリも余分に必要になります。また、大容量のデータベースサーバーキャッシュを常に利用できないかぎり、大半のアプリケーションでは、極端に大きなページサイズ (16 KB または 32 KB) の使用はおすすめしません。

データベースサーバーのメモリの使用状況は、ロードされたデータベース数とデータベースのページサイズに比例します。ページサイズを選択するときは、パフォーマンステスト (およびテスト全般) を実行することを強くおすすめします。その上で、満足できる結果を得られた最小のページサイズ (4 KB 以上) を選択します。同じサーバーで多数のデータベースが起動される場合は、正しい (かつ適切な) ページサイズの選択が重要です。

既存のデータベースのページサイズは変更できません。その代わり、新しいデータベースを作成し、dbinit の -p オプションを使用してページサイズを指定します。たとえば、次のコマンドは 4 KB のページサイズのデータベースを作成します。

dbinit -p 4096 new.db

新しいページサイズでデータベースを作成するために、PAGE SIZE 句を指定した CREATE DATABASE 文を使用することもできます。

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

 ページサイズとインデックス

 分散読み込み

 参照