この一般リリースでは、以下の新機能と変更が含まれています。

Pervasive PSQL v11 は、特にマルチコア マシンにおけるスケーラビリティとパフォーマンスを向上させることを目的に設計されています。マルチコア マシンに Pervasive PSQL v11 をインストールすると、マルチユーザー環境ですぐにその効果が得られます。

どれほどの効果があるのか知りたいと思われるでしょう。ハードウェア テクノロジの進歩によってスケーラビリティとパフォーマンスは明らかに向上しており、それらを利用できると考えられます。これまでは、ハードウェア テクノロジの進歩といえば速度の高速化を指していました。つまり、アプリケーションの実行速度が速くなるということです。近年、コンピューター テクノロジにおける進歩は、クロック速度の高速化ではなく並列処理効率の向上を指すようになってきました。これにより、アプリケーションに対し、おそらく今まで取り組むことがなかった課題が出てきました。

この進歩は、マルチコア環境のためにだけに変わったのではなく、劇的に変わっています。たとえば、複数のユーザーでデータを共有し、トランザクションの整合性を維持する必要があるデータベースを使用するアプリケーションの場合は、マルチコア プロセッサ上では実行速度が低下する可能性があります。

Pervasive PSQL v11 を使用する大多数のアプリケーションがこの状況に当てはまるので、マルチコアのサポートが Pervasive PSQL における主要な機能となっています。これはマルチユーザー アプリケーションをマルチコア環境に移行する場合に最も重要です。

ほとんどのソフトウェア アプリケーションは変更することなくマルチコア マシンで実行できます。しかし、次のような状況では変更を検討する必要があります。これは実在のフィードバックに基づいています。

どうしてでしょう？これは、ビジネス ソリューションの重要な各要素が、マルチコアの新しい世界では互いに最適化されていないからです。

これを次のように考えてみましょう。"アプリケーション" は、作成したコード（一般的な定義では "アプリケーション"）、データベース、オペレーティング システムおよびハードウェアという 4 つの主要な要素で構成されています。ハードウェアの変更は大きな影響があります。ただし、これはそのハードウェアが変更前のものと根本的に異なっていた場合です。

しかし、適切な調整を行うことで処理速度が上がるアプリケーションであれば、ハードウェアの変更の利点を活用し、パフォーマンスを大幅に向上させることができます。多くの場合、データベースなどアプリケーション スタックの一部をスワップ アウトすればマルチコアの問題を解決することができます。アプリケーションをすぐに変更する必要はありません。この手段は、アプリケーション開発の長期的な方策を講じる間、時間を稼ぐためのリスクの低い方法として用いることができます。

Pervasive PSQL v11 をデータベースとして使用すれば、マルチコア マシン上でパフォーマンスとスケーラビリティが向上することを実感することができます。

Pervasive PSQL v11 は、複数の類似動作を実行する並列スレッドを提供するよう設計されています。並列処理が増加したことで、マルチ プロセッサに関わる地点までのスループットが改善します。この結果、複数のクライアントがセントラル サーバーにアクセスするマルチコア環境で、データベース エンジンのパフォーマンスが向上します。マルチクライアント アプリケーションは、コードを再コンパイルしたり再設計することなく、このパフォーマンスの向上による利点を得ることができます。

また、Pervasive PSQL v11 はトランザクショナル インターフェイスにおける低レベルの同期メカニズムについても機能強化しています。複数のユーザーが、キャッシュされた同じファイル ページを同時に読み込むことができ、またそれらの操作はそれぞれ別々のサーバー CPU で処理することができます。チェックポイントやログ管理などの非ユーザー操作には、さらに別のサーバー CPU を使用することもできます。

Pervasive PSQL v11 は、特にマルチコア ハードウェア向けに行ったアーキテクチャ設計によってスケーラビリティも強化されました。たとえば、複数のユーザーがそれぞれ別々のファイルにアクセスする場合、それらの操作を別々のサーバー CPU で処理することができます。また、データベース エンジンは、以前に比べ少ないオーバーヘッドで多くのユーザー ロードを処理することもできるので、より安定したスループットが実現します。

パフォーマンスの向上と同様に、コードを再コンパイルしたり再設計することなく、このスケーラビリティの向上によるすべての利点を得ることができます。

