高度な機能

接続プールを使用すれば、作成済みの接続を再利用できるので、データプロバイダーはデータベースに接続するたびに新しい接続を作成する必要がなくなります。データプロバイダーでは .NET クライアントアプリケーションで自動的に接続プールを使用できるようになりました。

接続プールの動作は、接続文字列オプションによって制御することができます。たとえば、接続プール数、プール内の接続数、接続が破棄されるまでの時間（秒数）を定義することができます。

ADO.NET の接続プールは .NET Framework によって提供されません。ADO.NET データプロバイダー自体に実装する必要があります。

各接続プールは、それぞれ特有の接続文字列と関連付けられます。デフォルトでは、接続プールは一意な接続文字列を使って最初にデータベースに接続したときに作成されます。プールには、プールの最小限のサイズまで接続が格納されます。プールが最大限のサイズに達するまで、接続がプールに追加されていきます。

プールは、その中で接続が開いている限り、あるいは、Connection オブジェクトへの参照を持つアプリケーションによって使用されており、そのオブジェクトに開いている接続がある限り、アクティブであり続けます。

新しい接続を開いたとき、その接続文字列が既存のプールと一致しない場合は、新しいプールを作成する必要があります。同じ接続文字列を使用することで、アプリケーションのパフォーマンスやスケーラビリティを向上させることができます。

以下の C# コード例では、3 つの新しい PsqlConnection オブジェクトが作成されます。ただし、これらのオブジェクトを管理するために必要な接続プールは 2 つのみです。1 番目と 2 番目の接続文字列では、ユーザー ID とパスワードに割り当てられる値だけが異なることに注意してください。

接続プールは、アプリケーションが使用する一意な接続文字列を作成している最中に作成されます。プールが作成されると、Min Pool Size 接続文字列オプションによって設定される、プールの必要最小限のサイズ条件を満たすだけの接続がプールに格納されます。アプリケーションが Min Pool Size を超える接続を使用する場合、データプロバイダーは Max Pool Size 接続文字列オプション（プール内の最大接続数を設定します）の値になるまで、プールに接続を追加割り当てします。

Connection.Open(...) メソッドを呼び出すアプリケーションで Connection オブジェクトが要求されたとき、プールから使用可能な接続が入手できる場合には、接続はプールから取得されます。使用可能な接続とは、現在ほかの有効な Connection オブジェクトによって使用されておらず、合致する分散トランザクションコンテキストを持ち（妥当な場合）、サーバーへの有効なリンクを持っている接続と定義付けられます。

プールの最大サイズに達し、かつ入手できる使用可能な接続がない場合には、要求はデータプロバイダーのキューに入れられます。データプロバイダーは使用可能な接続をアプリケーションへ返すために、Connection Timeout 接続文字列オプションの値が示す時間だけ待ちます。この時間が経過しても接続が入手可能にならなかった場合は、データプロバイダーはアプリケーションにエラーを返します。

データプロバイダーに対し、プールされている接続数に影響を与えないで、指定したプールの最大サイズを超える接続を作成できるようにすることができます。これはたとえば、時折発生する接続要求の急増を処理する場合などに有用です。Max Pool Size Behavior 接続文字列オプションを SoftCap に設定することにより、作成される接続数は Max Pool Size に設定された値を超えることが可能になりますが、プールされる接続数は設定値を超えません。プールの最大接続数が使用されている場合、データプロバイダーは新しい接続を作成します。接続がプールに返されたとき、そのプールにアイドル状態の接続が入っている場合には、プールメカニズムは接続プールが Max Pool Size を決して超えないよう、破棄する接続を選択します。Max Pool Size Behavior を HardCap に設定した場合、作成される接続数は Max Pool Size に設定された値を超えません。

重要：PsqlConnection オブジェクトの Close() または Dispose() メソッドを使用して接続を閉じると、その接続はプールに追加されるか戻されます。アプリケーションで Close() メソッドを使用した場合、接続文字列の設定は Open() メソッドを呼び出す前の状態にとどまります。Dispose メソッドを使用して接続を閉じた場合には、接続文字列の設定は消去され、デフォルトの設定に戻されます。

接続プールから接続が削除されるのは、Load Balance Timeout 接続文字列オプションで決められた存続時間が過ぎた場合や、接続文字列の一致する新しい接続がアプリケーションによって開始された（PsqlConnection.Open() が呼び出された）場合です。

