データ ファイルの変換
PSQL ファイル互換性を維持する
PSQL には、PSQL ファイルを、PSQL エンジンの最新バージョンで利用できるようにする変換するツールがあります。この章では、これらのツールの概要、その使用目的と使用方法を説明します。以下の項目について説明します。
Rebuild ユーティリティの概念
Rebuild ユーティリティを使用すると、MicroKernel データ ファイルと辞書ファイルに対して以下の操作を行うことができます。
データベースで辞書ファイル(DDF)を使用している場合は、データ ファイルだけでなくこれらもリビルドする必要があります。
データ ファイルのリビルドの概念についてより理解を深めるため、以下のセクションをお読みください。
Rebuild ユーティリティの使用についての情報は、以下のセクションを参照してください。
サポートされるプラットフォーム
Rebuild には 2 つの様式があります。1 つはWindows 用の 32 ビット GUI バージョンで、もう 1 つは Linux、OS X、Raspbian および Windows 用のコマンド ライン バージョンです。Rebuild ユーティリティ の GUI のリファレンスおよびCLI 操作を参照してください。
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 ディレクトリにインストールされます。
ファイル形式
現在のデータベース エンジンはいくつかの古いデータ形式や辞書ファイル形式と互換性を保っていますが、最新の機能を利用するためにファイルを最新の形式に変換したい場合があります。次の表に、旧形式から新しい形式に変換する主な理由を挙げます。
8.x
v8.x より前
バージョン 7.x の機能の利用および全般的なパフォーマンスの向上。
バージョン 6.x の機能の利用および全般的なパフォーマンスの向上。バージョン 6.x のエンジンと バージョン 7.x のエンジンが共に稼動している場合にのみ、このオプションを使用します。
コマンド ラインの Rebuild ユーティリティを使用してできたファイル形式は、-f パラメーターによって異なります。-f パラメーターを指定しないと、Rebuild は MicroKernel の[作成ファイルのバージョン]設定オプションに指定されている値を使用します。たとえば、[作成ファイルのバージョン]の値が 8.x の場合、バージョン 7.x のファイルに対して Rebuild ユーティリティを実行すると、このファイルは バージョン 8.x の形式に変換されます。
Rebuild ユーティリティを実行する前に、変換するデータ ファイルをすべてバックアップしておくことをお勧めします。これは、元のファイルと同じ場所にリビルドする場合には特に重要です(この場合リビルドされたファイルは元のファイルを置き換えます)。バックアップ コピーを取っておけば、必要な場合に元のファイルを復元することができます。バックアップを確実に実行するためには、以下のいずれかの操作を行います。
メモ: Continuous オペレーション モードになっているファイルで Rebuild ユーティリティを実行することはできません。
テンポラリ ファイル
Windows では、Rebuild は TMP システム環境変数で指定されたディレクトリにテンポラリ ファイルを作成します。デフォルトで、Linux、OS X および Raspbian では Rebuild は出力ディレクトリ(-b パラメータが使用されていない場合はソース ディレクトリ)にテンポラリ ファイルを作成します。このため、テンポラリ ファイル ディレクトリには元のファイルと新しいファイルの両方を格納するために十分なディスク容量が必要です(Rebuild ユーティリティの実行中)。Rebuild GUI バージョンの[出力ディレクトリ]オプションを使用するか、CLI バージョンの -B オプションを使用して、これらのファイルを別のディレクトリに保存するように指定できます。
通常、変換が終了するとテンポラリ ファイルは自動的に削除されます。ただし、停電などの重大な障害が発生した場合は、テンポラリ ファイルが削除されないことがあります。このような場合は、以下のタイプのテンポラリ ファイルを削除してください。
_rbldxxxxxx、ここで、xxxxxx はランダムな 6 個の文字です。注意:Rebuild 実行モジュールである rbldcli を削除しないようにしてください。
Rebuild 処理の最適化
Rebuild はデータベース エンジンに Btrieve 呼び出しを行います。したがって、データベース エンジン環境設定およびお使いのコンピューター上のランダム アクセス メモリ(RAM)の量がリビルド処理のパフォーマンスに影響を与えます。このことは、特にサイズの大きなデータ ファイルをリビルドする際の所要時間を見れば明らかです。
一般的に、インデックスを構築するのはデータ ページを構築するよりはるかに時間がかかります。インデックスを多数持つデータ ファイルがある場合、同じファイルでインデックスが少ないものに比べ、ファイルを構築するのにより多くの時間を要します。
リビルドの処理時間には以下の項目が影響します。
CPU 速度およびディスク速度
CPU(中央処理装置)の速度および物理ストレージ ディスクへのアクセス速度が、リビルドの処理時間に影響します。一般的に、これらの両方の速度が速いほどリビルド処理も速く行われます。ディスク速度は、メモリに全体が入りきらない大きなファイルのリビルドではより重要になります。
ヒント: 3 GB または 4 GB 以上などの大きなサイズのファイルでは変換に数時間かかる場合があります。複数のデータベース エンジンが使用できる場合、リビルド処理をいくつかのマシンの CPU 間で分担したいと考えるでしょう。たとえば、すべてのファイルの中からいくつかずつをデータベース エンジンがインストールされている各マシンにコピーし、リビルド処理が終わったらファイルをコピーして元に戻します。
メモリ量
Rebuild では、デフォルトの方法ともう 1 つの方法の 2 つの方法を用いてファイルをリビルドすることができます。-m<0 | 2> パラメーターを参照してください。選択する方法は、使用できるメモリの量によって決まります。デフォルトの方法(-m2)では、利用可能なメモリがあれば、Rebuild は以下の手順を行います。
1
2
3
4
a.
b.
c.
手順 a および b を繰り返し、各レコードのキー値を処理します。
これで、テンポラリ ファイルにはいくつかのキー値が設定されました。それぞれのキー値は個別にソートされています。
5
6
残りの各キーについて、手順 4 および 5 を繰り返します。
この処理中にテンポラリ ファイルのオープンや書き込みに失敗などのエラーが発生した場合、Rebuild はもう 1 つの方法を用いてファイルのビルドを最初からやり直します。
デフォルトの方法には存在するメモリが足りない場合やデフォルトの方法で処理中にエラーが発生した場合、Rebuild はもう 1 つの方法(-m0)を使用します。
1
2
3
4
a.
b.
c.
手順 a および b を繰り返し、各レコードのキー値を処理します。
5
もう 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 で実行した場合、デフォルトのファイル名は rbldcli.log です。デフォルトを使用せず、ログ ファイルの場所と名前を指定することもできます。-lfile パラメーターを参照してください。
テキスト エディターを使用してログ ファイルを確認できます。ログ ファイルに記録される情報は、以下のとおりです。
Rebuild ユーティリティ の GUI のリファレンス
このセクションでは、Rebuild ユーティリティ のグラフィカル ユーザー インターフェイス(GUI)のオブジェクトについて説明します。
ファイル オプションの画面
この画面を使用すると、リビルドのリストにファイルを追加することができます。
図 39 Rebuild ユーティリティのファイル選択
Rebuild オプションの画面
この画面を使用すると、ファイルのリビルドに関するオプションを選択することができます。
図 40 Rebuild ユーティリティのファイル オプション
PSQL Programmer's Guide』のキー属性
たとえば、ページ サイズが 1024 で、24 個のキーを持つ v5.x ファイルがあるとします。Btrieve v6.0 以降のバージョンでは、ページ サイズが 1024 の場合、23 個までのキーのみをサポートするため、ファイルには、ユーティリティによって新しいページ サイズが自動的に割り当てられ、ログ ファイルに通知メッセージが記述されます。
Rebuild 進行状況画面
この画面を使用すると、リビルドの進行状況を知ることができます。また、リビルド処理完了後にログ ファイルを表示することができます。
図 41 Rebuild ユーティリティ進行状況画面
各ファイルのリビルド処理に関する情報を表示することができます。[ログ ファイルの表示]をクリックすると、デフォルトのテキスト ビューアーを使用してリビルド ログを表示します。
 
