SQL Serverメンテナンスプラン-タスクとスケジュールのベストプラクティス
Sql Server 2005データベースの保守計画を考案する必要があります。バックアップについては、毎日のフルデータベースバックアップとトランザクションログのバックアップを15分ごとに実行したいと思っています。私の問題は、他にどのようなタスクを実行したいか、どれくらいの頻度で実行すべきかを理解することです。
だから、今のところ私はこれを念頭に置いています。私の考えに欠陥がある場合、またはこれを行うためのより良い方法がある場合は、私を修正してください。
- バックアップ-すべてのテーブル、フルバックアップ（毎日）
- バックアップ-選択したテーブル、完全バックアップ（時間単位）
- バックアップ-トランザクションログ（15分ごと）
- データベースの整合性をチェックする（毎日）
- インデックスの再編成（毎日）
- 統計の更新（毎日）
- データベースの縮小（毎週）
- インデックスを再構築（毎週）
- メンテナンスクリーンアップ（毎日）
以前に（別のジョブで同様の計画を立てたとき）読んだことを覚えていましたが、これらのタスクの一部は毎日実行する必要がないか、毎日実行するべきではありません。どれについて、それは私をエスケープします。災害時のデータ損失を減らすより良いメンテナンスプランを作成するための小さなガイダンスを使用できますが、ピーク時に実行しているときにシステムに負担をかけることはありません（パフォーマンスも向上します）。
ジョシュ、
これはすべてのDBAにとって非常に一般的なタスクであり、正しい答えはすべてのDBAと各サーバーで同じではありません。他の多くのことと同様に、それはあなたが必要とするものに依存します。
ほとんどの場合、すでに示唆されているように、 "Shrink Database"を実行したくないでしょう。パフォーマンスに対するそのEVILと以下の参考文献がその理由を示します。ディスクとインデックスの断片化が発生し、パフォーマンスの問題が発生する可能性があります。自動拡張が発生しないように、データファイルとログファイルに大きなサイズを事前に割り当てておいた方がよいでしょう。
あなたの＃2を理解できませんでした。選択したテーブルの完全バックアップ。これについて詳しく説明できますか？
インデックスの再編成、統計の更新、インデックスの再構築を行う場合は、これを行う方法に注意する必要があります。そうしないと、リソースの使用量が増え、パフォーマンスの問題が発生します。
インデックスを再構築すると、インデックスの統計はフルスキャンで更新されますが、その後統計を更新すると、それらはデフォルトのサンプルで再度更新されます（これは、いくつかの要因に依存します（通常、テーブルサイズ> 8の場合、テーブルの5％） MB）パフォーマンスの問題につながる可能性があります。お使いのエディションによっては、オンラインでインデックスを再構築できる場合があります。このアクティビティを行う正しい方法は、断片化の量をチェックし、それに応じて、インデックスの再構築またはインデックスの再編成+統計の更新を行うことです。また、統計をより頻繁に更新する必要があるテーブルを特定し、統計をより頻繁に更新しようとする場合もあります。
メンテナンスプランは問題ありませんが、SSISにログインしてMPを微調整できない限り、これらのカスタマイズを最大限に活用することは困難です。それが私がそれらを使用しないことを好む理由です Ola Hallengrenの無料のスクリプト MPよりも堅牢です。また、このトピックについてPaul Randalが参照した記事に追いつくことをお勧めします。
参照： http://technet.Microsoft.com/en-us/magazine/2008.08.database.aspx
これはあなたの質問に対する包括的な答えではありませんが、良い出発点です。 HTHと追加の質問/コメントがある場合はお知らせください。
あなたがすでに答えを受け入れたとしても、私は私の経験を共有します。多分それは役に立つでしょう:-)。
- 毎日の完全バックアップ（毎日）-すばらしいですが、事前に決められた時間が経過したら、スペースを確認し、古いファイルを削除することを忘れないでください。
- 選択したテーブルをバックアップする（時間単位）-なぜこれが必要になるのか分からないので、差分バックアップを使用することをお勧めします。 SSIS、スクリプト、bcpの特定のテーブルのみをどのようにバックアップしますか？差分バックアップについては、ログバックアップの役割を盗むため、あまり頻繁にスケジュールしないでください。
- トランザクションログのバックアップ（15分ごと）-すごい、すべてのデータベースに本当に必要ですか？すべてのデータベースで完全復旧モデルを使用していますか？
- Dbの整合性を確認します-はい、ただし、環境を破壊しないようにする必要があります。 DBCCチェックステートメントはリソースに対してかなり利己的であり、完全なデータベースをスキャンするため、営業時間外にスケジュールする必要があります。
- インデックスを再編成する（毎日）-強制しないでください。必要な場合にのみ実行してください。断片化に関するインデックスDMVを確認し、必要性のみに基づいて再編成します。私はすべてのインデックスと統計操作を毎週1つのタスクに移動します。
- 統計の更新（毎日）-前の質問に対する 私の回答 を参照してください。すべての統計情報を強制的に更新するのではなく、毎日、統計情報が最後に更新された時期を確認し、場合によっては更新することをお勧めします。
- データベースの縮小（毎週）-ああ、違います。ファイルの縮小に関するPaul Randalの 記事をお読みください。
- インデックスを再構築（毎週）-5を参照してください。
メンテナンスクリーンアップ（毎日）-了解しました。
バックアップを確認するタスクを追加することをお勧めします-RESTOREコマンドのバージョンがあります（verifyOnly ..正しく思い出せば）-毎週としましょう。
データが失われた場合に備えて保護する必要があるとのことですが、このメンテナンス手順でシステムデータベースを追加する必要があると思います。また、サーバー自体とは別のマシンにファイルをバックアップするように注意してください。マスターdb、msdb..etcを再構築する必要がある場合に備えて、ファイルをどこかに保存します。あなたの仕事で頑張ってください！
遅い答えですが、他の読者に役立つかもしれません。
作成することができる、目に見えないリスクに関連する多くのメンテナンスまたはレポートタスクがあることに注意してください。
毎日実行される差分バックアップ中にドライブがいっぱいになるとどうなりますか？また、インデックスの再構築ジョブが異常に長く実行されるとどうなりますか？データの読み込みプロセスが原因で広範囲のリソース競合が発生し、通常の操作がひどくなる場合はどうでしょうか。これらはすべて計画されたイベントですが、保護しようとしているプロセスそのものにかなりの混乱を引き起こす可能性があります。
重要なタスクやリソースを集中的に使用するタスクが重複しないように、さまざまなジョブがどのように相互作用し、タイミングを合わせるかを常に検討してください。
最初にこの記事を読むことをお勧めします： http://www.sqlshack.com/removing-the-risk-from-important-maintenance-tasks-in-sql-server/
SQL Serverで重要なメンテナンスタスクを実行する方法について説明します–リスクはありません。たとえば、メンテナンスジョブに簡単なチェックを組み込んで、使用可能なリソースや、実行前に操作に必要なものを確認できます。これにより、環境がこれから行うことを確実に処理できるようになり、リソースが不十分な場合は意味のあるエラーで中止できます。
元気そう
ここで差分バックアップを実行するとメリットがある場合があります。確かにそれらを見てください
元気そう
元気そう
前に述べたように、データベースの縮小はデータとログファイルの物理的な断片化を引き起こし、よりランダムな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時間実行するスケジュールされたタスクと組み合わせて、毎回最悪のインデックスを処理し、土曜日ごとに、またはリスト内のすべてのインデックスが更新されたときに、断片化の完全な再スキャンを強制します。最適化されました。
最後に、「ファイルを自動的に縮小しないでください」グループに声をかけます。ファイルの縮小は、ログまたはDBファイル（無限ループなど）を超過する不規則なイベントが発生したときに散発的に使用するツールにすぎません。メンテナンスツールではありません。ディスク領域の圧迫がある場合、縮小はとにかく避けられないことを遅らせるだけです。