SQL Serverのメンテナンスプランを使用すると、タスクを簡単に整理、構成、およびスケジュールして、データベースエンジンとそこでホストされているデータベースの状態を維持できます。
メンテナンスプランは、データベース管理者に、インデックス作成、統計の更新、バックアップ、ログのクリーンアップなどの主要なタスクを構成する機会を提供します。前回の記事では、データベースの整合性チェックを実行するための基本的な保守計画を作成する方法についてすでに説明しました。この記事では、小さなデータベースをホストしているデータベースインスタンスのメンテナンスプランを作成するためのウォークスルーを行います。ウォークスルーの過程で、適度に多数の小さいを持つインスタンスのコンテキストで、各ステップで行われる重要な選択について説明します。 データベース。アイデアは、これらのデータベースのメンテナンスを1つずつ実行せずに構成することです。小規模なデータベースに重点を置くことは、メンテナンス操作に関連するパフォーマンスのオーバーヘッドを回避することを目的としています。
毎週のタスクのメンテナンス計画
図1：メンテナンスプランウィザードの起動
オブジェクトエクスプローラー>[インスタンス名]>管理>メンテナンスプランからメンテナンスプランウィザードを起動します（図1を参照）。ウィザードの最初のページには、構成可能なタスクの概要が表示されます。コードとジョブスケジューリングを使用してこれらのタスクを実行する方法は他にもありますが、メンテナンスプランウィザードを使用すると、1つのインスタンスでホストされている多数のデータベースを処理するときに非常に簡単に実行できます。
図2：メンテナンスプランウィザード
図3では、SQL Serverが、メンテナンスプランに名前を付けて説明するためのフィールドを公開しています。計画の説明を入力することは、文書化の目的で意味があります。新しい会社で新しいSQLServerインスタンスを引き継ぐことを想像してみてください。オブジェクト内にSQLServerオブジェクトの説明が含まれていると便利です。他の人にも同じことをする必要があります。私が与えた説明は、単に要点を説明するためのものであることに注意してください。実稼働環境では、より詳細な説明が望ましいでしょう。
図3：メンテナンスプランの命名
図3では、すべてのタスクに単一のスケジュールを使用するか、タスクごとに個別のスケジュールを使用するかを選択できることに注意してください。タスクをずらす柔軟性を持たせるために、別々のスケジュールを使用することを選択しました。サーバーリソースを圧倒するリスクを回避するために、あまりにも多くのメンテナンス操作を同時に実行したり、長期間にわたって連続して実行したりすることは望ましくありません。この時点で行う決定は、使用可能なリソースの容量と使用可能なメンテナンスウィンドウによっても異なる場合があります。一部の人々は十分な容量を持っており、各実行中にタスクをすばやく完了したいと考えています。この記事で取り上げるシナリオでは、問題のインスタンスが週末に使用されないと想定しています。
図4では、実行するタスクを選択します。 SQL Serverの優れた点の1つは、各タスクがウィンドウの下部に記述されていることです。 「Windows」で作業しているときでも、DBAとして作業しているときに、自分が何をしているかを理解することは有益です。私の経験では、多くの「管理者」は、機能を動作させるために急いでいるため、「次へ、次へ、次へ」をクリックするだけの習慣があります。しかし、時間をかけて次の「次へ」の影響を理解することは、新しい問題を引き起こすのではなく、付加価値のある何かをしていることを確認するのに役立ちます。
図4：メンテナンスタスクの選択
選択したタスクは次のとおりです。
データベースの整合性を確認する タスクは、データベース内のデータとインデックスページの内部整合性チェックを実行します。
インデックスの再編成 タスクは、テーブルとビューのクラスター化インデックスと非クラスター化インデックスを最適化および圧縮します。これにより、インデックススキャンのパフォーマンスが向上します。
インデックスの再構築 タスクは、インデックスを再構築することにより、データページとインデックスページのデータを再編成します。これにより、インデックススキャンとシークのパフォーマンスが向上します。このタスクは、インデックスページのデータと空き領域の分散も最適化し、将来の成長を加速させます。
統計の更新 タスクは、クエリオプティマイザがテーブル内のデータ値の分布に関する最新情報を持っていることを確認します。これにより、オプティマイザーはデータアクセス戦略についてより適切な判断を下すことができます。
履歴のクリーンアップ タスクは、バックアップと復元、SQL Serverエージェント、およびメンテナンスプランの操作に関する履歴データを削除します。このウィザードでは、削除するデータの種類と経過時間を指定できます。
データベースのバックアップ（フル） タスクを使用すると、ソースデータベース、宛先ファイル、またはテープを指定し、完全バックアップのオプションを上書きできます。
メンテナンスのクリーンアップ タスクは、メンテナンスプランの実行から残ったファイルを削除します。
図5は、これらのタスクが実行される順序を選択する場所を示しています。これはいくつかの理由で重要です。たとえば、インデックスの再構築はSQL Serverでもインデックス統計の更新を実行するため、インデックスの再構築後にインデックス統計の更新を実行することは意味がありません。選択した順序でこれをどのように処理するかについては、この記事の後半で説明します。もう1つの考えられる考慮事項は、特定の種類のメンテナンスを続行する前に、最初にバックアップを実行する方が理にかなっていると判断する場合があります。
図5：タスクの順序
図6では、最初の保守タスクを適用するデータベースを選択しています。後続の各タスクについてもこれを行う必要があります。これは、一部のデータベースをそのような操作から除外する必要があるという意味で重要です。たとえば、同じインスタンスに非常に大きなデータベース（VLDB）と非常に小さなデータベースが混在している場合（それ自体は悪い考えです）、VLDBを完全なブラインドインデックスの再構築から除外する必要がある場合があります。このような場合、そのVLDB内のキーテーブルを識別し、再構築およびその他の集中的なメンテナンス操作をキーテーブルに集中させる必要があります。この例では、システムデータベースのメンテナンスを個別に慎重に計画できるため、システムデータベースを除外しました。システムデータベースへの損傷がインスタンス全体に影響を与える可能性があることを考えると、システムデータベースを個別に処理する方が安全だと思います。
図6：スコープを決定する
各メンテナンス操作には、独自のオプションのセットがあります。図7は、DBCCCHECKDBに対して決定する必要のあるオプションを示しています。 MAXDOPを2に増やすことで、デフォルト設定から少し外れました。図8では、このタスクを土曜日と日曜日の夜の午前1時に実行することを選択しています。
図7：DBCCオプション
図8：DBCCスケジュール
インデックスの再編成タスクには、特定のオプションのセットもあります。言及する価値があるのは、インデックスを再編成する必要があるかどうかを決定する一連の条件です– 30％の断片化、1000以上のページ数、そして最後に再び使用されるのは最大28日です。このウィンドウは、私たちが行っているオプションを理解する必要性を強調しています。これらのオプションを正しく作成するには、インデックスとインデックスを適切な範囲で理解する必要があります。インデックスの再構築タスクでも同様の選択を行う必要があることに注意してください。また、インデックスの再編成に推奨される断片化のしきい値は、実際には30％ではなく15％であることに注意してください。
図9：インデックスオプションの再編成
インデックスの再構築タスクには、インデックスの再編成のオプションに加えて、他のいくつかのオプションがあります。 （図10を参照）。 TempDBで結果を並べ替えることを選択したことに注意してください。この選択を有効にするには、TempDBを適切に調整することが重要です。これは、この選択は、すべてのデータベースでのこの操作の並べ替えがTempDBで行われることを意味するためです。さらに、インデックスの再構築のスケジュールを設定する必要があります。このタスクでは、MAXDOPも2に設定しました。
図10：インデックスオプションの再構築
SQL Serverでインデックスの再構築が呼び出されると、デフォルトでインデックスの統計の更新も呼び出されることを前述しました。したがって、統計更新タスクを構成するときは、列の統計のみを更新することを選択します。 （図11）。このウィンドウには、フルスキャンまたはサンプリングのいずれかを実行するオプションもあります。コンテキストは小さなデータベースであるため、フルスキャンオプションを選択します。繰り返しになりますが、これには統計についてのある程度の理解が必要です。
図11：統計更新タスク
図12に示すように、4週間より古いデータを削除するようにクリーンアップジョブを構成することを選択します。
図12：履歴のクリーンアップタスク
バックアップタスクでは、3つのタブにかなりの数の構成オプションが表示されます。図13は、このバックアップタスクをユーザーデータベースに限定することを選択したことを示しています。日曜日の午前3時にスケジュールし、さらにバックアップ先をE：\ MSSQL \ Backupとして選択します（図14を参照）。 3番目のタブ（図15）では、バックアップの検証とチェックサムの実行を選択するため、バックアップの信頼性を確認することができます。
図13：データベースのバックアップタスク
図14：バックアップ先
図15：バックアップオプション
最後に、メンテナンスプランログの保持を管理するタスクを構成します。 （図16）。ここでも、4週間より古いログレコードを削除することを選択します。図17は、メンテナンスプランのアクティビティがログに記録され、データベース管理者グループにメールで送信されるようにするために選択したオプションを示しています。もちろん、この最後のオプションを機能させるには、データベースメールを構成し、オペレーターを正しく設定しておく必要があります。
図16：メンテナンスプランのクリーンアップタスク
図17：レポートオプション
図18と19は、構成したタスクの概要と、ウィザードが正常に完了したことに関するフィードバックを示しています。
図18：オプションの概要
図19：ウィザードの完了
日常業務のメンテナンス計画
また、単に整理するなど、他の目的のために個別の保守計画を設定することもできます。タスクごとにスケジュールを個別に構成できるため、毎日のタスクに個別の計画を設定する必要はありません。別のプランを設定したい理由の1つは、別のデータベースセットを対象とした別のタスクセットを選択することです（実際には、既存のプランでもこれを実行できる可能性があります）。
次の例では、同じインスタンス内に異なるリカバリポイントの目的を持つ別の大規模なデータベースのセットがあると仮定します。次に、別のバックアップ戦略を使用する必要があります。1時間のRPOを確保するために、毎週の完全バックアップに加えて、毎日の差分バックアップスケジュールと1時間ごとのトランザクションログバックアップスケジュールです。 （図21および22を参照）。
図20：毎日のタスク保守計画
図21：差分およびTlogバックアップタスク
図22：毎日のメンテナンス計画のタスクオーダー
差分バックアップの場合、毎日午前2時にトリガーされる毎日のスケジュールを選択します。 （図23を参照）。また、以前に構成したフルウィークリーバックアップの場合と同じバックアップオプションを選択します。
図23：毎日のメンテナンス計画のスケジュール
図24：バックアップの場所の違い
図25：差分バックアップオプション
一方、差分バックアップを毎日1時間ごとに実行するようにスケジュールすることを選択します。また、各データベースバックアップセットが独自の名前を持つディレクトリに保存されていることを確認します。ウィザードの残りの部分は、前のウォークスルーとほとんど同じです。
図26：トランザクションログのバックアップスケジュール
図27：トランザクションログのバックアップ場所
図28：トランザクションログのバックアップオプション
結論
メンテナンスプランウィザードを完了すると、メンテナンスプランとそれに対応するSQLエージェントジョブのセットが作成されます（図29を参照）。基本的に、メンテナンスプランはSSISパッケージのコレクションであり、スケジュールされたジョブを調べると、各サブプランジョブで実行されるジョブステップがSSISパッケージであることがわかります（図30を参照）。
次の例では、サブプランのジョブを毎年実行できることを示します。また、メンテナンスプランの実行結果を確認し、ジョブステップの実行に関連するエラーのトラブルシューティングを行います。保守計画ログも調べます。
図29：結果のSQLエージェントジョブ
図30：SSISパッケージのジョブステップ