接続プールの接続をアプリケーションに返す前に、プールマネージャーはその接続がサーバー側で閉じられているかどうかを確認します。接続が有効でなくなっていれば、プールマネージャーはその接続を破棄し、プールから別の入手可能で有効な接続を返します。

再使用するための接続プールから接続をどのような順序で削除するかを、Connection Pool Behavior 接続文字列オプションを用いて、接続の使用頻度または使用時期を基に制御することができます。接続をバランスよく使用するには、LeastFrequentlyUsed 値または LeastRecentlyUsed 値を使用します。あるいは、毎回同じ接続を使用した方がパフォーマンスが良くなるアプリケーションの場合は、MostFrequentlyUsed 値または MostRecentlyUsed 値を使用できます。

Connection オブジェクトの ClearPool メソッドおよび ClearAllPools メソッドは、接続プールからすべての接続を削除します。ClearPool は特定の接続に関連付けられている接続プールを空にします。対照的に、ClearAllPools はデータプロバイダーによって使用されるすべての接続プールを空にします。メソッドを呼び出すときに使用中だった接続は、閉じるときに破棄されます。

メモ：デフォルトで、無効な接続を破棄することによって、接続数が Min Pool Size 属性で指定した数より少なくなった場合、新しい接続はアプリケーションで必要になるまで作成されません。

アイドル状態の接続が、そのデータベースへの物理的接続を失った場合には何が起こるのでしょうか。たとえば、データベースサーバーが再起動されたり、ネットワークが一時的に中断されるとします。プール内の既存の Connection オブジェクトを使って接続しようとするアプリケーションは、データベースへの物理的接続が失われているため、エラーを受け取る可能性があります。

Control Centerはこの状況をユーザーに意識させないで処理します。Connection.Open() では、データプロバイダーは単に接続プールから接続を返すだけなので、アプリケーションはこのとき何のエラーも受け取りません。SQL ステートメントを実行するために Connection オブジェクトが初めて使用されたとき（たとえば、Command オブジェクトの Execute メソッドを介して）、データプロバイダーはサーバーへの物理的接続が失われていることを検出し、SQL ステートメントを実行する前にサーバーへの再接続を試みます。データプロバイダーがサーバーへ再接続できた場合、アプリケーションには SQL の実行結果が返され、エラーは何も返されません。データプロバイダーはこのシームレスな再接続を試みる際、接続フェールオーバーオプションが有効になっていればそれを利用します。プライマリサーバーが使用できないときはバックアップサーバーへ接続するようデータプロバイダーを構成する方法については、接続フェールオーバーの使用を参照してください。

メモ：データプロバイダーは、SQL ステートメントの実行時にデータベースサーバーへの再接続を試みることができるため、ステートメントが実行されるときに接続エラーをアプリケーションへ返すことができます。データプロバイダーがサーバーに再接続できない（たとえば、サーバーがまだダウンしている）場合、実行メソッドは再接続の試行が失敗したことと、その接続が失敗した理由の詳細を知らせるエラーをスローします。

この接続プール内の停止接続を処理する技術には、接続プールメカニズムを超越して最高のパフォーマンスを得られるという効果があります。一部のデータプロバイダーは、接続がアイドル状態である間、ダミーの SQL ステートメントを使って定期的にサーバーに ping を実行します。その他のデータプロバイダーは、アプリケーションから接続プール内の接続の使用を要求されたときにサーバーに ping を実行します。これらの手法はいずれもデータベースサーバーへの往復を追加するため、結局のところ、アプリケーションの通常の操作が発生している間ずっと、アプリケーションの速度が落ちます。

データプロバイダーは、このデータプロバイダーを使用するアプリケーションの調整およびデバッグが行える PerfMon カウンターのセットをインストールします。PerfMon カウンターの詳細については、PerfMon のサポートを参照してください。

ステートメントキャッシュは、プリペアドステートメントのグループまたは Command オブジェクトのインスタンスで、アプリケーションによって再使用が可能です。ステートメントキャッシュを使用するとアプリケーションのパフォーマンスを向上させることができます。これは、プリペアドステートメントの動作が、そのステートメントがアプリケーションの存続期間中に何度再使用されたとしても、1 度だけ実行されるためです。キャッシュ内のステートメントの有効性を分析することができます（接続統計情報によるパフォーマンスの分析を参照してください）。

