SQL Serverバックアップ-いくつかの質問

金曜日の午後9時に毎週のバックアップジョブを実行しますが、ディスクスペース（時々非常に低くなります）とパフォーマンスに関するいくつかの問題が発生しています。何が起こるかを合理化/最適化することを検討しており、コメントをお待ちしています。

具体的には：

1. バックアッププロセスは、バックアップ中に統計を更新するのに約4時間かかります。このプロセスを安全に無効にして時間を節約できますか？

2. ディスクスペースが非常に頻繁に不足しているため、プロセスを再調整する必要があるかと考えています。現在、バックアップを作成してから以前のバックアップを削除しますが、これがディスク容量を圧迫しています。最初に以前のものを安全に削除してからバックアップを実行できますか？

その他のコメントや意見は大歓迎です編集：サーバー上のSQLファイルの合計サイズは約35GBです。1つのデータベースのサイズは約25GBで、他の6つの共有は他の10GB程度を占めています。

（1）はい、通常、バックアッププロセスは自分で行います。可能な場合、バックアップ時に何もしません。バックアップを取得してから、統計の更新を行うことができます。どうやら、同時に2つのジョブ（バックアップ用に1つ、統計の更新用に1つ）を実行しているようです。

（2）バックアップをテープまたは他のディスクストレージにコピーしますか？その場合、通常、新しいバックアップをローカルで作成する前にファイルをクリーンアップします。そうでない場合、ストレージスペースをスクレイピングする場合、新しいファイルを作成する前にバックアップファイルを圧縮することを検討します。（つまり、@ Simonが示唆したように、バックアップで圧縮を有効にできない場合、これはいくつかのスペースも節約します。）

ここでは質問2にしか答えられません。圧縮されたバックアップを確認することをお勧めします。

• 2008エンタープライズエディションを使用している場合、SQL Serverはこれを実行できます。以下の2つを見ていない場合。
• クエストライトスピード
• RedGate SQLバックアップ

1）バックアップを作成するタスクと統計を更新するタスクの間に直接的な関係はありません。したがって、問題なくそれらを分割できます。統計を更新する部分は、インデックスを最適化/再構築するジョブに関連していると思います。

2）たとえそれが短時間であっても、バックアップなしでいたくはありません。したがって、別の場所に既に保存されている場合にのみ、最後のバックアップを削除する必要があります。

ここでの補足事項：データベースがある同じストレージボックスでバックアップを行っている場合、ストレージボックスにハードウェアの問題がある場合、バックアップは安全ではありません。したがって、同じマシン上ではなく、別の場所にバックアップ用の十分なスペースがあることを確認する必要があります。

サイドノート2：サイモンによって既に指定されているように、スペースの問題がある場合は、圧縮されたバックアップに時間/お金を投資してください。この質問には多くのアイデアがあります。可能な限り最小のバックアップ…SQL Serverで。

3〜4 GBのデータベースでは、統計の更新タスクに4時間かかることはありません。おそらく、I / Oの問題があるか、I / Oの問題を引き起こしている非常に断片化されたデータベースがあります。データベースでデフラグまたはインデックスの再構築を実行し、パフォーマンスが向上するかどうかを確認します。そうでない場合は、perfmonを起動して、パフォーマンスのボトルネックがどこにあるかを確認します。

新しいバックアップを作成する前に、唯一のバックアップを削除することはお勧めしません。バックアップが失敗したり、インスタンスがダウンしたのは初めてではないため、リカバリの機会がない時間のギャップがあることはお勧めできません。

それはあなたの問題の解決策ではありません。両方を収容するスペースを増やす方法を考え出すことは、そのための正しい方法です。