web-dev-qa-db-ja.com

SSDTがローカルで遅い

SSDTを使用してローカルDBを更新すると、3分かかります。その間、Visual StudioがCPUをスラッシュします。コンピューターからそれを使用して同一のリモートDBを更新すると、わずか30分で、Visual StudioはCPUを使用しません。私のローカルコンピューターは、リモートコンピューターよりも強力ではありません。確かに、私のローカルSQL Server（2016 Developer）のワークロードははるかに低くなっています。

私はSQL Serverプロファイラーを実行しましたが、実行時間の長いクエリはありません-結局のところ、SQL ServerではなくVisual Studioがスラッシングしています。

ローカルDBを更新するとき、リモートDBを更新するときよりも、Visual Studioの同じインスタンスの速度が非常に遅くなる原因は何ですか？または、どうすればこれをデバッグできますか？

sql-serverssdt
3
wezten

デプロイのタイミングに違いがある場合は、いくつかの注意点があります。

  1. 接続は同じように行われていますか（プロトコルなど）？両方のインスタンスで次のクエリを実行して確認できます。

    SELECT *
FROM sys.dm_exec_connections conn
INNER JOIN sys.dm_exec_sessions sess
        ON sess.[session_id] = conn.[session_id]
WHERE [nt_user_name] <> N'SQLSERVERAGENT';

  2. 使用されているリンクサーバーはありますか？もしそうなら、それは2つのインスタンス間のセキュリティ設定の違いは可能です。

  3. インスタンスレベルの既定の照合順序は、両方のSQLサーバーで同じですか？データベースレベルのデフォルトの照合順序は、「データベースプロパティの配置」を使用している場合は特に、「通常」同期しています。インスタンスレベルの照合順序は主に変数名とカーソル名に影響するため、ここでの考えは、増分更新を把握するためにSSDTがスキーマを比較する可能性があるということです。

  4. 同じSSDTプロファイルとオプションを使用して展開していますか？設定が異なると、ロールアウトのタイミングも異なります。

  5. 2つのインスタンス間に他の違いはありますか？

この特定のケースでは、2つのインスタンス間に違いがありました。リモートインスタンスは実際には2016ではなくSQL Server 2008 R2です。また、インスタンスレベルのデフォルトの照合順序は2つのインスタンス間で異なりました。

その情報を参考にして、いくつか試してみることをお勧めします。

  1. DBプロジェクトのプロパティで、「ターゲットプラットフォーム」が2008 R2に設定されている場合は、それを2016に変更してローカルにデプロイし、違いがあるかどうかを確認してください。

  2. そうでない場合は、デフォルトの照合順序をテストするために、2008 R2インスタンスと同じデフォルトの照合順序でローカルに新しいインスタンスを作成します。

  3. 2008 R2 Expressをローカルにインストールして（リモートインスタンスと同じデフォルトの照合順序を使用）、それに発行してみてください。

この特定のケースでは、「ターゲットプラットフォーム」が「2008 R2」に設定され、それを「2016」に変更することで、ローカルでの発行に関する問題が解決されました。もちろん、SQL Server 2016用に生成されたDDLが2008 R2でいくつかのエラーを引き起こす可能性は非常に高いですが、それは「作成」スクリプトのみで発生する可能性があり、増分展開スクリプトの問題ではありません。 「互換性のないプラットフォームを許可する」オプションを有効にする必要がある場合があります。 「2016」が2008 R2インスタンスへの公開の「ターゲットプラットフォーム」であるという問題がある場合は、別のSSDT公開プロファイルが必要になる場合があります。

追伸ただし、理想的には、リモート2008 R2インスタンスが共有のDev/QA/Productionサーバーである場合、ローカルインスタンスも2008 R2である必要があります。これにより、展開先と同じ環境で開発を行うことができます。 ）。

2
Solomon Rutzky