PSQL には、PSQL ファイルを、PSQL エンジンの最新バージョンで利用できるようにする変換するツールがあります。この章では、これらのツールの概要、その使用目的と使用方法を説明します。以下の項目について説明します。

Rebuild ユーティリティを使用すると、MicroKernel ファイル（データ ファイルと辞書ファイル）に対して以下の操作を行うことができます。

データベースで辞書ファイル（DDF）を使用している場合は、データ ファイルだけでなくこれらもリビルドする必要があります。

データ ファイルのリビルドの概念についてより理解を深めるため、以下のセクションをお読みください。

Rebuild ユーティリティの使用についての情報は、以下のセクションを参照してください。

Rebuild には 2 つの様式があります。1 つはWindows 用の 32 ビット GUI バージョンで、もう 1 つは Linux、OS X、および Windows 用のコマンドライン バージョンです。Rebuild ユーティリティ の GUI のリファレンスおよび CLI 操作を参照してください。

Rebuild は、Linux および OS X では rbldcli というプログラムとして実行されます。デフォルトでは、このプログラムは /usr/local/psql/bin にあります。

Rebuild は Windows では rbldcli.exe というプログラムとして実行されます。これらのファイルはデフォルトで、Program Files ディレクトリにインストールされます。

現在のデータベース エンジンはいくつかの古いデータ形式や辞書ファイル形式と互換性を保っていますが、最新の機能を利用するためにファイルを最新の形式に変換したい場合があります。次の表に、旧形式から新しい形式に変換する主な理由を挙げます。

コマンドラインの Rebuild ユーティリティを使用してできたファイル形式は、-f パラメーターによって異なります。-f パラメーターを指定しないと、Rebuild は MicroKernel の［作成ファイルのバージョン］設定オプションに指定されている値を使用します。たとえば、［作成ファイルのバージョン］の値が 8.x の場合、バージョン 7.x のファイルに対して Rebuild ユーティリティを実行すると、このファイルは バージョン 8.x の形式に変換されます。作成ファイルのバージョンおよび -f パラメーターを参照してください。

Rebuild ユーティリティを実行する前に、変換するデータ ファイルをすべてバックアップしておくことをお勧めします。これは、元のファイルと同じ場所にリビルドする場合には特に重要です（この場合リビルドされたファイルは元のファイルを置き換えます）。バックアップ コピーを取っておけば、必要な場合に元のファイルを復元することができます。バックアップを確実に実行するためには、以下のいずれかの操作を行います。

Windows では、Rebuild は TMP システム環境変数で指定されたディレクトリにテンポラリ ファイルを作成します。デフォルトで、Linux および OS X では Rebuild は出力ディレクトリ（-b パラメータが使用されていない場合はソース ディレクトリ）にテンポラリ ファイルを作成します。このため、テンポラリ ファイル ディレクトリには元のファイルと新しいファイルの両方を格納するために十分なディスク容量が必要です（Rebuild ユーティリティの実行中）。Rebuild GUI バージョンの［出力ディレクトリ］オプションを使用するか、CLI バージョンの -B オプションを使用して、これらのファイルを別のディレクトリに保存するように指定できます。

通常、変換が終了するとテンポラリ ファイルは自動的に削除されます。ただし、停電などの重大な障害が発生した場合は、テンポラリ ファイルが削除されないことがあります。このような場合は、以下のタイプのテンポラリ ファイルを削除してください。

Rebuild はデータベース エンジンに Btrieve 呼び出しを行います。したがって、データベース エンジン環境設定およびお使いのコンピューター上のランダム アクセス メモリ（RAM）の量がリビルド処理のパフォーマンスに影響を与えます。このことは、特にサイズの大きなデータ ファイルをリビルドする際の所要時間を見れば明らかです。

一般的に、インデックスを構築するのはデータ ページを構築するよりはるかに時間がかかります。インデックスを多数持つデータ ファイルがある場合、同じファイルでインデックスが少ないものに比べ、ファイルを構築するのにより多くの時間を要します。

リビルドの処理時間には以下の項目が影響します。

CPU（中央処理装置）の速度および物理ストレージ ディスクへのアクセス速度が、リビルドの処理時間に影響します。一般的に、これらの両方の速度が速いほどリビルド処理も速く行われます。ディスク速度は、メモリに全体が入りきらない大きなファイルのリビルドではより重要になります。

Rebuild では、デフォルトの方法ともう 1 つの方法の 2 つの方法を用いてファイルをリビルドすることができます。-m<0 | 2> パラメーターを参照してください。選択する方法は、使用できるメモリの量によって決まります。デフォルトの方法（-m2）では、利用可能なメモリがあれば、Rebuild は以下の手順を行います。

この処理中にテンポラリ ファイルのオープンや書き込みに失敗などのエラーが発生した場合、Rebuild はもう 1 つの方法を用いてファイルのビルドを最初からやり直します。

