設定リファレンス
 
このページをシェアする                  
設定リファレンス
PSQL で使用できる構成方法および設定
この章では、以下の項目について説明します。
設定の概要
PCC による設定
CLI ユーティリティによる設定
設定のプロパティ
サービス設定プロパティ
サーバー設定プロパティ
Windows クライアント設定プロパティ
Linux および OS X クライアント設定プロパティ
設定の概要
設定は、データベース エンジンとクライアントの設定を指定することができるプロセスです。設定は、PSQL Control Center(PCC)を使用するか、または コマンド ライン インターフェイス(CLI)ユーティリティを使用して指定できます。
PCC では、設定はエンジンまたはクライアントのプロパティです。PCC でエンジンの設定にアクセスするにはおよび PCC でローカル クライアントの設定にアクセスするにはを参照してください。
コンポーネントの設定は任意です。設定を行わない場合は、各コンポーネントにはデフォルトの構成が読み込まれます。よい結果を得るためには、クライアントとエンジン コンポーネントで同じバージョンの PCC を使用してください。
設定を使用できるのは、以下の理由からです。
システムまたは PSQL アプリケーションが、設定の変更を必要とするため。お使いのアプリケーションのマニュアルで、推奨される値を確認してください。複数のアプリケーションを同時に起動する場合は、それぞれに推奨されている値の合計を使用します。複数のアプリケーションを順次起動する場合は、推奨されている最も高い値を使用します。
設定を最適化して PSQL が必要以上にメモリを使用せずにサービスを提供できるようにするため(マニュアルに記述されている必要メモリは、コンピューターのリソースを最大限に活用するためのガイドラインとなります)。
設定自体の説明は、設定リファレンスにあります。
設定の変更が有効になっていることを確認する
エンジンの設定によっては、設定内容の変更後にデータベース エンジンの再起動が必要になります。エンジンを再起動することにより、設定が有効になります。この章の各設定の説明では、データベース エンジンの再起動が必要かどうかを明示しています。また、設定の変更によりエンジンの再起動が必要な場合は、PCC によりポップアップ メッセージが表示されます。
CLI ユーティリティも、入力ファイルを使用しないでコマンド ラインから設定を変更したことを知らせます。入力ファイルを使用した場合は、常にエンジンの再起動が要求されます。CLI ユーティリティによる設定を参照してください。
コマンド ラインからサーバー データベース エンジンの停止および起動を行う場合は、『PSQL User's Guide』の以下のトピックを参照してください。
Windows サーバー上でのサーバー エンジンの起動と停止
Linux および OS X 上でのデータベース エンジンの起動と停止
ワークグループ エンジンの停止および起動を行う場合は、『PSQL User's Guide』の Windows 上でのワークグループ エンジンの起動と停止を参照してください。
さらに、クライアント プロパティを変更すると、クライアントを再起動する必要がある場合があります。クライアントの再ロードは、PSQL に依存するすべてのアプリケーションを終了して再起動するだけです。
別のマシンに接続する
ローカル クライアントのコンポーネントだけでなく、ローカル エンジンおよびリモート エンジンの構成も行えます。ただし、エンジンはそれぞれ個別に構成する必要があります。PCC による設定および CLI ユーティリティによる設定を参照してください。
PCC を使ってリモート マシンに接続しているときは、エンジン コンポーネントのみを表示および変更できます。クライアントのコンポーネント(ワークグループ エンジン、ワークステーション エンジン、クライアント マシンなど)は、各マシンでローカルに設定する必要があります。
PCC による設定
PCC では、設定はエンジンまたはクライアントのプロパティです。登録済みのエンジンはすべて PSQL エクスプローラーの中にノードとして現れ、プロパティを介して設定を構成できます。PSQL エクスプローラー にはローカル クライアントのみが現れます。
クライアントの設定は、各クライアント マシンで設定します。デフォルトで、PCC はクライアント コンポーネントと共にインストールされます。
PCC でエンジンの設定にアクセスするには
1 PSQL エクスプローラーで、ツリーのエンジン ノードを展開します(ノードの左の展開アイコンをクリックします)。
2 設定を指定するデータベース エンジンを右クリックします。
3 プロパティー]をクリックします。
4 ツリー内で目的のオプション カテゴリをクリックし、そのカテゴリに含まれるオプションの設定内容を表示します。
5 オプションで、Shift+F1 を押すと、当該設定のヘルプを表示できます。
PCC でローカル クライアントの設定にアクセスするには
1 PSQL エクスプローラーで、ツリーのローカル クライアント ノードを展開します(ノードの左の展開アイコンをクリックします)。
2 MicroKernel ルーター]を右クリックします。
3 プロパティー]をクリックします。
4 ツリー内で目的のオプション カテゴリをクリックし、そのカテゴリに含まれるオプションの設定内容を表示します。
5 オプションで、Shift+F1 を押すと、当該設定のヘルプを表示できます。
CLI ユーティリティによる設定
設定のコマンド ライン インターフェイス(CLI)バージョンは、PSQL Control Center のプロパティ ダイアログ ボックスと同様の設定機能を提供します。CLI 設定は、PSQL v12 でサポートされる Windows、Linux、および OS X プラットフォームでのみ動作します。
Windows では、実行可能プログラムは bcfg.bat で、デフォルトで Program Files ディレクトリにインストールされます。
Linux および OS X では、実行可能プログラムの名前は bcfg といい、デフォルトでは /usr/local/psql/bin ディレクトリにあります。これら 2 つのシステム上で bcfg を起動するには、以下の条件に合致する必要があります。
表 6 bcfg の実行要件
要件
説明
Java Runtime Environment(JRE)
bcfg を実行するために必要な JRE コンポーネントは、PSQL の一部としてインストールされます。bcfg は、PSQL の一部としてインストールされる JRE の「ローカル」バージョンを使用します。
PSQL のサーバーまたはクライアント
同一マシンに互換性のある PSQL Server または Client が既にインストールされている必要があります。『Getting Started With PSQL』の PSQL Server、Vx Server、Client の Linux 版および OS X 版のインストールを参照してください。
bcfg を実行する要件に合致しているのに、実行に問題がある場合は、以下のトラブルシューティング ガイドを参考にしてください。
表 7 bcfg の実行に関するトラブルシューティング
トラブルシューティングする状態
説明
"java.lang.UnsatisfiedLinkError" というエラーを受け取った。
このエラーは、ファイル ブラウザー アプリケーションを使用してスクリプト ファイルをダブルクリックして bcfg を起動しようとしたときに、よく起こります。コマンド プロンプトから bcfg を起動してください。
このエラーは、LD_LIBRARY_PATH 変数が設定されていない場合に発生します。ユーザー psql として bcfg を実行している場合、この変数は psql のプロファイルに設定されます。この変数は、以下のコマンドを使用して明示的に設定することもできます。
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/psql/lib64
OS X では、この変数は DYLD_LIBRARY_PATH になります。
以下のエラー メッセージが返された。
"データベース エンジンに接続できません。ターゲット マシンがアクセス可能で、かつエンジンが実行されていることを確認してください。"
このエラー状況は、ローカル サーバーを管理しようとした場合に発生します。
ローカル サーバーを管理するには、pvsw グループのメンバーであるか root ユーザーである必要があります。
Getting Started With PSQL』の Linux および OS X での PSQL のアカウント管理も参照してください。
構成の設定
設定は、コマンド ラインから一度に 1 つずつ設定するか、入力ファイルに 1 つ以上を指定して設定することができます。
ヒント: 入力ファイルを作成する便利な方法は、最初に出力ファイルを作成することです。その後、出力ファイルを編集して、その編集したものを入力ファイルとして使用できます。編集が許可される種類については、入力ファイルの編集を参照してください。
エンジンの再起動
入力ファイルを使用した場合、bcfg ユーティリティはファイルの処理後、データベース エンジンを再起動するよう促します。再起動は、入力ファイル内の設定に関係なく適用されます。エンジンを停止して起動することにより、その設定が有効になります。
コマンド ラインから構成を行った場合は、bcfg はその設定が再起動を要求する場合にのみ、データベース エンジンの再起動を促します。
エンジンの再起動方法については、設定の変更が有効になっていることを確認するを参照してください。
シナリオの例:コマンド ラインから単一の設定を構成する
ネットワークが停止した場合に、クライアントがサーバーに再接続するかどうかに関係する設定をオンにしたいとします。しかし、その設定の完全な名前がわかりません。その場合は、次の手順を踏みます。
1 コマンド プロンプトで「bcfg -H 再接続」と入力し、Enter キーを押します。Linux 版の場合は "再接続" の部分を "reconnect" に置き換えてください。
ユーティリティによって、文字列 "再接続" を含んでいるすべての設定がレポートされます。Linux の場合は英語でレポートされます。
ID               設定名
-----------------------------
29               自動再接続の有効化
148              自動再接続の有効化
149              自動再接続タイムアウト
29 と 148 の 2 つが目的の設定であるようですが、必要な設定は一体どちらなのでしょうか?
2 bcfg 29」と入力して、Enter キーを押します。
ユーティリティは、設定 ID 29 について次のようにレポートします。
=====================
自動再接続の有効化
=====================
ID:29
値:Off
オプション:On     Off
デフォルト値:Off
説明:<クライアント設定> ネットワーク停止の場合に、クライアントがサーバーへの再接続を試みるかどうかを指定します。再接続されたクライアントは、エラーに遭遇しなかったかのように処理を続行します。
説明によると、この設定はクライアントに適用されるものであり、現在 Off に設定されているということです。
3 bcfg 29 on」と入力して、Enter キーを押します。
ユーティリティは、システム設定 29 が更新されたことを知らせます。
4 設定が On になっていることを確認したい場合は、「bcfg 29」と入力して Enter キーを押します。
ユーティリティは、設定 ID 29 について次のようにレポートします。
=====================
自動再接続の有効化
=====================
ID:29
値:On
オプション:On    Off
デフォルト値:Off
説明:<クライアント設定> ネットワーク停止の場合に、クライアントがサーバーへの再接続を試みるかどうかを指定します。再接続されたクライアントは、エラーに遭遇しなかったかのように処理を続行します。
値が On に設定されていることに注目してください。
入力ファイルの編集
入力ファイルには、少なくとも 1 つの設定に対する完全なレコードが 1 つは含まれていなければなりません。出力ファイルを基に入力ファイルを作成する場合、一部の設定を削除する際には、残す設定のレコードは完全な状態であるようにしてください。
完全なレコードには、ID と値のペアが少なくとも 1 つ含まれます。しかし、見やすくするために、先頭行の設定の見出しから設定の説明までを含めることをお勧めします。たとえば、以下は「自動再接続の有効化」に関するレコードの、推奨される最小レコードです。
=====================
自動再接続の有効化
=====================
ID:29
値:On
オプション:On    Off
デフォルト値:Off
説明:<クライアント設定> ネットワーク停止の場合に、クライアントがサーバーへの再接続を試みるかどうかを指定します。再接続されたクライアントは、エラーに遭遇しなかったかのように処理を続行します。
入力ファイルに設定レコードを含めるという制限以外に、唯一変更が許可されるのはの割り当てです。割り当ては、オプションまたは範囲によってどのような値でも指定できます。
コマンド構文
bcfg -I inputfile [-S server] [-U username]
[-P password] [-E]
   または
bcfg -O outputfile [-S server] [-U username]
[-P password] [-E]
   または
bcfg ID [value] [-S server] [-U username]
[-P password]
   または