ステートメントキャッシュは物理接続に属します。実行された後、プリペアドステートメントはステートメントキャッシュに置かれ、接続が閉じられるまで保持されます。

ステートメントキャッシングは複数のデータソース間で使用できるほか、Data Access Application Block を含む Microsoft Enterprise Library などの抽象化技術の下で使用できます。

デフォルトで、ステートメントキャッシングは無効になっています。既存のアプリケーションのステートメントキャッシングを有効にするには、Statement Cache Mode 接続文字列オプションを Auto に設定します。この場合は、すべてのステートメントをステートメントキャッシュに置くことができます。

キャッシュすると明示的にマークしたステートメントのみをステートメントキャッシュに置くように、ステートメントキャッシングを設定することもできます。これを行うには、そのステートメントの Command オブジェクトの StatementCacheBehavior プロパティに Cache を設定し、Statement Cache Mode 接続文字列オプションに ExplicitOnly を設定します。

表 2 はステートメントキャッシング設定とその影響を要約したものです。

表 2 ステートメントキャッシュ動作の要約
動作	StatementCacheBehavior	Statement Cache Mode
ステートメントを明示的にステートメントキャッシュに追加します。	Cache	ExplicitOnly（デフォルト）
ステートメントをステートメントキャッシュに追加します。必要に応じ、ステートメントは、Cache とマークされたステートメント用の場所を空けるために削除されます。	Implicit（デフォルト）	Auto
ステートメントをステートメントキャッシュから明確に除外します。	DoNotCache	Auto または ExplicitOnly

ステートメントキャッシングを使用すると、アプリケーションの存続期間中にプリペアドステートメントを複数回再使用するアプリケーションはパフォーマンスが向上します。ステートメントキャッシュのサイズは Max Statement Cache Size 接続文字列オプションに設定します。ステートメントキャッシュのスペースが限られている場合は、1 度しか使用されないプリペアドステートメントをキャッシュしないでください。

アプリケーションが使用する全プリペアドステートメントをキャッシュすれば、最高のパフォーマンスを提供できるように思われます。しかし、この手法では、接続プールを使ってステートメントキャッシングを実装した場合、データベースのメモリに負担をかける結果になります。この場合、プールされた接続はそれぞれステートメントキャッシュを持ち、アプリケーションが使用する全プリペアドステートメントを含むことになります。これらのプールされたプリペアドステートメントは、すべてデータベースのメモリにも保持されます。

接続フェールオーバーによって、ハードウェア障害やトラフィックの過負荷などが原因でプライマリデータベースサーバーが利用できなくなった場合でも、アプリケーションは代替またはバックアップデータベースサーバーに接続することができます。接続フェールオーバーは、重要な .NET アプリケーションが依存するデータを常に使用可能な状態にします。

プライマリサーバーが接続を受け入れない場合に接続を試行する代替データベースのリストを設定することで、データプロバイダーにおける接続フェールオーバー機能をカスタマイズすることができます。接続が成功するまで、あるいはすべての代替データベースへの接続を指定した回数試行するまで、接続の試行が続けられます。

たとえば、図 1 は複数のデータベースサーバーを持つ環境を示しています。データベースサーバー A はプライマリデータベースサーバー、データベースサーバー B は 1 番目の代替サーバー、そしてデータベースサーバー C は 2 番目の代替サーバーとして設計されています。

まず、アプリケーションはプライマリデータベースであるデータベースサーバー A（1）に接続を試みます。接続フェールオーバー機能を有効にすると、アプリケーションがデータベースサーバー A に接続できなかった場合はデータベースサーバー B（2）に接続を試みます。その接続の試行も失敗した場合、アプリケーションはデータベースサーバー C（3）に接続を試みます。

このシナリオで、最低でもどれか 1 つのサーバーへは接続できると思われますが、接続にすべて失敗した場合、データプロバイダーはプライマリサーバーと各代替データベースに対し指定の回数分だけ接続を再試行させることができます。接続の再試行（Connection Retry Count）機能を使用すれば、試行回数を指定することができます。接続の試行間隔（Connection Retry Delay）機能を使用すれば、接続の試行間隔を秒数で指定することもできます。接続の再試行の詳細については、接続の再試行機能の使用を参照してください。