デフォルトの方法には存在するメモリが足りない場合やデフォルトの方法で処理中にエラーが発生した場合、Rebuild はもう 1 つの方法（-m0）を使用します。

もう 1 つの方法は、デフォルトの方法に比べて一般的にはるかに時間がかかります。多数のインデックスを持つサイズの大きなファイルがある場合、2 つの方法の差は何時間から何日にまで及ぶことがあります。Rebuild が必ずデフォルトの方法を使用するようにする唯一の方法は、十分な使用可能メモリを確保することです。設定プロパティのいくつかは、利用可能なメモリ量に影響を与えます。

以下の式は、速い方法でファイル インデックスをリビルドするのに必要な連続した空きメモリの最適かつ最小の量を見積もります。最適なメモリ量は、RAM 上のすべてのマージ ブロックを格納するのに十分な量です。最小のメモリ量は、RAM 上の 1 つのマージ ブロックを格納できる量です。

たとえば、ファイルに 8,000,000 レコードが含まれていて、最も長いキーが 20 バイト（リンク重複キーではない）である場合、理想的なメモリの量は 373.5 MB、つまり ((( 20 + 8 ) * 8,000,000 ) + 65536 ) / 0.6 = 373,442,560 バイトとなります。

最適な連続空きメモリの量は 373.5 MB です。少なくともこれだけの空きメモリがあれば、Rebuild 処理はすべて RAM 上で行われます。60 % という割り当て制限のため、メモリの最適な量というのは、実際はリビルド処理開始時に必要とされる空き領域の量で、リビルド処理が実際に使用する量ではありません。この最適量に 0.6 をかけると、Rebuild が実際に使用する最大量が決定されます。

メモリの最低量は最適量の 1/30、12,448,086 バイト、または 12.45 MB です。

除数に 30 を使用するのはデータベース エンジンが一度に追跡するマージ ブロックは 30 以下であるためですが、常に 1 つのマージ ブロックがメモリ上にある必要があります。除数に 0.6 を使用するのは、エンジンがリビルド処理に 60% より多くの物理メモリを割り当てることはないためです。

使用可能メモリが最小の量より少ない場合、Rebuild はデータ ファイルのリビルドにもう 1 つの方法を使用します。

最後に、割り当てられたメモリブロックは 2 つの条件を満たす必要があります。必要なブロックと割り当てられたブロック サイズは次のようになります。

必要なブロック数は 30 以下です。

割り当てられたブロック サイズは以下の値以上である必要があります。

ページ サイズ 512 バイト、12.45 MB のブロック割り当てに成功したと仮定すると、必要なブロック数は次のようになります。

最初の条件に合っています。

割り当てられたブロック サイズの値は次のようになります。

割り当てられたブロック（12,500,000 バイト）は 9324 バイトより大きいですか?そうであれば 2 番目の条件に合っています。インデックス キーはテンポラリ ファイルに 12.45 MB ずつの塊として書き込まれ、メモリに格納され、次にインデックスに書き込まれます。

この設定は、ランタイムでインデックスを作成中に MicroKernel がソートのために動的に割り当てる、または割り当てを解除するメモリの最大容量を指定します。ソート バッファー サイズを参照してください。

設定がゼロ（デフォルト）の場合、Rebuild は最適なメモリ バイト値を計算し、その値に基づいてメモリを割り当てます。メモリ割り当てに成功したら、割り当てられたブロックのサイズは少なくとも最小メモリ バイトで定義された値になります。必要なメモリ量を見積もる式を参照してください。

設定がゼロ以外の値で、値が計算された最小メモリ バイトより小さい場合、Rebuild はその値を使用してメモリを割り当てます。

最後に、Rebuild は割り当てるべきメモリ量と実際に利用可能な量の 60% とを比較します。そして、その 2 つのうち小さい方を割り当てようとします。メモリ割り当てに失敗した場合、Rebuild は最後に割り当てようとしたメモリ量の 80% の割り当てを試みることを続けます。メモリ割り当てに完全に失敗した場合（これは最小メモリ バイトよりメモリ量が少ないことを意味します）、Rebuild はファイルのリビルドにもう 1 つの方法を使用します。

この設定は、総物理メモリに対して MicroKernel が消費できるメモリの割合を指定します。MicroKernel による L1、L2 およびその他すべてのメモリの使用量が含まれます（リレーショナル エンジンは含まれません）。MicroKernel の最大メモリ使用量を参照してください。

リビルドするサイズの大きなファイルがある場合、［MicroKernel の最大メモリ使用量］のパーセンテージを一時的にデフォルトより小さい値に設定します。リビルド処理が終わったら、再度適切なパーセンテージに設定し直します。

この設定は、MicroKernel によって割り当てられるレベル 1 キャッシュのサイズを指定します。MicroKernel では、すべてのデータ ファイルへのアクセスにこのキャッシュが使用されます。キャッシュ割当サイズを参照してください。