bcfg -H <keyword | ''keyword with spaces''> [-S server]
[-U username] [-P password]
オプション
-I
ユーティリティに入力ファイルを渡す場合の必須パラメーター。
inputfile
指定したサーバーに関する 1 つまたは複数の設定のレコードと、各設定に割り当てる値を含んでいるテキスト ファイル。
入力ファイルを作成する便利な方法は、最初に出力ファイルを作成することです。その後、設定値を必要に応じて編集し、その編集したものを入力ファイルとして使用できます。編集が許可される種類については、入力ファイルの編集を参照してください。
-O
ユーティリティ実行の出力結果をテキスト ファイルに送る場合の必須パラメーター。
outputfile
ユーティリティの実行結果として、指定されたサーバーの現在の設定を含んでいるテキスト ファイル。
ID
設定を示す、一意な 2 桁または 3 桁の整数。
設定のいくつかは、設定を有効にするためにデータベース エンジンの再起動を必要とします。再起動が必要な場合は、bcfg が再起動を促します。エンジンの再起動を参照してください。
value
設定に割り当てる値。有効な値は、設定レコードの「オプション」または「範囲」に示されています。
value を省略した場合、ユーティリティは現在の設定を返します。
value を記述した場合、ユーティリティは値の割り当てを基に設定を変更します。
-H
keyword 用のヘルプ検索オプション(つまり、keyword 用のヘルプ)。Keyword を含む設定を検索するためのユーティリティで、ID および設定名を返すか、あるいは "一致する項目なし" を返します。次の行を参照してください。
keyword
ALLOW CLIENT-STORED CREDENTIALS や SUPPORTED PROTOCOLS など、設定の名前。
keyword は大文字小文字を区別しないことに注意してください。ただし、keyword にスペースを入れる場合は、文字列を二重引用符で囲む必要があります。
ユーティリティは、部分的なキーワードを基にヘルプを表示できます。たとえば、「-H クライアント」と指定した場合は、設定名の一部に "クライアント" という語を含んでいるすべての設定が返されます。Linux 版の場合は設定名が英語なので "クライアント" の部分を "client" に置き換えてください。「-H a」と指定した場合は、設定名に "a" を含んでいるすべての設定が返されます。
-S
設定がリモート サーバー(ローカル サーバー以外のサーバー)に適用される場合の必須パラメーター。
server
データベース エンジンを含んでいるリモート サーバーの名前、または IP アドレス。
-U
server へのアクセスにユーザー名が必要な場合の必須パラメーター。
username
server に接続するユーザー名。PSQL セキュリティも参照してください。
server がローカル マシンの場合、以下の条件を満たしていれば usernamepassword は必要ありません。
管理者として、あるいは Pervasive_Admin グループのメンバーとしてローカル マシンにログインしている。
ローカル マシンがターミナル サービスを実行していない。
-P
server へのアクセスにパスワードが必要な場合の必須パラメーター。
password
server へ接続する username と一緒に使用するパスワード。username を参照してください。PSQL セキュリティも参照してください。
-E
inputfile の読み取り時、あるいは outputfile への書き込み時のエラーを無視します。
設定のプロパティ
各設定のプロパティを表形式で一覧表示します。
表 8 設定プロパティの表形式
表形式の列
説明
名前
プロパティの名前
データ型
値のデータ型を定義します。データ型は次のとおりです。
Numeric
Bool(ean)
String
複数選択 - リストからいくつかの値を選択します。
単一選択 - リストから 1 つの値を選択する必要があります。
現在の設定を示します。
単位
値が数値の場合、必要に応じてこのフィールドに単位(KB、秒など)が示されます。
サービス設定プロパティ
Windows サーバー環境では、PSQL Server はサービスとして起動します。サービスはインストール処理の一部としてロードされ、完全インストールであれば常に使用可能な状態に設定されます。
PCC 内でサービスの起動ポリシーを構成することができます。
PCC を使ってサービスの起動ポリシーを設定するには
1 オペレーティング システムの[スタート]メニューまたはアプリ画面から Control Center にアクセスします。
2 PSQL エクスプローラーでサービスノードを展開します(下位ノードを表示するには、ノードの左にある展開アイコンをクリックします)。
3 目的のサービス、PSQL(relational)または PSQL(transactional)を右クリックします。
4 プロパティー]をクリックします。
5 希望の起動ポリシーをクリックします。
ポリシー
説明
手動
サービスは、オペレーティング システムの起動時に自動的に開始されません。オペレーティング システムの起動後または再起動後に、サービスを手動で開始する必要があります。
自動
サービスは、オペレーティング システムの起動時または再起動時に自動的に開始されます。
無効
サービスは、起動ポリシーが[手動]または[自動]に再設定されるまで機能しなくなります。
6 OK]をクリックします。
サーバー設定プロパティ
各 PSQL データベース エンジンには、独自のサーバー設定パラメーターがあります。このトピックでは、エンジンで使用可能な設定オプションについて説明します。
PSQL サーバーは、Windows、Linux、および OS X プラットフォームで、PSQL Control Center またはコマンド ライン ユーティリティの bcfg を使用して構成することができます。PCC については、『PSQL User's Guide』の PSQL Control Center の使用を参照してください。ほとんどの場合、PCC のエクスプローラーで右クリックすれば、[設定]ダイアログを選択して開くことができます。bcfg については、CLI ユーティリティによる設定を参照してください。
次の表は、サーバー設定オプションとその設定項目の一覧をアルファベット順で示します。各設定の詳しい説明がリンク先のセクションにあります。
表 9 サーバー設定オプションおよび設定項目
設定オプション
設定項目名
サーバー名(表示のみ)
エンジンのバージョン(表示のみ)
エンジンのタイプ(表示のみ)
アクセス
サーバーを右クリックし、[プロパティ]>[アクセス]を選択すると、次の設定が表示されます。
リモート リクエストの受付
キャッシュ エンジン接続の許可
クライアント保持の資格情報の容認
Authentication(Linux および OS X エンジンのみ)
Configuration File(Linux および OS X エンジンのみ)
クライアント資格情報の入力要求
ワイヤ暗号化
ワイヤ暗号化レベル
リモート リクエストの受付
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Boolean
オン
オフ
オン
なし
はい
この設定は、通信マネージャーが、リモート サーバーやクライアント ワークステーションからのリクエストを受け付けるかどうかを指定します。このオプションをオンにすると、通信マネージャーは、ネットワークでの存在を通知します。
キャッシュ エンジン接続の許可
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Boolean
オン
オフ
オン
なし
はい
クライアントがキャッシュ エンジンを使用してサーバーに接続することをサーバーがサポートするかどうかを指定します。オフに設定してもクライアントはサーバーに接続はできますが、キャッシュ エンジンを使用することはできません。
クライアント保持の資格情報の容認
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Boolean
オン
オフ
オン
なし
いいえ
この設定をオンにした場合、データベース エンジンはクライアントに保管されているユーザー資格情報を受け付けます。保管方法および場所は、クライアントのオペレーティング システムによって異なります。
Windows クライアント:資格情報は Windows レジストリに格納されています。[クライアント資格情報の入力要求]がオンに設定されている場合は、ポップアップ ダイアログで[ユーザー名とパスワードを保存]チェック ボックスをオンにすることによって、資格情報を保存できるようになります。代わりの方法として、pvnetpass コマンド ライン ユーティリティを使用すると、保管されている資格情報を管理することができます。
Linux および OS X クライアント:資格情報は、pvnetpass ユーティリティによって PSQL レジストリに格納されます。
この設定をオフにした場合、データベース エンジンはクライアントに対し、資格情報が必要なデータベース操作の対象から保管されている資格情報は強制的に除外します。このような資格情報は、アプリケーションから、またはログイン ダイアログで提供する必要があります。この設定がオフであっても、ログイン ダイアログを使用して指定されれば、ログイン ダイアログはクライアント保持の資格情報を書き込もうとします。ただし、これは受け入れられません。
クライアント保持の資格情報が認められている場合は、資格情報を知らなくても、誰でもその特定クライアントのコンピューターに向かい、保管されている資格情報を使ってデータベースにログインすることができます。この動作は、個々のユーザーの厳密な認証は重要でない環境、たとえば、すべてのユーザーが同レベルのアクセス権限を持っている、物理的にセキュリティ保護されているような環境では便利です。一方、権限のない人が存在したり、権限のあるユーザーがアクセス権限のレベルを変更しているような環境では、この設定はオフにしておく必要があります。
クライアント資格情報の入力要求も参照してください。
ログイン動作のまとめ
 
