|
各 Pervasive PSQL データベース エンジンには、独自のサーバー設定オプションがあります。このセクションでは、エンジンで使用可能な設定オプションについて説明します。
Windows および Linux プラットフォームで、グラフィカルなユーティリティ Pervasive PSQL Control Center を使用して Pervasive PSQL サーバーを構成することができます。bcfg
コマンド ライン インターフェイス ユーティリティを使用することもできます。PCC については、『Pervasive PSQL User's Guide』の 「Pervasive PSQL Control Center の使用」を参照してください。bcfg
については、CLI ユーティリティによる設定を参照してください。
次の表は、サーバー設定オプションとその設定項目の一覧を示します。
[アクセス]には次の設定が含まれています。
この設定は、通信マネージャーが、リモート サーバーやクライアント ワークステーションからのリクエストを受け付けるかどうかを指定します。このオプションをオンにすると、通信マネージャーは、ネットワークでの存在を通知します。
クライアントがキャッシュ エンジンを使用してサーバーに接続することをサーバーがサポートするかどうかを指定します。オフに設定してもクライアントはサーバーに接続はできますが、キャッシュ エンジンを使用することはできません。
この設定をオンにした場合、データベース エンジンはクライアントに保管されているユーザー資格情報を受け付けます。保管方法および場所は、クライアントのオペレーティング システムによって異なります。
pvnetpass
コマンド ライン ユーティリティを使用すると、保管されている資格情報を管理することができます。
pvnetpass
ユーティリティによって Pervasive レジストリに格納されます。
この設定をオフにした場合、データベース エンジンはクライアントに対し、資格情報が必要なデータベース操作の対象から保管されている資格情報は強制的に除外します。このような資格情報は、アプリケーションから、またはログイン ダイアログで提供する必要があります。この設定がオフであっても、ログイン ダイアログを使用して指定されれば、ログイン ダイアログはクライアント保持の資格情報を書き込もうとします。ただし、これは受け入れられません。
クライアント保持の資格情報が認められている場合は、資格情報を知らなくても、誰でもその特定クライアントのコンピューターの前に座り、保管されている資格情報を使ってデータベースにログインすることができます。この動作は、個々のユーザーの厳密な認証は重要でない環境、たとえば、すべてのユーザーが同レベルのアクセス権限を持っている、物理的にセキュリティ保護されているような環境では便利です。一方、権限のない人が存在したり、権限のあるユーザーがアクセス権限のレベルを変更しているような環境では、この設定はオフにしておく必要があります。
関連項目: クライアント資格情報の入力要求
データ型
|
範囲
|
デフォルト
|
単位
|
エンジン再起動の必要性
|
---|---|---|---|---|
単一選択
|
3 つのオプションがあります。次の解説を参照。
|
Emulate Workgroup Engine(ワークグループ エンジンのエミュレート)
|
なし
|
必要
|
以下のオプションは、サーバー エンジンへのアクセスに使用する認証のタイプを指定します。使用可能なオプションは次のとおりです。
pvnetpass
ユーティリティを使用してクライアントからユーザー名とパスワードを指定することができます。PAM は非常に柔軟で、Linux 用のカスタム モジュールを多数提供しています。詳細については、PAM に関する Web サイトを確認ください。
上記の 3 種類の認証方法に加え、使用可能な場合は、Samba を使用することもできます。サーバーは、Samba を介して既知の FIFO 共有を作成します。FIFO は、$PVSW_ROOT/etc/pipe/mkde.pip
に作成されます。$PVSW_ROOT/etc/pipe
は、PVPIPE$ として Samba が共有する必要があります。
メモ
末尾の $ は、この共有が非表示になることを意味します。Pervasive PSQL クライアント コンポーネントが、¥¥<サーバー>¥PVPIPE$¥mkde.pip(大文字小文字区別なし)として自動的にこのパイプへのアクセスを処理します。明示的な処理を実行したり、このパイプにアクセスするようにアプリケーションを変更したりする必要はありません。唯一の例外は、Samba または Pervasive PSQL の設定のトラブルシューティングを行う場合です(後述の「トラブルシューティング」のセクションを参照)。
クライアントがリモート エンジンに接続し、エンジンがバージョン ブロックで "Unix" と返した場合、まずレジストリ(RTSS 設定)で認証情報を確認します。ユーザー名とパスワードがレジストリ内で見つからなかった場合、クライアントは上記のパイプに接続し、サーバーからクライアント認証情報を受け取り、検証します。
認証されるためには、共有に接続し、パイプを読み取ることができる必要があります。これは、エンジンを使用できるユーザーと使用できないユーザーを指定する一つの方法です。最も簡単な方法は、smb.conf(Samba の設定ファイル)内の Samba の「valid users」の設定を使用する方法です。クライアントが認証されなかった場合、ステータス 3119 が返されます。
サーバーに Samba をインストールする場合は、インストール プログラムによって Samba 共有が設定されます。Pervasive パイプの設定例を以下に示します。
################################################### [PVPIPE$] comment = Pervasive pipes path = /usr/local/psql/etc/pipe force group = pvsw # force group pvsw when accessing pipe - will be # useful if primary group for this user is not pvsw valid users = @pvsw # only members of group pvsw will have access oplocks = False # Absolutely necessary - prevents caching on the client ###################################################
Samba を通じて共有されるファイルへのアクセスを構成する方法については、Samba のマニュアルを参照してください。
メモ
PVPIPE$ へのクライアントの読み取りアクセスを許可すると、そのクライアントはリモートでエンジンへのアクセスが許可されます。
クライアントが正しく認証されることを確認するには、コマンド プロンプトで「¥¥
<サーバー>
¥
pvpipe$
¥
mkde.pip
」と入力します。多数の疑問符(印刷不可能なシンボル)といくつかの印刷可能な文字が表示され、警告音が鳴ります。表示されなかった場合、Samba の設定で、このパイプを読み取る権限があるかどうかを確認します。権限があるのにエラー 94 または 3119 が発生する場合は、Pervasive PSQL Control Center でエンジンの設定プロパティを使用して、または pvnetpass を使用して、RTSS 設定を確認します。
この設定は、Linux で、ローカル ファイル システムの Windows クライアントへのエクスポートに使用される smb.conf ファイルのロケーションを指定します。エンジンでは、リモート システムの UNC パスを、正しいデータベース ファイルへのローカル呼び出しに変換するときに、このファイルが必要です。
デフォルト値は /etc/smb.conf です。Samba の設定ファイルを別のロケーションにインストールした場合、正しいパスとファイル名を入力します。
この設定は、ユーザー認証を必要とするデータベース操作中に利用できる資格情報がない場合、Windows Pervasive PSQL クライアントがユーザーにログイン資格情報の入力を求めるかどうかを決定します。
この設定をオンにした場合、ほかの認証資格情報がないときには、ユーザーにログイン ダイアログを表示するよう、エンジンが Windows クライアントに要求します。この設定は、混合またはデータベース セキュリティが有効になっている場合にのみ適用されます。ただし、いかなる状況下でも Linux クライアントには適用されません。有効な資格情報が別の手段、たとえば、明示的な Btrieve Login(78)オペレーションやクライアントに保管されている資格情報によって提供される場合は、ログイン ダイアログは表示されません。
ユーザー資格情報を必要とする操作で、エンジンにデータベース コンテキストが指定されていない場合、エンジンは、ユーザーは現在のデータベースヘのログインを試みていると見なします。
この設定をオフにして、新しいセキュリティ モデルのいずれかを使用している場合は、ユーザー資格情報をプログラムから提供する(クライアントに保管されている資格情報を提供するか、Btrieve の Login(78)、Open(0)、または Create(14)オペレーションによって提供する)必要があります。そうしないと、ログインの試行は認証エラーで失敗します。
関連項目
このプロパティは、指定されたクライアントまたはサーバーがネットワーク通信で暗号化を使用するかどうかを指定します。デフォルト値は "必要な場合" です。これは、クライアントまたはサーバーは、通信ストリームの相手側が暗号化を要求している場合にのみ暗号化を使用するという意味です。たとえば、サーバー A は[ワイヤ暗号化]値を "常時" に設定しており、サーバー B は "しない" に設定しているとします。クライアントはこの値を "必要な場合" に設定しています。この場合、クライアントはサーバー A と通信する場合には暗号化を使用しますが、サーバー B と通信する場合には暗号化を使用しません。
次の表は、クライアント値とサーバー値の考えられる組み合わせを基に動作をまとめています。
クライアント設定
|
サーバー設定:"しない"
|
サーバー設定:"常時"
|
サーバー設定:"必要な場合"
|
---|---|---|---|
しない
|
暗号化を使用しません。
|
ステータス コード 5001
|
暗号化を使用しません。
|
常時
|
ステータス コード 5000
|
暗号化を使用します。レベルは、クライアントとサーバー間で最も高い[ワイヤ暗号化レベル]設定によって決定されます。
|
暗号化を使用します。レベルは、クライアントの[ワイヤ暗号化レベル]設定によって決定されます。
|
必要な場合
|
暗号化を使用しません。
|
暗号化を使用します。レベルは、サーバーの[ワイヤ暗号化レベル]設定によって決定されます。
|
暗号化を使用しません。
|
この設定では、暗号化された通信で使用する暗号化キーの長さを指定します。次のレベルを使用できます。
128 ビット長のキーを使用する暗号化は、一般に「高度」暗号化と認められています。ほかの設定は、そのレベルに応じて保護力は低下しますが、パフォーマンスは向上します。ある程度のレベルの暗号化は必要であるが、より良いパフォーマンスを得るために、抑止レベルが低下することを受け入れるつもりである場合に適しています。
クライアントとサーバーの両方が暗号化を要求し、一方が他方よりも強度の高い暗号化レベルを指定した場合、2 つのエンティティは強度の高いレベルを使って通信します。クライアントとサーバーの両方が暗号化を要求し、一方が他方よりも強度の高い暗号化レベルを指定した場合、2 つのエンティティは強度の高いレベルを使って通信します。
[通信プロトコル]には次の設定が含まれています。
この設定は、接続不能となる前にクライアントがサーバーにどれだけの時間接続を試行するかを指定します。自動再接続が有効になっているクライアントが、最初に自動再接続が有効なサーバーに接続すると、サーバーはこの値をクライアントに通知し、両方のコンポーネントがネットワーク中断イベントでどれだけの時間再接続を試行するかがわかるようにします。
この設定は、ネットワークの中断時にクライアントが再接続を試行することをサーバーにサポートさせるかどうかを指定します。オンに設定すると、自動再接続が有効になります。
自動再接続は、この設定をクライアント側の設定でも有効にしておかない限り、そのクライアント接続では有効になりません。
接続不能となる前にクライアントがサーバーにどれだけの時間再接続を試行するかを指定します。前述の自動再接続タイムアウトを参照してください。
このオプションは、[TCP/IP マルチホーム]がオフの場合に MicroKernel が受信待ちする IP アドレス(1 つまたは複数)を指定します。このオプションは、[TCP/IP マルチホーム]がオンの場合は無視されます。
複数の IP アドレスを指定できますが、その場合は各アドレス間をカンマで区切る必要があります。このアドレス文字列は IPv4 アドレスと IPv6 アドレスの組み合わせも可能です。Pervasive PSQL でサポートされる IPv6 アドレス形式が使用できます。『Getting Started with Pervasive PSQL』の「ドライブ ベースの形式」を参照してください。
このオプションは、MicroKernel が受信待ちをする NetBIOS ポートを指定します。サーバー エンジンでは NetBIOS をサポートしません。
この設定では、データベース エンジンがクライアント接続の受信待ちをするプロトコルを指定します。2 つ以上のプロトコルを指定した場合、エンジンは指定したすべてのプロトコルで接続の受信待ちをします。デフォルトは TCP/IP です。使用可能なオプションは次のとおりです。
サーバーとクライアントの両方で有効なプロトコルが最低 1 つないと、通信を行うことができません。
NetBIOS が有効なのは Pervasive PSQL Workgroup のみで、Pervasive PSQL Server では無効です。
Linux プラットフォームで動作する Pervasive PSQL でサポートされるプロトコルは TCP/IP のみです。したがって、サポート プロトコルの設定は、Linux では使用できません。
このオプションは、データベース エンジンがすべてのネットワーク インターフェイスでクライアント接続の受信待ちをするかどうかを指定します。オンに設定した場合、データベース エンジンはすべてのネットワーク インターフェイスで受信待ちをし、[リッスン IP アドレス]オプションの IP アドレスは無視されます。この設定をオフにすると、クライアント通信に使用するデータベース エンジンへのアドレスを[リッスン IP アドレス]に指定する必要があります。
これは、リレーショナル インターフェイスで使用されるポート番号を設定します。
このポート番号は、このサーバーを指定するクライアント DSN に定義されたものと同じ番号である必要があります。クライアント DSN でポート番号を変更する方法については、『SQL Engine Reference』の 「クライアント DSN 用の詳細な接続属性」を参照してください。
ポートに関する詳細については、『Getting Started with Pervasive PSQL』の「デフォルトの通信ポートの変更」を参照してください。
[ファイル互換性]には次の設定が含まれています。
この設定は、新しく作成されるすべてのファイルの形式を指定します。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 はトランザクション一貫性保守を確実にするのに行を一意に識別できることが必要なため、ファイルは重複のないキーを定義するかまたはシステム データを含める必要があります。デフォルト値は[必要な場合]です。使用可能な値は、次のとおりです。
メモ
システム データ設定は既存のファイルには影響しません。この設定は新規ファイルがどのように作成されるかにのみ影響します。
[システム データの作成]を有効にしないで作成され、重複のないキーを持たないファイルにトランザクション一貫性保守を適用したい場合は、[システム データの作成]を[常時]または[必要な場合]に設定した後、ファイルを再作成する必要があります。
SRDE は常に、システム データを含むファイルを作成します。この情報は、SQL、OLE-DB、JDBC、また Btrieve API 以外のあらゆる方法で作成されたファイルに当てはまります。
インデックスはユーザーによって削除されることがあるため、ファイルが重複のないキーを持っている場合でも、システム データを追加したい場合があります。
[データ整合性]には次の設定が含まれています。
この設定は、ファイルのバックアップを容易にするアーカイブ ログを MicroKernel に実行させるかどうかを指定します。システム障害が発生した場合、アーカイブ ログ ファイルおよび BUTIL -ROLLFWD コマンドを使用して、最後にバックアップを取ったときからシステム障害が発生するまでの間にファイルに加えられた変更を修復できます。
MicroKernel にアーカイブ ログを実行させるには、アーカイブ ログを実行するファイルのあるボリュームにアーカイブ ログ設定ファイルを作成し、エントリを追加することによりファイルを指定する必要があります。アーカイブ ログの詳細については、「アーカイブ ログおよび Continuous オペレーションについて」を参照してください。
この設定は、システム トランザクションを起動させるタイム リミットを指定します。MicroKernel は、[オペレーション バンドル制限]か[起動時間制限]のいずれかで設定された値に達した場合、またはキャッシュの再利用が必要な場合に、システム トランザクションを起動します。
このオプションは、システム トランザクションを起動するのに必要なオペレーション(1 つの任意のファイルで実行)の最大数を指定します。MicroKernel は、[オペレーション バンドル制限]か[起動時間制限]のいずれかで設定された値に達した場合、またはキャッシュの再利用が必要な場合に、システム トランザクションを起動します。
MicroKernel Database エンジンでは、各ユーザー トランザクション(Begin Transaction から End Transaction または Abort Transaction まで)が 1 つのオペレーションとして扱われます。たとえば、Begin Transaction オペレーションと End Transaction オペレーションの間に 100 の Btrieve オペレーションがある場合、Begin Transaction オペレーションと End Transaction オペレーションを含む 102 の Btrieve オペレーションが、1 つのオペレーションとして扱われます。
トランザクション一貫性保守は、システム障害時に正常終了していたトランザクションがデータ ファイルにコミットされることを保証する点以外はトランザクション ログと同じです。
トランザクション ログとトランザクション一貫性保守の詳細については、「トランザクション ログおよびトランザクション一貫性保守」を参照してください。
メモ
[トランザクション一貫性保守]をオンにしている場合、一部のファイルで、トランザクションの一貫性が保守されないことがあります。ファイルは、少なくとも 1 つは重複のないキーを含んでいるか、ファイル作成時に[システム データ]設定が "常時" または "必要な場合" に設定されている必要があります。そうしないと、ファイルに対する変更はトランザクション ログに書き込まれません。トランザクション一貫性保守およびシステム データの詳細については、開発者リファレンスの『Pervasive PSQL Programmer's Guide』を参照してください。
システム データは既存のファイルには影響しないため、重複のないキーを持たず、[システム データの作成]を有効にしないで作成したファイルは再作成する必要があります。これらのファイルを再作成する前に[システム データの作成]を必ず有効にしてください。
注意
ゲートウェイ ロケーター ファイルにより、同一ファイル サーバー上の異なるディレクトリにある複数のファイルを異なるエンジンが管理することができます。データベースが異なるディレクトリにある複数のファイルを含んでいる場合は、データベース内のすべてのデータ ファイルを同一データベース エンジンで管理する必要があります。同一データベース内のファイルを複数のデータベースで管理する場合、データベースの整合性およびトランザクション アトミシティは保証されません。起こり得る問題を回避する方法については、「ロケーター ファイルのリダイレクト」を参照してください。
詳細については、トランザクション ログにある同様の「関連する設定」を参照してください。
この設定は、データ ファイルに影響するすべてのオペレーションをログに記録することにより、MicroKernel がトランザクションのアトミシティを確実にするかどうかを制御します。
関連する[トランザクション一貫性保守]の設定がオンになっている場合、ロギングは自動的に行われ、[トランザクション ログ]設定は無視されます。
トランザクション ログとトランザクション一貫性保守の詳細については、「トランザクション ログおよびトランザクション一貫性保守」を参照してください。
メモ
[トランザクション ログ]をオンにしている場合、一部のファイルで、トランザクションの一貫性が保守されないことがあります。ファイルは、少なくとも 1 つは重複のないキーを含んでいるか、ファイル作成時に[システム データ]設定が "常時" または "必要な場合" に設定されている必要があります。そうしないと、ファイルに対する変更はトランザクション ログに書き込まれません。トランザクション一貫性保守およびシステム データの詳細については、開発者リファレンスの『Pervasive PSQL Programmer's Guide』を参照してください。
システム データは既存のファイルには影響しないため、重複のないキーを持たず、[システム データの作成]を有効にしないで作成したファイルは再作成する必要があります。これらのファイルを再作成する前に[システム データの作成]を必ず有効にしてください。
注意
使用するデータベースがデータ ファイル間のトランザクション アトミシティを必要としない場合を除いては、トランザクション ログの設定をオフにしないでください。トランザクション ログがオフに設定されている場合、複数ファイルのデータベースのデータの整合性は保証されません。
[トランザクション ログ]の設定をオフにすることを、使用するアプリケーションのベンダーがサポートしていない場合は、オフにしないでください。
サーバー設定の[トランザクション一貫性保守]はトランザクション ログに似ていますが、より高レベルのデータ安全性を提供し、パフォーマンスは低レベルとなります。サーバーの設定にある[ログ バッファー サイズ]および[トランザクション ログ サイズ]はトランザクション ログと関連しています。[ログ バッファー サイズ]を使用すると、トランザクション一貫性保守とパフォーマンスとのバランスを構成することができます。ログ バッファーが大きいほどディスクに書き込まれる回数が少ないため、パフォーマンスが向上します。ただし、ログ バッファー内のデータベースの変更はシステム障害が起こった場合保守されません。
トランザクション ログ サイズは、新しいセグメントを開始する前に各ログ ファイル セグメントがどれだけのサイズになることができるかを制御します。
Btrieve または SQL トランザクションが使用されない場合は、これらすべての設定は無視されることに注意してください。
レコード ロックの競合が発生した場合、データベース エンジンとそのクライアントは同等の再試行メカニズムを使用します。エンジンは、ウェイト ロック タイムアウト時間内に要求されたレコードのロックを取得できなかった場合には、該当するステータス コードと共に制御をアプリケーションに返します。
ウェイト ロック タイムアウト設定は、ロックの競合が発生した場合に次のような利点をもたらします。
ウェイト ロック タイムアウトは、次のような状況の場合にのみ適用されます。
ウェイト ロック タイムアウトは、Windows または Linux 上の Pervasive クライアントを介してトランザクショナル インターフェイスを使用するアプリケーションには適用されません。このようなアプリケーションは、ロックの競合が検出された直後にロック競合エラーを受け取るか、あるいはロックが解放されるのを待ち続けるかのいずれかです。その時点で、アプリケーションは競合の処理方法(再試行、待機など)を決定します
トランザクショナル インターフェイス API は、レコード ロック状況を処理するための制御を提供します。詳しい解説は Pervasive PSQL ソフトウェア開発キット(SDK)の開発者リファレンス『Btrieve API Guide』を参照してください。ここでは、制御のメカニズムを簡単に説明します。
[デバッグ]には次の設定が含まれています。
この設定は、MicroKernel がトレース ファイルに書き込むデータ バッファーのサイズを指定します。この設定を使用するには、[トレース オペレーションの実行]設定をオンにしておく必要があります。指定するサイズは、必要とするトレースのレベル(データ全体のバッファーの内容を確認する必要があるのか、またはあるレコードを特定できるだけのバッファー内容があれば十分なのかなど)に左右されます。
この設定は、MicroKernel がトレース ファイルに書き込むキー バッファーのサイズを指定します。この設定を使用するには、[トレース オペレーションの実行]設定をオンにしておく必要があります。指定するサイズは、必要とするトレースのレベル(キー全体のバッファー内容を確認する必要があるのか、またはあるキーを特定できるだけのバッファー内容があれば十分なのかなど)に左右されます。
トレースされる Btrieve インターフェイスのオペレーション コードにはチェックマークが付けられています(選択されています)。リストからトレースするオペレーションを選択します。
この設定は、MicroKernel がトレース情報を書き込むトレース ファイルを指定します。ファイル名には、ドライブまたはボリュームの指定およびパスが含まれていること、もしくは UNC パスを使用していることが必要です。トレース ファイルをデフォルトのロケーションに配置しない場合は、別のパスやファイル名を入力します。
Pervasive PSQL ファイルのデフォルトの保存場所については、『Getting Started with Pervasive PSQL』の 「Pervasive PSQL ファイルはどこにインストールされますか?」を参照してください。
メモ
ODBC トレースと MicroKernel トレースに同じトレース ファイル名を使用しないでください。
この設定は、各 Btrieve インターフェイス呼び出しをトレースし、その結果をファイルに保存することを可能にするトレース機能を有効にするかどうかを指定します。開発者は、トレース機能を使用するとアプリケーションのデバッグができます。MicroKernel は、強制書き込みモードを使用してトレース ファイルに書き込みを行うため、MicroKernel が正常にアンロードされなかった場合でも、データがファイルに書き込まれます。MicroKernel のパフォーマンスは、リクエストを受け取る頻度によって大幅に影響を受けることがあります。このオプションを有効にする場合は、[トレース ファイルのロケーション]を指定してください。
メモ
トレースを開始または終了するためにエンジンを再起動する必要はありません。トレースのオン/オフは実行中に行ってエンジンに直接変更を適用することができます。PCC から、変更を有効にするためにエンジンを再起動するようにメッセージが表示されても、この設定については無視してかまいません。
[ディレクトリ]には次の設定が含まれています。
この設定は、データベース名設定ファイルの別のロケーションへのパスを指定します。
サーバー エンジンの場合、ディレクトリ パスではなくローカル ファイルのパスです。ワークグループ エンジンの場合、ワークグループ MicroKernel にアクセス可能なリモート パスを指定できます。デフォルト値は、エンジンのプラットフォームによって異なります。
設定ファイルをデフォルトのロケーションに配置しない場合は、有効なパスを入力します。
この設定は、MicroKernel が、トランザクション ログを保存するために使用するロケーションを指定します。パスは有効なパスであり、ドライブまたはボリュームの指定か UNC パスが含まれている必要があります。デフォルト値は、オペレーティング システムによって異なります。
エンジンは、トランザクション一貫性保守またはトランザクション ログの設定がオンでない場合、この設定を無視します。
注意
複数のデータベース エンジンで同一のディレクトリを使用してはいけません(たとえば、2 つ以上のワークグループ エンジンの[トランザクション ログのディレクトリ]にリモート サーバーのディレクトリを指定するなど)。このような環境では、各エンジンはログのロール フォワードが必要になった場合に、どのトランザクション ログ セグメントを使用するかを決定できません。
データベース エンジンの使用率が高い場合には、データ ファイルが存在するのとは物理的に別のボリュームにトランザクション ログが保持されるようにシステムを構成する必要があります。高負荷の下では、単一ドライブで I/O 帯域幅を競う代わりに、ログの書き込みとデータ ファイルの書き込みを別のドライブに分ける方が一般的にパフォーマンスがよくなります。トランザクション ログの詳細については、「トランザクション ログおよびトランザクション一貫性保守」を参照してください。
この設定は、多数のインデックスを作成するようなオペレーションで、テンポラリ ファイルを保存するために使用される MicroKernel 作業ディレクトリのロケーションを指定します。ディスク容量に制限がある場合は、このオプションを使用して十分な空き容量があるボリュームに作業ディレクトリを指定できます。
デフォルト値はありません。ただし、作業ディレクトリを指定しない場合、データ ファイルのロケーションがデフォルトになります。作業ディレクトリを指定するには、[作業ディレクトリ]フィールドにパスを入力します。パスには、ドライブまたはボリュームの指定か UNC パスが含まれている必要があります。
情報には、次のような表示のみの項目が示されます。
表示のみの項目
|
説明
|
---|---|
サーバー名
|
データベース エンジンが実行されているマシンの名前。
|
エンジンのバージョン
|
データベース エンジンのリリース バージョン。
|
エンジンの種類
|
データベース エンジンの製品カテゴリ。たとえば、「サーバー」や「ワークグループ」。
|
[メモリの使用]には次の設定が含まれています。
この設定は、MicroKernel の起動時に、スレッドやメモリ バッファーを含むリソースを割り当てるように MicroKernel に指示します。 起動時のリソース割り当てには L1 キャッシュに加えてバックグランド スレッドも含まれます。 Pervasive PSQL コンポーネントは必要に応じてリソースを自動的に割り当てます。このため、ほとんどの場合、この設定はオフ(デフォルト)にすることができます。
この設定がオフの場合、最初のオペレーションが要求されるまでリソースが割り当てられません。お使いのシステムが多数のユーザーをサポートする場合は、この設定をオンにする方が適切です。
この設定を初めてオンにしたときに、Windows の動作方法のため、メモリの割り当てに顕著な違いが見られないかもしれません。MicroKernel がその L1 キャッシュを割り当てる場合、Windows オペレーション システムは単にメモリのページを確保するだけで、実際にそれらを MicroKernel にはコミットしまません。その後、MicroKernel が実際にキャッシュ メモリにアクセスすると、Windows は実際の物理ページをコミットするので、Pervasive PSQL コンポーネント(ntdbsmgr や w3dbsmgr など)のメモリ使用が増加します。
Windows タスク マネージャーで "仮想メモリ サイズ" を見ると、L1 キャッシュがアクセスされたときにメモリの値が変化することがわかります。バックグランド スレッドがアクセスされたときにスレッド数が変わることもわかります。
この設定により、アクティブなクライアントが存在しない状態で一定の時間が過ぎると、MicroKernel は、大部分のメモリ容量およびスレッド リソースをシステムに解放し、最小の状態に戻ります。その時間は、[最小の状態に戻す待ち時間]の値で設定します。ほかのクライアントがアクティブになった場合は、MicroKernel により、リソースが再度割り当てられます。
この設定は、MicroKernel が最小の状態に戻る前に非アクティブ状態でどれだけ待機するかを指定します。(最小の状態とは、MicroKernel 起動時の初期状態です。)MicroKernel を最小の状態に戻すと、大部分の容量のメモリとスレッド リソースがシステムに解放されます。MicroKernel を最小の状態に戻したくない場合もあります。たとえば、繰り返し MicroKernel を使用するバッチ ファイルを使用中の場合などです。ほかのクライアントがアクティブになった場合は、MicroKernel により、リソースが再度割り当てられます。
この設定は、[非アクティブ時、最小の状態に戻す]にオフ(デフォルト)が設定されている場合は無視されます。
この設定は、ランタイムでインデックスを作成中に MicroKernel がソートのために動的に割り当てる、または割り当てを解除するメモリの最大容量(キロバイト単位)を指定します。
ソート用に指定されたサイズ以上のメモリが必要な場合、または利用可能な処理メモリの 60 % 以上を占める場合は、MicroKernel により、テンポラリ ファイルが作成されます。処理に必要な利用可能メモリの量は、動的な値で、システムの設定や負荷によって変化します。0 キロバイトを指定すると、MicroKernel は、利用可能なメモリのうち最大 60 % まで、必要なだけのメモリを割り当てます。
このオプションは、MicroKernel が、MicroKernel 自体のキャッシュ割当サイズに加え、設定プロパティで指定したシステム キャッシュを使用するかどうかを指定します。
L2 キャッシュを使用している場合は、[システム キャッシュ]をオフに設定する必要があります。MicroKernel の最大メモリ使用量の設定を確認してください。[MicroKernel の最大メモリ使用量]にゼロより大きい値が設定されている場合は、L2 キャッシュを使用しています。
L2 キャッシュを使用していない場合は[システム キャッシュ]をオンにすると、パフォーマンスが向上します。MicroKernel は書き出すページを構成したりグループ化するのにシステム キャッシュを使用します。システム キャッシュがより効果的にページをディスクに書き出せるようにフラッシュを十分に遅らせます。ただし、サーバーにキャッシュ付きのディスク アレイがある場合は[システム キャッシュ]の設定をオフにすることにより、より良いパフォーマンスを得られることがあります。
Windows サーバーの場合のみ、Windows パフォーマンス モニター ユーティリティのページング ファイルおよびプロセス オブジェクトを使用して Windows のシステム キャッシュが効率的に使用されているかをチェックできます。NTDBSMGR インスタンスの場合は、ページ ファイル オブジェクトの[% 使用]および[% 最大使用]をモニターし、プロセス オブジェクトの[Page Fault/sec]および[Page File Bytes]をモニターします。
[パフォーマンス チューニング]には次の設定が含まれています。
データ型
|
範囲
|
デフォルト
|
単位
|
エンジン再起動の必要性
|
---|---|---|---|---|
Numeric
|
1 メガバイトからメモリによって制限される量
(後述の「メモ」を参照してください)
|
最初の起動時に動的に初期化される
|
メガバイト
(後述の「メモ」を参照してください)
|
必要
|
この設定は、MicroKernel によって割り当てられるレベル 1 キャッシュのサイズを指定します。MicroKernel では、すべてのデータ ファイルへのアクセスにこのキャッシュが使用されます。
ごく一般的に言うと、[キャッシュ割当サイズ]の値がシステム上の物理メモリの 40 % より小さく、設定情報の[MicroKernel の最大メモリ使用量]が 40% より大きい値に設定されている場合に、全体のパフォーマンスは最高になります。最適な設定は、データ ファイルのサイズ、システム上で実行されるほかのアプリケーションの数、およびコンピューターにインストールされているメモリの量によって変わります。
Windows では、この設定は、データベース エンジンが初めて起動されたときに物理メモリの 20% に設定され、その値がレジストリに書き込まれます。その後は、エンジンが起動するたびにレジストリから値を読み取ります。設定プロパティを使用して値を変更すると、レジストリの値も更新されます。システムにメモリを追加したり取り除いたりした場合には、新しく使用可能になったメモリを最大限活かせるようにこの設定を変更する必要があります。
パフォーマンスを最適化するには、使用中のファイルの合計サイズより小さいサイズをキャッシュに割り当てますが、特に、サーバーがほかのアプリケーションを実行しているときは、利用可能なメモリをすべてキャッシュに割り当ててしまわないように注意します。必要以上に大きい値を指定しても、メモリを無駄に使用するだけで、パフォーマンスの向上を図ることはできません。
データベース エンジンは、初めて起動されたときにこの値を設定し、レジストリに書き込みます。この初期値には物理メモリの 20% が設定されます。キャッシュの最大サイズはシステムのメモリの容量に応じて異なりますが、データベース エンジンは 64 MB を初期最大値に設定します。レジストリ設定が初期化されると、エンジンは起動されるたびにレジストリからこの値を読み取ります。エンジンがこの設定を再計算することはありません。設定プロパティを使用して値を変更すると、レジストリの値も更新されます。システムにメモリを追加したり取り除いたりした場合には、新しく使用可能になったメモリを最大限活かせるようにこの設定を手動で変更する必要があります。
設定の[キャッシュ エンジンの使用]がオンに設定されている場合、この情報はクライアント ソフトウェア(クライアント キャッシュ)にも適用されます。
メモ
Pervasive PSQL v10 より前の Pervasive PSQL クライアントを使用する場合、キャッシュ割当サイズの値はバイト単位で指定する必要があります。最小の 64KB(65,536 バイト)が指定されます。最大値はメモリ容量によって制限されます。
データ型
|
範囲
|
デフォルト
|
単位
|
エンジン再起動の必要性
|
---|---|---|---|---|
Numeric
|
プロセッサのコア数 ~ 256
|
プロセッサのコア数。このプロセッサのコア数は、データベース エンジンが起動しているマシンのプロセッサ数です。
|
なし
|
必要
|
この設定は、リモート クライアントからのリクエストを処理するために MicroKernel が最初に作成するスレッドの数を指定します。通信スレッドは、リクエストを行うクライアント プロセスに代わって、実際に Btrieve オペレーションを実行する要素です。このように、通信スレッドはワーカ スレッドによく似ています。通信スレッドは許容される最大範囲まで、必要に応じて動的に増加します。最大値は、256 です。
通信スレッドの設定は、ある特定の状況下における改善に役立ちます。たとえば、1 つのファイルに対して多くのクライアントが操作(主に書き込み)を行うような場合、より低い値を設定すればスケーラビリティが向上するはずです。スレッド数の値をより低くすると、システム リソースでコンテキスト スイッチを行わないようにします。このほか、大量のワーカー スレッド間でスラッシングによって速度低下が発生する状況も、この通信スレッドの設定によって改善する可能性があります。ワーカー スレッドは、既存の全スレッドがレコードまたはファイルのロックで待機している場合にのみ動的に作成されます。
この値は、バージョン 8.x 以降の形式のデータ ファイル内に保持する空きページの概算パーセントを指定します。この設定は、旧バージョンの形式のファイルには適用されません。MicroKernel では、この値を使用して、ファイルを拡張するか空きページを最初に使用するかを決定します。データベース エンジンは Turbo Write Accelerator を使用するので、ディスク書き込みのパフォーマンスは、ファイル内の空きページ数が増加するにつれて向上します。これは、そのデータベース エンジンが複数の連続したファイル ページをディスク上に書き込むことができるからです。したがって、ディスク書き込みのパフォーマンスとファイルのサイズは互いに相殺関係にあります。ただし、ファイルに空きページが多すぎると実際には全体のパフォーマンスを落とします。
データ ファイル内に一定の連続した空きページを保持するためには、データベース エンジンが定期的にそのデータ ファイルを拡張する必要があります。この設定がファイルのサイズに影響があることを覚えておいてください。たとえば、空きページのないファイルで作業するときに、[ファイルの拡張係数]の値に 50% を指定した場合、そのファイルのサイズは最終的に 2 倍になります。[ファイルの拡張係数]の値に 75% を指定した場合、そのファイルのサイズは 4 倍になります。90% を指定した場合、そのサイズは 10 倍近くになります。
完全に使用しないページのみが空きページとみなされることに注意してください。ページのなかには途中までしか使用していないページもあるので、15% の空きページといった場合、ファイルの 15% が使用されないという意味ではありません。
この値は MicroKernel への単なる指示です。ファイルが更新される度合いによって、実際の空き領域のパーセンテージはいつでも小さくすることができます。
この設定は、バージョン 8.x より前の形式のファイルには適用できません。旧バージョンの形式のファイルにも空きページがあり、そのファイルの動作状況によって空きページのパーセンテージは異なります。
この設定は、MicroKernel が、インデックス バランスを実行するかどうかを制御します。インデックス バランスにより、読み取りオペレーションのパフォーマンスは向上しますが、このオプションを有効にすると、時間がさらにかかり、挿入、更新、削除オペレーション時にさらにディスクの I/O が必要な場合があります。インデックス バランスの詳細については、開発者リファレンス『Pervasive PSQL Programmer's Guide』を参照してください。
これを指定すると、データ ファイルは、オペレーティング システムのファイル セグメントである 2 GB の限界を超えるごとに自動的に分割されます。オンに設定した場合、データ ファイルは 2 GB のセグメントに分割されます。オフに設定した場合、データ ファイルはセグメント化されず単一のファイルのままです。セグメント化されていない大きなファイルを使用する利点は、ディスク I/O が効率的であるということです。このため、パフォーマンスの向上が期待できます。
セグメントされていないファイルは、お使いのオペレーティング システムによって指定されているファイル サイズの制限を受けます。以前作成したファイルが既にセグメント化されている場合、そのセグメントはファイル上でそのまま残ります。
「ファイル バージョンの自動アップグレード」の関連情報も参照してください。
データ型
|
範囲
|
デフォルト
|
単位
|
エンジン再起動の必要性
|
---|---|---|---|---|
Numeric
|
262144 - メモリによって制限される
|
次の値のうち、小さい方の値:
(MB 単位の物理メモリ / 256) または 8 MB |
バイト
|
必要
|
この設定は、MicroKernel によって使用されるトランザクション ログ バッファーおよびアーカイブ ログ バッファーのサイズを指定します。ログ バッファーのサイズを増やすことにより、MicroKernel がログ情報をディスクに書き込む回数が減るため、パフォーマンスの向上が図れます。
メモ
[ログ バッファー サイズ]に[トランザクション ログ サイズ]より大きい値を設定すると、MicroKernel は[トランザクション ログ サイズ]の値を[ログ バッファー サイズ]に指定した値に自動的に変更します。
この設定は、総物理メモリに対して MicroKernel が消費できるメモリの割合を指定します。MicroKernel による L1、L2 およびその他すべてのメモリの使用量が含まれます(SRDE は含まれません)。データベース エンジンは、指定した割合が必要でないか使用できない場合は、これより少ないメモリを使用します。
値にゼロ(0)を指定すると、動的キャッシュはオフになります。この場合、使用できるキャッシュは L1 のみで、[キャッシュ割当サイズ]で指定したサイズになります。データベース サーバー専用のマシンを使用している場合、[MicroKernel の最大メモリ使用量]を最大値に設定するか、オペレーティング システムが占有しないメモリの割合を指定します。データベース サーバーでほかのアプリケーションが実行され、これらすべてとパフォーマンスのバランスをとる必要がある場合は、低い値を設定して、データベース キャッシュが利用可能なメモリを使用する場合に、ほかのアプリケーションと競合しないようにする必要があります。
メモ
[キャッシュ割当サイズ]に[MicroKernel の最大メモリ使用量]の値よりも大きな物理メモリ量を設定した場合は、[キャッシュ割当サイズ]の値が優先されます。たとえば、物理メモリが 1 GB のマシンで、[キャッシュ割当サイズ]に 600 MB、[MicroKernel の最大メモリ使用量]に 40% を設定したとします。L1 キャッシュには 600 MB のメモリが割り当てられます。[キャッシュ割当サイズ]の値の方が大きいので、その値が優先され、L1 キャッシュに割り当てられるメモリ量は[MicroKernel の最大メモリ使用量]に指定された値よりも大きくなります。
次の方程式を使用してMicroKernel 最大メモリ使用量の近似値を割り出します。
(L1 キャッシュサイズ + 内部割り当て + L2 キャッシュ サイズ / 物理メモリのサイズ) * 100
この場合、
パフォーマンス チューニングの詳細については、「パフォーマンス チューニング」を参照してください。
この設定は、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 - ディスク容量によって制限される
|
ログ バッファー サイズの 2 倍
|
バイト
|
必要
|
この設定は、トランザクション ログ セグメントの最大サイズを指定します。ログ ファイルが制限されたサイズに達すると、MicroKernel は、古いログ セグメント ファイルを閉じ、新しいファイルの使用を開始します。トランザクション ログ セグメントのサイズを制限することにより、MicroKernel が一時的に使用するディスク容量を少なくできるため、これを行いたいと思われるでしょう。しかし、サイズを制限すると、ログ セグメントを頻繁に閉じて作成することが必要になるため、MicroKernel の処理量が増え、パフォーマンスが低下する可能性があります。
メモ
このオプションに[ログ バッファー サイズ]で指定した値よりも小さい値を設定すると、データベース エンジンは[トランザクション ログ サイズ]の設定を自動的に[ログ バッファー サイズ]の値に合わせます。
|