Pervasive PSQL v11 におけるマルチコアに関する改善点の大部分は透過的です。その最適化をより高めるために調整する必要がある設定は特にありません。なお、［通信スレッド数］設定は変更されています。この設定を使用すると、パフォーマンスを微調整することができます。設定を参照してください。

マルチコア環境におけるハードウェアとソフトウェアの相互作用によっていくつかの問題が出てきました。それによりアプリケーションでパフォーマンスが低下する可能性もあります。その問題の中には、マルチスレッドとメモリの競合などがあります。これらの問題およびその他の問題の詳細については、CITO Research の CTO（最高技術責任者）Dan Woods 氏によるホワイト ペーパー「マルチコアのジレンマ」（The Multi-core Dilemma）を参照してください。このホワイト ペーパーは Pervasive Web サイトから入手可能です。

本ドキュメントではマルチ スレッドとメモリの競合について簡単に説明します。これによりマルチコアのサポートが Pervasive PSQL v11 の主要な機能となっている理由を明らかにします。

マルチスレッド化されたアプリケーションは、必ずしもマルチコア マシンで実行速度が速くなるわけではありません。事実、マルチスレッド化されたアプリケーションの実行速度は低下する場合があります。

スレッドが正しく並列に動作するためには、それらのスレッドを同期させる必要があります。アプリケーションがマルチスレッド化できても、スレッド自体が同期するわけではありません。実際、この状況はごく一般的なことで、古いアプリケーションは必要に応じて追加のスレッドを分離独立させています。これは、効率性を確保する設計に基づくよりも便利なためです。そのようなアプリケーションはスレッドが互いに競合するため、マルチコア マシンで効率よく実行されません。スレッドの競合により、マルチコアが関わっていない地点までのスループットが阻害されるので、マルチコアが提供されてもメリットがありません。

また、マルチコア アーキテクチャは、マルチ スレッドを一連のシングル スレッドとして分離独立させるサブタスクを認識することがあります。そうすると、シングルスレッド化されたプログラムと同じように、そのスレッドは単独のキューに強制的に入れられ、1 つずつ処理されます。キャッシュではこの問題を改善できません。より悪化してしまいます（メモリの競合を参照してください）。

可能であれば、コアごとに個別のデータを処理するようにします。そうでなければ、同期に伴うオーバーヘッドによってパフォーマンスが著しく低下する恐れがあります。Pervasive PSQL v11 は、同期される並列スレッドを提供するよう設計されていることを思い出してください。

開発者はアプリケーションの作成時に、並列処理または非並列処理のどちらにするか決定する必要はありませんでした。アプリケーションの大半はシーケンシャルに作成されます。つまり、これらは逐次的または連続的に情報へアクセスするということです。メモリの競合に伴う問題は、マルチコア システムで非並列（一般的）アプリケーションを実行したときに発生します。

人々が一群となって一斉に 1 つの出入り口を通り抜けようとする様子を描く（喜劇的）寸劇を思い浮かべてください。 出入り口は人々でいっぱいになり、ぎゅうぎゅう詰めに押し込められている様子は面白いと思われるでしょう。 では次に、これを複数のスレッド（人々）を同時に処理（出入り口）しようとする状況に置き換えてみてください。4 個から 16個（またはそれ以上）のスレッドが一度に同じプロセッサを通り抜けようとする場合は混雑が生じ、オペレーティング システムがそれらを整理する必要があります。

複数のコアまたはプロセッサに同じデータを指すキャッシュがある場合、1 つのコアがそのデータを変更すると、別のコアにキャッシュされたデータは無効になります。このため、キャッシュを同期させる必要があります。また、あるプロセッサのタスクが、別のプロセッサのタスクによって作成された古いデータに対して実行されないようにするために、各プロセッサがキャッシュを繰り返しチェックする場合にも競合が発生します。このチェックでは、各プロセッサがメモリ キャッシュを個別かつ順次にチェックするので、処理速度が低下します。

メモリの競合を減らす方法として、Pervasive PSQL v11 では複数のユーザーによる操作を別々のサーバー CPU 上で処理することを思い出してください。複数のユーザーが、キャッシュされた同じファイル ページを同時に読み込むことができ、また別々のファイルにアクセスすることができます。