表 10 ログイン設定動作のまとめ
クライアント資格情報の入力要求
クライアント保持の資格情報の容認
動作
オフ
オフ
PSQL クライアントは、ユーザーに入力を求めることも保管されている資格情報を使用することもしないため、クライアント アプリケーションが Btrieve オペレーションで資格情報を提供する必要があります。
オフ
オン
資格情報がクライアント アプリケーションの Btrieve オペレーションで提供されない場合、クライアントは、ログイン ダイアログまたは pvnetpass によって保管されている資格情報を利用できる場合は、それを使用します。どちらの方法でも資格情報が提供されない場合は、接続に失敗します。ログイン ダイアログは表示されません。
オン
オフ
資格情報がクライアント アプリケーションの Btrieve オペレーションで提供されない場合、クライアントはユーザーにログイン ダイアログを表示し、Linux または OS X クライアントはアクセス許可エラーを示すステータス コードを返します。ログイン ダイアログまたは pvnetpass によって保管された資格情報は使用しません。
オン
オン
資格情報がクライアント アプリケーションの Btrieve オペレーションで提供されない場合は、保管されている資格情報を使用します。利用できる資格情報が保管されていない場合、クライアントはユーザーにログイン ダイアログを表示し、Linux または OS X クライアントはアクセス許可エラーを示すステータス コードを返します。
Authentication(Linux および OS X エンジンのみ)
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
単一選択
3 つのオプションがあります。次の解説を参照。
Emulate Workgroup Engine(ワークグループ エンジンのエミュレート)
なし
はい
以下のオプションは、サーバー エンジンへのアクセスに使用する認証のタイプを設定します。
Emulate Workgroup Engine(ワークグループ エンジンのエミュレート)。Samba を使用してシステムのユーザー アクセスを認証する場合、この値を使用します。オペレーティング システムによるセキュリティを回避し、レジストリに RTSS パスワードを保存したくない場合は、[Emulate Workgroup Engine]を使用します。
Proprietary Authentication(using btpasswd)(専用認証(btpasswd の使用))。Linux では Samba、OS X では SMB を認証に使用せず、ユーザーがサーバーにアカウントを持っていない場合は、この値を使用します。このオプションを使用すると、Linux システムまたは OS X システムへの接続用パスワード ファイルを別々に維持できます。
サーバーで BTPASSWD の認証を使用する場合、クライアントからこのサーバーに接続するユーザー名とパスワードを設定する必要があります。PSQL Control Center または pvnetpass ユーティリティを使用します。『PSQL User's Guide』のグループ、ユーザー、およびセキュリティおよび pvnetpass の両トピックを参照してください。
Proprietary Authentication は、サーバーにより高いセキュリティ強度が必要で、サーバーで使用されるユーザー認証方式と異なるユーザー名とパスワードが必要な場合に使用します。
Standard Linux Authentication(標準 Linux 認証)。認証に Samba を使用せず、ユーザーが Linux または OS X システムにアカウントを持っている場合は、この値を使用します。
Linux の標準認証は PAM と共に使用されます。PAM は、Linux または OS X サーバーで既存のユーザー名とパスワードを使用したい場合に使用します。クライアントからユーザー名とパスワードを指定する場合は、pvnetpass ユーティリティを使用できます。PAM は非常に柔軟で、Linux および OS X 用のカスタム モジュールを多数提供しています。詳細については、PAM に関する Web サイトを確認ください。
PSQL のインストールで PAM が検出された場合、PAM を使用できるようインストールの設定を整えます。PSQL のインストール後に PAM をインストールし、PAM による標準認証を使用する場合は、PSQL を再インストールする必要があります。これは、PAM のインストールでファイルのコピー、各種設定ファイルの作成、権限の設定、およびリンクの作成を行っているためです。PSQL を再インストールして PAM を検出し、その PAM 設定を正しく完了させる必要があります。
PSQL をアンインストールし、再度インストールし直します。アンインストールとインストールの手順については、『Getting Started With PSQL』の PSQL Server、Vx Server、Client の Linux 版および OS X 版のインストールの章を参照してください。
PVPIPE$ を使用した Samba と認証(Linux のみ)
上記の 3 種類の認証方法に加え、使用可能な場合は、Samba を使用することもできます。Configuration File(Linux および OS X エンジンのみ)で説明されているように PVPIPE$ が共有されている場合、PSQL エンジンは FIFO を $PVSW_ROOT/etc/pipe/mkde.pip に作成します。PVPIPE$ は Linux でのみサポートされます。
メモ: 末尾の $ は、この共有が非表示になることを意味します。PSQL クライアント コンポーネントが、\\<サーバー>\PVPIPE$\mkde.pip(大文字小文字区別なし)として自動的にこのパイプへのアクセスを処理します。明示的な処理を実行したり、このパイプにアクセスするようにアプリケーションを変更したりする必要はありません。唯一の例外は、Samba または PSQL の設定のトラブルシューティングを行う場合です。
クライアントがリモート エンジンに接続し、エンジンがバージョン ブロックで "Unix" と返した場合は、まずレジストリ(RTSS 設定)で認証情報を確認します。ユーザー名とパスワードがレジストリ内で見つからなかった場合、クライアントは上記のパイプに接続し、サーバーからクライアント認証情報を受け取り、検証します。
認証されるためには、共有に接続し、パイプを読み取ることができる必要があります。これは、エンジンを使用できるユーザーと使用できないユーザーを指定する 1 つの方法です。これを行う最も簡単な方法は、smb.conf 設定ファイル内の「valid users」値を設定することです。クライアントが認証されなかった場合、ステータス 3119 が返されます。
注意: PVPIPE$ へのクライアントの読み取りアクセスを許可すると、そのクライアントはリモートでエンジンへのアクセスが許可されます。
クライアントが認証されることを確認するには、コマンド プロンプトで「\\<サーバー>\pvpipe$\mkde.pip」と入力します。多数の疑問符(印刷不可能なシンボル)といくつかの印刷可能な文字が表示され、警告音が鳴ります。表示されなかった場合は、Samba の設定ファイルを調べて、このパイプを読み取る権限があるかどうかを確認します。権限があるのにエラー 94 または 3119 が発生する場合は、PSQL Control Center でエンジンの設定プロパティを使用して、または pvnetpass を使用して、RTSS 設定を確認します。
Samba を介して共有されるファイルへのアクセスの詳細については、Samba のマニュアルを参照してください。
Configuration File(Linux および OS X エンジンのみ)
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
String
適用外
/etc/smb.conf
なし
はい
この設定は、ローカル ファイル システムを Windows クライアントへエクスポートする場合に使用される smb.conf ファイルの場所を設定します。エンジンは、リモート システムの UNC パスを正しいデータベース ファイルへのローカル呼び出しに変換するときに、このファイルを必要とします。サード パーティ製の Samba パッケージではなくネイティブの SMB ファイル共有が使用されている OS X システムでは、この設定は適用されないことに留意してください。
デフォルト値は /etc/smb.conf です。Samba の設定ファイルを別の場所にインストールした場合は、正しいパス名を入力します。
PSQL は smb.conf 設定ファイルの有無について、次に示す場所をこの順序で調べます。
/etc/samba/smb.conf
/etc/smb.conf
/usr/local/samba/lib/smb.conf
/usr/local/lib/smb.conf
/lib/smb.conf
/etc/samba.d/smb.conf
/opt/samba/lib/smb.conf
/usr/share/samba/smb.conf
/usr/local/share/samba/smb.conf
/home/samba/lib/smb.conf
/opt/local/etc/samba3/smb.conf
最初に見つかった smb.conf が使用されます。smb.conf が見つからない場合は、PSQL はシステム ログ ファイルにエントリを記録し、どの Samba 共有も有効になりません。
Linux の場合、PVPIPE$ の FIFO 共有を使用したいが、smb.conf ファイルにまだ共有が存在しない場合には、次のようにファイルに設定する必要があります。psql ユーザーと pvsw グループは PSQL サーバーのインストールにより作成されます。
[PVPIPE\$]
comment = PSQL pipes
path = /usr/local/psql/etc/pipe
# only members of group pvsw will have access
valid users = @pvsw
# Absolutely necessary - prevents caching
oplocks = no
level2 oplocks = no
read only = yes
browseable = no
psql というユーザー名のユーザーがこの共有にアクセスできるようにするには、smbpasswd コマンドを特定のパラメーターと一緒に使用する必要があります。引数 -n に関する情報は Samba のドキュメントをお読みください。アクセスを有効にする準備が整ったら、PSQL Server または Vx Server がインストールされているシステムで以下のことを行います。
1 root としてログインします。
2 次のコマンドを実行して、ユーザー psql をローカルの smbpasswd ファイルへ追加します。
smbpasswd -a -n psql
3 smbd を再起動してこの変更を有効にします。
クライアント資格情報の入力要求
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Boolean
オン
オフ
オフ
なし
いいえ
この設定は、ユーザー認証を必要とするデータベース操作中に利用できる資格情報がない場合、Windows PSQL クライアントがユーザーにログイン資格情報の入力を求めるかどうかを決定します。
この設定をオンにした場合、ほかの認証資格情報がないときには、ユーザーにログイン ダイアログを表示するよう、エンジンが Windows クライアントに要求します。この設定は、混合またはデータベース セキュリティが有効になっている場合にのみ適用されます。ただし、いかなる状況下でも Linux または OS X クライアントには適用されません。有効な資格情報が別の手段、たとえば、明示的な Btrieve Login(78)オペレーションやクライアントに保管されている資格情報によって提供される場合は、ログイン ダイアログは表示されません。
ユーザー資格情報を必要とする操作で、エンジンにデータベース コンテキストが指定されていない場合、エンジンは、ユーザーは現在のデータベースヘのログインを試みていると見なします。
この設定をオフにして、新しいセキュリティ モデルのいずれかを使用している場合は、ユーザー資格情報をプログラムから提供する(クライアントに保管されている資格情報を提供するか、Btrieve の Login(78)、Open(0)、または Create(14)オペレーションによって提供する)必要があります。そうしないと、ログインの試行は認証エラーで失敗します。
関連項目
クライアント保持の資格情報の容認
ワイヤ暗号化
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
単一選択
しない
必要な場合
常時
必要な場合
なし
はい
このプロパティは、指定されたクライアントまたはサーバーがネットワーク通信で暗号化を使用するかどうかを指定します。デフォルト値は "必要な場合" です。これは、クライアントまたはサーバーは、通信ストリームの相手側が暗号化を要求している場合にのみ暗号化を使用するという意味です。たとえば、サーバー A は[ワイヤ暗号化]値を "常時" に設定しており、サーバー B は "しない" に設定しているとします。クライアントはこの値を "必要な場合" に設定しています。この場合、クライアントはサーバー A と通信する場合には暗号化を使用しますが、サーバー B と通信する場合には暗号化を使用しません。
次の表は、クライアント値とサーバー値の考えられる組み合わせを基に動作をまとめています。
表 11 クライアント/サーバーのワイヤ暗号化組み合わせの結果
クライアント設定
サーバー設定:"しない"
サーバー設定:"常時"
サーバー設定:"必要な場合"
しない
暗号化を使用しません。
ステータス コード 5001
暗号化を使用しません。
常時
ステータス コード 5000
暗号化を使用します。レベルは、クライアントとサーバー間で最も高い[ワイヤ暗号化レベル]設定によって決定されます。
暗号化を使用します。レベルは、クライアントの[ワイヤ暗号化レベル]設定によって決定されます。
必要な場合
暗号化を使用しません。
暗号化を使用します。レベルは、サーバーの[ワイヤ暗号化レベル]設定によって決定されます。
暗号化を使用しません。
ワイヤ暗号化レベル
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
単一選択


なし
はい
この設定では、暗号化された通信で使用する暗号化キーの長さを指定します。次の表は、使用できるレベルを示しています。
表 12 暗号化レベル値の意味
説明
40 ビット暗号化キーを使用します
56 ビット暗号化キーを使用します
128 ビット暗号化キーを使用します
128 ビット長のキーを使用する暗号化は、一般に「高度」暗号化と認められています。ほかの設定は、そのレベルに応じて保護力は低下しますが、パフォーマンスは向上します。ある程度のレベルの暗号化は必要であるが、より良いパフォーマンスを得るために、抑止レベルが低下することを受け入れるつもりである場合に適しています。
クライアントとサーバーの両方が暗号化を要求し、一方が他方よりも強度の高い暗号化レベルを指定した場合、2 つのエンティティは強度の高いレベルを使って通信します。クライアントとサーバーの両方が暗号化を要求し、一方が他方よりも強度の高い暗号化レベルを指定した場合、2 つのエンティティは強度の高いレベルを使って通信します。
通信プロトコル
[通信プロトコル]には次の設定が含まれています。
自動再接続タイムアウト
自動再接続の有効化(Windows のみ)
リッスン IP アドレス
NetBIOS ポート(ワークグループ エンジンのみ)
サポート プロトコル
TCP/IP マルチホーム
TCP/IP ポート
自動再接続タイムアウト
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Numeric
45 - 65535
180
はい
この設定は、接続不能となる前にクライアントがサーバーにどれだけの時間接続を試行するかを指定します。自動再接続が有効になっているクライアントが、最初に自動再接続が有効なサーバーに接続したとき、サーバーはこの値をクライアントに通知し、両方のコンポーネントがネットワーク中断イベントでどれだけの時間再接続を試行するかがわかるようにします。
自動再接続の有効化(Windows のみ)
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Boolean
オン
オフ
オフ
なし
はい
この設定は、ネットワークの中断時にクライアントが再接続を試行することをサーバーにサポートさせるかどうかを指定します。オンに設定すると、自動再接続が有効になります。
自動再接続は、この設定をクライアント側の設定でも有効にしておかない限り、そのクライアント接続では有効になりません。
接続不能となる前にクライアントがサーバーにどれだけの時間再接続を試行するかを指定します。前述の自動再接続タイムアウトを参照してください。
リッスン IP アドレス
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
String
有効な IP アドレス(単独または複数)。複数のアドレスの場合は各アドレス間をカンマで区切ります。
0.0.0.0
なし
はい
このオプションは、[TCP/IP マルチホーム]がオフの場合に MicroKernel が受信待ちする IP アドレス(1 つまたは複数)を指定します。このオプションは、[TCP/IP マルチホーム]がオンの場合は無視されます。
複数の IP アドレスを指定できますが、その場合は各アドレス間をカンマで区切る必要があります。このアドレス文字列は IPv4 アドレスと IPv6 アドレスの組み合わせも可能です。PSQL でサポートされる IPv6 アドレス形式が使用できます。『Getting Started With PSQL』のドライブ ベースの形式を参照してください。
NetBIOS ポート(ワークグループ エンジンのみ)
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Numeric
33 ~ 254
66
なし
はい
このオプションは、MicroKernel が受信待ちをする NetBIOS ポートを指定します。サーバー エンジンでは NetBIOS をサポートしません。
サポート プロトコル
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
複数選択
次の解説を参照。
TCP/IP
なし
はい
この設定では、データベース エンジンがクライアント接続の受信待ちをするプロトコルを指定します。2 つ以上のプロトコルを指定した場合、エンジンは指定したすべてのプロトコルで接続の受信待ちをします。デフォルトは TCP/IP です。使用可能なオプションは次のとおりです。
TCP/IP
SPXII
NetBIOS
サーバーとクライアントの両方で有効なプロトコルが最低 1 つないと、通信を行うことができません。
PSQL Workgroup
NetBIOS が有効なのは PSQL Workgroup のみで、PSQL Server では無効です。
Linux および OS X
Linux または OS X プラットフォームで動作する PSQL でサポートされるプロトコルは TCP/IP のみです。したがって、サポート プロトコルの設定は、これらの環境では使用できません。
TCP/IP マルチホーム
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Boolean
オン
オフ
オン
なし
はい
このオプションは、データベース エンジンがすべてのネットワーク インターフェイスでクライアント接続の受信待ちをするかどうかを指定します。オンに設定した場合、データベース エンジンはすべてのネットワーク インターフェイスで受信待ちをし、[リッスン IP アドレス]オプションの IP アドレスは無視されます。この設定をオフにする場合は、クライアント通信に使用するデータベース エンジンへのアドレスを[リッスン IP アドレス]に指定する必要があります。
TCP/IP ポート
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Numeric
256 ~ 65535
1583
なし
はい
これは、リレーショナル エンジンで使用されるポート番号を設定します。
このポート番号は、このサーバーを指定するクライアント DSN に定義されたものと同じ番号である必要があります。クライアント DSN でポート番号を変更する方法については、『ODBC Guide』の詳細な接続属性を参照してください。
ポートに関する詳細については、『Getting Started With PSQL』のデフォルトの通信ポートの変更を参照してください。
ファイル互換性
[ファイル互換性]には次の設定が含まれています。
作成ファイルのバージョン
システム データ
作成ファイルのバージョン
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
単一選択
6.x - 9.x
9.x
なし
いいえ
この設定は、新しく作成されるすべてのファイルの形式を指定します。10.x のデータベース エンジンは、既存のファイル形式を使用してファイルに書き込みができます。つまり、書き込みを行うとき、バージョン 7.x のファイルにはバージョン 7.x のファイル形式、バージョン 8.x のファイルにはバージョン 8.x のファイル形式、というように適切なファイル形式を使用します (10.x のデータベース エンジンは、5.x、6.x、7.x、8.x、および 9.x バージョンで作成されたファイルの読み取りが可能です。)
バージョン 6.x、7.x、または 8.x は、旧バージョンの MicroKernel と互換性を保つ必要がある場合にのみ指定します。以前のファイル バージョンを指定しても、既存の 9.x ファイルには影響しません。
メモ: 辞書ファイル(DDF)は 6.x またはそれ以降のファイル形式で作成する必要があります。データベースの新規作成ウィザードは[作成ファイルのバージョン]設定を使用します。データ ファイルは、サポートされている以前のファイル形式のいずれでもかまいません。DDF だけは 6.x またはそれ以降のファイル形式を使用する必要があります。
システム データ
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
単一選択
次の解説を参照。
必要な場合
なし
いいえ
システム データは各レコード内の隠されている重複のないキーを参照します。MicroKernel はトランザクション一貫性保守を確実にするのに行を一意に識別できることが必要なため、ファイルは重複のないキーを定義するかまたはシステム データを含める必要があります。デフォルト値は[必要な場合]です。使用可能な値は、次のとおりです。
なし]。デフォルトでは、システム データはファイル作成時に追加されません。Create オペレーションを使用するアプリケーション開発者はこの設定を無効にして変更することができます。
必要な場合]。ファイルが、重複のないキーを持たない場合、ファイル作成時にそのファイルにシステム データが追加されます。
常時]。ファイルが、重複のないキーを持つかどうかに関係なく、システム データが、ファイル作成時に常に追加されます。
メモ: システム データ設定は既存のファイルには影響しません。この設定は新規ファイルがどのように作成されるかにのみ影響します。