データプロバイダーは、現在対象としている代替サーバーとの通信が確立できなかった場合にのみ、次の代替サーバーへフェールオーバーします。データプロバイダーがデータベースとの通信に成功したが、ログイン情報が正しくないなどの原因でそのデータベースが接続要求を拒否した場合、データプロバイダーは例外を生成し、代替サーバーリスト内の次のデータベースへは接続を試行しません。これは、各代替サーバーがプライマリサーバーのミラーであり、認証パラメーターや関連情報がすべて同じであることが前提です。

接続フェールオーバーでは新しい接続のみを保護し、トランザクションやクエリの状態は保持しません。ご使用のデータプロバイダーにおける接続フェールオーバーの設定の詳細については、接続フェールオーバーの設定を参照してください。

クライアントロードバランスは接続フェールオーバーと共に動作してユーザーの環境で新しい接続を分散することで、接続要求に対応できないサーバーがないようにします。接続フェールオーバーとクライアントロードバランスがどちらも有効な場合、プライマリデータベースおよび代替データベースへ接続が試行される順序はランダムです。

たとえば、図 2 で示すようにクライアントロードバランスが有効になっているとします。

まず、データベースサーバー B への接続が試行されます（1）。それからデータベースサーバー C への接続が試行され（2）、続いてデータベースサーバー Aへの接続が試行されます（3）。その後、これと同じ順序で接続が試行されます。対照的に、このシナリオでクライアントロードバランスが無効だった場合、各データベースへの接続の試行はシーケンシャルな順序で行われます。つまり、最初にプライマリサーバーに試行したら、その後は代替サーバーリスト内のエントリ順に基づいて代替サーバーに試行します。

ご使用のデータプロバイダーにおけるクライアントとロードバランスの設定の詳細については、接続フェールオーバーの設定を参照してください。

接続の再試行では、データプロバイダーが最初の接続の試行に失敗した後に、プライマリサーバーおよび（設定している場合）代替サーバーへ接続を試行する回数を定義します。接続の再試行は、システム復旧の有力な方策となります。たとえば、停電などの電力障害によりクライアントとサーバーの両方が動作しなくなってしまうシナリオを考えてみましょう。電力が復旧してすべてのコンピューターが再起動される際、サーバーが自身のスタートアップルーチンを完了する前にクライアントがそのサーバーに接続しようとするかもしれません。接続の再試行が有効な場合、クライアントアプリケーションは、サーバー側で接続が正しく受け入れられるようになるまで接続を何度も試行し続けることができます。

接続の再試行は、サーバーが 1 つしかない環境でも使用できますが、複数サーバーを持つ環境における接続フェールオーバーシナリオの補完機能としても使用できます。

接続文字列オプションを使用すると、データプロバイダーが接続を試行する回数や接続の試行間隔を秒単位で指定できます。接続の再試行に対する設定の詳細については、接続フェールオーバーの設定を参照してください。

接続フェールオーバーによって、ハードウェア障害やトラフィックの過負荷などが原因でプライマリデータベースサーバーが利用できなくなった場合でも、アプリケーションは代替またはバックアップデータベースサーバーに接続することができます。

接続フェールオーバーに関する詳細については、接続フェールオーバーの使用を参照してください。

接続フェールオーバーを別のサーバーに構成するには、プライマリサーバーが接続を受け入れない場合に接続を試行する代替データベースサーバーのリストを指定する必要があります。これを行うには Alternate Servers 接続文字列オプションを使用します。接続の確立に成功するまで、あるいはリストにエントリされるすべての代替データベースへの接続を 1 回ずつ試行（デフォルト）するまで、接続の試行が続けられます。

任意で、以下の接続フェールオーバー機能も指定することができます。

•データプロバイダーが最初に接続を試行した後に、プライマリサーバーおよび代替サーバーへ接続を試行する回数。デフォルトでは、データプロバイダーは接続を再試行しません。この機能を設定するには Connection Retry Count 接続文字列オプションを使用します。

•データプロバイダーがプライマリサーバーおよび代替サーバーへの接続を試行する際、ロードバランスを使用するかどうか。ロードバランスが有効な場合、データプロバイダーは接続の試行順序のパターンをシーケンシャルではなくランダムにします。デフォルトでは、ロードバランスは使用されません。この機能を設定するには Load Balancing 接続文字列オプションを使用します。

接続文字列を使用して、データプロバイダーに対し接続フェールオーバーを使用するよう指示します。接続文字列の使用を参照してください。

次の C# コードには、データプロバイダーで接続フェールオーバー機能と、その接続オプションであるロードバランス、接続の再試行、および接続の再試行の間隔をすべて使用するように設定する接続文字列が含まれています。

