私の会社では、最大10 GBのデータベースをサポートするSQL Express 2008 R2を使用しています。
すべてのテーブルの行数がほぼ同じ2つのデータベースがあります。ただし、そのうちの1つは(開発部門にある)サイズが4.5 GBで、もう1つ(本番環境のもの)は9.87GBです。
開発中のデータベースは、テスト目的で行を一括で挿入することで自動生成されました。データベースが稼働している間は、その量のデータを生成するためにほぼ1年遅くなります。
特に1つのテーブルには4,700,000行あり、次のクエリを実行します。
SELECT colum1,column2 FROM table WHERE column1 = 2
本番データベースでの応答には約2分、開発データベースでは20秒かかります。
本番データベースを縮小したところ、完了するまでに約20分かかりましたが、その後、データベースのサイズが7 GBに減少しました。右クリックでインデックスを再構築しようとしましたが、タイムアウトが発生し、再構築を完了できません。
私の質問は、同じレコード数の2つのデータベースのサイズが大きく異なるのはなぜですか。また、本番データベースのパフォーマンスを向上させるにはどうすればよいですか。
ありがとう。
断片化がさらに増えるため、データベースを縮小しないでください。そして、はい、断片化のためにサイズが異なるように見えるので、何も格納しない(半分塗りつぶされたページ)スペースがたくさんあります。これはおそらく、スキーマの設計が正しくなく、クラスター化インデックスが誤って選択されているためです。しかし、断片化は本番システムで発生するため、それを確認し、定期的にインデックスを再構築することをお勧めします。
あなたが得るエラーはあなたがSORT_IN_TEMPDB = ON
オプション。また、オンラインのREORGANIZE
オプションを検討してください。失敗した場合でも、失敗する前に行われたすべての作業が保存されます。ただし、REORGANIZE
オプションは、ツリー全体ではなく、インデックスのリーフレベルを最適化するだけです。
それでも問題が解決しない場合は、スクリプトを使用してデータベースを再作成し、本番データを入力する方法しかありませんが、必要ないことを願っています。
SSMSの右クリックを使用している場合、タイムアウトになるだけだと思います。
TSQLステートメントとして再構築を実行する必要があります。
SSMSを右クリックして、インデックスの削除と再構築の構文を取得できます。
サイズに関しては、断片化されたインデックスはより多くのスペースを必要とします。
インデックスの再構築がタイムアウトし、クエリ時間が大幅に異なる場合、インデックスが著しく断片化している可能性が高くなります。
開発データベースも最適化する必要があります。
私の会社でも、開発時のクエリに4〜5秒かかり、本番環境では30秒かかっていた同様の状況に直面しました。
この問題は次のように解決されました。
MDF
ファイルをさらに3つ追加しました。現在、合計はtempDBの4 MDF
です。