SELECT xyz INTO #Temp from SSMSは、ある環境では別の環境より5倍長くなります
初めて投稿するときは、正しくやっているといいのですが。
私はたくさんのことを学んでいる「偶然のdba」ですが、確かにまだ学ぶことがたくさんあります。これが私のブレインダンプです：
- 製品サーバーには500万行あります。それらの行をテストサーバーにコピーしました。
- SNAPSHOTまたはREADUNCOMMITTEDを使用すると、経過時間が異なりますが、ProdとTestの比率は常に約5：1です（SNAPSHOTでは14分：3分、READ UNCOMMITTEDでは4分：sub-1）。
- STATISTICS IO ONを使用すると、Prodでの読み取りのほとんどが論理的（〜90％）であるのに対し、Testでの読み取りはいずれも論理的ではないことがわかります。I 考える つまり、Prodはどちらかといえば高速になるはずです。
- ほとんどの場合、タイプ「PAGEIOLATCH_SH」の待機が発生するようです。
- 私はしません 考える フィルタリングされていない、結合されていない、ソートされていないクエリではインデックスを使用しないため、さまざまな統計が問題になる可能性があります。
- 両方のサーバーで上位n行を選択すると、非常に線形のスケールが明らかになります...比率は常に約5：1です。
- 比較はアップルトゥアップルではありませんが、関連する違いはアクティビティとストレージだけだと思います。
- アクティビティがほとんどないときに比較を実行しましたが、同じ結果が得られました。
- 自動拡張が1MB（ugh）に設定されていることを発見しました。これを変更したのですが、これがファイルシステムレベルでのストレージの断片化につながったのではないかと思います。
- データベースはWindowsインストールとは別のボリュームにありますが、tempdbおよびFILESTREAMストアとボリュームを共有しています。 仮定する また、ストレージの断片化につながる可能性があります。
- 「ドライブの最適化」ウィンドウユーティリティは、ボリュームが「OK（98％のスペース効率）」であることを示しています。これは、ファイルシステムの断片化が問題ではないことを示唆しているようです。
質問：
ご清聴ありがとうございました！
編集：2番目のステートメントに残りの時間情報を追加しました。
私にとっては、tempdbの問題のように聞こえます。何ができるか-各サーバーにあるファイルの数を確認してください-推奨事項を確認できます ここ 。
それらは十分に大きく、挿入を行うときに成長していませんか？ tempdbのログファイルはどうですか？それらが成長している場合-最善は前にそれらを拡張することです（そしてそのように維持します）。
あなたがチェックできるもう一つのこと-それらが成長しているかどうか、あなたはおそらく インスタントファイル初期化 を使用することによってそれをより速くすることができます。