Rebuild ユーティリティの作業
以下の Rebuild の作業が行えます。
GUI 操作
PSQL Control Center のメニューから[ツールRebuild]を選択するか、オペレーティング システムの[スタート]メニューまたはアプリ画面から Rebuild にアクセスします。
1
Rebuild の開始画面で[次へ]をクリックすると、ファイルの選択画面が表示されます。
2
追加]をクリックしてリビルドするデータ ファイルまたは辞書ファイルを選択します。複数のファイルを一度に選択することもできます。
図 42 ファイルの選択用ダイアログ ボックス
元のファイルと同じディレクトリでファイルをリビルドする場合、元のファイルはリビルド完了後に削除されます。新しいファイルを別のディレクトに置く場合は、元のファイルは削除されません。
3
目的のファイルを追加したら、[次へ]をクリックします。
4
5
次へ]をクリックしてリビルド処理を開始します。
このユーティリティは処理に関する情報をレポートします。リビルド処理が完了すると、成功か失敗かが表示され[ログ ファイルを表示する]ボタンが有効になります。
図 43 リビルド処理
6
結果を表示するには、[ログ ファイルを表示する]をクリックします。ログ ファイルの内容は、オペレーティング システムのデフォルトのテキスト エディターで表示されます。
Rebuild ユーティリティでは、変換を試みたすべてのファイルについてログ ファイルに書き込みます。[エラー時続行]の設定を無効にした場合、ログ ファイルには、エラーが発生した時点までの情報が記録されます。リビルドが失敗した場合、ログ ファイルにはそのエラーの原因を説明するメッセージが記録されます。
7
CLI 操作
Rebuild コマンド ライン ユーティリティの名前は、Windows の場合は rbldcli.exe、Linux、OS X および Raspbian の場合は rbldcli です。以下のコマンド ライン Rebuild ユーティリティ作業が行えます。
コマンド ライン パラメーター
parameter オプションには、このユーティリティで使用するパラメーターを指定します。パラメーターはどのような順序でも使用できます。各パラメーターの前にはハイフン(-)を付けます。ハイフンの後、または、1 文字のパラメーターおよびパラメーター値の後にスペースを入れないでください。
メモ: Linux、OS X および Raspbian プラットフォームでは、パラメーターで大文字小文字が区別されます。
parameter は以下のように定義されています。
エラーが発生しても、次のデータ ファイルまたは辞書ファイルのリビルドを続行するように、Rebuild に指示します。ユーティリティにより、MicroKernel データ ファイル以外のファイルであることや MicroKernel ファイルでエラーが発生したことが通知されますが、データ ファイルのリビルドは続行されます。エラーはログ ファイルに書き出されます。ログ ファイルを参照してください。

