.net - データベース接続を長時間開いたままにしても安全ですか

Question

リモートデータベースに接続されている .net クライアントアプリケーションがあります。クライアントの存続期間 (時間) の間、単一の接続を開いたままにしておくことは安全ですか?

複数 (10 または 100) のクライアントを実行している場合、答えは成り立ちますか?

score 30 · Accepted Answer

これを行うことは絶対に安全です。これが、クライアント/サーバーアプリケーションのしくみです。3 層アプリケーションを使用している場合でも、アプリケーションサーバーは接続のプールを開いたままにします。

スケーラビリティは問題です。少なくとも、マシンのメモリが最新のキットよりも少なかった時代には、スケーラビリティが問題でした。2 層 (クライアント/サーバー) アプリケーションでは、各クライアントが接続を開き、開いたままにしていました。これにはいくつかの効果がありました。

メモリは接続ごとに使用されていたため、(比較的) アイドル状態の接続が多数あると、マシンのメモリが使い果たされていました。ただし、最新の 64 ビットサーバーは数十または数百 GB のメモリを搭載できるため、このような接続を非常に多数サポートできます。
トランザクションがクライアントマシン上でコミットされていない場合、トランザクションが開いている限り、ロックは開いたままになります。これにより、誰かが取引を開始し、昼食に出かけて、何かを開いたままでしたことを忘れる可能性があるという一連の問題が発生しました。これにより、トランザクションによって参照されるすべてのレコードが一度に何時間もロックされます。
ただし、トランザクションはデータベースへの複数のアクセスを簡単にカバーできますが、これは接続プールでは困難です。

3 層アーキテクチャで一般的なプールアーキテクチャでは、アプリケーションサーバーとデータベース間の接続数に制限があります。クエリは次に利用可能な接続を使用するだけで、更新はすぐにコミットされます。これにより、限られた数の接続しか開いていないため、使用するリソースが少なくなり、(楽観的な同時実行戦略と組み合わせて) 潜在的なアプリケーションの同時実行の問題の大部分が排除されます。

長いトランザクション(つまり、データベースへの複数の呼び出しをカバーするトランザクション)を使用するには、トランザクションを接続から分離する必要があります。これは TP モニターの基本アーキテクチャであり、これをサポートするXAやOLE トランザクションなどの標準プロトコルがいくつかあります。このタイプの外部管理トランザクションが利用できない場合、アプリケーションは、アプリケーションのトランザクションによって行われた変更を元に戻す補正トランザクションを作成する必要があります。このタイプのアーキテクチャは、ワークフロー管理システムでよく使用されます。

score 19 · Accepted Answer

ビジネスオペレーションごとに接続を開閉する

クライアント/サーバーアプリケーションについて話している場合は、使用が終了したらすぐに各接続を閉じることをお勧めします。個々のアプリケーションインスタンスは、接続を開くときにパフォーマンスにわずかな影響を与える可能性がありますが、アプリケーション全体はより適切にスケーリングされます。これは、使用しているデータベースサーバーによって多少異なります。SQL Server は、インストールされているハードウェアに基づいて、さまざまな数の同時接続を処理します。クライアント/サーバーアプリを数千のデスクトップにスケールアップする場合、小さな DB サーバーでは、接続が開いているすべてのデスクトップを処理できない可能性がありますが、一部の接続のみが開いている数千のデスクトップをうまく処理できます。

私は数年前にこれを最初に見ました。いくつかの部門に問題なく展開されたアプリケーションは、組織全体に展開されました。アプリケーションはすぐに非常に遅くなりました。組織は、パフォーマンスを向上させるために、DB サーバー用に非常に高価なハードウェアの購入を検討していました。各ビジネス操作の後に、db 接続を開いたり閉じたりすることをお勧めしました。幸いなことに、彼らはアプリケーションを設計していたので、これは難しい変更ではありませんでした。彼らは変更を行い、毎週のネットワーク更新中に展開しました。一晩でアプリケーションのパフォーマンスが大幅に向上しました。彼らは何千ドルも節約しました。

score 10 · Accepted Answer

長期間の接続の難しさは、接続がまだそこにあることを完全に確信できない場合があることです。ネットワーク障害、サーバーの再起動、またはステートフルファイアウォールがその状態の一部を忘れていると、すべて「古い」接続が発生し、開いているように見えますが、使用しようとするとエラーが発生します。

