SQL Serverメンテナンスプラン-タスクとスケジューリングのベストプラクティス

私は、SQL Server 2005データベースのメンテナンスプランを考案する必要があります。バックアップについては、毎日15分ごとにデータベースの完全バックアップとトランザクションログバックアップを行いたいと考えています。私が抱えている問題は、他にどのようなタスクをやりたいのか、どのくらいの頻度でそれらを行うべきなのかを把握することです。

それで、これまでのところ私はこれを念頭に置いています。私の考えに欠陥がある場合、またはこれを行うためのより良い方法がある場合は、私を修正してください。

1. バックアップ-すべてのテーブル、フルバックアップ（毎日）
2. バックアップ-選択したテーブル、フルバックアップ（1時間ごと）
3. バックアップ-トランザクションログ（15分ごと）
4. データベースの整合性を確認する（毎日）
5. インデックスの再編成（毎日）
6. 統計の更新（毎日）
7. データベースの縮小（毎週）
8. インデックスの再構築（毎週）
9. メンテナンスクリーンアップ（毎日）

これらのタスクの一部は毎日実行する必要がないか、毎日実行するべきではないことを少し前に（別のジョブで同様の計画を設定したとき）読んだことを思い出しました。どのものに関しては、それは私を免れます。災害時のデータ損失を削減するより良いメンテナンスプランを作成するための少しのガイダンスを使用できますが、ピーク時の実行時にシステムに負担をかけません（そしてパフォーマンスも向上します）。

ジョシュ、

これはすべてのDBAにとって非常に一般的なタスクであり、すべてのサーバーと各サーバーで正しい答えが同じではありません。他の多くのことと同様に、必要なものに依存します。

間違いなく、既に提案されている「データベースの縮小」を実行したくないでしょう。そのパフォーマンスに対するEVILおよび以下の参照で、その理由を説明します。ディスクやインデックスの断片化を引き起こし、パフォーマンスの問題につながる可能性があります。自動成長が開始されないように、データファイルとログファイルのサイズを事前に割り当てることをお勧めします。

あなたの＃2を理解できませんでした。選択したテーブルの完全バックアップ。これについて詳しく説明していただけますか？

インデックスの再編成、統計の更新、インデックスの再構築については、これを行う方法に注意する必要があります。そうしないと、より多くのリソースを使用し、パフォーマンスの問題が発生します。

インデックスを再構築すると、インデックスの統計はフルスキャンで更新されますが、その後統計を更新すると、デフォルトのサンプル（テーブルサイズ> 8の場合は通常5％のテーブルに依存します）で更新されますMB）パフォーマンスの問題につながる可能性があります。使用しているエディションによっては、オンラインでインデックスを再構築できる場合があります。このアクティビティを実行する正しい方法は、断片化の量を確認し、それに応じてインデックスの再構築またはインデックスの再編成と統計の更新を行うことです。また、統計をより頻繁に更新する必要があるテーブルを特定し、統計をより頻繁に更新することもできます。

メンテナンスプランは問題ありませんが、SSISにログインしてMPを微調整できる場合を除き、これらのカスタマイズを行うことでそれらを最大限に活用することは困難です。そのため、私はそれらを使用せず、MPよりも堅牢なOla Hallengrenの無料スクリプトを使用することを好みます。また、このトピックに関するPaul Randalの参照記事を確認することをお勧めします。

参照：http : //technet.microsoft.com/en-us/magazine/2008.08.database.aspx

これはあなたの質問に対する包括的な答えではありませんが、良い出発点です。HTHおよび追加の質問/コメントがある場合はお知らせください。

回答を既に受け入れた場合でも、私の経験を共有します。たぶん役立つでしょう:-)。

1. 完全な毎日のバックアップ（毎日）-すばらしいですが、事前に定義された時間の後にスペースを確認して古いファイルを削除することを忘れないでください。
2. 選択したテーブルのバックアップ（1時間ごと）-なぜこれが必要なのか理解できないため、差分バックアップを使用することをお勧めします。特定のテーブル（SSIS、スクリプト、bcp）のみをバックアップするにはどうすればよいですか？差分バックアップに関しては、ログバックアップの役割を盗むため、あまり頻繁にスケジュールしないでください。
3. トランザクションログのバックアップ（15分ごと）-すばらしい。すべてのデータベースに必要ですか？すべてのデータベースが完全復旧モデルを使用していますか？
4. データベースの整合性を確認します-はい。ただし、環境を強制終了しないようにする必要があります。DBCCチェックステートメントはリソースに対してかなり利己的であり、完全なデータベースをスキャンするため、営業時間外にスケジュールする必要があります。
5. インデックスの再編成（毎日）-強制しないでください。必要な場合にのみ行ってください。フラグメンテーションに関するインデックスDMVを確認し、必要に応じてのみ再編成します。私はすべてのインデックスおよび統計操作を単一の週次タスクで移動します。
6. 統計の更新（毎日）- 前の質問に対する私の答えをご覧ください。毎日すべての統計を強制的に更新するのではなく、統計が最後に更新された時期を確認し、場合によっては更新することをお勧めします。
7. データベースの縮小（毎週）-ああ、いいえ。ファイルの縮小に関する Paul Randalの記事をご覧ください。
8. インデックスの再構築（毎週）-5。