[システム データの作成]を有効にしないで作成され、重複のないキーを持たないファイルにトランザクション一貫性保守を適用したい場合は、[システム データの作成]を[常時]または[必要な場合]に設定した後、ファイルを再作成する必要があります。

リレーショナル エンジンは常に、システム データを含むファイルを作成します。この情報は、SQL、OLE-DB、JDBC、また Btrieve API 以外のあらゆる方法で作成されたファイルに当てはまります。
インデックスはユーザーによって削除されることがあるため、ファイルが重複のないキーを持っている場合でも、システム データを追加したい場合があります。
データ整合性
[データ整合性]には次の設定が含まれています。
選択ファイルのアーカイブ ロギング
起動時間制限
オペレーション バンドル制限
トランザクション一貫性保守
トランザクション ログ
ウェイト ロック タイムアウト
選択ファイルのアーカイブ ロギング
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Boolean
オン
オフ
オフ
なし
はい
この設定は、ファイルのバックアップを容易にするアーカイブ ログを MicroKernel に実行させるかどうかを指定します。システム障害が発生した場合、アーカイブ ログ ファイルおよび BUTIL -ROLLFWD コマンドを使用して、最後にバックアップを取ったときからシステム障害が発生するまでの間にファイルに加えられた変更を修復できます。
MicroKernel にアーカイブ ログを実行させるには、アーカイブ ログを実行するファイルのあるボリュームにアーカイブ ログ設定ファイルを作成し、エントリを追加することによりファイルを指定する必要があります。アーカイブ ログの詳細については、アーカイブ ログおよび Continuous オペレーションについてを参照してください。
起動時間制限
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Numeric
1 - 1800000
10000
ミリ秒
いいえ
この設定は、システム トランザクションを起動させるタイム リミットを指定します。MicroKernel は、[オペレーション バンドル制限]か[起動時間制限]のいずれかで設定された値に達した場合、またはキャッシュの再利用が必要な場合に、システム トランザクションを起動します。
オペレーション バンドル制限
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Numeric
1 ~ 65535
65535
なし
いいえ
このオプションは、システム トランザクションを起動するのに必要なオペレーション(1 つの任意のファイルで実行)の最大数を指定します。MicroKernel は、[オペレーション バンドル制限]か[起動時間制限]のいずれかで設定された値に達した場合、またはキャッシュの再利用が必要な場合に、システム トランザクションを起動します。
MicroKernel Database エンジンでは、各ユーザー トランザクション(Begin Transaction から End Transaction または Abort Transaction まで)が 1 つのオペレーションとして扱われます。たとえば、Begin Transaction オペレーションと End Transaction オペレーションの間に 100 の Btrieve オペレーションがある場合、Begin Transaction オペレーションと End Transaction オペレーションを含む 102 の Btrieve オペレーションが、1 つのオペレーションとして扱われます。
トランザクション一貫性保守
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Boolean
オン
オフ
オフ
なし
はい
トランザクション一貫性保守は、システム障害時に正常終了していたトランザクションがデータ ファイルにコミットされることを保証する点以外はトランザクション ログと同じです。
トランザクション ログとトランザクション一貫性保守の詳細については、トランザクション ログおよびトランザクション一貫性保守を参照してください。
メモ: [トランザクション一貫性保守]をオンにしている場合、一部のファイルで、トランザクションの一貫性が保守されないことがあります。ファイルは、少なくとも 1 つは重複のないキーを含んでいるか、ファイル作成時に[システム データ]設定が "常時" または "必要な場合" に設定されている必要があります。そうしないと、ファイルに対する変更はトランザクション ログに書き込まれません。トランザクション一貫性保守およびシステム データの詳細については、『PSQL Programmer's Guide』を参照してください。

システム データは既存のファイルには影響しないため、重複のないキーを持たず、[システム データの作成]を有効にしないで作成したファイルは再作成する必要があります。これらのファイルを再作成する前に[システム データの作成]を必ず有効にしてください。
注意: ゲートウェイ ロケーター ファイルにより、同一ファイル サーバー上の異なるディレクトリにある複数のファイルを異なるエンジンが管理することができます。データベースが異なるディレクトリにある複数のファイルを含んでいる場合は、データベース内のすべてのデータ ファイルを同一データベース エンジンで管理する必要があります。同一データベース内のファイルを複数のデータベースで管理する場合、データベースの整合性およびトランザクション アトミシティは保証されません。起こり得る問題を回避する方法については、リダイレクト ロケーター ファイルの作成を参照してください。
関連する設定
詳細については、トランザクション ログにある同様の「関連する設定」を参照してください。
トランザクション ログ
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Boolean
オン
オフ
オン
なし
はい
この設定は、データ ファイルに影響するすべてのオペレーションをログに記録することにより、MicroKernel がトランザクションのアトミシティを確実にするかどうかを制御します。
関連する[トランザクション一貫性保守]の設定がオンになっている場合、ロギングは自動的に行われ、[トランザクション ログ]設定は無視されます。
トランザクション ログとトランザクション一貫性保守の詳細については、トランザクション ログおよびトランザクション一貫性保守を参照してください。
メモ: [トランザクション ログ]をオンにしている場合、一部のファイルで、トランザクションの一貫性が保守されないことがあります。ファイルは、少なくとも 1 つは重複のないキーを含んでいるか、ファイル作成時に[システム データ]設定が "常時" または "必要な場合" に設定されている必要があります。そうしないと、ファイルに対する変更はトランザクション ログに書き込まれません。トランザクション一貫性保守およびシステム データの詳細については、開発者リファレンスの『PSQL Programmer's Guide』を参照してください。

システム データは既存のファイルには影響しないため、重複のないキーを持たず、[システム データの作成]を有効にしないで作成したファイルは再作成する必要があります。これらのファイルを再作成する前に[システム データの作成]を必ず有効にしてください。
注意: 使用するデータベースがデータ ファイル間のトランザクション アトミシティを必要としない場合を除いては、トランザクション ログの設定をオフにしないでください。トランザクション ログがオフに設定されている場合、複数ファイルのデータベースのデータの整合性は保証されません。

[トランザクション ログ]の設定をオフにすることを、使用するアプリケーションのベンダーがサポートしていない場合は、オフにしないでください。
関連する設定
サーバー設定の[トランザクション一貫性保守]はトランザクション ログに似ていますが、より高レベルのデータ安全性を提供し、パフォーマンスは低レベルとなります。サーバーの設定にある[ログ バッファー サイズ]および[トランザクション ログ サイズ]はトランザクション ログと関連しています。[ログ バッファー サイズ]を使用すると、トランザクション一貫性保守とパフォーマンスとのバランスを構成することができます。ログ バッファーが大きいほどディスクに書き込まれる回数が少ないため、パフォーマンスが向上します。ただし、ログ バッファー内のデータベースの変更はシステム障害が起こった場合保守されません。
トランザクション ログ サイズ]は、新しいセグメントを開始する前に各ログ ファイル セグメントがどれだけのサイズになることができるかを制御します。
Btrieve または SQL トランザクションが使用されない場合は、これらすべての設定は無視されることに注意してください。
ウェイト ロック タイムアウト
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Numeric
0 - 2147483647
30000
ミリ秒
はい
レコード ロックの競合が発生した場合、データベース エンジンとそのクライアントは同等の再試行メカニズムを使用します。エンジンは、ウェイト ロック タイムアウト時間内に要求されたレコードのロックを取得できなかった場合には、該当するステータス コードと共に制御をアプリケーションに返します。
ウェイト ロック タイムアウトの利点
ウェイト ロック タイムアウト設定は、ロックの競合が発生した場合に次のような利点をもたらします。
データベース エンジンは、ロックの解除を待つ間にもリクエストの処理を続行できる
複数のスレッドがロックされたリソースを待っている場合、スレッド キューの能力が向上する
ネットワーク トラフィックが軽減することによって、ネットワークのパフォーマンスが向上する
ウェイト ロック タイムアウトを適用する状況
ウェイト ロック タイムアウトが適用されるのは、次の 2 種類のアプリケーションのみです。
リレーショナル エンジンを使用するアプリケーション。
再試行する必要がない 1 つの変更操作を実行する Btrieve アプリケーション。このようなアプリケーションは、1 秒またはウェイト ロック タイムアウト値のうち、いずれか短い方の時間内にロック エラーを受け取ります。
通常、ウェイト ロック タイムアウトは、Windows、Linux、または OS X 上の PSQL クライアントを介して MicroKernel エンジンを使用する Btrieve アプリケーションには適用されません。その代りに、このようなアプリケーションは次のいずれかの操作を行います。
"ノーウェイト" ロック バイアス(200, 400)付きの読み取り操作、または "書き込みノー ウェイト" ロック バイアス(500)が適用されている書き込み操作の場合、ページまたはロックの競合エラーを直ちに受け取ります。
"書き込みノー ウェイト" ロック バイアス(500)が適用されていない非トランザクショナル書き込み操作の場合、1 秒またはウェイト ロック タイムアウト値のうち、いずれか短い方の時間内にページまたはロックの競合エラーを直ちに受け取ります。
関連する操作が、"ウェイト" ロック バイアス(100, 300)付きの読み取り操作の場合は、無限に待機します。
関連する操作が、トランザクション内の書き込み操作であり、かつ、"書き込みノー ウェイト" ロック バイアス(500)がその操作またはトランザクションに適用されていない場合は、無限に待機します。
ページまたはロックの競合エラーを受け取った際、アプリケーションは、再試行、待機、または他のオプションのどの方法でその競合を処理するか判断することができます。
ページ ロックへの対処
MicroKernel エンジン API は、レコード ロック状況を処理するための制御を提供します。詳しい説明については、PSQL 開発者用ドキュメントの『Btrieve API Guide』を参照してください。ここでは、制御のメカニズムを簡単に説明します。
明示的レコード ロック - 読み取り操作にロック バイアス(100、200、300 または 400)を加えると、レコードの読み取り時にウェイトするかどうかを指定できます。これらのバイアスは Begin Transaction オペレーションに適用することもできます。
トランザクション中の暗黙ページ ロック - ほとんどのページ ロックの競合は行レベルのロックであるために回避されますが、ロック バイアス 500 を加算すれば、トランザクションがページ ロックの発生によってウェイト状態になることを避けられます。
排他ファイル ロック - 明示的ファイル ロックを避けるために並行トランザクションを使用します。ファイルを排他的に開けなかった場合、リクエストは常に直ちに返されます。
デバッグ
[デバッグ]には次の設定が含まれています。
データ バッファーのバイト数
キー バッファーのバイト数
トレースするオペレーションの選択
トレース ファイルのロケーション
トレース オペレーションの実行
データ バッファーのバイト数
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Numeric
0 - 65535
128
バイト
いいえ
この設定は、MicroKernel がトレース ファイルに書き込むデータ バッファーのサイズを指定します。この設定を使用するには、[トレース オペレーションの実行]設定をオンにしておく必要があります。指定するサイズは、必要とするトレースのレベル(データ全体のバッファーの内容を確認する必要があるのか、またはあるレコードを特定できるだけのバッファー内容があれば十分なのかなど)に左右されます。
キー バッファーのバイト数
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Numeric
0 - 255
128
バイト
いいえ
この設定は、MicroKernel がトレース ファイルに書き込むキー バッファーのサイズを指定します。この設定を使用するには、[トレース オペレーションの実行]設定をオンにしておく必要があります。指定するサイズは、必要とするトレースのレベル(キー全体のバッファー内容を確認する必要があるのか、またはあるキーを特定できるだけのバッファー内容があれば十分なのかなど)に左右されます。
トレースするオペレーションの選択
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
複数選択
次の解説を参照。
すべて
なし
いいえ
トレースされる Btrieve API オペレーション コードにはチェックマークが付けられています(選択されています)。リストからトレースするオペレーションを選択します。
Abort Transaction (21)
Get Position (22)
Begin Transaction (19)
Get Previous (7)
Clear Owner (30)
Get Previous Extended (37)
Close (1)
Insert (2)
Create(14)
Insert Extended (40)
Create Index (31)
Open (0)
Delete (4)
Reset (28)
Drop Index (32)
Set Directory (17)
End Transaction (20)
Set Owner (29)
Extend(16)
Stat (15)
Find Percent (45)
Step First (33)
Get By Percent (44)
Step Last (34)
Get Direct/Chunk (23)
Step Next (24)
Get Directory (18)
Step Next Extended (38)
Get Equal(5)
Step Previous
Get First(12)
Stop (25)
Get Greater (8)
Step Previous Extended (39)
Get Greater or Equal (9)
Unlock (27)
Get Last(13)
Update (3)
Get Less or Equal (11)
Update Chunk (53)
Get Less Than (10)
Version (26)
Get Next (6)
 