通常、接続プーリングスキームでは、システムにプール内の接続が正常であることを時折チェックさせるか、未使用の接続を破棄するタイムアウトを設定することで、これを解決します。

一般的に言えば、分散システムでは、あらゆる種類の障害に対処するためのコードを作成する必要があります。長時間の接続を開いたままにしておくと、これがより困難になります。

score 4 · Accepted Answer

特定の詳細は一般的に重要ですが、接続を長時間開いたままにしても問題はありません。

アプリケーションが接続プーリングの場合、プール内の接続スロットは通常、必要になるまで接続されたままになります。

現在では非常にまれな接続ベースのライセンスモデル以外では、接続自体を維持するだけでリソースを消費することはほとんどありません。

TCP を介して動作する SQLServer クライアントは、30 秒間隔でキープアライブを送信します。(キープアライブは基本的に 0 len の TCP パケットです)通常、無視できるトラフィックと見なされます。

帯域幅が非常に少ない環境や、信頼性の低い WLAN リンクを使用する環境で運用している場合、TCP キープアライブ間隔を長くすると、長時間の接続がアクティブなままになる可能性が高くなり、ネットワーク上の「アイドルチャット」の量が減少する可能性があります。

接続プールを使用する理由と使用しない理由があります。

プールの使用に対して：

環境汚染の可能性を取り除きます - 他のクエリがクエリの実行を妨げる可能性のある特別な環境オプションを設定する場合 (xact_abort、トランザクション分離レベルなど)

構成済み/ライセンス済みの接続制限が有効な場合、アプリケーションのアイドル接続は、他のアプリケーションで使用できない接続です。

毎回接続することに対して：

接続のセットアップ (特に安全な接続のセットアップ) には、クライアントとサーバー間の追加のラウンドトリップが多数必要です。ラウンドトリップは、WAN アプリケーションのパフォーマンスを低下させる傾向があります。

score 2 · Accepted Answer

実際には、接続を開いているクライアントの数と、何らかの接続プールを使用しているかどうかによって異なります。

3 層システムで、中間層で接続プールが有効になっている場合、クライアント設定は適用されません。中間層を使用していない場合で、サーバーへの接続数が気になる場合は、この中間層を使用すると管理が大幅に改善されるため、検討する時期です。

開いているすべての接続は、サーバー上で一定量のメモリを消費し、少しのオーバーヘッドを追加します。クライアントがサーバーと直接通信する 2 層システムの場合、サーバーの仕様とクライアントの数を調べて、接続を開いたままにする価値があるかどうかを確認する必要があります。2 層システムで数千のアクティブなクライアントがある場合、それらをすべて開いたままにしたくないでしょう... 2 層システムで数十のクライアントしかない場合は、それらを開いたままにしておきます。 .

score 1 · Accepted Answer

一般的に言えば、このように接続を開いたままにしないでください。.NET には ADO.NET 接続プーリングシステムがあり、まさにあなたがしようとしていることを実行し、それをはるかに優れたものにします。;-)

更新: 私は 'tard です。反応的に投稿しました。ここでは当てはまりません。

-オイシン

score 1 · Accepted Answer

もちろん。実際に問題が発生するのは、(特定の分離レベルで) トランザクションを長時間開いたままにしておく場合だけです。

ライセンスされた接続制限があり、接続はサーバーのメモリを消費するため、少ないほど良いですが.

score 1 · Accepted Answer

安全。それはほとんどプーリングが行うことです...プログラムの実行中は接続を開いたままにし、さまざまなクエリに使用します。

ただし、データベース接続のタイムアウトに注意する必要がある場合があります。接続が古くなり、奇妙なエラーが発生し始めます。データベースのタイムアウト値を非常に大きな値に設定するか、時折ダミークエリを使用して接続を維持します。

score 0 · Accepted Answer

データベースとそれで何をしているかによって異なります。ほとんどの場合、接続の開閉には費用がかかります。たとえば、モバイルデバイス (SQL Server Compact Edition) で SQLCE を使用している場合、実際にはデバイスで接続を開いたままにしておくことをお勧めします。

対照的に、マルチユーザーデータベースを使用している場合は、これらの接続をより慎重に管理する必要があります。既に述べたように、ADO.Net 接続プーリングは効率の管理に非常に役立ちます。

.net - データベース接続を長時間開いたままにしても安全ですか

9 に答える 9

Related

Reference