この設定は、データベース エンジンがデータ ファイルにアクセスするのにどれだけのメモリが使用できるかを決定します。インデックスを構築する際に使用するものではありません。

キャッシュ割り当てサイズを大きな値に増やしても、インデックスの構築は速くなりません。実際、重要なメモリを占めることにより Rebuild にとっては利用不可能となり、処理を遅くする可能性があります。大きなファイルをリビルドする場合には、キャッシュ値を低い値に抑えます。たとえば、現在の値の 20% で、ただし 5 MB を下回らないようにします。こうすると、できるだけ多くのメモリをインデックスのリビルドに残すことができます。

ファイルのページ サイズも、インデックス構築の速度に影響します。Rebuild がもう 1 つの方法を使用した場合、小さいキー ページを使用するとインデックスの構築に必要な時間は劇的に増加します。Rebuild がデフォルトの方法を使用した場合には、キー ページ サイズはインデックスの構築にはあまり影響を与えません。

Rebuild は、ページ サイズをアプリケーションのパフォーマンスまたはディスク ストレージに対して最適化します。

（アプリケーションがそのデータにアクセスする）パフォーマンスについて最適化するには、Rebuild はデフォルトのページ サイズ 4096 バイトを使用します。この結果は、物理ストレージ上の大きなページ サイズと遅いリビルド時間になります。

ディスク ストレージに対するページ サイズの最適化に関する解説は、開発者リファレンスの『PSQL Programmer's Guide』のページ サイズの選択 を参照してください。

アプリケーションで、8,000,000 レコード、20 バイトのキーおよび 512 バイトのページ サイズを使用すると仮定します。MicroKernel は各インデックス ページに 8 個から 18 個の間のキー値を書き込みます。こうすると、各ページで必要となる物理ストレージ量が減ります。ただし、8,000,000 レコードにインデックスを付けると、およそ 7 階層の深さの B ツリーが作成され、ほとんどのキー ページが 7 番目のレベルに属します。パフォーマンスは低下します。

ページ サイズ 4096 バイトを使用すると、データベース エンジンは各インデックス ページに 72 から 145 個のキー値を書き込みます。B ツリーはおよそ 4 レベルの深さで済み、Rebuild が新しいキー値を挿入するときに調べるページ数が少なくなります。パフォーマンスは向上しますが、物理ストレージをより必要とします。

インデックス数もインデックス構築の速度に影響します。一般的に、インデックス数が多いほどビルド処理には時間がかかります。インデックスの構築に必要な時間は、B ツリーの深さの増加により幾何級数的に増加します。

リビルド処理からの情報はテキスト ログ ファイルに追加されます。ログ ファイルはデフォルトで現在の作業ディレクトリに保存されます。

CLI Rebuild を Windows、Linux、および OS X で実行した場合、デフォルトのファイル名は rbldcli.log です。デフォルトを使用せず、ログ ファイルの場所と名前を指定することもできます。-lfile パラメーターを参照してください。

テキスト エディターを使用してログ ファイルを確認できます。ログ ファイルに記録される情報は、以下のとおりです。

このセクションでは、Rebuild ユーティリティ のグラフィカル ユーザー インターフェイス（GUI）のオブジェクトについて説明します。

この画面を使用すると、リビルドのリストにファイルを追加することができます。

この画面を使用すると、ファイルのリビルドに関するオプションを選択することができます。

この画面を使用すると、リビルドの進行状況を知ることができます。また、リビルド処理完了後にログ ファイルを表示することができます。

以下の Rebuild の作業が行えます。

PSQL Control Center のメニューから［ツール｜Rebuild］を選択するか、オペレーティング システムの［スタート］メニューまたはアプリ画面から Rebuild にアクセスします。

Rebuild コマンド ライン ユーティリティの名前は、Windows の場合は rbldcli.exe、Linux および OS X の場合は rbldcli です。以下のコマンド ライン Rebuild ユーティリティ作業が行えます。

parameter オプションには、このユーティリティで使用するパラメーターを指定します。パラメーターはどのような順序でも使用できます。各パラメーターの前にはハイフン（-）を付けます。ハイフンの後、または、1 文字のパラメーターおよびパラメーター値の後にスペースを入れないでください。

parameter は以下のように定義されています。

File および @command_file は次のように定義されます。

parameter、file および @command_file は、コマンド ライン パラメーターに定義されています。

以下の例はエラー時も処理を続けます。ページ サイズは 4096 バイトに設定され、リビルドされたファイルはサーバー上の別のディレクトリに保存します。

parameter、file および @command_file は、コマンド ライン パラメーターに定義されています。

以下の例はエラー時も処理を続けます。ページ サイズは 4096 バイトに設定され、リビルドされたファイルはサーバー上の別のディレクトリに保存します。

Rebuild は、ファイルごとに処理されたレコード数を画面上に表示します。1 度に 50 レコードずつ増加します。さらに、Rebuild はこれらの情報をテキスト ログ ファイルに書き込みます。ログ ファイルを参照してください。