Get Next Extended (36)
 
トレース ファイルのロケーション
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
String
適用外
file_path\PSQL\bin\mkde.tra
なし
いいえ
この設定は、MicroKernel がトレース情報を書き込むトレース ファイルを指定します。ファイル名には、ドライブまたはボリュームの指定およびパスが含まれていること、もしくは UNC パスを使用していることが必要です。トレース ファイルをデフォルトのロケーションに配置しない場合は、別のパスやファイル名を入力します。
PSQL ファイルのデフォルトの保存場所については、『Getting Started With PSQL』の PSQL ファイルはどこにインストールされますか?を参照してください。
メモ: ODBC トレースと MicroKernel トレースに同じトレース ファイル名を使用しないでください。
トレース オペレーションの実行
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Boolean
オン
オフ
オフ
なし
いいえ
この設定は、各 Btrieve API 呼び出しをトレースし、その結果をファイルに保存することを可能にするトレース機能を有効にするかどうかを指定します。開発者は、トレース機能を使用するとアプリケーションのデバッグができます。MicroKernel は、強制書き込みモードを使用してトレース ファイルに書き込みを行うため、MicroKernel が正常にアンロードされなかった場合でも、データがファイルに書き込まれます。MicroKernel のパフォーマンスは、リクエストを受け取る頻度によって大幅に影響を受けることがあります。このオプションを有効にする場合は、[トレース ファイルのロケーション]を指定してください。
メモ: トレースを開始または終了するためにエンジンを再起動する必要はありません。トレースのオン/オフは実行中に行ってエンジンに直接変更を適用することができます。PCC から、変更を有効にするためにエンジンを再起動するようにメッセージが表示されても、この設定については無視してかまいません。
ディレクトリ
[ディレクトリ]には次の設定が含まれています。
DBNames 設定ファイルのディレクトリ
トランザクション ログのディレクトリ
作業ディレクトリ
DBNames 設定ファイルのディレクトリ
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
String
適用外
環境による
なし
はい
この設定は、データベース名設定ファイルの別のロケーションへのパスを指定します。
サーバー エンジンの場合、ディレクトリ パスではなくローカル ファイルのパスです。ワークグループ エンジンの場合、ワークグループ MicroKernel にアクセス可能なリモート パスを指定できます。デフォルト値は、エンジンのプラットフォームによって異なります。
Windows プラットフォーム: application_data_directory\
Linux または OS X サーバー: /usr/local/psql/etc
設定ファイルをデフォルトのロケーションに配置しない場合は、有効なパスを入力します。
トランザクション ログのディレクトリ
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
String
適用外
環境による
なし
はい
この設定は、MicroKernel が、トランザクション ログを保存するために使用するロケーションを指定します。パスは有効なパスであり、ドライブまたはボリュームの指定か UNC パスが含まれている必要があります。デフォルト値は、オペレーティング システムによって異なります。
エンジンは、トランザクション一貫性保守またはトランザクション ログの設定がオンでない場合、この設定を無視します。
注意: 複数のデータベース エンジンで同一のディレクトリを使用しないでください。たとえば、2 つ以上のエンジンのトランザクション ログ ディレクトリとしてリモート サーバーのディレクトリを設定すると便利だと思われるかもしれません。しかし、エンジンは、ログのロール フォワードを実行する必要が生じた場合、どのトランザクション ログ セグメントがどのエンジンによって使用されているかを判断できません。
データベース エンジンを頻繁に使用すると見込まれる場合は、データ ファイルが存在するのとは物理的に別のボリュームにトランザクション ログが保持されるようにシステムを構成する必要があります。高負荷の下では、単一ドライブで I/O 帯域幅を競う代わりに、ログの書き込みとデータ ファイルの書き込みを別のドライブに分ける方が一般的にパフォーマンスがよくなります。トランザクション ログの詳細については、トランザクション ログおよびトランザクション一貫性保守を参照してください。
作業ディレクトリ
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
String
適用外
データ ファイルと同一ディレクトリ
なし
はい
この設定は、多数のインデックスを作成するようなオペレーションで、テンポラリ ファイルを保存するために使用される MicroKernel 作業ディレクトリのロケーションを指定します。ディスク容量に制限がある場合は、このオプションを使用して十分な空き容量があるボリュームに作業ディレクトリを指定できます。
デフォルト値はありません。ただし、作業ディレクトリを指定しない場合、データ ファイルのロケーションがデフォルトになります。作業ディレクトリを指定するには、[作業ディレクトリ]フィールドにパスを入力します。パスには、ドライブまたはボリュームの指定か UNC パスが含まれている必要があります。
情報
情報には、次のような表示のみの項目が示されます。
表示のみの項目
説明
サーバー名
データベース エンジンが実行されているマシンの名前。
エンジンのバージョン
データベース エンジンのリリース バージョン。
エンジンの種類
データベース エンジンの製品カテゴリ。たとえば、「サーバー」や「ワークグループ」。
メモリの使用
[メモリの使用]には次の設定が含まれています。
起動時のリソース割当
非アクティブ時、最小の状態に戻す
最小の状態に戻す待ち時間
ソート バッファー サイズ
システム キャッシュ
起動時のリソース割当
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Boolean
オン
オフ
オフ
なし
はい
この設定は、MicroKernel の起動時に、スレッドやメモリ バッファーを含むリソースを割り当てるように MicroKernel に指示します。起動時のリソース割り当てには L1 キャッシュに加えてバックグランド スレッドも含まれます。PSQL コンポーネントは必要に応じてリソースを自動的に割り当てます。このため、ほとんどの場合、この設定はオフ(デフォルト)にすることができます。
この設定がオフの場合、最初のオペレーションが要求されるまでリソースが割り当てられません。お使いのシステムが多数のユーザーをサポートする場合は、この設定をオンにする方が適切です。
この設定を初めてオンにしたときに、Windows の動作方法のため、メモリの割り当てに顕著な違いが見られないかもしれません。MicroKernel がその L1 キャッシュを割り当てる場合、Windows オペレーション システムは単にメモリのページを確保するだけで、実際にそれらを MicroKernel にはコミットしまません。その後、MicroKernel が実際にキャッシュ メモリにアクセスすると、Windows は実際の物理ページをコミットするので、PSQL コンポーネント(ntdbsmgr や w3dbsmgr など)のメモリ使用が増加します。
Windows タスク マネージャーで "仮想メモリ サイズ" を見ると、L1 キャッシュがアクセスされたときにメモリの値が変化することがわかります。バックグランド スレッドがアクセスされたときにスレッド数が変わることもわかります。
非アクティブ時、最小の状態に戻す
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Boolean
オン
オフ
オフ
なし
はい
この設定により、アクティブなクライアントが存在しない状態で一定の時間が過ぎると、MicroKernel は、大部分のメモリ容量およびスレッド リソースをシステムに解放し、最小の状態に戻ります。その時間は、[最小の状態に戻す待ち時間]の値で設定します。ほかのクライアントがアクティブになった場合は、MicroKernel により、リソースが再度割り当てられます。
最小の状態に戻す待ち時間
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Numeric
0 - 2147483647
300000
ミリ秒
はい
この設定は、MicroKernel が最小の状態に戻る前に非アクティブ状態でどれだけ待機するかを指定します。(最小の状態とは、MicroKernel 起動時の初期状態です。)MicroKernel を最小の状態に戻すと、大部分の容量のメモリとスレッド リソースがシステムに解放されます。MicroKernel を最小の状態に戻したくない場合もあります。たとえば、繰り返し MicroKernel を使用するバッチ ファイルを使用中の場合などです。ほかのクライアントがアクティブになった場合は、MicroKernel により、リソースが再度割り当てられます。
この設定は、[非アクティブ時、最小の状態に戻す]にオフ(デフォルト)が設定されている場合は無視されます。
ソート バッファー サイズ
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Numeric
0 - メモリによって制限される
0
バイト
はい
この設定は、ランタイムでインデックスを作成中に MicroKernel がソートのために動的に割り当てる、または割り当てを解除するメモリの最大容量(キロバイト単位)を指定します。
ソート用に指定されたサイズ以上のメモリが必要な場合、または利用可能な処理メモリの 60 % 以上を占める場合は、MicroKernel により、テンポラリ ファイルが作成されます。処理に必要な利用可能メモリの量は、動的な値で、システムの設定や負荷によって変化します。0 キロバイトを指定すると、MicroKernel は、利用可能なメモリのうち最大 60 % まで、必要なだけのメモリを割り当てます。
システム キャッシュ
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Boolean
オン/オフ
オフ(サーバー エンジン)
オン(ワークグループ エンジン)
なし
はい
このオプションは、MicroKernel が、MicroKernel 自体のキャッシュ割当サイズに加え、設定プロパティで指定したシステム キャッシュを使用するかどうかを指定します。
L2 キャッシュを使用している場合は、[システム キャッシュ]をオフに設定する必要があります。MicroKernel の最大メモリ使用量の設定を確認してください。[MicroKernel の最大メモリ使用量]にゼロより大きい値が設定されている場合は、L2 キャッシュを使用しています。
L2 キャッシュを使用していない場合は[システム キャッシュ]をオンにすると、パフォーマンスが向上します。MicroKernel は書き出すページを構成したりグループ化するのにシステム キャッシュを使用します。システム キャッシュがより効果的にページをディスクに書き出せるようにフラッシュを十分に遅らせます。ただし、サーバーにキャッシュ付きのディスク アレイがある場合は[システム キャッシュ]の設定をオフにすることにより、より良いパフォーマンスを得られることがあります。
Windows サーバーの場合のみ、Windows パフォーマンス モニター ユーティリティのページング ファイルおよびプロセス オブジェクトを使用して Windows のシステム キャッシュが効率的に使用されているかをチェックできます。NTDBSMGR インスタンスの場合は、ページ ファイル オブジェクトの[% 使用]および[% 最大使用]をモニターし、プロセス オブジェクトの[Page Fault/sec]および[Page File Bytes]をモニターします。
パフォーマンス チューニング
[パフォーマンス チューニング]には次の設定が含まれています。
自動最適化
キャッシュ割当サイズ
通信スレッド数
ファイルの拡張係数
インデックス バランスの実行
セグメント サイズを 2 GB に制限
ログ バッファー サイズ
MicroKernel の最大メモリ使用量
I/O スレッド数
トランザクション ログ サイズ
自動最適化
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Boolean
オン
オフ
オフ
なし
いいえ
この設定は、自動最適化をオンまたはオフにします。オンの場合には、この機能は次のように動作します。
設定がオンになった 1 時間後から、エンジンは最適化対象のファイルの検出を開始します。
エンジンはまず、前回エンジンが再起動した以降にアクティブになったファイルを識別します。
エンジンは次に、残りのファイルについて、以下の条件のいずれかを満たしているか調べます。
 