ヒント:このパラメーターは、混合するファイルのセットに対してワイルドカード文字(*.*)を指定した場合に特に便利です。混合ファイルのセットとは、MicroKernel ファイルと非 MicroKernel ファイルの組み合わせです。Rebuild は非 MicroKernel ファイルを処理するたび(または MicroKernel ファイルのエラー時)にエラーを報告しますが、処理を続行します。
-d を指定すると、バージョン 6.0 より前の補助インデックス(重複が可能)を 6.x、7.x または 8.x のリンク重複キーのあるインデックスに変換します。

このパラメータを指定しないと、Rebuild はインデックスを繰り返し重複キーとして保持します。

MicroKernel エンジンを介してのみデータ ファイルにアクセスし、かつファイルに比較的多数の重複キーがある場合には、-d パラメーターを使用して Get Next オペレーションや Get Previous オペレーションのパフォーマンスを向上させることができます。
-m<0 | 2>
ページ サイズをディスク ストレージまたは処理に最適化します。またはリビルドするファイルに特定のページサイズを指定します。

このパラメーターを指定しないと、Rebuild は元のファイルのページ サイズを使用します。元のファイルのページ サイズでは現在のデータベース エンジンで動作しない場合、Rebuild はページ サイズを変更し、変更したことを示す情報メッセージを表示します。たとえば、5.x などの古いファイル形式ではページ サイズが 1024 でキーを 24 個持つファイルをサポートしていました。8.x のファイル形式では、ページ サイズ 1024 で 23 個のキーしかサポートしません。したがって、Rebuild は 8.x ファイルを作成する場合、異なるページ サイズを選択します。