具体的に説明すると、この接続文字列の設定は、データプロバイダーで 2 つの代替サーバーを接続フェールオーバーサーバーとして使用すること、最初の接続の試行に失敗した場合はさらに 4 回接続を再試行すること、試行間隔は 5 秒間とし、プライマリサーバーと代替サーバーへの接続の試行順序はランダムとすることを示しています。接続の試行は 1 回当り 60 秒間持続し、試行する順序は最初に行ったランダム順序がそのまま最後まで使用されます。

データプロバイダーは、接続での暗号化されたネットワーク通信（ワイヤ暗号化とも呼ばれます）をサポートします。デフォルトでは、データプロバイダーはサーバーの設定を反映します。暗号化設定の詳細については、表 28 を参照してください。

データプロバイダーで許可される暗号化のレベルは、使用される暗号化モジュールによって異なります。デフォルトの暗号化モジュールでは、データプロバイダーは 40 ビット、56 ビット、および 128 ビット暗号化をサポートしています。

データ暗号化は、データの暗号化と復号で必要となる追加オーバーヘッド（主に CPU 使用）のため、パフォーマンスに悪影響を与えることがあります。

暗号化に加え、Control Centerは .NET Framework で定義されるセキュリティ権限を通してセキュリティを実装します。

データプロバイダーをロードして実行するためには、FullTrust 権限を設定する必要があります。これは、System.Data のクラスが FullTrust 権限を継承しなければならないためです。これらのクラスは、すべての ADO.NET データプロバイダーで DataAdapter を実装するために必要です。

データプロバイダーには AllowPartiallyTrustedCallers 属性がマークされています。

Zen Bulk Load は、すべてのバルクロードの要求に対して 1 か所ですべてを行えるワンストップ手法を提供します。これは、Zen およびこのバルクロード機能をサポートするすべての DataDirect Connect 製品にバルクロード操作を行う上で単純かつ一貫性があります。つまり、標準ベースの API バルクインターフェイスを使用してバルクロードアプリケーションを記述し、それから、その仕事を実行するためにすぐにデータベースのデータプロバイダーまたはドライバーをプラグインすることができます。

データを Zen、Oracle、DB2、および Sybase にロードする必要があるとします。これまでは、バルクロード操作のためにデータベースベンダー製のツールを使用するか、独自のツールを作成する必要がありました。今では、Zen Bulk Load に組み込まれた相互運用性により、作業は非常に簡単になりました。もう 1 つの利点は、Zen Bulk Load は 100% マネージコードを使用するため、ほかのベンダー製の基盤となるユーティリティやライブラリを必要としないことです。

異なるデータストア間でのバルクロード操作は、クエリの結果をカンマ区切り値（CSV）形式ファイルであるバルクロードデータファイルに残すことによって完成されます。このファイルは、Control Center と、バルクロードをサポートする DataDirect Connect for ADO.NET データプロバイダー間で使用できます。さらに、バルクロードデータファイルは、DataDirect Connect 製品やバルクロード機能をサポートするデータプロバイダーで使用できます。たとえば、Zen データプロバイダーで生成された CSV ファイルは、バルクロード対応の DataDirect Connect forODBC ドライバーで使用できます。

Control Centerで Zen Bulk Load を使用する方法は 2 つあります。

この図で、ODBC アプリケーションは CSV ファイルへデータをエクスポートするコードを含み、ADO.NET アプリケーションは CSV ファイルを指定して開くコードを含みます。Control Centerおよび DataDirect ODBC ドライバーは一貫した形式を使用するため、これらの標準インターフェイスを介して相互運用性がサポートされます。

ADO.NET 用の Zen BulkLoad の実装は、事実上の業界標準である Microsoft SqlBulkCopy クラスの定義を使用し、強力な組み込み機能を追加してバルク操作の信頼性をより高めるため、柔軟性に加えて相互運用性も高めます。

データプロバイダーには、Zen Bulk Load をサポートするためのプロバイダー固有のクラスが含まれます。詳細については、データプロバイダー固有のクラスを参照してください。共通プログラミングモデルを使用する場合は、Zen Common Assembly のクラスを使用できます（Zen Common Assembly を参照してください）。

Pervasive.Data.Common アセンブリには、バルクデータ形式間の機能を提供する CsvDataReader および CsvDataWriter などの Zen Bulk Load に対応したクラスが含まれています。

