3

この問題には SQL Server 2008 R2 を使用しています。

私のアプリの 1 つで、別のデータベースのテーブルを参照する必要があります。だから私はクエリを行います:

USE Db1
SELECT * FROM Db2.dbo.Table1

わずか 300 レコードのテーブルでも、クエリが完了するまでに最大 2 秒かかります。遅延は一貫しており、Management Studio で実行して [実行] をクリックすると、結果は同じです。これを約 10 回実行し、一貫した結果が得られました。

今度はクエリを実行しますが、今回は実際のデータベースのコンテキストで実行します。

USE Db2
SELECT * FROM Table1

同じ結果が返されるまでの待ち時間はほとんどありません。

奇妙なことに、最初のクエリに戻ると、遅延が発生しなくなりました。この動作は、SQL Server を再起動するたびに再現されます。

以前にこの動作に遭遇した人はいますか? 私が間違っている可能性があることについて何か考えはありますか?

4

2 に答える 2

3

最後にこれを理解しました。SELECT で参照されているデータベースの Auto Close プロパティが True に設定されていました。これを False に設定すると、SELECT 呼び出し中の遅延がなくなりました。

つまり、すべての SELECT ステートメントに対して常にデータベースを起動していたのです。イベント ビューアを確認したところ、呼び出しごとにデータベースの起動ログが表示されます。

これを false に設定するには、Management Studio を使用し、データベースを右クリックして [プロパティ] に移動します。[プロパティ] ウィンドウで [オプション] を選択し、[自動] グループの下の最初の項目は [自動終了] です。これを False に設定します。

Auto Close プロパティの詳細については、以下のリンクを参照してください。デフォルトではTrueに設定されています。これを False に設定すると、この問題は発生しません。

Auto_Close

于 2013-08-03T13:21:43.080 に答える
0

ここに謎はなく、完全修飾名はまったく役割を果たしません。

テーブル データは、最初に要求したときにメモリにキャッシュされます。以降の呼び出しでは、ディスクからデータを読み取るのではなく、メモリからデータを読み取ります。さらに、SQL Server はコンパイルされた実行プランをキャッシュし、それらを新しいクエリに再利用します。

SQL Server を再起動するたびに、メモリ バッファーと実行プラン キャッシュを空にして開始するため、実行する最初のクエリは大幅に遅くなります。

意味のある結果を得るには、次のコマンドを使用してバッファと実行計画のキャッシュをクリアする必要があります。

  • DBCC FREEPROCCACHEは実行プラン キャッシュを消去し、新しいクエリを強制的に再コンパイルします。
  • DBCC DROPCLEANBUFFERSはメモリ バッファーを消去し、SQL Server にディスクからデータを再読み込みさせます。
于 2013-07-09T13:49:55.003 に答える