データベース エンジンでは、指定されたページ サイズを無視してそのサイズを自動的に更新することがあります。たとえば、バージョン 9.5 のファイル形式の場合、1536 や 3072 などの奇数ページ サイズはサポートされません。データベース エンジンでは効率を良くするために、ページ サイズを次の有効なページ サイズへ自動的に更新します。旧バージョンのファイル形式の場合、データベース エンジンは別の条件に基づいてページ サイズを更新することができます。

インデックス ページ サイズ も参照してください。
開発者リファレンス『PSQL Programmer's Guide』のページ サイズの選択を参照してください。
Rebuild 処理の最適化 を参照してください。
-bdirectoryname
リビルドしたファイルに別の場所を指定します。別のサーバー上の場所も指定できます。デフォルトの場所は、データ ファイルのあったディレクトリです。必ず存在する場所を指定してください。Rebuild はディレクトリを作成しません。また、そのディレクトリは PSQL データベース エンジンが起動しているマシン上のディレクトリでなければなりません。

完全修飾したパスまたは相対パスのいずれも使用できます。
directoryname にはワイルドカード文字を使用しないでください。

ローカル サーバーの場合は、MicroKernel Database エンジンとメッセージ ルーターがロードされている必要があります。リモート サーバーの場合は、MicroKernel Database エンジンと通信コンポーネントがロードされている必要があります。

このパラメーターを指定しないと、リビルドされたファイルによって元のデータ ファイルが置き換えられます。元のファイルのコピーは保持されません。

このパラメーターを指定すると、リビルドされたファイルは指定の場所に置かれ、元のファイルが保持されます。これに関する例外があります。指定した場所に同じ名前のデータ ファイルが既に存在する場合です。元のファイルと同じ名前のファイルが指定された場所に含まれていた場合、Rebuild ではエラーが起こります。たとえば、folder1 というディレクトリにある mydata.mkd をリビルドしようとするとします。リビルドされたファイルを foder2 というディレクトリに保存したいとします。folder2 にも mydata.mkd が存在していた場合(おそらく気付かないうちに)、Rebuild ではエラーになり、ログ ファイルを調べるよう通知があります。

メモ:指定した場所(このパラメーターを指定しなかった場合は元のファイルの場所)に対して、ファイルを作成するアクセス権があることを確認してください。
-knumber
-lfile
ログ ファイルも参照してください。
file のページ圧縮をオンにすると、以下の条件が設定されます。
file のページ圧縮をオフにします。このパラメーターは、file にページ圧縮が指定されていない場合は無効です。
file のページ圧縮をオンにします。
file のレコード圧縮をオフにします。このパラメーターは、file にレコード圧縮が指定されていない場合は無効です。
このパラメータを指定しないと、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 は次のように定義されます。
@command_file
1
デフォルトでは、ユーティリティを実行するには 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
parameterfile、および @command_file は、コマンド ライン パラメーターに定義されています。
使い方の例
以下の例はエラー時も処理を続けます。ページ サイズは 4096 バイトに設定され、リビルドされたファイルはサーバー上の別のディレクトリに保存します。
rbldcli -c -p4096 -b/usr/local/psql/tmp /usr/local/psql/data/DEMODATA/*.mkd
1
2
状況により、\bin ディレクトリをプログラム ファイルをインストールしたディレクトリに変更します。その場所が Path システム変数に含まれている場合は、この操作は不要です。
3
rbldcli [–parameter ...]file
または
rbldcli @command_file
parameterfile、および @command_file は、コマンド ライン パラメーターに定義されています。
使い方の例
以下の例はエラー時も処理を続けます。ページ サイズは 4096 バイトに設定され、リビルドされたファイルはサーバー上の別のディレクトリに保存します。
rbldcli -c -p4096 -bc:\dbtemp c:\datafiles\*.mkd
Rebuild は、ファイルごとに処理されたレコード数を画面上に表示します。1 度に 50 レコードずつ増加します。さらに、Rebuild はこれらの情報をテキスト ログ ファイルに書き込みます。ログ ファイルを参照してください。