2

バックエンドとして SQL Server 2008 を使用するアプリケーションに取り組んでいます。毎日の終わりに、データベースをバックアップしてラップトップに復元し、自宅で開発を続けることができます。両方のセットアップですべてが正常に機能しますが、ローカル マシンで実行されているクエリは、職場のリモート サーバーにクエリを実行している場合よりも劇的に長くなります (数秒と 1 秒未満)。

サーバーを名前で指定し、「.」を使用します。ローカル インスタンスに接続します。アプリは、統合セキュリティを使用して ADO 経由で接続する Excel VBA です。

職場のサーバーの仕様はわかりませんが、私のラップトップよりも優れていると思うので、おそらく違いの一部を説明しています. ただし、私の開発用ラップトップはまともで (Windows 7、2.4 GHz Core i5、64 ビット、8 GB RAM)、この時点でデータベースは非常に小さいです。

なぜパフォーマンスが劇的に異なるのでしょうか? パフォーマンスを改善するには、ラップトップで何を確認する必要がありますか?

編集:クエリに問題がないことがわかりました。私のラップトップでは、データを取得するためのサーバーへのラウンドトリップにかなりの時間がかかっていました。実際には接続であるのに、クエリであると誤って想定していました。SSMS を介してデータベース エンジンに接続すると、どちらの環境でもほぼ同じ時間がかかりますが、ADO を使用して接続すると、ローカルで接続に時間がかかります。この遅延の原因は何ですか？

Mitch の返信を回答としてマークし (クエリ時間と環境の差異のトラブルシューティングに役立ちます)、接続遅延に関する新しい質問を作成します。

更新:これは、ローカルホストでの接続の恐ろしいパフォーマンスに関する SE.DBAs に関する私の質問へのリンクです: https://dba.stackexchange.com/q/18231/2848

4

1 に答える 1

7

問題のクエリは、両方の環境で同じクエリ プランを持っていますか?

最初の実行時はローカルで遅く、2 回目の実行では高速ですか? (そうであれば、ページをメモリにロードする物理 I/O 速度の違いである可能性があります)

最初のステップとして、すべてのインデックスを再構築し、両方の環境で列の統計を更新してから、クエリ プランを再比較します。

use myDb
go

exec sp_msforeachtable "dbcc dbreindex('?')" 
go

exec sp_msforeachtable "update statistics ? with fullscan, columns" 
go

本番環境に関する通常の注意事項があります (DB が小さいと述べているため、これらのコマンドの実行に時間がかかることはありません)。

于 2012-05-06T03:41:52.537 に答える