共通アセンブリは、共通プログラミングモデルを使用するバルクロードクラスのサポート機能も拡張します。つまり、SqlBulkCopy パターンが新しい DbBulkCopy 階層で使用できるようになりました。

データプロバイダーの将来のバージョンには、共通プログラミングモデル技術を拡張するほかの機能が含められます。Pervasive.Data.Common アセンブリが対応しているクラスの詳細については、Zen Common Assembly を参照してください。

異なるデータストア間でのクエリの結果は、カンマ区切り値（CSV）形式ファイルであるバルクロードデータファイルに保存されます。BulkFile プロパティで定義されるファイル名は、バルクデータの読み書きに使用されます。ファイル名に拡張子が含まれない場合は、".CSV" と見なされます。

Zen ソーステーブルの GBMAXTABLE には 4 つの列が含まれています。次の C# コード例は、CsvDataWriter によって作成される GBMAXTABLE.csv および GBMAXTABLE.xml への書き出しを行います。この例では、DbDataReader クラスを使用していることに注目してください。

バルクロードデータファイルの GBMAXTABLE.csv には、次のようなクエリの結果が含まれます。

GBMAXTABLE.xml ファイルは、このバルクロードデータファイルの形式を指定するバルクロードの設定ファイルです。これについて次のセクションで説明します。

バルクロード構成ファイルは、CsvDataWriter.WriteToFile メソッドが呼び出されたときに作成されます（詳細については CsvDataWriter を参照してください）。

バルクロード構成ファイルは、バルクロードデータファイル内の列の名前とデータ型を定義します。これらの名前とデータ型は、データのエクスポート元のテーブルや結果セットと同様に定義します。

バルクデータファイルが作成できなかったり XML 構成ファイルに記述されているスキーマに準拠していない場合は、例外がスローされます。XML スキーマ定義の使用法については、バルクデータ構成ファイル用の XML スキーマ定義を参照してください。

構成ファイルを持たないバルクロードデータファイルが読み込まれた場合は、以下のデフォルトが想定されます。

バルクロード設定ファイルは、バルクデータファイルについて記述されており、基となる XML スキーマによってサポートされます。XML スキーマについては次で定義されています。

http://www.datadirect.com/ns/bulk/BulkData.xsd

前のセクションで示したバルクロードデータファイルは、バルクロード構成ファイルの GBMAXTABLE.xml で定義されています。このファイルには、テーブル内の 4 つの列のそれぞれについてデータ型とその他の情報が記述されています。

バルク操作は、専用のバルクプロトコルを使用して実行できます。つまり、データプロバイダーは基となるデータベースのプロトコルを使用します。場合によっては、専用のバルクプロトコルが使用できない場合があります。たとえば、ロードしようとするデータが、専用のバルクプロトコルが対応していないデータ型の場合です。その場合、データプロバイダーは配列バインドなどの非バルク手法を自動的に使用してバルク操作を実行し、最適なアプリケーション稼働時間を継続します。

時には、異なる文字セットを使用するデータベース間でデータをバルクロードする必要があります。

Control Center では、デフォルトのソース文字データ、つまり CsvDataReader からの出力および CsvDataWriter への入力は Unicode（UTF-16）形式です。ソース文字データは、常に CSV ファイルのコードページに変換されます。しきい値を超えてデータが外部のオーバーフローファイルに書き出された場合、ソース文字データはバルク構成 XML スキーマで定義されている externalfilecodepage 属性で指定されたコードページに変換されます（バルクデータ構成ファイル用の XML スキーマ定義を参照してください）。構成ファイルで externalfilecodepage の値が定義されていない場合は CSV ファイルのコードページが使用されます。

不要な変換処理を行わないためには、CSV および外部ファイルの文字データを Unicode（UTF-16）にするのが最良の方法です。以下のいずれかの状況では、アプリケーションにデータを別のコードページで保存させたい場合があります。

•データが ADO.NET で書き出され ODBC で読み取られる。この場合、読み取り（および関連する文字変換）は ODBC によって行われます。文字データが既に正しいコードページである場合、文字変換は不要です。

•空白が考慮の対象となる。文字データがよりコンパクトに表されるかどうかは、コードページによって異なります。たとえば、ASCII データは 1 文字が 1 バイトで、UTF-16 は 1 文字が 2 バイトです。