オペレーティング システム（OS）はマルチ コアの問題をどのように支援するのか、知りたいと思われるでしょう。最新の 64 ビット OS にもかかわらず、期待するほどの効果はありません。

リソースの競合が発生した場合、OS がその問題の解決にあたります。大多数のアプリケーションで、マルチコア システム上の OS がスレッドの競合を処理するときには速度が低下します。つまり、マルチコア システム上の OS では、競合ポイントの解決に時間がかかります。

これには次のような理由があります。アプリケーションがオペレーティング システムに対し、単一ファイルで複数のタスクを実行する方法を今もなお要求している場合、マルチコア用に最適化されたオペレーティング システムであっても問題を解決することはできません。

マルチコア処理用の命令が組み込まれていないアプリケーションからのリクエストを OS が受ける場合、その OS にとってリクエストを処理する順序の並び替えは大きな負荷となります。これは車の交通渋滞に似ています。概念的に言えば、OS はそれぞれの車を通す前に、待機している車の各運転手に対し、進行する準備ができているかどうか尋ねます。そのような処理渋滞が OS レベルで起こっていたとしても、ユーザーは、その処理速度の低下をアプリケーションのパフォーマンスの問題としてとらえます。

マルチコア用に最適化されたアプリケーションは、共有リソースの管理方法およびリソースへのアクセス優先度について、OS へ指示を与えることができます。情報の要求は、キャッシュ ラインの競合を行わない、または中央メモリにアクセスしないよう整理されます。

Pervasive PSQL v11 には、特にマルチコア ハードウェア向けのアーキテクチャ設計が含まれていることを思い出してください。低レベル ロックは、マルチコア マシン向けに最適化されました。

マルチコア マシンは今や標準仕様となっているので、現行または将来のハードウェア アップグレードには複数のコアが含まれます。一方、オペレーティング システムは最良のパフォーマンスを支援するためのマルチコア マシンに対応できていません。これらの状況に対処するにはどのような方法が一番よいでしょうか。

最終的には、マルチコア マシンで最適に実行されるようアプリケーションを再設計する必要があります。そうすれば、アプリケーションはマルチ プロセッサにおける並列スレッドを利用し、さらに同期の問題を回避することができます。

再設計には周到な計画と実装するための時間を要します。場合によっては数年かかるかもしれません。それまでの間は従来の状況が続くことになるでしょう。このセクションの冒頭でも述べたように、アプリケーションをマルチコア環境に移行する上で、マルチコアのサポートは最も重要です。

"アプリケーション" はコード、データベース、オペレーティング システムおよびハードウェアで構成されています。ハードウェア システムは既にマルチコア サポートに対応しています。アプリケーションがマルチコアを活用することによって、オペレーティング システムからなんらかの支援が得られます。それはデータベースにゆだねられます。

Pervasive PSQL v11 のマルチコア機能は、マルチコア環境向けに最適化されていないアプリケーションでユーザーやエンド ユーサーが経験するパフォーマンスの低下を補うのに役立ちます。ほとんどの場合、アプリケーション コードの再コンパイルや変更を行わなくても、アプリケーションのパフォーマンスを向上させることができます。

インターネット プロトコル バージョン 6（IPv6）は IPv4 の後継として設計された次世代インターネット プロトコルです。ここでは、以下の項目について説明します。

Pervasive PSQL v11 は Windows オペレーティング システムにおける以下のアクセス方法に IPv6 をサポートします。

どちらのアクセス方法も、IPv4 環境、IPv6 環境、またはこれら 2 つを兼ね備えた環境で正しく機能します。Pervasive PSQL で特別な設定を行う必要はありません。

Pervasive PSQL Client は、Pervasive PSQL データベース エンジンを実行している IPv6 ホストへ接続します。これは IPv4 の場合も同じです。つまり、クライアントは DTI を介して、あるいは URI または UNC の記述によってサーバーを指定し接続します。サーバーの指定は、Pervasive PSQL Server または Workgroup が実行されているマシンのマシン名または IP アドレスのどちらを用いても可能です。

以下のドキュメントも参照してください。

次に IPv6 アドレスを使用してサーバーを指定する方法について説明します。

