2

サイズが非常に速く成長しているデータベースが1つあります。現在、そのサイズは約60GBですが、db_spaceusedストアドプロシージャを実行した後、40 GB以上が未使用であることを確認できました（未使用のスペースは異なり、テーブルの拡張用であると理解している予約済みのスペースではありません）。また、実際のデータサイズは約10〜12 GBで、予約済みスペースには数GBあります。

その未使用のスペースを収集するために、縮小操作を使用しようとしましたが、役に立たなかったことがわかりました。さらに検索した後、データフラグメントが生成され、ディスク操作中に取引が発生するため、シュリンクDBを使用しないこともわかりました。今、私はスペースを再収集してDBを再収集するために他にどのような操作を試みる必要があるのか​​本当にわかりません。サイズが原因でクエリに予想よりも時間がかかる可能性があり、このスペースを再利用するとパフォーマンスが向上する可能性があることを確認します（不明）。

調査中に、GererateScripts機能にも出くわしました。データやスキーマのエクスポートにも役立ちますが、スクリプト（ユーザー、権限などすべて）の作成にも役立つかどうかはわかりません。そのため、スクリプトは、作成スキーマを使用してDBのレプリカ（ディープコピー/クローン）をそのまま作成するのに役立ちます。他のdb/serverへのデータを入力しますか？

任意のポインタが役立ちます。

4

1 に答える 1

3

データベースが60Gbの場合、それは60Gbに成長したことを意味します。データがわずか20Gbであっても、データを時々増大させる操作がある可能性があります（たとえば、夜間のインデックス保守ジョブ）。データベースを60Gbのままにしておくことをお勧めします。スペースを再利用しようとしないでください。害を及ぼすだけであり、データベースが最初に60Gbに成長した原因はすべて、再び発生してデータベースの成長を引き起こす可能性があります。

実際には、反対にすべきです。60Gbに成長した理由を特定し、データが30Gbに達したときに何が起こるかを推定してみてください。データベースは90Gbに拡張されますか？はいの場合は、今すぐ90Gbに拡張する必要があります。最後に必要なのは、成長がランダムに発生し、重要な瞬間にディスク領域が不足する可能性があることです。実際、サーバーでインスタントファイルの初期化が有効になっているかどうかを今すぐ確認する必要があります。

もちろん、問題は、データサイズが3倍になる原因と、それを特定する方法です。簡単な方法はわかりません。まず、SQLエージェントのジョブを確認することをお勧めします。メンテナンススクリプトを確認してください。アプリケーション自体を調べてください。データの増加と削除のパターンがありますか？過去のバックアップを見て（持っていますよね？）、比較してください。

ところで、私はデューデリジェンスを想定しており、データファイルが60Gbに成長していることを確認しました。大きくなったログファイルが簡単な場合は、完全復旧モデルを有効にして、ログのバックアップを忘れたことを意味します。

于 2012-06-08T08:49:59.680 に答える