構成ファイルでは、任意で文字型の列ごとに 2 番目のコードページを定義することができます。文字データが CharacterThreshold プロパティで定義した値を超え、別個のファイルに格納される場合（外部オーバーフローファイルを参照してください）、この値はそのファイルのコードページを定義します。

この値を省略したりソース列で定義されたコードページが不明の場合は、CSV ファイルに定義されたコードページが使用されます。

CsvDataWriter オブジェクトの BinaryThreshold または CharacterThreshold プロパティの値がしきい値を超えた場合、別のファイルが生成されてバイナリまたは文字データを格納します。これらのオーバーフローファイルは、バルクデータファイルと同じディレクトリにあります。

オーバーフローファイルに文字データが含まれる場合、ファイルの文字セットは CSV バルク構成ファイルで指定された文字セットが決定します。

ファイル名には CSV ファイル名と拡張子 ".lob" が含まれます（たとえば、CSV_filename_nnnnnn.lob）。これらのファイルは CSV ファイルと同じ場所に存在します。_000001.lob から開始して 1 ずつ大きくなります。

デフォルトで、バルクコピー操作はトランザクションの一部ではなく分離した操作として実行されます。つまり、エラーが発生しても操作をロールバックするチャンスはないということです。

Zen では、既存のトランザクション内でバルクコピー操作を行うことができます。複数の手順で存在するトランザクションの一部としてバルクコピー操作を定義することができます。この手法を使うと、複数のバルクコピー操作を同じトランザクション内で実行し、トランザクション全体をコミットまたはロールバックすることができます。

エラー発生時にバルクコピー操作のすべてまたは一部をロールバックする方法については、Microsoft のオンラインヘルプで "トランザクションとバルクコピー操作（ADO.NET）" を参照してください。

.NET Framework では、プログラムを再コンパイルすることなくエンドユーザーが問題を特定するのに役立つ Trace クラスを提供します。

Control Centerはさらに以下の診断機能を実現します。

トレース機能は、環境変数または PsqlTrace クラスを使って有効にできます。データプロバイダーは、パブリックメソッドの全呼び出しの入力引数と、そのメソッドの出力および戻り値（ユーザーが呼び出したものすべて）をトレースします。各呼び出しには、メソッドの開始（ENTER）と終了（EXIT）のエントリがあります。

デバッグ中、機密事項のデータがプライベート変数または内部変数として格納され、アクセスが同じアセンブリに制限されたとしても、そのデータを読み取ることができます。セキュリティを維持するために、トレースログはパスワードを 5 つのアスタリスク（*****）で示します。

環境変数を使用してトレースを有効にするということは、アプリケーションを変更しなくてもよいということです。ただし、環境変数の値を変更したら、その新しい値を有効にするにはアプリケーションの再起動が必要になります。

表 3 では、トレースを有効にしたり制御したりするための環境変数について説明します。

表 3 環境変数
環境変数	説明
PVSW_NET_Enable_Trace	1 以上に設定すると、トレースが有効になります。0（デフォルト）に設定すると、トレースは無効になります。
PVSW_NET_Recreate_Trace	1 に設定すると、アプリケーションを開始するたびにトレースファイルが再作成されます。0（デフォルト値）に設定すると、トレースファイルに追加されます。
PVSW_NET_Trace_File	トレースファイルのパスと名前を指定します。

•PVSW_NET_Enable_Trace = 1 に設定すると、トレース処理が開始されます。そのため、トレースを有効にする前に、トレースファイルのプロパティ値を定義しておく必要があります。いったんトレース処理が開始されたら、ほかの環境変数の値を変更することはできません。

•接続文字列オプションでも環境変数でもトレースファイルが指定されていないのにトレースを有効にすると、データプロバイダーは PVSW_NETTrace.txt という名前のファイルに結果を保存します。

ユーザーによっては、トレースを有効にするのに、データプロバイダーの Trace クラスの静的メソッドを使用する方が便利だと思われるかもしれません。以下の C# コードでは、.NET Trace オブジェクトの静的メソッドを使用して、トレースファイルの名前を MyTrace.txt とする PsqlTrace クラスを作成します。この値は環境変数で設定した値よりも優先されます。これ以降、データプロバイダーへの呼び出しはすべて MyTrace.txt へトレースされます。

トレースは次のような形式で出力されます。

各項目の説明は次のとおりです。

Correlation# は重複のない番号で、これによって、アプリケーション内の同じメソッド呼び出しの ENTER エントリと EXIT エントリを符合させます。