未加工の IPv6 アドレスは、コロンで区切られた 8 個のセグメントで構成されます。各セグメントは 4 桁の 16 進数値として記述できます。たとえば、「1234:5678:90ab:cdef:1234:5678:90ab:cdef」と表記されます。

Pervasive PSQL がサポートするのはユニキャスト アドレスのみです。Pervasive PSQL で使用できるユニキャスト アドレス形式は以下のとおりです。

IPv6 にはアドレス識別子が含まれています。この識別子はショートカットとして機能したり、また詳細な宛先の指定に用いたりすることができます。 Pervasive PSQL は IPv6 に以下の修飾子をサポートします。

UNC パスでは、コロンなど特定の文字を使用することはできません。 未加工の IPv6 アドレスではコロンを使用するので、UNC パスの扱いには異なる方法が使用できます。 Pervasive PSQL は以下の方法をサポートします。

ipv6-literal.net 名は以下に示す 3 つの変更を施した未加工の IPv6 アドレスです。

例：

Ipv6-literal.net 名は Pervasive PSQL で使用される URI または UNC で受け入れられます。

かっこ付き IPv6 アドレスとは角かっこで囲まれた未加工の IPv6 アドレスです。この形式は UNC で正しく動作するアドレスとしても参照されます。

例：

角かっこの使用は、Pervasive PSQL における URI または UNC で使用する未加工の IPv6 アドレスには必要です。制限事項を参照してください。URI で、ゾーン ID を含めたアドレスを使用する場合、ゾーン ID 文字 "%" はエスケープ文字 "%25" に置き換えられることに注意してください。制限事項を参照してください。UNC パスにおけるかっこ付きの IPv6 または UNC 形式のアドレスは Windows XP および Windows 2003 オペレーティング システムではサポートされません。

Pervasive PSQL で IPv6 を使用する際の制限事項を次の表に示します。

次の表では、Pervasive PSQL v11 における IPv6 のサポートについてよく寄せられる質問（FAQ）の回答を記載しています。

以下の Pervasive PSQL ユーティリティで IPv6 がサポートされます。これらユーティリティで特別な設定を行う必要はありません。

IPv6 は広く採用されていないため、ここではアプリケーション プログラマーにとって有用と思われるいくつかの側面について説明します。ネットワークの概念または IPv6 の詳しい説明は行いませんが、IPv6 について簡単に紹介します。IPv6 の詳しい説明については、www.ipv6.org（英語サイト）に記載の「IPv6 specification（仕様）」、また、さまざまなオペレーティング システム ベンダーおよびネットワーク ハードウェア ベンダーが提供している IPv6 ドキュメントを参照してください。

IPv6 は IPv4 の後継として設計された次世代インターネット プロトコルです。IPv4 はインターネットで使用された最初のインプリメンテーションであり、現在も最も多く使用されています。IPv4 には、その使用年数やネットワークにおける世界的環境の変化のため、将来的なニーズに対応できない限界がいくつかあります。

最も深刻な限界は、アドレス空間がいずれ枯渇するということでしょう。現在でさえ、パブリック IPv4 アドレスは相対的に十分とはいえません。さらに、全世界に広がるネットワークでは、構成性能の簡素化、セキュリティの強化および拡張性など、IPv4 が提供できる限度を超えた要件を導入しています。

IPv6 アドレスは、IPv4 の欠点を解決するだけでなく多くの利点をもたらします。最近のハードウェアやオペレーティング システムでは IPv6 サポートを提供します。特定の分野のアプリケーションでは既に IPv6 サポートが必要となっています。たとえば、米国および日本の政府は IPv6 への対応を義務付けています。IPv4 はいずれ IPv6 に切り替えられるため、この切り替えが早ければ早いほど IPv6 の利点がわかるようになります。

IPv4 から IPv6 サポートへの移行期間中は、いくつかのオペレーティング システムで両方のプロトコルが機能する可能性があります。オペレーティング システムによって、これは "デュアル IP レイヤー" または "デュアル スタック" と呼ばれます。ただし、IPv4 および IPv6 トラフィックは別々にルーティングされます。2 つのホスト間で通信する場合、双方が共に IPv4 対応、あるいは IPv6 対応である必要があります。

オペレーティング システム レベルでネットワーク設定を構成する場合は、以下の点に留意してください。