分析
以上
断片化
15%
未使用
15%
順序不同
5%
これらの条件は、ウォッチ リスト トピックで定義されたものと同じです。自動最適化の利点として、ファイルの選択や[ウォッチ リスト]への追加を手動で行う必要がなく、また、その後ファイルの確認や最適化も手動で行う必要がありません。
これらの条件のいずれかを満たす最初のファイルから、最適化が直ちに開始されます。
エンジンは 1 度に 1 つのファイルを最適化します。1 つのファイルの処理が終わると、次のファイルの最適化を始めるまでに 1 分間待機します。
効率化のため、次の条件を満たすファイルは対象から外れます。
24 時間以内に最適化されている
サイズが 10 MB 未満
このようなファイルを最適化する場合には、[ウォッチ リスト]にファイルを追加して手動で監視するようにするか、または dbdefrag ユーティリティを使用します。
自動最適化の条件を満たすすべてのファイルの最適化が終了すると、エンジンは次の回のファイル検出を始めるまでに 60 分間待機します。
pvsw.log のメッセージには、ファイルが自動で最適化されたか手動で最適化されたかが記されます。
メモ: アクティブなファイルが閉じられ、キャッシュからそのページが削除された場合、エンジンはそのファイルを自動最適化の候補と見なさなくなります。次にファイルが開かれたとき、エンジンは再度それを検出します。
データの最適化の詳細については、データ ファイルの断片化の監視を参照してください。
キャッシュ割当サイズ
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Numeric
1 メガバイトからメモリによって制限される量
(後述の「メモ」を参照してください)
最初の起動時に動的に初期化される
メガバイト
(後述の「メモ」を参照してください)
はい
この設定は、MicroKernel によって割り当てられるレベル 1 キャッシュのサイズを指定します。MicroKernel では、すべてのデータ ファイルへのアクセスにこのキャッシュが使用されます。
ごく一般的に言うと、[キャッシュ割当サイズ]の値がシステム上の物理メモリの 40 % より小さく、設定情報の[MicroKernel の最大メモリ使用量]が 40% より大きい値に設定されている場合に、全体のパフォーマンスは最高になります。最適な設定は、データ ファイルのサイズ、システム上で実行されるほかのアプリケーションの数、およびコンピューターにインストールされているメモリの量によって変わります。
サーバー エンジン
Windows では、この設定は、データベース エンジンが初めて起動されたときに物理メモリの 20% に設定され、その値がレジストリに書き込まれます。その後は、エンジンが起動するたびにレジストリから値を読み取ります。設定プロパティを使用して値を変更すると、レジストリの値も更新されます。システムにメモリを追加したり取り除いたりした場合には、新しく使用可能になったメモリを最大限活かせるようにこの設定を変更する必要があります。
パフォーマンスを最適化するには、使用中のファイルの合計サイズより小さいサイズをキャッシュに割り当てますが、特に、サーバーがほかのアプリケーションを実行しているときは、利用可能なメモリをすべてキャッシュに割り当ててしまわないように注意します。必要以上に大きい値を指定しても、メモリを無駄に使用するだけで、パフォーマンスの向上を図ることはできません。
ワークグループ エンジンおよびクライアント キャッシュ
データベース エンジンは、初めて起動されたときにこの値を設定し、レジストリに書き込みます。この初期値には物理メモリの 20% が設定されます。キャッシュの最大サイズはシステムのメモリの容量に応じて異なりますが、データベース エンジンは 64 MB を初期最大値に設定します。レジストリ設定が初期化されると、エンジンは起動されるたびにレジストリからこの値を読み取ります。エンジンがこの設定を再計算することはありません。設定プロパティを使用して値を変更すると、レジストリの値も更新されます。システムにメモリを追加したり取り除いたりした場合には、新しく使用可能になったメモリを最大限活かせるようにこの設定を手動で変更する必要があります。
クライアント キャッシュ
設定の[キャッシュ エンジンの使用]がオンに設定されている場合、この情報はクライアント ソフトウェア(クライアント キャッシュ)にも適用されます。
メモ: PSQL v10 より前の PSQL クライアントを使用する場合、キャッシュ割当サイズの値はバイト単位で指定する必要があります。最小の 64KB(65,536 バイト)が指定されます。最大値はメモリ容量によって制限されます。
通信スレッド数
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Numeric
プロセッサのコア数 ~ 256
プロセッサのコア数。このプロセッサのコア数は、データベース エンジンが起動しているマシンのプロセッサ数です。
なし
はい
この設定は、リモート クライアントからのリクエストを処理するために MicroKernel が最初に作成するスレッドの数を指定します。通信スレッドは、リクエストを行うクライアント プロセスに代わって、実際に Btrieve オペレーションを実行する要素です。このように、通信スレッドはワーカ スレッドによく似ています。通信スレッドは許容される最大範囲まで、必要に応じて動的に増加します。最大値は、256 です。
通信スレッドの設定は、ある特定の状況下における改善に役立ちます。たとえば、1 つのファイルに対して多くのクライアントが操作(主に書き込み)を行うような場合、より低い値を設定すればスケーラビリティが向上するはずです。スレッド数の値をより低くすると、システム リソースでコンテキスト スイッチを行わないようにします。このほか、大量のワーカー スレッド間でスラッシングによって速度低下が発生する状況も、この通信スレッドの設定によって改善する可能性があります。ワーカー スレッドは、既存の全スレッドがレコードまたはファイルのロックで待機している場合にのみ動的に作成されます。
ファイルの拡張係数
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Numeric
0-100
15
パーセント
はい
この値は、バージョン 8.x 以降の形式のデータ ファイル内に保持する空きページの概算パーセントを指定します。この設定は、旧バージョンの形式のファイルには適用されません。MicroKernel では、この値を使用して、ファイルを拡張するか空きページを最初に使用するかを決定します。データベース エンジンは Turbo Write Accelerator を使用するので、ディスク書き込みのパフォーマンスは、ファイル内の空きページ数が増加するにつれて向上します。このようにパフォーマンスが向上するのは、そのデータベース エンジンが複数の連続したファイル ページをディスク上に書き込むことができるからです。したがって、ディスク書き込みのパフォーマンスとファイルのサイズは互いに相殺関係にあります。ただし、ファイルに空きページが多すぎると実際には全体のパフォーマンスを落とします。
データ ファイル内に一定の連続した空きページを保持するためには、データベース エンジンが定期的にそのデータ ファイルを拡張する必要があります。この設定がファイルのサイズに影響があることを覚えておいてください。たとえば、空きページのないファイルで作業するときに、[ファイルの拡張係数]の値に 50% を指定した場合、そのファイルのサイズは最終的に 2 倍になります。[ファイルの拡張係数]の値に 75% を指定した場合、そのファイルのサイズは 4 倍になります。90% を指定した場合、そのサイズは 10 倍近くになります。
完全に使用しないページのみが空きページとみなされることに注意してください。ページのなかには途中までしか使用していないページもあるので、15% の空きページといった場合、ファイルの 15% が使用されないという意味ではありません。
この値は MicroKernel への単なる指示です。ファイルが更新される度合いによって、実際の空き領域のパーセンテージはいつでも小さくすることができます。
この設定は、バージョン 8.x より前の形式のファイルには適用できません。旧バージョンの形式のファイルにも空きページがあり、そのファイルの動作状況によって空きページのパーセンテージは異なります。
インデックス バランスの実行
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Boolean
オン
オフ
オフ
なし
はい
この設定は、MicroKernel が、インデックス バランスを実行するかどうかを制御します。インデックス バランスにより、読み取りオペレーションのパフォーマンスは向上します。しかし、このオプションを有効にすると、時間がさらにかかり、挿入、更新、削除オペレーション時にさらにディスクの I/O が必要な場合があります。インデックス バランスの詳細については、『PSQL Programmer's Guide』を参照してください。
セグメント サイズを 2 GB に制限
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Boolean
オン
オフ
オン
なし
はい
この設定は、データ ファイルのサイズがオペレーティング システムのファイル セグメントの上限である 2 GB を超えるごとに、ファイルを自動的に分割するかどうかを指定します。オンに設定した場合、データ ファイルは 2 GB のセグメントに分割されます。オフに設定した場合、データ ファイルはセグメント化されず単一のファイルのままです。セグメント化されていない大きなファイルを使用する利点は、ディスク I/O が効率的であるということです。このため、パフォーマンスの向上が期待できます。
セグメント化されていないファイルは、お使いのオペレーティング システムで指定されているファイル サイズの制限を受けます。以前作成したファイルが既にセグメント化されている場合、そのセグメントはファイル上でそのまま残ります。
ファイル バージョンの自動アップグレードの関連情報も参照してください。
ログ バッファー サイズ
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Numeric
262144 - メモリによって制限される
次の値のうち、小さい方の値:
(MB 単位の物理メモリ / 256)
または 8 MB
バイト
はい
この設定は、MicroKernel によって使用されるトランザクション ログ バッファーおよびアーカイブ ログ バッファーのサイズを指定します。ログ バッファーのサイズを増やすことにより、MicroKernel がログ情報をディスクに書き込む回数が減るため、パフォーマンスの向上が図れます。
メモ: ログ バッファー サイズ]に[トランザクション ログ サイズ]より大きい値を設定すると、MicroKernel は[トランザクション ログ サイズ]の値を[ログ バッファー サイズ]に指定した値に自動的に変更します。
MicroKernel の最大メモリ使用量
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Numeric
0-100
60
パーセント
いいえ
この設定は、総物理メモリに対して MicroKernel が消費できるメモリの割合を指定します。MicroKernel による L1、L2 およびその他すべてのメモリの使用量が含まれます(リレーショナル エンジンは含まれません)。データベース エンジンは、指定した割合が必要でないか使用できない場合は、これより少ないメモリを使用します。
値にゼロ(0)を指定すると、動的キャッシュはオフになります。この場合、使用できるキャッシュは L1 のみで、[キャッシュ割当サイズ]で指定したサイズになります。データベース サーバー専用のマシンを使用している場合、[MicroKernel の最大メモリ使用量]を最大値に設定するか、オペレーティング システムが占有しないメモリの割合を指定します。データベース サーバーでほかのアプリケーションが実行され、これらすべてとパフォーマンスのバランスをとる必要がある場合は、低い値を設定して、データベース キャッシュが利用可能なメモリを使用する場合に、ほかのアプリケーションと競合しないようにする必要があります。
メモ: キャッシュ割当サイズ]に[MicroKernel の最大メモリ使用量]の値よりも大きな物理メモリ量を設定した場合は、[キャッシュ割当サイズ]の値が優先されます。たとえば、物理メモリが 1 GB のマシンで、[キャッシュ割当サイズ]に 600 MB、[MicroKernel の最大メモリ使用量]に 40% を設定したとします。L1 キャッシュには 600 MB のメモリが割り当てられます。[キャッシュ割当サイズ]の値の方が大きいので、その値が優先され、L1 キャッシュに割り当てられるメモリ量は[MicroKernel の最大メモリ使用量]に指定された値よりも大きくなります。
次の方程式を使用して MicroKernel 最大メモリ使用量の近似値を割り出します。
(L1 キャッシュサイズ + 内部割り当て + L2 キャッシュ サイズ / 物理メモリのサイズ) * 100
各項目の説明は次のとおりです。
L1 キャッシュ サイズキャッシュ割当サイズ
内部割り当て:L1 キャッシュの約 25% のサイズ
L2 キャッシュ サイズ:システムのメモリ ロードに基づいて拡大および縮小するメモリ容量
物理メモリサイズ:マシンにインストールされているメモリ容量
パフォーマンス チューニングの詳細については、パフォーマンス チューニングを参照してください。
I/O スレッド数
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Numeric
1 ~ 1024
32
なし
はい
この設定は、MicroKernel が起動するバックグラウンドの I/O スレッドの数を指定します。これらのスレッドは、MicroKernel のキャッシュからディスク上のファイルへすべてのページをアトミックかつ調和のとれた方法で書き出す責任を果たします。また、最初にファイルを開いてファイル コントロール レコードの読み取りも行います。その他のほとんどの読み取りはローカル ワーカ スレッドおよび通信スレッドが行います。MicroKernel が、データ ファイルを更新、またはデータ ファイルに書き込みを行うと、各ファイルは、指定された I/O スレッドにシーケンシャルに割り当てられます。最後のスレッドに達すると、すべてのデータ ファイルがバックグラウンド スレッドに割り当てられるまで、MicroKernel は、処理をやり直します。MicroKernel では、必要に応じて追加の I/O スレッドを作成しないため、必要と思われる I/O スレッドの数を予想して最大数を指定します。
最適なパフォーマンスを実現するには、[最大オープン ファイル数]に基づいた値を指定します。Monitor ユーティリティは開いているファイル数の現在値とピーク値を表示します。データベースに平均 256 個のファイルがある場合、デフォルトの 32 I/O スレッドでは各スレッドが 8 ファイルを受け持つことになります。実際に即した方法として、I/O スレッドごとに、およそ 8 ファイルを持つようにします。たとえば、オープン ファイル数の平均が 400 の場合、およそ 50 個の I/O スレッドを使用します。64 より大きい値を指定するとパフォーマンスが損なわれることがありますが、これはシステムの能力によります。
メモ: この設定は、マシンの特性、OS の設定およびデータベース エンジンの作業負荷に影響されるため、適切な I/O スレッド数を正確に計算することはできません。
トランザクション ログ サイズ
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Numeric
65536 - ディスク容量によって制限される
バイト
はい
この設定は、トランザクション ログ セグメントの最大サイズを指定します。ログ ファイルが制限されたサイズに達すると、MicroKernel は、古いログ セグメント ファイルを閉じ、新しいファイルの使用を開始します。トランザクション ログ セグメントのサイズを制限することにより、MicroKernel が一時的に使用するディスク容量を少なくできるため、これを行いたいと思われるでしょう。しかし、サイズを制限すると、ログ セグメントを頻繁に閉じて作成することが必要になるため、MicroKernel の処理量が増え、パフォーマンスが低下する可能性があります。
メモ: このオプションに[ログ バッファー サイズ]で指定した値よりも小さい値を設定すると、データベース エンジンは[トランザクション ログ サイズ]の設定を自動的に[ログ バッファー サイズ]の値に合わせます。
Windows クライアント設定プロパティ
クライアントの設定オプションは、それぞれのインストレーションで設定が可能です。これらのオプションは、ワークステーションとして機能するサーバーを含め、ワークステーションごとに個別に設定する必要があります。
グラフィカル ユーティリティの PSQL Control Center やコマンド ライン インターフェイス ユーティリティの bcfg を使って、クライアントを構成することができます。PCC については、『PSQL User's Guide』の PSQL Control Center の使用を参照してください。bcfg については、CLI ユーティリティによる設定を参照してください。
次の表は、使用可能なクライアント設定オプションとその設定の対応をアルファベット順で示します。
表 13 クライアントの設定
設定オプション
プロパティ名
[キャッシュ エンジンのデバッグ]で使用できる設定は、サーバー構成にある類似した設定と同様の機能をクライアント キャッシュに対して実行します。デバッグの関連するサーバー設定を参照してください。
アクセス
[アクセス]には次の設定が含まれています。
ゲートウェイ一貫性保守
ロード再試行回数
IDS の使用
ローカル MicroKernel エンジンの使用
リモート MicroKernel エンジンの使用
ゲートウェイ一貫性保守
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Boolean
オン
オフ
オフ
なし
適用外
このオプションは、MicroKernel ルーターが、PSQL が動作していないコンピューターのリストをレジストリに保存する必要があるかどうかを指定します。レジストリに保存すると、ゲートウェイ エンジンの検索に必要な時間を短縮できます。ワークグループに新しいエンジンを追加するときは、このオプションをオフに設定する必要があります。
ロード再試行回数
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Numeric
0 ~ 65536
5
なし
適用外
この設定は、MicroKernel ルーターが、ターゲット エンジンに対して接続を再試行する回数を指定します。
IDS の使用
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Boolean
オン
オフ
オフ
なし
適用外
この設定は主に、PSQL(IDS)を使用するレガシー アプリケーションで使用されます。IDS 機能はコア製品に統合されたため、IDS を単独のインストール済みコンポーネントとして使用することはできなくなりました。IDS の統合は、クライアント/サーバー環境の再構成を必要とします。
一般的には、アプリケーションは独自のファイルの場所情報を指定します。別の方法として、IDS は、テキスト ファイル idshosts の情報に基づいてファイル場所のマッピングを指定します。
アプリケーションが idshosts によるマッピング機能を使用しない場合は、パフォーマンスを向上させるために[IDS の使用]をオフにします。
アプリケーションが既に idshosts を使用している場合、あるいはこの代替方法を使用してファイルの場所をマップしたいと考えている場合は、[IDS の使用]をオンにします。idshosts ファイルの使用を参照してください。
メモ: IDS の使用]にオンを設定した場合や、レガシー アプリケーションがファイルの場所情報を PIDS URL の形式で渡す場合には PSQL 8.5 以降が必要です。リクエスターは IDS 情報を表すのにデータベース URI を使用します。データベース URI は PSQL 8.5 で追加されました。開発者リファレンス『PSQL Programmer's Guide』のデータベース URI を参照してください。
ローカル MicroKernel エンジンの使用
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Boolean
オン
オフ
オン
なし
適用外
この設定は、ローカル アプリケーションがローカル エンジンに接続を試みるかどうかを指定します。オフに設定すると、ローカル エンジンへの接続は試行されません。
リモート MicroKernel エンジンの使用
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Boolean
オン
オフ
オン
なし
適用外
この設定は、MicroKernel ルーターが、リモート サーバーで動作している MicroKernel サーバーまたはワークグループ エンジンへのアクセスを許可するかどうかを指定します。この設定をオンにし、[ローカル MicroKernel エンジンの使用]の設定をオンにした場合、まずリモート サーバーへの接続が試行されます。
ワイヤ暗号化
ワイヤ暗号化を参照してください。
メモ: クライアント側のワイヤ暗号化設定は PSQL JDBC および ADO.NET アクセス方法では使用されません。クライアント側のワイヤ暗号化設定の場合、暗号化は接続文字列を使用して指定できます。『JDBC Driver Guide』の接続文字列の概要、および『Data Provider for .NET Guide』の基本的な接続文字列の定義を参照してください。
ワイヤ暗号化レベル
ワイヤ暗号化レベルを参照してください。
メモ: クライアント側のワイヤ暗号化設定は PSQL JDBC および ADO.NET アクセス方法では使用されません。クライアント側のワイヤ暗号化設定の場合、暗号化は接続文字列を使用して指定できます。『JDBC Driver Guide』の接続文字列の概要、および『Data Provider for .NET Guide』の基本的な接続文字列の定義を参照してください。
アプリケーションの特性
[アプリケーションの特性]には次の設定が含まれています。
スペースを含むファイル/ディレクトリ
スプラッシュ スクリーン
キー長の検証
スペースを含むファイル/ディレクトリ
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Boolean
オン
オフ
オン
なし
適用外
このオプションは、MicroKernel エンジン オペレーションのファイル名でスペースを使用できるように MicroKernel エンジンに指示します。
スプラッシュ スクリーン
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Boolean
オン
オフ
オフ
なし
適用外
この設定は、MicroKernel エンジンのスプラッシュ スクリーンを表示させるかどうかを制御します。スプラッシュ スクリーンは、最初にクライアント リクエスターがロードされるときに表示されます。
キー長の検証
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Boolean
オン
オフ
オン
なし
適用外
このオプションを従来の Btrieve アプリケーションで使用すると、クライアント リクエスターに渡されたインデックスのキー長がキーに対して十分なサイズであるかどうかが、リクエスターで検証されなくなります。このオプションをオフに設定することで、アプリケーションはステータス 21 のエラーを回避できるようになります。
注意: ただし、オフに設定した場合、このオプションはメモリの上書きを防ぐための PSQL リクエスターによるチェックを無効にします。メモリの上書きにより生じる状況で、望ましくない状況はいくつかありますが、中でも一般保護エラー(GPF)が発生する可能性があります。
キャッシュ エンジン
これらの設定は、キャッシュ エンジンが実行されている場合にのみ適用されます。ワークグループ エンジンはキャッシュ エンジンを兼ねています。ただし、データベース サーバー エンジンが実行されている場合にはキャッシュ エンジンは使用されないことに注意してください。
[キャッシュ エンジン]には次の設定が含まれています。
起動時のリソース割当
非アクティブ時、最小の状態に戻す
キャッシュ割当サイズ
MicroKernel の最大メモリ使用量
最小の状態に戻す待ち時間
起動時のリソース割当
データ型
範囲
デフォルト
単位
データベース エンジン再起動の必要性
Boolean
オン
オフ
オフ
なし
適用外
この設定は、キャッシュ エンジンの起動時に、スレッドやメモリ バッファーを含むリソースを割り当てるようにキャッシュ エンジンに指示します。
このオプションをオフにすると、最初のオペレーションが要求されるまでリソースが割り当てられません。必要に応じて、PSQL コンポーネントにより、自動的にリソースが割り当てられます。したがって、多くの場合、このリソース割り当てを自分で行う必要はありません。
非アクティブ時、最小の状態に戻す
この設定は、ワークグループ エンジンが実行されている場合にのみ表示されます。
データ型
範囲
デフォルト
単位
データベース エンジン再起動の必要性
Boolean
オン
オフ
オフ
なし
適用外
この設定により、アクティブなクライアントが存在しない状態で一定の時間が過ぎると、キャッシュ エンジンは大部分のメモリ容量およびスレッド リソースをシステムに解放し、最小の状態に戻ります。その時間は、[最小の状態に戻す待ち時間]の値で設定します。ほかのクライアントがアクティブになった場合は、キャッシュ エンジンにより、リソースが再度割り当てられます。
キャッシュ割当サイズ
データ型
範囲
デフォルト
単位
データベース エンジン再起動の必要性
Numeric
1 メガバイトからメモリによって制限される量
(後述の「メモ」を参照してください)
最初の起動時に動的に初期化される
メガバイト
(後述の「メモ」を参照してください)
適用外
この設定は、MicroKernel によって割り当てられるレベル 1 キャッシュのサイズを指定します。MicroKernel では、すべてのデータ ファイルへのアクセスにこのキャッシュが使用されます。
ごく一般的に言うと、[キャッシュ割当サイズ]の値がシステム上の物理メモリの 40 % より小さく、設定プロパティの[キャッシュ エンジンの最大メモリ使用量]が 40% より大きい値に設定されている場合に、全体のパフォーマンスは最高になります。最適な設定は、データ ファイルのサイズ、システム上で実行されるほかのアプリケーションの数、およびコンピューターにインストールされているメモリの量によって変わります。
データベース エンジンは、初めて起動されたときにこの値を設定し、レジストリに書き込みます。この初期値には物理メモリの 20% が設定されます。レジストリ設定が初期化されると、エンジンは起動されるたびにレジストリからこの値を読み取ります。エンジンがこの設定を再計算することはありません。設定プロパティを使用して値を変更すると、レジストリの値も更新されます。システムにメモリを追加したり取り除いたりした場合には、新しく使用可能になったメモリを最大限活かせるようにこの設定を手動で変更する必要があります。
メモ: PSQL v10 より前の PSQL クライアントを使用する場合、キャッシュ割当サイズの値はバイト単位で指定する必要があります。最小の 64KB(65,536 バイト)が指定されます。最大値はメモリ容量によって制限されます。
MicroKernel の最大メモリ使用量
データ型
範囲
デフォルト
単位
データベース エンジン再起動の必要性
Numeric
0-100
60
パーセント
適用外
この設定は、総物理メモリに対してキャッシュ エンジンが消費できるメモリの割合を指定します。キャッシュ エンジンによって使用されるメモリには、L1、L2、およびその他すべてのメモリが含まれます。データベース エンジンは、指定した割合が必要でないか使用できない場合は、これより少ないメモリを使用します。
値にゼロ(0)を指定すると、動的キャッシュはオフになります。この場合、使用できるキャッシュは L1 のみで、[キャッシュ割当サイズ]で指定したサイズになります。
パフォーマンスのチューニングについては、パフォーマンス チューニングを参照してください。
最小の状態に戻す待ち時間
この設定は、ワークグループ エンジンが実行されている場合にのみ表示されます。
データ型
範囲
デフォルト
単位
データベース エンジン再起動の必要性
Numeric
0 - 2147483647
300000
ミリ秒
適用外
この設定は、キャッシュ エンジンが最小の状態に戻る前に非アクティブ状態でどれだけ待機するかを指定します。(最小の状態とは、キャッシュ エンジン起動時の初期状態です。)キャッシュ エンジンを最小の状態に戻すと、大部分の容量のメモリとスレッド リソースがシステムに解放されます。キャッシュ エンジンを最小の状態に戻したくない場合もあります。たとえば、繰り返しキャッシュ エンジンを使用するバッチ ファイルを使用中の場合などです。ほかのクライアントがアクティブになった場合は、キャッシュ エンジンにより、リソースが再度割り当てられます。
この設定は、[非アクティブ時、最小の状態に戻す]にオフ(デフォルト)が設定されている場合は無視されます。
キャッシュ エンジンのデバッグ
これらの設定は、キャッシュ エンジンが実行されている場合にのみ適用されます。ワークグループ エンジンはキャッシュ エンジンを兼ねています。ただし、データベース エンジンが実行されている場合にはキャッシュ エンジンは使用されないことに注意してください。
キャッシュ エンジンのデバッグ]で使用できる設定は、[サーバー|デバッグ]にある類似した設定がメインのデータベース エンジンに対して実行するのと同様の機能を、クライアント キャッシュに対して実行します。各設定の詳細については、関連するサーバー設定を参照してください。
データ バッファーのバイト数
キー バッファーのバイト数
トレースするオペレーションの選択
トレース ファイルのロケーション
トレース オペレーションの実行
通信プロトコル
[通信プロトコル]には次の設定が含まれています。
自動再接続の有効化
サポート プロトコル
接続タイムアウト
自動再接続の有効化
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Boolean
オン
オフ
オフ
なし
適用外
この設定は、ネットワークの中断時にクライアントが自動再接続を試行するかどうかを指定します。オンに設定すると、自動再接続が有効になります。
自動再接続は、この設定をサーバーの設定でも有効にしておかない限り、有効になりません。
サポート プロトコル
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
複数選択
次の解説を参照。
下記の 3 つの選択肢があります
なし
適用外
この設定は、クライアントが使用するプロトコルを指定します。複数のプロトコルを指定した場合、クライアントは、使用可能なすべてのプロトコルで接続を試行します。最初に接続できたプロトコルは、そのセッションの間使用されます。使用可能なオプションは次のとおりです。
TCP/IP
SPXII
NetBIOS
 