Value は、個々の関数呼び出しに固有のオブジェクトのハッシュコードです。

パフォーマンスモニター（PerfMon）や VS パフォーマンスモニター（VSPerfMon）ユーティリティを使用すると、アプリケーションのパラメーターを記録し、その結果をレポートやグラフにして見ることができます。また、パフォーマンスモニターではアプリケーションの CLR（共通言語ランタイム）例外の回数や頻度を確認することもできます。加えて、使用中の接続数や接続プール数を分析して、ネットワークの負荷を調整することができます。

データプロバイダーは、このデータプロバイダーを使用するアプリケーションの調整およびデバッグが行える PerfMon カウンターのセットをインストールします。カウンターは、パフォーマンスモニターの［Zen ADO.NET Data Provider］というカテゴリ名の下に置かれます。

表 4 では、アプリケーションの接続を調整するために使用できる各種 PerfMon カウンターについて説明します。

表 4 PerfMon カウンター
カウンター	説明
Current # of Connection Pools	プロセスに関連付けられている現在のプール数。
Current # of Pooled and Non-Pooled Connections	プールされている接続とプールされていない接続の現在の数。
Current # of Pooled Connections	プロセスに関連付けられているすべてのプールにある現在の接続数。
Peak # of Pooled Connections	プロセスの開始後、すべての接続プールにおいてカウントされた最大の接続数。
Total # of Failed Commands	プロセスの開始後、何らかの理由でエラーになったコマンドの実行総数。
Total # of Failed Connects	プロセスの開始後、何らかの理由でエラーになった接続を開くために試行した合計回数。

PerfMon とパフォーマンスカウンターの使用法の詳細については、Microsoft ドキュメントライブラリを参照してください。

.NET Framework 2.0 以上では実行時の統計をサポートしており、統計情報は接続単位で収集されます。Control Centerは、幅広い種類の実行時の統計情報項目をサポートしています。これらの統計情報項目が提供する情報は、以下に役立ちます。

統計情報項目の計測がパフォーマンスに与える影響はわずかです。最良の結果を得るためには、ネットワーク分析またはアプリケーションのパフォーマンス作用分析時にのみ統計情報の収集を有効にすることを考慮してください。

統計情報収集は、すべての Connection オブジェクトで、それらが使用可能である限り有効にできます。たとえば、アプリケーションで、ビジネス分析の実行に関連する複雑なトランザクションのセットを開始する前に統計情報を有効にし、タスクの完了時に統計情報を無効にするように定義できます。データプロバイダーがサーバーに対して待機させられた時間および返された行数をタスクの完了直後に取得できますし、後から取得することもできます。アプリケーションはタスクの最後で統計情報を無効にするため、統計情報項目は関心のある期間だけ計測されます。

統計情報項目は、機能上 4 つのカテゴリに分類されます。

•ステートメントキャッシュの統計情報項目は、ステートメントキャッシュ内でのステートメントの動作を説明する値を返します（ステートメントキャッシュの使用法については、ステートメントキャッシングの使用を参照してください）。

Connection オブジェクトを作成すると、StatisticsEnabled プロパティを使用して統計情報の収集を有効にすることができます。データプロバイダーは、接続が開かれると統計情報項目のカウントを開始し、ResetStatistics が呼び出されるまで継続します。接続を閉じた後 ResetStatistics を呼び出さずに再度開くと、統計情報項目のカウントは接続が閉じられた時点から継続されます。

RetrieveStatistics メソッドを呼び出すと、1 つまたは複数の統計情報項目のカウントを取得します。返される値は、RetrieveStatistics メソッドが呼び出された時点での "適切な時期のスナップショット" となります。

統計情報収集および取得の範囲を定義できます。次の C# コード例では、統計情報項目はタスク A 作業のみを測定し、タスク B 作業の処理後に回収されます。

すべての統計情報項目を表示するには、次の C# コード例のようなコードを使用することができます。

SocketReads および SocketWrites 統計情報項目のみを表示するには、次の C# コード例のようなコードを使用できます。

ADO.NET Entity Framework ユーザーへの注記：PsqlConnection の統計情報用のメソッドおよびプロパティは、ADO.NET Entity Framework レイヤーでは利用できません。代わりに、データプロバイダーは「擬似」ストアドプロシージャを介して同様の機能を公開します。詳細については、ADO.NET Entity Framework でのストアドプロシージャの使用を参照してください。