hosts ファイル内で、各 IP は互換性のあるアドレス形式を持つ行のみを使用します。たとえば、あるホスト名の IPv4 アドレスを要求した場合、IPv6 の行は無視されます。また、互換性のあるアドレスが localhost に適用されるので、通常 hosts ファイルには 127.0.0.1（IPv4）および ::1（IPv6）という localhost 行があります。

ホスト名を IP アドレスへ変換するために検索を行う場合、アプリケーション プログラマーが IPv4、IPV6 またはその両方を使用するかどうかを指定します。オペレーティング システムのネットワーク コンポーネントは、管理者レベルの環境設定を使用して、ローカル hosts ファイル、ローカル DNS キャッシュ、リモート DNS サーバーなど、検索の順序を決定します。IPv6 では、DNS を使用しないでリモート マシンを見つけることができる新しい自動検出プロトコルがあります。

以下の制限事項に従い、hosts ファイルに IPv6 アドレスを指定できます。

hosts ファイルが最も役立つのは、ゾーン ID が不要な場合です。

ゾーン ID はネットワーク インターフェイスに割り当てられます。単独のネットワーク インターフェイス カード（NIC）およびゲートウェイを用いる場合、ゾーン ID は必要とされません。これは、単独のゲートウェイであれば 1 つのルートのみで到達するからです。IPv6 に対応しているほとんどマシンには、ISATAP、6to4、または Teredo のような変換ルーターのビルトイン サポートのため、複数のインターフェイスが搭載されています。

netsh コマンドでは、インターフェイス名（"Local Area Connection 2" または "eth0" など）を使用する必要があります（interface= パラメーターを使用します）。IPv6 アドレスで ping を使用する場合は、ゾーン ID を使用する必要があるかもしれません。たとえば、「fe80::abcd%10」と指定される場合、10 進数の 10 がゾーン ID です。

Windows プラットフォームでは、ipconfig コマンドを使用するとインターフェイスごとのゾーンID を表示できます。

IPv6 では、DNS（Domain Name System）を使用しないでリモート マシンを見つけることができる自動検出プロトコルがあります。LLMNR（Link Local Multicast Name Resolution：リンク ローカル マルチキャスト名前解決）は、DNS パケット形式に基づくプロトコルです。LLMNR を使用すると、IPv4 ホストおよび IPv6 ホストのどちらも、DNS サーバーを使用することなく単一のサブネット上のホストの名前解決を行うことができます。各 IPv6 マシンはリンク ローカル アドレスを持つため、そのマシンがサブネット上に存在する場合は、リンク グローバル アドレスで DNS 検索を行う前に、LLMNR によってそのマシンの場所を特定（名前解決）します。

Pervasive PSQL v11 は、64 ビット アプリケーション用 ODBC インターフェイスをサポートするようになりました。64 ビット ODBC ドライバーは Pervasive PSQL Server 64 ビットおよび Pervasive PSQL Client 64 ビットでインストールされます。

64 ビット Windows オペレーティング システムの場合、Windows レジストリ設計により 64 ビット DSN と 32 ビット DSN は区別されています。 Windows ODBC データ マネージャーの場合、作成されたアプリケーションのビット アーキテクチャ（ビット数）がわかっていること、またその同じビット数を用いて DSN を作成していることが要求されます。 Pervasive PSQL v11 はこの同じモデルを採用しています。このため、64 ビット アプリケーションは 64 ビット ODBC ドライバーを使用し、32 ビット アプリケーションは 32 ビット ODBC ドライバーを使用します。

アプリケーションのビット数が Pervasive PSQL Server 製品のビット数と一致している必要はありません。たとえば、64 ビット ODBC ドライバーや 32 ビット ODBC ドライバーは、Pervasive PSQL Server 64 ビットまたは Pervasive PSQL Server 32 ビットのどちらででも使用することができます。

Pervasive PSQL v11 は次の表で示すように 3 つの ODBC ドライバーを提供します。

名前付きデータベースへの接続方法を単純化するため、Pervasive PSQL v11 には以下の点を改善しています。

次の表では、Pervasive PSQL v11 における ODBC および DSN のサポートについてよく寄せられる質問（FAQ）の回答を記載しています。

DSN 用の DTI 関数で管理するのは 32 ビット エンジン DSN のみです。そのため、以下の DTI 関数は 32 ビット エンジン インターフェイス ODBC ドライバーとともに廃止される予定です。