9. メンテナンスクリーンアップ（毎日）-OK

10. また、バックアップを確認するタスクを追加することをお勧めします-RESTOREコマンドのバージョンがあります（verifyOnly ..正確に思い出す場合）-毎週としましょう。

あなたは、データ損失の場合にシールドされたいと言っているので、このメンテナンス手順でシステムデータベースを追加する必要があると思います。また、サーバー自体とは異なるマシンにファイルをバックアップするよう注意してください。マスターデータベースmsdb..etcを再構築する必要がある場合に実行するファイルをどこかに保管してください。あなたの仕事で頑張ってください！

遅い答えですが、他の読者にとって役に立つかもしれません。

目に見えないリスクを伴うメンテナンスやレポート作成タスクがたくさんあることを覚えておいてください。

毎日実行される差分バックアップ中にドライブがいっぱいになるとどうなりますか？また、インデックス再構築ジョブが異常に長く実行された場合はどうなりますか？データの読み込みプロセスが広範囲にわたるリソースの競合を引き起こし、通常の操作に支障をきたす場合はどうですか これらはすべて計画的なイベントですが、保護しようとしているプロセスそのものに大きな混乱を引き起こす可能性があります。

さまざまなジョブがどのように相互作用するかを常に考慮し、機密性の高いタスクやリソースを集中的に使用するタスクに重複がないように時間を調整します。

最初にこの記事を読むことをお勧めします：http : //www.sqlshack.com/removing-the-risk-from-important-maintenance-tasks-in-sql-server/

SQL Serverで重要なメンテナンスタスクを実行する方法について説明します（リスクなし）。たとえば、メンテナンスジョブに簡単なチェックを組み込み、利用可能なリソースと、実行前に操作に必要なものを確認できます。これにより、あなたの環境があなたがやろうとしていることを処理できることを保証し、リソースが不十分な場合に意味のあるエラーで中止することができます。

1. 元気そう

2. ここで差分バックアップを行うとメリットが得られる場合があります。必ず調べてください

3. 元気そう

4. 元気そう

5. 前述のように、データベースの縮小は、データとログファイルの物理的な断片化を引き起こし、よりランダムなIO読み取りを引き起こすため、悪いです。

5、6、および8：以下を参照してください。

インデックスは最新の統計情報に依存しているため、これらは本当に密接に関係しています。これらの操作の順序は非常に重要です。私が採用しているベースラインの方法は、確かにすべての人に有効ではないかもしれませんが、2ラウンドのインデックスメンテナンスを実行することです。まず、クラスター化インデックスを実行し、次に非クラスター化インデックスを実行します。私が両方に使用する方法は次のとおりです。インデックスが十分に大きく、十分に断片化されている場合（sys.dm_db_index_physical_stats）、インデックスを再構築します（これには、フルスキャンによる統計の更新が含まれます）。インデックスが再構築するには小さすぎるか、再構築に十分断片化されていない（100ページ未満で、5％〜15％の断片化）場合は、最初にインデックスの再編成を実行します。次に、フルスキャンで統計の更新を実行します。

現在、これはインデックス統計をカバーしていますが、列統計に対しては何もしません。毎週、列の統計を更新します。

これが何らかの形で役立つことを願っています！

私はあなたの「データの損失はここに法的な影響を与える可能性がある」というコメントに傾いた。

次に、バックアップを処理する（およびフラッシュで壊滅的なイベントから回復し、最小限の混乱を引き起こす）強力なサードパーティツール（DPMなど）を、インターネットから引き出すことができるスクリプトよりもはるかに速く、はるかに優れたものにしたいと考えています。

バックアップを持つことは一つのことです。緊急時にそれらを使用する方法を知ることは別です。

重大な障害が発生した後にバックアップを復元する必要がある場合は、おそらくすでにストレスとプレッシャーにさらされていることを忘れないでください。12のトランザクションログファイルを含むRESTORE DATABASEステートメントを完全に掘り下げて作成するという追加の負担は必要ありません。

職場では、DPMを使用して、先週の5分間に350Gbデータベースを任意のポイントに回復/復元できます。GUIインターフェースを使用。価値がある、私の本で。

残りについては、Ola Hallengrenのインデックススクリプトを確認し、必要に応じてパラメーターを調整してください。個人的には、再スキャンなしで毎晩1時間実行するようにスケジュールされたタスクと結合したため、毎回最悪のインデックスを処理し、土曜日ごと、またはリスト内のすべてのインデックスのときにフラグメンテーションの完全な再スキャンを強制します最適化されました。

最後に、「ファイルを自動的に圧縮しない」グループに自分の声を追加します。File Shrinkは、ログまたはDBファイル（無限ループなど）を過剰に生成する不規則なイベントが発生したときに散発的に使用するツールにすぎません。保守ツールとは想定されていません。ディスクスペースが圧迫されている場合、シュリンクはとにかく避けられないものを遅らせるだけです。