メモ: サーバーとクライアントの両方で有効なプロトコルが最低 1 つないと、通信を行うことができません。NetBIOS が有効なのは PSQL ワークグループ のみで、PSQL Server では無効です。Linux または OS X プラットフォームで動作する PSQL でサポートされるプロトコルは TCP/IP のみです。したがって、サポート プロトコルの設定は、これらの環境では使用できません。
接続タイムアウト
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Numeric
1 ~ 2147483647
15
適用外
この設定の値は、クライアントがリモート データベース エンジンを検索または接続するまで待つ時間を指定します。この値の設定が小さ過ぎると、接続が完了する前にタイムアウトになるため、サーバーが見つからないという擬似エラーがクライアントに返されます。この値の設定が大き過ぎると、クライアントが接続不可能なサーバーへ接続しようとした場合、エラーが返されるまでに著しく時間がかかる可能性があります。一般的に、ほとんどのネットワークでは 15 秒から 30 秒の間の値が妥当です。「サーバーが見つかりません」というエラーが頻発する場合は、より高い値を設定してください。
この設定は、以前は通信リクエスターの TCP/IP 接続タイムアウトと呼ばれていました。
パフォーマンス チューニング
[パフォーマンス チューニング]には次の設定が含まれています。
キャッシュ エンジンの使用
キャッシュ エンジンの使用
データ型
範囲
デフォルト
単位
データベース エンジン再起動の必要性
Boolean
オン
オフ
オフ
なし
適用外
この設定は、クライアント キャッシュ エンジンを使用するかどうかを指定します。クライアント キャッシュ エンジンは、MicroKernel エンジンを特殊化したもので、読み取り専用にデータをキャッシュし、別プロセスで実行されます。単純に、クライアント キャッシュ エンジンはよくクライアント キャッシュと呼ばれます。
キャッシュ エンジンの使用]設定がオフの場合、クライアント側に何もキャッシュされません。アプリケーションからの読み取り要求によって、リモート データベース エンジンからデータを取得します。
キャッシュ エンジンの使用]設定がオンの場合、クライアント キャッシュ エンジンが、クライアントとリモート データベース エンジンとの間で、データのキャッシュを仲介する役割を果たすことを意味します。アプリケーションが初めて読み取り要求を行ったときに、クライアント キャッシュ エンジンはデータをキャッシュします。同じレコードに対して読み取り要求をもう一度行うと、その要求はクライアント キャッシュ エンジンがキャッシュしたデータで対応します。その読み取りのために、リモート データベース エンジンにアクセスする必要はありません。
クライアント キャッシュは、いろいろな意味でワークグループ エンジンと似ています。デフォルトでは、アプリケーションが最初にデータベースにアクセスしたときにクライアント キャッシュはメモリに自動的にロードされ、そのアプリケーションを終了すると数分後にアンロードされます。
クライアント キャッシュを常にメモリに保持して、各使用セッションがキャッシュを再配置するパフォーマンス コストを回避したい場合もあるでしょう。クライアント キャッシュをロードしたままにする場合は、コマンド プロンプトから次のコマンドを実行してください。
file_path\PSQL\bin\w3dbsmgr -btrv
クライアント キャッシュが開始するとトレイ アイコンが表示されます。このトレイ アイコンを使用すれば Windows タスク バーからクライアント キャッシュ エンジンを制御できます。クライアント キャッシュを停止するには、トレイ アイコンを右クリックし、[エンジンを停止して終了]をクリックします。
クライアントがサービスとしてインストールされた場合、クライアント キャッシュ エンジン サービスはデフォルトで自動開始します。ただし、クライアント キャッシュ サービスが実行中でも、[キャッシュ エンジンの使用]設定がオンになっていなければ、アプリケーションはクライアント キャッシュを実行しません。
メモ: PSQL は、このクライアント キャッシュと、データベース エンジン キャッシュやほかのクライアント キャッシュとの同期をとります。この動作は完全に自動的かつ透過的に行われます。ただし、データベース エンジン キャッシュでデータベースの変更が発生し、その変更がすべてのクライアント キャッシュに反映されるまでの間には最大 5 秒の遅延が生じます。お使いのシステムで、クライアント キャッシュにそのような古いページが最大 5 秒間存在することが許容されない場合は、クライアント キャッシュを使用しないでください。
以下の操作はクライアント キャッシュには格納されません
トランザクション内にあるすべての操作
ロック バイアスのかかった操作
INSERT、UPDATE、DELETE などの書き込み操作
Open および Close 操作
キャッシュ割当サイズでクライアント キャッシュに関する説明も参照してください。
セキュリティ
[セキュリティ]には次の設定が含まれています。
ランタイム サーバー サポート
ランタイム サーバー サポート
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
String
Yes
No
ユーザー名,パスワード
はい
なし
適用外
この設定は、ランタイム サーバー サポートを制御します。この設定が Yes(有効)の場合は、現在実行しているドライブの現在のユーザー名とパスワードが使用されます。別のユーザー名で RTSS を有効にするには、「ユーザー名,パスワード」を入力します。
「CN=ユーザー名.O=組織,パスワード」の形式で、完全修飾された NDS ユーザー名を使用できることに注意してください。ユーザー名はシンプルなバインダリ名であってもかまいません。バインダリ コンテキスト一覧の最初のエントリはシンプルな名前である必要があります。そうしないと、NDS のログインが失敗します。シンプルな名前で NDS ログインが失敗した場合は、バインダリ ログインが試行されます。バインダリ ログインは、ログイン試行を処理している間、進行を妨げることがあります。
SUPERVISOR および ADMIN は、正しいパスワードと一緒に入力しても、有効なユーザー名ではありません。リクエスターが、SUPERVISOR または ADMIN 以外のログイン ユーザー名を検出できない場合は、ログインを試行しません。
Linux および OS X クライアント設定プロパティ
PSQL のクライアントおよびサーバーは、どちらもグラフィカル ユーティリティの PSQL Control Center やコマンド ライン インターフェイス ユーティリティの bcfg を使って構成することができます。PCC については、『PSQL User's Guide』の PSQL Control Center の使用を参照してください。bcfg については、CLI ユーティリティによる設定を参照してください。
設定値での大文字小文字の区別
Linux または OS X クライアントは設定値の確認または変更を行う場合、大文字小文字を区別しません。たとえば、設定値に Yes または yes を入力した場合、クライアントはこれらを同一の値であると解釈します。
ローカル設定([Local])によって影響を受けるクライアントのパフォーマンス
Linux または OS X クライアント インターフェイスが初めて呼び出されたときに、そのデフォルトの設定値が PSQL レジストリに設定されます。PSQL クライアントは、自身のインストールにサーバー エンジンが含まれているかどうかを認識しません。そのため、ローカル設定([Local])を有効("Yes")にします。これは、クライアントのパフォーマンスに影響を及ぼす可能性があります。
クライアントを使用しているコンピューターにサーバー エンジンがない場合は、ローカル設定([Local])を無効("No")にします。Use Local MicroKernel Engine|ローカル MicroKernel エンジンの使用を参照してください。
埋め込みスペースを含むファイル名
デフォルトで、Linux および OS X クライアント インターフェイスはスペースを含むファイル名をサポートします。
たとえば、次のような例です。
/mymount/usr/gary/file with spaces.mkd
スペースを含まないファイル名を使用したい場合は、[スペースを含むファイル/ディレクトリ]([Embedded Spaces])設定を変更する必要があります。Embedded Spaces|スペースを含むファイル/ディレクトリを参照してください。
設定リファレンス
次の表は、Linux および OS X クライアントの設定オプションの一覧を示します。
表 14 クライアントの設定
設定オプション
プロパティ名
Access|アクセス
[Access|アクセス]には次の設定が含まれています。
Use Local MicroKernel Engine|ローカル MicroKernel エンジンの使用
Use Remote MicroKernel Engine|リモート MicroKernel エンジンの使用
Use IDS|IDS の使用
Wire Encryption|ワイヤ暗号化
Wire Encryption Level|ワイヤ暗号化レベル
Use Local MicroKernel Engine|ローカル MicroKernel エンジンの使用
ローカル MicroKernel エンジンの使用を参照してください。
Use Remote MicroKernel Engine|リモート MicroKernel エンジンの使用
リモート MicroKernel エンジンの使用を参照してください。
リモート エンジンと UNC パス
UNC パスがクライアントから正しく動作するようにするには、以下のことを行う必要があります。
アクセスしようとするファイルと同じコンピューターにあるエンジンを実行している必要があります。
リモート MicroKernel エンジンの使用]をオンに設定しておきます。
メモ: ローカルの Linux または OS X システムを指す UNC パスを使って送信することはできません。ただし、次のような UNC スタイルのパスは使用することができます。
//localhost/usr/local/psql/data/samples/sample.btr
ファイル サーバーにエンジンが不要の場合(つまり、クライアントのローカル エンジンが欲しい場合)、クライアントのリモート ファイル システムをマウントし、UNC 形式ではなく "ネイティブ形式" のパスになるようパスを変更する必要があります。たとえば、次のようなパスが Linux および OS X でネイティブな形式です。
/mnt/myremotedata/sample.btr
Use IDS|IDS の使用
IDS の使用を参照してください。
Wire Encryption|ワイヤ暗号化
ワイヤ暗号化を参照してください。
メモ: クライアント側のワイヤ暗号化設定は PSQL JDBC および ADO.NET アクセス方法では使用されません。クライアント側のワイヤ暗号化設定の場合、暗号化は接続文字列を使用して指定できます。『JDBC Driver Guide』の接続文字列の概要、および『Data Provider for .NET Guide』の基本的な接続文字列の定義を参照してください。
Wire Encryption Level|ワイヤ暗号化レベル
ワイヤ暗号化レベルを参照してください。
メモ: クライアント側のワイヤ暗号化設定は PSQL JDBC および ADO.NET アクセス方法では使用されません。クライアント側のワイヤ暗号化設定の場合、暗号化は接続文字列を使用して指定できます。『JDBC Driver Guide』の接続文字列の概要、および『Data Provider for .NET Guide』の基本的な接続文字列の定義を参照してください。
Communication Protocols|通信プロトコル
[Communication protocols|通信プロトコル]には次の設定が含まれています。
Enable AutoReconnect|自動再接続の有効化
Enable AutoReconnect|自動再接続の有効化
データ型
範囲
デフォルト
単位
エンジン再起動の必要性
Boolean
オン
オフ
オフ
なし
適用外
この設定は、ネットワークの中断時にクライアントが自動再接続を試行するかどうかを指定します。オンに設定すると、自動再接続が有効になります。
自動再接続は、この設定をサーバーの設定でも有効にしておかない限り、有効になりません。
メモ: PSQL Linux および OS X クライアントはこの Auto-Reconnect(自動再接続)機能をサポートしますが、Linux および OS X サーバーではサポートしません。このため、Linux または OS X クライアントから AutoReconnect(PARC)機能を使用した場合のみ Windows サーバーに接続することができます。
Application Characteristics|アプリケーションの特性
[Application characteristics|アプリケーションの特性]には次の設定が含まれています。
Embedded Spaces|スペースを含むファイル/ディレクトリ
Verify Kye Length|キー長の検証
Embedded Spaces|スペースを含むファイル/ディレクトリ
スペースを含むファイル/ディレクトリを参照してください。
Verify Kye Length|キー長の検証
キー長の検証を参照してください。