これらの関数の操作はすべて 32 ビット レジストリのみで行います。64 ビット データベース エンジンが 64 ビット オペレーティング システムにインストールされた場合にもこれは適用されます。32 ビット ODBC アドミニストレーターはエンジン DSN 用の DTI 関数を使用します。そのため、既存の エンジン DSN および新規作成されたエンジン DSN の一覧は 32 ビット レジストリ用のみです。

DSN を管理する関数の説明については、『Distributed Tuning Interface Guide』を参照してください。

ODBC アドニミストレーターによる DSN のセットアップには、以下のような変更が行われました。

GUI の新しいコントロールの説明については、『SQL Engine Reference』のDSN と ODBC アドミニストレーターの章を参照してください。

ODBC 用の sql.h および sqltypes.h ヘッダー ファイルには、32 ビット アプリケーションと 64 ビット アプリケーションのコンパイルに違いがあります。64 ビット ODBC の説明については、Microsoft Web サイトで ODBC に関するドキュメントを参照してください。 たとえば、以下の情報（英語）が有用です。

http://msdn.microsoft.com/en-us/library/ms716287(VS.85).aspx

64 ビット オペレーティング システムにインストールされた Pervasive PSQL Server および Client の場合、Pervasive PSQL Control Center（PCC）で 32 ビットまたは 64 ビット用に別々の ODBC アドミニストレーターを選択することができます。この選択は［ツール］メニューから行うことができます。『Pervasive PSQL User's Guide』のその他のユーティリティを参照してください。

また、［データベースの新規作成］ダイアログで DSN を作成するためのオプションは、32 ビット限定となりました（オプション名は［32-ビット エンジン DSN の作成］）。『Pervasive PSQL User's Guide』のデータベースの新規作成 GUI リファレンスを参照してください。（PCC は 32 ビット アプリケーションです。64 ビット バージョンは使用できません。）

Pervasive ODBC DSN セットアップ GUI は変更されました。ODBC DSN セットアップの GUI を参照してください。

Pervasive PSQL v11 は ADO.NET データ プロバイダーでバージョン 3.2 および 3.5 の 2 つのバージョンを提供します。デフォルトで、どちらのバージョンもデータベース エンジンおよび Pervasive PSQL Client と一緒にインストールされます。

Pervasive PSQL の 32 ビット版または 64 ビット版のどちらをインストールした場合でも、両方のデータ プロバイダーが Program Files (x86) ディレクトリ下に置かれます。ただし、ビット数によってデータ プロバイダーはそれぞれ異なります（同じものではありません）。各データ プロバイダーは 32 ビットおよび 64 ビットの両方の .NET Framework で動作します。

Pervasive PSQL ADO.NET データ プロバイダー 3.2 には前のバージョンからの新機能はありません。これは Pervasive PSQL v11 でそのバージョン 3.2 を使用したいアプリケーション開発者向けに含まれています。

Pervasive PSQL ADO.NET データ プロバイダー 3.5 は .NET Framework 3.5 SP1 における新機能をサポートします。このプロバイダーは、.NET Framework バージョン 2.0、3.0、3.5、3.5 SP1、および 4.0 に準拠しています。バージョン 3.5 のプロバイダーは、.NET Framework 4.0 で導入された新機能をサポートしませんが、Entity Framework 1.0 の全機能をサポートする .NET Framework 4.0 で実行します。

さらに、Pervasive PSQL ADO.NET Data Provider 3.5 には以下の主な機能が含まれます。

詳しい説明については、開発者用ドキュメントの『Pervasive Data Provider for .NET Guide and Reference』を参照してください。

Pervasive PSQL v11 では以下の新たな開発環境向けの PDAC が含まれています。

RAD Studio 2009 および 2010 のサポートは、Pervasive PSQL v11 でサポートされる Delphi および C++ Builder コンポーネントのみを対象としています。

Pervasive PSQL v11 では、バージョン 6 より古い Delphi および C++ Builder 開発環境向けの PDAC 統合は提供されません。廃止予定および廃止された機能を参照してください。

開発者用ドキュメントの『Pervasive Direct Access Components Guide』も参照してください。

