データ ファイルの変換
データ ファイル互換性を維持する
PSQL には、Btrieve ファイルを、PSQL エンジンの最新バージョンで利用できるようにする変換するツールがあります。以下のトピックでは、ツールの概念と変換を行うための各種ツールについて説明します。
Rebuild ツールの概念
Rebuild ツールを使用すると、MicroKernel データ ファイルと辞書ファイルに対して以下の操作を行うことができます。
•旧ファイル形式を新しい PSQL 形式に変換する
•新しいファイル形式を 6.x 形式より古くない形式に変換する
•同じファイル形式（6.x、7.x、8.x、9.5、または 13.0）を使用してファイルをリビルドする
•ファイルにインデックスを追加する
•ファイルのページ サイズを変更する
•ファイルをリビルドしてシステム データとキーまたはキーなしのシステム データを含める
•Rebuild で使用するログ ファイルの場所と名前を指定する
データベースで辞書ファイル（DDF）を使用している場合は、データ ファイルだけでなくこれらもリビルドする必要があります。
データ ファイルのリビルドの概念についてより理解を深めるため、以下のセクションをお読みください。
Rebuild ツールの使用についての情報は、以下のトピックを参照してください。
サポートされるプラットフォーム
Rebuild には 2 つの様式があります。1 つはWindows 用の 32 ビット GUI バージョンで、もう 1 つは Linux、OS X、Raspbian および Windows 用のコマンド ライン バージョンです。
Rebuild ツールの GUI のリファレンスおよび
CLI バージョン Rebuild 操作を参照してください。
Linux、OS X および Raspbian CLI Rebuild
Rebuild は、Linux、OS X および Raspbian では rbldcli というプログラムとして実行されます。デフォルトでは、このプログラムは /usr/local/psql/bin にあります。
Windows CLI Rebuild
Rebuild は Windows では rbldcli.exe というプログラムとして実行されます。これらのファイルはデフォルトで、Program Files ディレクトリにインストールされます。
ファイル形式
現在のデータベース エンジンはいくつかの古いデータ形式や辞書ファイル形式と互換性を保っていますが、最新の機能を利用するためにファイルを最新の形式に変換したい場合があります。次の表に、旧形式から新しい形式に変換する一般的な理由を挙げます。
表 76 Rebuild ツールによる変換
変換前のファイル形式 | 変換後のファイル形式 | 変換の理由 |
|---|
9.5 | 13.0 | ファイルのサイズ（テラバイト単位） |
9.0 | 9.5 | 120 個以上のセグメント キーと最大 256 GB のファイル サイズ。 |
8.x | 9.x | 最大 128 GB のファイル サイズのサポートの追加。 |
8.x | 8.x | ファイルから削除レコードのスペースを除去する、ページ サイズを変更する、またはシステム データを追加する。 |
v8.x より前 | 8.x | 挿入（Insert）、更新（Update）、削除（Delete）パフォーマンスの向上（Turbo Write Accelerator によっても実現）。 |
7.x | 7.x | 変換前のファイルには、システム キーがない。 |
v7.x より前 | 7.x | バージョン 7.x の機能の利用および全般的なパフォーマンスの向上。 |
v6.0 より前 | 6.x | バージョン 6.x の機能の利用および全般的なパフォーマンスの向上。バージョン 6..x のエンジンを実行している場合にのみ、このオプションを使用します。 |
コマンド ラインの Rebuild ユーティリティを使用してできたファイル形式は、-f パラメーターによって異なります。-f パラメーターを指定しないと、Rebuild は MicroKernel エンジンの［作成ファイルのバージョン］設定の値を使用します。たとえば、［作成ファイルのバージョン］の値が 8.x の場合、バージョン 7.x のファイルに対して Rebuild ツールを実行すると、このファイルは バージョン 8.x の形式に変換されます。
Rebuild ユーティリティを実行する前に、変換するデータ ファイルをすべてバックアップしておくことをお勧めします。これは、元のファイルと同じ場所にリビルドする場合には特に重要です（この場合リビルドされたファイルは元のファイルを置き換えます）。バックアップ コピーを取っておけば、必要な場合に元のファイルを復元することができます。バックアップを確実に実行するためには、以下のいずれかの操作を行います。
•バックアップを実行する前にすべてのデータ ファイルを閉じます。
•Continuous オペレーションを使用します（バックアップ中のみ）。
メモ：Continuous オペレーション モードになっているファイルで Rebuild ユーティリティを実行することはできません。
テンポラリ ファイル
Windows では、Rebuild は TMP システム環境変数で指定されたディレクトリにテンポラリ ファイルを作成します。デフォルトで、Linux、OS X および Raspbian では Rebuild は出力ディレクトリ（-b オプションが使用されていない場合はソース ディレクトリ）にテンポラリ ファイルを作成します。このため、テンポラリ ファイル ディレクトリには元のファイルと新しいファイルの両方を格納するために十分なディスク容量が必要です（Rebuild の実行中）。Rebuild GUI バージョンの［出力ディレクトリ］オプションを使用するか、CLI バージョンの -b オプションを使用して、これらのファイルを別のディレクトリに保存するように指定できます。
通常、変換が終了するとテンポラリ ファイルは自動的に削除されます。ただし、停電などの重大な障害が発生した場合は、テンポラリ ファイルが削除されないことがあります。このような場合は、手動で以下のタイプのテンポラリ ファイルを削除する必要があります。
プラットフォーム | テンポラリ ファイル名 |
|---|
Linux、OS X、Raspbian | _rbldxxxxxx、ここで、xxxxxx はランダムな 6 個の文字です。注意：Rebuild 実行モジュールである rbldcli を削除しないようにしてください。 |
Windows | _rbldx、x は 数字です。 |
Rebuild 処理の最適化
Rebuild はデータベース エンジンに Btrieve 呼び出しを行います。そのため、データベース エンジンの構成設定と処理メモリの容量がリビルド処理のパフォーマンスに影響を与えます。これは特に、サイズの大きなデータ ファイルをリビルドする際の所要時間に関しては顕著です。
一般的に、インデックスを構築するのはデータ ページを構築するよりはるかに時間がかかります。インデックスを多数持つデータ ファイルがある場合、同じファイルでインデックスが少ないものに比べ、ファイルを構築するのにより多くの時間を要します。
リビルドの処理時間には以下の項目が影響します。
CPU 速度およびディスク速度
CPU（中央処理装置）の速度および物理ストレージ ディスクへのアクセス速度が、リビルドの処理時間に影響します。一般的に、これらの両方の速度が速いほどリビルド処理も速く行われます。ディスク速度は、メモリに全体が入りきらない大きなファイルのリビルドではより重要になります。
ヒント： ギガバイトの範囲内のサイズが大きいファイルでは変換に数時間かかる場合があります。複数のデータベース エンジンが使用できる場合、リビルド処理をいくつかのマシンの CPU 間で分担したいと考えるでしょう。たとえば、すべてのファイルの中からいくつかずつを、データベース エンジンがインストールされている各マシンにコピーし、リビルド処理が終わったらファイルをコピーして元の場所にに戻します。
メモリ量
Rebuild では、デフォルトの方法ともう 1 つの方法の 2 つの方法を用いてファイルをリビルドすることができます。
-m<0 | 2> パラメーターを参照してください。選択する方法は、使用できるメモリの量によって決まります。デフォルトの方法（-m2）では、利用可能なメモリがあれば、Rebuild は以下の手順を行います。
1 元のファイルに定義されているのと同じレコード構造とインデックスを持つ空のデータ ファイルを新規作成します。
2 新しいファイルからすべてのインデックスを削除します。
3 新しいファイルにインデックスなしですべてのデータをコピーします。
4 以下の処理でインデックスを追加します。
a. 元のファイルの特定のキーについて、Extended Step オペレーションを使用してメモリ バッファーにできるだけ多くのキー値を読み込みます。
b. メモリ バッファーの値をソートし、ソートされた値をテンポラリ ファイルに書き出します。
c. 手順
a および
b を繰り返し、各レコードのキー値を処理します。
これで、テンポラリ ファイルにはいくつかのキー値が設定されました。それぞれのキー値は個別にソートされています。
5 データのセットをインデックス ページにマージし、各ページの容量いっぱいまで書き込みます。各インデックス ページはデータ ファイルの最後に追加され、ファイル長は拡大されます。
6 残りの各キーについて、手順
4 および
5 を繰り返します。
この処理中にテンポラリ ファイルのオープンや書き込みに失敗などのエラーが発生した場合、Rebuild はもう 1 つの方法を用いてファイルのビルドを最初からやり直します。
デフォルトの方法には存在するメモリが足りない場合やデフォルトの方法で処理中にエラーが発生した場合、Rebuild はもう 1 つの方法（-m0）を使用します。
1 元のファイルに定義されているのと同じレコード構造とインデックスを持つ空のデータ ファイルを新規作成します。
2 新しいファイルからすべてのインデックスを削除します。
3 新しいファイルにインデックスなしですべてのデータをコピーします。
4 以下の順序でインデックスを追加します。
a. 元のファイルの特定のキーについて、Step Next オペレーションを使用して、1 度に 1 レコードを読みます。
b. レコードからキー値を抽出し、インデックスの適切な場所に挿入します。この処理では、キー ページがいっぱいになると必然的にページの分割が行われます。
c. 手順
a および
b を繰り返し、各レコードのキー値を処理します。
5 残りの各キーについて、手順
4 を繰り返します。
もう 1 つの方法は、デフォルトの方法に比べて一般的にはるかに時間がかかります。多数のインデックスを持つサイズの大きなファイルがある場合、2 つの方法の差は何時間から何日にまで及ぶことがあります。Rebuild が必ずデフォルトの方法を使用するようにする唯一の方法は、十分な使用可能メモリを確保することです。設定プロパティのいくつかは、利用可能なメモリ量に影響を与えます。
必要なメモリ量を見積もる式
以下の式は、速い方法でファイル インデックスをリビルドするのに必要な連続した空きメモリの最適かつ最小の量を見積もります。最適なメモリ量は、RAM 上のすべてのマージ ブロックを格納するのに十分な量です。最小のメモリ量は、RAM 上の 1 つのマージ ブロックを格納できる量です。
キー長 = ファイル上で最大のキーのすべてのセグメントの合計サイズ
キー オーバーヘッド = 8（キー タイプがリンク重複でない場合）、12（キー タイプがリンク重複の場合）。
レコード数 = ファイル内のレコード数
最適なメモリ バイト = (((キー長 + キー オーバーヘッド) * レコード数) + 65536) / 0.6
最小メモリ バイト = 最適メモリ バイト / 30
たとえば、ファイルに 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 以下です。
必要なブロック数 = Round Up (最適なメモリ バイト / 割り当てられたブロック)
割り当てられたブロック サイズは以下の値以上である必要があります。
((2 * 最大キー数 + 1) * (キー長 + キー オーバーヘッド)) * 必要なブロック数
ページ サイズ 512 バイト、12.45 MB のブロック割り当てに成功したと仮定すると、必要なブロック数は次のようになります。
必要なブロック数 = 373,500,000 / 12,450,000 = 30
最初の条件に合っています。
割り当てられたブロック サイズの値は次のようになります。
最大キー数 = (512-12) / 28 = 18
(((2 * 18) + 1) * (20 + 8)) * 9 = 9324
割り当てられたブロック（12,500,000 バイト）は 9324 バイトより大きいですか? そうであれば 2 番目の条件に合っています。インデックス キーはテンポラリ ファイルに 12.45 MB ずつの塊として書き込まれ、メモリに格納され、次にインデックスに書き込まれます。
ソート バッファー サイズ
この設定は、ランタイムでインデックスを作成中に MicroKernel がソートのために動的に割り当てる、または割り当てを解除するメモリの最大容量を指定します。
設定がゼロ（デフォルト）の場合、Rebuild は最適なメモリ バイト値を計算し、その値に基づいてメモリを割り当てます。メモリ割り当てに成功したら、割り当てられたブロックのサイズは少なくとも最小メモリ バイトで定義された値になります。
必要なメモリ量を見積もる式を参照してください。
設定がゼロ以外の値で、値が計算された最小メモリ バイトより小さい場合、Rebuild はその値を使用してメモリを割り当てます。
最後に、Rebuild は割り当てるべきメモリ量と実際に利用可能な量の 60% とを比較します。そして、その 2 つのうち小さい方を割り当てようとします。メモリ割り当てに失敗した場合、Rebuild は最後に割り当てようとしたメモリ量の 80% の割り当てを試みることを続けます。メモリ割り当てに完全に失敗した場合（これは最小メモリ バイトよりメモリ量が少ないことを意味します）、Rebuild はファイルのリビルドにもう 1 つの方法を使用します。
MicroKernel の最大メモリ使用量
この設定は、総物理メモリに対して MicroKernel が消費できるメモリの割合を指定します。MicroKernel による L1、L2、およびその他すべてのメモリの使用量が含まれます。リレーショナル エンジンによる使用量は含まれません。
リビルドするサイズの大きなファイルがある場合、［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、および Raspbian で実行した場合、デフォルトのファイル名は rbldcli.log です。デフォルトを使用せず、ログ ファイルの場所と名前を指定することもできます。
-lfile パラメーターを参照してください。
ログはテキスト エディターで読み込むこともできます。記録される情報は、以下のとおりです。
•リビルド処理の開始時刻
•コマンド ラインで指定されたパラメーター
•ステータス コードおよびエラー説明（エラーが発生した場合）
•処理中のファイル
•処理に関する情報（ページ サイズの変更など）
•処理済みレコード総数
•再構築されたインデックス総数（-m2 処理方法が使用された場合）
•リビルド処理の終了時刻
•処理のステータス（たとえば、ファイルのリビルドが成功したかどうかなど）
Rebuild ツールの GUI のリファレンス
このトピックでは、Rebuild ツールのグラフィカル ユーザー インターフェイスのオブジェクトについて説明します。
ファイル オプションの画面
この画面を使用すると、リビルドのリストにファイルを追加することができます。
GUI のオブジェクト | 説明 | 関連情報 |
|---|
選択ファイル | リビルドするためにリストされたデータ ファイルおよび辞書ファイル。［追加］ボタンを使用して選択したものです。 | |
［追加］ボタン | リビルドするファイルのリストにデータ ファイルまたは辞書ファイルを追加します。 | |
［削除］ボタン | 選択したデータ ファイルまたは辞書ファイルをリストから削除します。 | |
［クリア］ボタン | 選択されたデータ ファイルおよび辞書ファイルのリスト全体をクリアします。 | |
Rebuild オプションの画面
この画面を使用すると、ファイルのリビルドに関するオプションを選択することができます。
図 38 Rebuild ツールのファイル オプション
GUI のオブジェクト | 説明 | 関連情報 |
|---|
システム データ | Rebuild 時にファイルにシステム データ キーを作成するかどうかを指定します。 システム データはトランザクション一貫性保持とトランザクション ログでは必須です。 システム データおよびキー データを使用してファイルをリビルドするかどうかを指定します。MicroKernel は、ユーザー定義のユニークなキーが存在しないとき、システム データを含まないファイルのロギングを行うことができません。 | |
ページ圧縮 | ファイルにページ圧縮を使用するかどうかを指定します。選択肢は、"既存を保持"、"圧縮 On"、および "圧縮 Off" です。"既存を保持" を選択すると、ファイルにページ圧縮が設定されている場合は、それを維持します。 | ページ圧縮には 9.5 以上のファイル形式であることが必要です。 |
レコード圧縮 | ファイルにレコード圧縮を使用するかどうかを指定します。選択肢は、"既存を保持"、"圧縮 On"、および "圧縮 Off" です。"既存を保持" を選択すると、ファイルにレコード圧縮が設定されている場合は、それを維持します。 | |
エラー時続行 | リビルド処理中にエラーが発生した場合に、Rebuild の処理を続行するかどうかを決定します。このオプションを選択すると、エラーが発生した場合でも、ツールは次のファイルの処理を続行します。ツールにより、MicroKernel データ ファイル以外のファイルであることやその他のエラーが発生したことが通知されますが、データ ファイルのリビルドは続行されます。このオプションを選択しない場合、エラーが検出されたときにはリビルド処理が停止します。
このオプションは、リビルド ファイルにワイルドカード文字を指定した場合に効果的です。 | |
終了時に設定を保存 | このダイアログ ボックスの現在の設定を保存して、次回のリビルドのセッションでもこの設定を使用できるようにします。 | |
キー番号 | ファイルのリビルド処理を行う際にツールが読み込むキーを指定します。このオプションで［NONE］を選択した場合、ファイルの複製、インデックスの削除、新しいファイルへのレコードのコピーが行われた後、インデックスがリビルドされます。この方法は、キー番号を指定するよりも短時間でリビルドでき、ファイルのサイズも小さくなるため、できる限りこの方法を使用するようにしてください。
この方法では、元のファイルとは異なる物理順序のレコードを含む新規ファイルが作成されることがあります。
キー番号を指定した場合には、インデックスの削除と置き換えは行われず、ファイルの複製とコピーが行われます。この方法は、［NONE］を指定するよりもリビルドに時間がかかりますが、インデックスをリビルドしたくない場合には、この方法を使用します。 | •『 PSQL Programmer's Guide』の キー属性 |
ファイル フォーマット | 以前の Rebuild ツールは、エンジンのファイル互換性プロパティにある［作成ファイルのバージョン］設定に基づくファイル バージョンを使用していました。 最新の Rebuild ツールを使用すると、その設定とは無関係にファイル バージョンを指定することができます。 | |
ページ サイズ | 新しいファイルのページ サイズをバイト単位で指定します。"EXISTING"、"最適化（ディスク スペース）"、"最適化（データ アクセス）"のいずれかを選択するか、サイズをバイト単位で指定します。"EXISTING" を選択した場合は現在のページ サイズが使用されます。何らかの理由で元のサイズが使用できない場合は、ツールにより、ほかのページ サイズに変更されます。 たとえば、ページ サイズが 1024 で、24 個のキーを持つ v5.x ファイルがあるとします。Btrieve v6.0 以降のバージョンでは、ページ サイズが 1024 の場合、23 個までのキーのみをサポートするため、ファイルには、ツールによって新しいページ サイズが自動的に割り当てられ、ログ ファイルに通知メッセージが記述されます。 | •ディスク スペースの最適化については、『 PSQL Programmer's Guide』の ページ サイズの選択を参照してください。 |
出力パス | リビルドされたファイルの保存先となる別の場所を指定します（デフォルトの場所は現在のディレクトリです）。必ず既存のディレクトリを指定してください。
このオプションを使用すれば、サイズの大きいファイルを別のサーバーでリビルドすることができます。MicroKernel とその通信コンポーネントが、リビルドされたファイルを格納するサーバーでロードされている必要があります。パスには、ワイルドカード文字を使用しないでください。
出力ディレクトリの場所が元のファイルの場所と異なる場合、元のファイルはリビルド中に削除されません。出力ディレクトリが元のファイルと同じディレクトリである場合には、リビルドの完了時に元のファイルは削除されます。 DefaultDB w/ DB security: ［名前付きデータベースの管理］で指定したデータベースのファイルの場所以外ではリビルドできません。 | |
ログ ファイル | リビルド ログ ファイルの場所を指定します（デフォルトの場所は現在の作業ディレクトリです）。パスには、ワイルドカード文字を使用しないでください。 | |
Rebuild ツールの使用
以下のトピックでは、Rebuild ツールの GUI バージョンとコマンド ライン バージョンについて説明します。
GUI バージョン Rebuild 操作
►GUI Rebuild ウィザードを開始するには
PSQL Control Center のメニューから［ツール｜Rebuild］を選択するか、オペレーティング システムの［スタート］メニューまたはアプリ画面から Rebuild にアクセスします。
►ファイルをリビルドするには
1 Rebuild の開始画面で［次へ］をクリックすると、ファイルの選択画面が表示されます。
2 ［追加］をクリックしてリビルドするデータ ファイルまたは辞書ファイルを選択します。複数のファイルを一度に選択することもできます。
図 39 ファイルの選択用ダイアログ ボックス
元のファイルと同じディレクトリでファイルをリビルドする場合、元のファイルはリビルド完了後に削除されます。新しいファイルを別のディレクトに置く場合は、元のファイルは削除されません。
3 目的のファイルを追加したら、［次へ］をクリックします。
5 ［次へ］をクリックしてリビルド処理を開始します。
Rebuild は処理に関する情報をレポートします。リビルド処理が完了すると、成功か失敗かが表示され［ログ ファイルを表示する］ボタンが有効になります。
6 結果を表示するには、［ログ ファイルを表示する］をクリックします。ログ ファイルの内容は、オペレーティング システムのデフォルトのテキスト エディターで表示されます。
Rebuild では、変換を試みたすべてのファイルについてログ ファイルに書き込みます。［エラー時続行］の設定を無効にした場合、ログ ファイルには、エラーが発生した時点までの情報が記録されます。リビルドが失敗した場合、ログ ファイルにはそのエラーの原因を説明するメッセージが記録されます。
7 ファイルのリビルドが完了してログ ファイルを見終わったら、［完了］をクリックします。
CLI バージョン Rebuild 操作
Rebuild コマンド ライン ツールの名前は、Windows の場合は rbldcli.exe、Linux、OS X および Raspbian の場合は rbldcli です。以下のトピックでは、コマンド ライン構文と典型的な Rebuild 操作について説明します。
コマンド ライン パラメーター
パラメーター（parameter）には、このツールで使用する設定を指定します。パラメーターはどのような順序でも使用できます。各パラメーターの前にはハイフン（-）を付けます。ハイフンの後、または、1 文字のパラメーターおよびパラメーター値の後にスペースを入れないでください。
メモ：Linux、OS X および Raspbian では、パラメーターで大文字小文字が区別されます。
parameter は以下のように定義されています。
-c | エラーが発生しても、次のデータ ファイルまたは辞書ファイルのリビルドを続行するように、Rebuild に指示します。ツールにより、MicroKernel データ ファイル以外のファイルであることや MicroKernel ファイルでエラーが発生したことが通知されますが、データ ファイルのリビルドは続行されます。エラーはログ ファイルに書き出されます。 ログ ファイルを参照してください。 ヒント：このパラメーターは、混合するファイルのセットに対してワイルドカード文字（*.*）を指定した場合に特に便利です。混合ファイルのセットとは、MicroKernel ファイルと非 MicroKernel ファイルの組み合わせです。Rebuild は非 MicroKernel ファイルを処理するたび（または MicroKernel ファイルのエラー時）にエラーを報告しますが、処理を続行します。 |
-d | -d を指定すると、バージョン 6.0 より前の補足インデックス（重複が可能）を 6.x、7.x または 8.x のリンク重複キーのあるインデックスに変換します。 このパラメータを指定しないと、Rebuild はインデックスを繰り返し重複キーとして保持します。 MicroKernel エンジンを介してのみデータ ファイルにアクセスし、かつファイルに比較的多数の重複キーがある場合には、-d オプションを使用して Get Next オペレーションや Get Previous オペレーションのパフォーマンスを向上させることができます。 |
-m<0 | 2> | "m" パラメータは処理方法を示します。Rebuild はこのパラメータが指定されているかどうかによって処理方法を選択します。このパラメーターを指定しない場合、Rebuild は以下のように処理します。 •十分なメモリが使用可能である場合は、-m2 をデフォルトの処理方法とします。 •メモリが不十分である場合はもう 1 つの方法の -m0 を使用します。 選択した方法によって影響を受けるメモリの量については、 メモリ量を参照してください。 |
0 | インデックスの削除や置き換えを行うことなくデータ ファイルまたは辞書ファイルの複製を作成してコピーします。この方法は -m2 の方法に比べて時間がかかります。インデックスをリビルドしない場合には、この方法が使用できます。 -m0 を使用すると、各キー ページの使用率が 55% から 65% のファイルが作成されます。このファイルは書き込み用により最適化されていて、読み取りには最適化されていません。状況によりますが、リビルドにかける時間の余裕がある場合は、書き込み用に最適化されるリビルドを行うのが望ましいでしょう。 |
2 | データ ファイルまたは辞書ファイルの複製を作成し、インデックスを削除して新しいファイルにレコードをコピーした後、インデックスをリビルドします。この方法は、-m0 の方法よりも短時間でリビルドでき、ファイルのサイズも小さくなります。 -m2 の方法では、元のファイルとは異なる物理順序のレコードを含むファイルが作成されることがあります。 -m2 の方法を使用して作成されるファイルのキー ページは 100% 使用済みです。こうすると、ファイルを読み取り用に最適化することができます。 |
-p<D | P | bytes> | •ページ サイズをディスク ストレージまたは処理に最適化します。またはリビルドするファイルに特定のページサイズを指定します。 •このパラメーターを指定しないと、Rebuild は元のファイルのページ サイズを使用します。元のファイルのページ サイズでは現在のデータベース エンジンで動作しない場合、Rebuild はページ サイズを変更し、変更したことを示す情報メッセージを表示します。たとえば、5.x などの古いファイル形式ではページ サイズが 1024 でキーを 24 個持つファイルをサポートしていました。8.x のファイル形式では、ページ サイズ 1024 で 23 個のキーしかサポートしません。したがって、Rebuild は 8.x ファイルを作成する場合、異なるページ サイズを選択します。 •データベース エンジンでは、指定されたページ サイズを無視してそのサイズを自動的に更新することがあります。たとえば、バージョン 9.5 のファイル形式の場合、1536 や 3072 などの奇数ページ サイズはサポートされません。データベース エンジンでは効率を良くするために、ページ サイズを次の有効なページ サイズへ自動的に更新します。旧バージョンのファイル形式の場合、データベース エンジンは追加の条件に基づいてページ サイズを更新することができます。 |
D | ページ サイズをディスク ストレージに最適化します。 『 PSQL Programmer's Guide』の ページ サイズの選択を参照してください。 |
P | 処理に対して最適化します（つまり、そのデータにアクセスするアプリケーションのための最適化です）。-pP では、Rebuild はデフォルトのページ サイズ 4096 バイトを使用します。 |
bytes | 新しいファイルのページ サイズをバイト単位で指定します。9.0 より前のファイル バージョンの場合、有効な値は 512、1024、1536、2048、2560、3072、3584 および 4096 です。ファイル バージョン 9.0 の場合、上記と同じ値に 8192 が加えられます。ファイル バージョン 9.5 の場合、有効な値は 1024、2048、4096、8192 および 16384 です。ファイル バージョン 13.0 の場合、有効な値は 4096、8192 および 16384 です。 |
-bdirectoryname | リビルドしたファイルに別の場所を指定します。別のサーバー上の場所も指定できます。デフォルトの場所は、データ ファイルのあったディレクトリです。必ず存在する場所を指定してください。Rebuild はディレクトリを作成しません。また、そのディレクトリはデータベース エンジンが起動しているマシン上のディレクトリでなければなりません。 完全修飾したパスまたは相対パスのいずれも使用できます。directoryname にはワイルドカード文字を使用しないでください。 ローカル サーバーの場合は、MicroKernel データベース エンジンとメッセージ ルーターがロードされている必要があります。リモート サーバーの場合は、MicroKernel データベース エンジンと通信コンポーネントがロードされている必要があります。 このパラメーターを指定しないと、リビルドされたファイルによって元のデータ ファイルが置き換えられます。元のファイルのコピーは保持されません。 このパラメーターを指定すると、リビルドされたファイルは指定の場所に置かれ、元のファイルが保持されます。これに関する例外があります。指定した場所に同じ名前のデータ ファイルが既に存在する場合です。元のファイルと同じ名前のファイルが指定された場所に含まれていた場合、Rebuild ではエラーが起こります。たとえば、folder1 というディレクトリにある mydata.mkd をリビルドしようとするとします。リビルドされたファイルを foder2 というディレクトリに保存したいとします。気付かないうちに folder2 にも mydata.mkd が存在していた場合は、Rebuild でエラーが起こり、ログ ファイルを調べるよう通知されます。 メモ：指定した場所（このパラメーターを指定しなかった場合は元のファイルの場所）に対して、ファイルを作成するアクセス権があることを確認してください。 |
-knumber | キー番号を指定します。Rebuild はこれを使って元のファイルを読み、リビルドしたファイルを並べ替えます。このパラメーターを指定しないと、Rebuild はもとのファイルを物理順に読み、リビルドしたファイルも物理順で作成します。 |
-s[D | K] | リビルドしたファイルに、元のファイルの既存のシステム データとキーを保持します。このパラメーターを指定しないと、Rebuild はシステム データとキーをリビルドしたファイルに含めません。 |
D | リビルドしたファイルにシステム データを含めます。システム データにはインデックスが作成されません。 |
K | リビルドしたファイルにシステム データとキーを含めます。システム データにはインデックスが作成されます。 |
-lfile | Rebuild のログ ファイルにファイル名を指定します。オプションでパスの場所を指定することができます。デフォルトのファイル名は、Windows、Linux、OS X、および Raspbian では rbldcli.log です。デフォルトの場所は現在の作業ディレクトリです。 以下の条件が適用されます。 •パスの場所は既に存在している必要があります。Rebuild はパスの場所を作成しません。 •ファイル名を指定しないでパスの場所を指定した場合、Rebuild はこのパラメーターを無視してデフォルトのファイル名と場所を使用します。 •パスの場所を指定しないでファイル名を指定した場合、Rebuild はデフォルトの場所を使用します。 •指定した場所に対する読み取りおよび書き込みのアクセス権を持っている必要があります。ファイルのアクセス権のためにログ ファイルを作成できなかった場合、Rebuild はデフォルトの場所を使用します。 |
-pagecompresson | file のページ圧縮をオンにすると、以下の条件が設定されます。 •データベース エンジンのバージョンは 9.5 以上 •作成ファイルのバージョン設定は 0950（9.5）以上 |
-pagecompressoff | file のページ圧縮をオフにします。このパラメーターは、 file にページ圧縮が指定されていない場合は無効です。 |
-recordcompresson | |
-recordcompressoff | file のレコード圧縮をオフにします。このパラメーターは、 file にレコード圧縮が指定されていない場合は無効です。 |
-f<6 | 7 | 8 | 9 | 95|13> | リビルド後のデータ ファイルまたは辞書ファイルのファイル形式を指定します。ファイル形式は、バージョン 6.x、7.x、8.x および 9.x が使用できます。次の例ではファイルを 9.0 形式でリビルドします。 rbldcli -f9 <file_path>\class.mkd 次の例ではファイルを 9.5 形式でリビルドします。 rbldcli -f95 <file_path>\class.mkd 指定しない場合、Rebuild は MicroKernel の［作成ファイルのバージョン］設定オプションに指定されている値を使用します。 メモ 1：現在のデータベース エンジンでサポートされているバージョンより新しいファイル形式を指定した場合、Rebuild はそのエンジンでサポートされている最新のファイル形式を使用します。Rebuild はこれに関してはエラーもメッセージも報告しません。 メモ 2：Rebuild はインデックスのデータ型を変換しません。ファイルを古いデータベース エンジンで使用するために古いファイル形式にリビルドする場合、エンジンが使用されているデータ型をサポートしているかどうかを確認してください。必要に応じ、アプリケーションとそのデータベース エンジンによって、手作業でデータ型を調整する必要があります。 例 1：データ ファイルに WZSTRING データ型を使用するインデックス フィールドが含まれています。データ ファイルを 6.x 形式にリビルドする場合、WZSTRING データ型は変換されません。このデータ ファイルを Btrieve 6.15 エンジンで使用することはできません。このエンジンは WZSTRING データ型をサポートしません。 例 2：データ ファイルに NULL が含まれています。データ ファイルをを 7.x ファイル形式にリビルドします。真の NULL は変換されません。このデータ ファイルを PSQL 7 エンジンで使用することはできません。このエンジンは 真の NULL をサポートしません。 |
-uiduname | セキュリティが設定されているデータベースにアクセスする権限を与えられたユーザー名を指定します。 |
-pwdpword | uname で識別されるユーザーのパスワードを指定します。uname が指定された場合、pword は必ず指定する必要があります。 |
-dbdbname | セキュリティが設定されたデータベース名を指定します。 |
File および @command_file は次のように定義されます。
file | 変換するデータ ファイルおよび辞書ファイルを指定します。元のファイルが現在の作業ディレクトリにない場合は、完全修飾パスまたは相対パスのいずれかを使用して場所を含めてください。ファイル名にはアスタリスク（*）ワイルドカード文字を使用して、複数のファイルを指定することができます。 メモ：元のファイルにオーナー ネームが含まれている場合、Rebuild はリビルドしたファイルにオーナー ネームとレベルを適用します。 |
@command_file | Rebuild で実行されるコマンド ファイルを指定します。1 つのコマンド ファイルに複数の項目を指定できます。コマンド ファイルの各項目には、コマンド ライン パラメーター（ある場合）と変換するファイルのセットを指定し、その後に <end> または ［end］ を続けます。 変換するファイルを指定する場合には、完全なディレクトリ名を使用します。ファイル名にはアスタリスク（*）ワイルドカード文字を使用できます。 次に、Rebuild コマンド ファイルの例を示します。 –c d:\mydir\*.*<end>
–c –p1024 e:\dir\*.*<end>
–m0 –k0 d:\ssql\*.*<end> |
►Rebuild を Linux、OS X および Raspbian で実行するには
1 ログインするアカウントが PSQL ユーティリティを実行する権限を持っていることを確認してください。
デフォルトでは、ユーティリティを実行するには
psql ユーザーとしてログインする必要があります。
psql ユーザーにはパスワードがありません。
su コマンドを使用することによって
root アカウントでのアクセスのみを行うことができます。
psql 以外のアカウントからこのユーティリティを使用するには、まず
.bash_profile を変更する必要があります。『
Getting Started with PSQL』の
Linux、OS X、Raspbian での PSQL のアカウント管理を参照してください。
2 /usr/local/psql/bin ディレクトリに移動します。
3 プロンプトに、次のどちらかのコマンドを入力します。
rbldcli [–parameter ...] file
または
rbldcli @command_file
parameter、
file、および
@command_file は、
コマンド ライン パラメーターに定義されています。
使い方の例
以下の例はエラー時も処理を続けます。ページ サイズは 4096 バイトに設定され、リビルドされたファイルはサーバー上の別のディレクトリに保存します。
rbldcli -c -p4096 -b/usr/local/psql/tmp /usr/local/psql/data/DEMODATA/*.mkd
►Rebuild を Windows で実行するには
1 PSQL がインストールされているマシンで、コマンド プロンプトを開きます。
2 状況により、\bin ディレクトリをプログラム ファイルをインストールしたディレクトリに変更します。その場所が Path システム変数に含まれている場合は、この操作は不要です。
3 プロンプトに、次のどちらかのコマンドを入力します。
rbldcli [–parameter ...] file
または
rbldcli @command_file
parameter、
file、および
@command_file は、
コマンド ライン パラメーターに定義されています。
使い方の例
以下の例はエラー時も処理を続けます。ページ サイズは 4096 バイトに設定され、リビルドされたファイルはサーバー上の別のディレクトリに保存します。
rbldcli -c -p4096 -bc:\dbtemp c:\datafiles\*.mkd
►リビルド中のファイルの進行状況を見るには
Rebuild は、ファイルごとに処理されたレコード数を画面上に表示します。1 度に 50 レコードずつ増加します。さらに、Rebuild はこれらの情報をテキスト ログ ファイルに書き込みます。
ログ ファイルを参照してください。