Pervasive PSQL v11 では SDK アクセス方法である DTI（Distributed Tuning Objects）の機能を拡張しています。

Pervasive PSQL v11 には以下の新しいメソッドが含まれています。

『Distributed Tuning Objects Guide』でこの新しいメソッドを参照してください。

製品の認証とは、特定のハードウェア構成アイテムを製品のライセンスに関連付けるキーの検証処理です（このキーは「製品キー」と呼びます）。この関連付けの結果、インストール ID が固有なものとなります。これにより、ソフトウェアが正当なものであること、また適切なハードウェアおよびソフトウェア プラットフォームに存在することを保証します。

製品キーを認証すると、その固有のインストール ID が Pervasive へ送られます。Pervasive ではキーの信頼性を検証し、そのキーが複数のインストールに使用されていないことを確認します。

デフォルトでは、評価版キーが Pervasive PSQL と一緒にインストールされ、このキーは一定期間を過ぎると失効します。データベース エンジンを使用し続けるためには、評価期間が終わる前に期限なしキーを用いて製品を認証しておく必要があります。製品の認証には、以下の 3 種類の方法があります。

Pervasive PSQL データベース エンジンをインストールしているマシンがインターネットへ直接アクセスできる場合は、オンライン 認証が利用できます。

これは最も一般的な認証方法で、インストール処理の一部として透過的に行うことができます。インストール時に適切な時点でキーを入力すると製品の認証が処理されます。

インストール後でも、License Administrator を使用することで製品の認証が行えます。『Pervasive PSQL User's Guide』の キーを認証するにはを参照してください。製品を認証した後に、データベース エンジンを再起動する必要はありません。

インターネットへ直接アクセスできない場合は、リモート認証またはオフライン認証を使用できます。

データベース エンジンがあるマシンはインターネット接続できないが、そのマシンがインターネット接続可能な別のマシンとネットワーク接続している場合は、リモート認証が使用できます。PSQL クライアントは、インターネット アクセスが可能なマシンにあることが必要です。

インターネットへ接続できないマシンにデータベース エンジンをインストールする場合は、インストール時にキーを提供することができません。この場合は一時ライセンスを使って製品をインストールします。

製品のインストール後、クライアント マシンで PSQL のライセンス ユーティリティを使用して、インターネット接続不可のマシンで製品を認証します。リモート認証は、PSQL クライアントがデータベース エンジンとインターネット アクセスとの間を仲介する役目を果たすことを除けば、オンライン認証と同様です。

『Pervasive PSQL User's Guide』の キーをリモートで認証するにはを参照してください。製品を認証した後に、データベース エンジンを再起動する必要はありません。

データベース エンジンがインストールされているマシンが、ネットワークへもインターネットへも接続できない場合は、オフライン認証を使用します。

オフライン認証には 2 つのマシンを必要とします。どちらかのマシンにインターネット アクセスおよび PSQL クライアントが必要です。もう一方のマシンは孤立しており（クライアント マシンまたはインターネットへ接続できない）、データベース エンジンがあります。

オフライン認証に使用するユーティリティおよびその使用手順については、『Pervasive PSQL User's Guide』のキーをオフラインで認証するにはを参照してください。製品を認証した後に、データベース エンジンを再起動する必要はありません。

状況によっては、製品の認証を何度も行う必要があるかもしれません。たとえば、サーバー マシンを新しいものにリプレースする場合、その新しいマシンで Pervasive PSQL を認証したいと思われるでしょう。1 つの製品キーを初めて認証解除した場合は、その後、最大 5回まで認証することができます。

認証解除は、製品キーと特定のマシンのハードウェア構成との関連付けを切り離します。これにより、別のマシンで製品を認証することができ、新しいハードウェア構成と関連付けし直すことができます。

Pervasive PSQL で提供しているライセンス ユーティリティを使用すれば、オンラインまたはリモートによる認証解除を使用してキーを認証解除することができます。オンラインで認証解除する場合は、キーを認証解除するにはを参照してください。リモートで認証解除する場合は、キーをオフラインで認証解除するにはを参照してください。これらのタスクについては、『Pervasive PSQL User's Guide』を参照してください。

オフラインの認証解除については、弊社サポート部門へのご連絡が必要です。

製品キーを認証解除すると、そのキーに関連付けられているすべての追加ユーザー カウントも認証が解除されるので注意してください。一時ライセンスを認証解除することはできません。これは、認証の有効期限が過ぎると無効になります。

Pervasive PSQL v11 では、製品を仮想マシン内で認証することができます。Pervasive PSQL は物理マシンで直接使用しようと、仮想マシン内で実行しようと、同じライセンス要件が適用されます。各製品キーに関連付けられるソフトウェアは 1 つだけなので、仮想イメージ（クローンやコピーも含む）ごとに個別の製品キーが必要です。

仮想マシン用の認証および認証解除は、このセクションの前で説明した同じ方法で動作します。

仮想イメージと同様に、1 つのクラスター ノードで製品キーと関連付けられる Pervasive PSQL は 1 つだけです。クラスター環境内のノードごとにも、それぞれキーが必要です。

サーバーのハードウェアに障害が生じた場合、そのサーバー上の Pervasive PSQL 製品に関連付けられた製品キーはまだ認証されている状態です。これは、本製品を別のシステムで使用することができないことを意味します。製品キーを再認証できる状態にするには、弊社サポート部門までお問い合わせください。

直ちにシステムを作動させる必要がある場合は、製品 CD-ROM またはダウンロードしたインストール イメージを使用して、Pervasive PSQL v11 を 30 日間評価版として代替機にインストールします。

Pervasive PSQL v11 では、製品認証テクノロジを弊社の OEM パートナーにも拡張します。OEM パートナーである場合、以下のリソースを参照してください。

Pervasive PSQL v11 では以下の設定が変更されています。

通信スレッドの設定範囲およびデフォルト値が変更されました。

前のバージョンでこの範囲は 1 ～ 1,024 で、デフォルトは 16 でした。

通信スレッドの設定は、ある特定の状況下における改善に役立ちます。たとえば、1 つのファイルに対して多くのクライアントが操作（主に書き込み）を行うような場合、より低い値を設定すればスケーラビリティが向上するはずです。スレッド数の値をより低くすると、システム リソースでコンテキスト スイッチを行わないようにします。このほか、大量のワーカー スレッド間でスラッシングによって速度低下が発生する状況も、この通信スレッドの設定によって改善する可能性があります。Pervasive PSQL v11 で、ワーカー スレッドは、既存の全スレッドがレコードまたはファイルのロックで待機している場合にのみ動的に作成されます。

『Advanced Operations Guide』の通信スレッド数を参照してください。

［リッスン IP アドレス］設定では、複数の IP アドレスを受け付けるようになりました。各アドレスはカンマで区切って指定できます。このアドレス文字列は IPv4 アドレスと IPv6 アドレスの組み合わせも可能です。IPv6 アドレスにサポートされるすべての形式が使用できます。IPv6 アドレスの形式を参照してください。

［TCP/IP マルチホーム］設定がオフ（チェックボックスがオフ）の場合、データベース エンジンが受信待ちする（単一または複数の）IP アドレスを［リッスン IP アドレス］設定に指定します。『Advanced Operations Guide』のリッスン IP アドレスおよび TCP/IP マルチホームを参照してください。

Pervasive PSQL v11 では、以下のユーティリティに対して変更が行われています。

Pervasive PSQL Control Center (PCC）では DSN に関して、以下の点が変更されています。

ODBC およびデータ ソース名（DSN）も参照してください。

32 ビット DSN 用の Pervasive ODBC セットアップ GUI が変更されました。64 ビット DSN 用の Pervasive ODBC セットアップ GUI が新たに追加され、利用できます。ODBC DSN セットアップの GUI を参照してください。

Pervasive PSQL v11 では、以下のカテゴリの機能を使用することは推奨しません。これらの機能は Pervasive PSQL v11 でも利用できますが、将来的には製品から削除される予定です。今後、新たにアプリケーションを開発したり、既存のアプリケーションを修正する際の参考にしてください。

以下の ODBC 機能は Pervasive PSQL v11 でも利用できますが、将来的には製品から削除される予定です。

Delphi 2006（および 2006 と互換性のある 2007）用の PDAC 動的ライブラリは Pervasive PSQL v11 でも利用できますが、将来的には製品から削除される予定です。

以下の機能は Pervasive PSQL v11 でサポートされなくなりました。