MSDBのメンテナンスの重要性

MSDBは、SQLServerで使用されるシステムデータベースです。 MSDBは、バックアップと復元の履歴、SQLエージェントのジョブ履歴、ログ配布モニターの履歴、SSISパッケージ、Database Engine Tuning Advisorデータ、ServiceBrokerキューデータなどのあらゆる種類のデータを格納します。ユーザーデータベースと同様に、msdbには、インデックスの最適化や、さらに重要なことに定期的なパージなど、定期的なメンテナンスが必要です。

履歴のバックアップと復元

デフォルトでは、msdbからバックアップと復元の履歴をパージまたは削除する方法はありません。データを削除する手動または自動プロセスを設定するまで、永久に保持されます。このデータをパージしないことにより、msdbは増大し続けます。つまり、これらのテーブルの読み取りと書き込みが遅くなり、バックアップジョブの速度に影響を与える可能性があります。

ほとんどのサードパーティツールと信頼できるメンテナンスソリューションには、これが問題になるのを防ぐために、バックアップと復元の履歴をクリアするプロセスが含まれています。バックアップ履歴を削除しているかどうかを知る簡単な方法は、msdbに直接クエリを実行することです。

SELECT CONVERT(CHAR(100), SERVERPROPERTY('Servername')) AS Server,
  msdb.dbo.backupset.database_name,
  msdb.dbo.backupset.backup_finish_date,
  CASE msdb..backupset.type
    WHEN 'D' THEN 'Database'
    WHEN 'L' THEN 'Log'
  END AS backup_type
FROM msdb.dbo.backupmediafamily
INNER JOIN msdb.dbo.backupset ON msdb.dbo.backupmediafamily.media_set_id = msdb.dbo.backupset.media_set_id
ORDER BY msdb.dbo.backupset.backup_finish_date;

90日を超えるバックアップまたは復元の履歴がある場合は、それらのバックアップに関する履歴情報を特定の期間保持する必要があることを義務付ける規制要件があるかどうかを調査する必要があります。要件がない場合は、特定の期間より古いデータを削除することを検討する必要があります。データベースを復元するためにバックアップ履歴は必要ありません。msdbを適切なサイズに保つために、定期的にバックアップ履歴を削除することをお勧めします。 90日以内に保つことは、私が通常クライアントに推奨する範囲です。

バックアップと復元の履歴を削除するプロセスを設定するには、sp_delete_backuphistoryを実行するジョブを作成します msdbにストアドプロシージャを配置し、日付パラメータを渡します。ストアドプロシージャは、指定した日付より古いすべてのバックアップと復元の履歴を削除します。データベース保守計画を作成して、履歴のクリーンアップタスクを使用することもできます。

データベースエンジンチューニングアドバイザー

DTAとも呼ばれるデータベースエンジンチューニングアドバイザーは、開発者とデータベース管理者がデータベースのチューニングを支援するために使用できるツールです。 DTAは、msdbデータベースを利用して、チューニング履歴やその他のサポートオブジェクトを保存します。

クライアントの本番サーバーのmsdbでDTAの残骸を日常的に見つけています。これらのテーブルを見つけたら、直接クエリを実行して、DTAがまだ使用されているかどうかを判断します。幸いなことに、パフォーマンスに大きな影響を与える可能性があるため、本番環境に対してDTAをアクティブに実行しているクライアントはまだ見つかりません。確認してクライアントと通信したら、msdbからDTAテーブルを削除します。場合によっては、これにより数ギガバイトのスペースが解放されます。予防策として、本番環境に対してDTAを実行することによるパフォーマンスへの影響についても説明し、将来の使用は開発サーバーで行う必要があることをクライアントに促します。

SQLServerエージェント

ときどき、ジョブ履歴ログのサイズを制限するために誤ってチェックボックスをオフにしたクライアントを見つけることがあります。サーバーがビジー状態で、ログがすぐにロールオーバーし続けるため、SQL Serverエージェントジョブのトラブルシューティング時に参照できる有用なジョブ履歴がない場合、これは簡単な間違いです。より良いアプローチは、最大ジョブ履歴ログ・サイズ（行単位）を無制限に拡大するのではなく、はるかに高い値に増やすことです。

クライアントの仕事が無制限に増加した場合、sysjobhistoryテーブルが過度に大きくなり、パージする必要がありました。履歴を削除する最善の方法は、sp_purge_jobhistoryを使用することです。日付パラメータを渡します。ストアドプロシージャは、指定した日付より古いすべてのジョブ履歴を削除します。 SQL Serverエージェントの履歴の最小日数を保持する必要がある場合、行に基づいてジョブ履歴ログを制限することは効果的ではありません。代わりに、ジョブ履歴ログのサイズを制限せず、sp_purge_jobhistoryを実行し、必要なジョブ履歴の最小日数の日付パラメーターを渡すジョブをスケジュールします。 14日または30日の値を使用するのが一般的です。

サービスブローカー

最近、msdbのサイズが14GBに増えたクライアントで問題が発生しました。インスタンスを現在のサービスパックに更新しようとした後、アップグレードはスクリプトをmsdbに適用できず、msdbが再び指数関数的に増加しました。調査の結果、Service Brokerでイベント通知が有効になっていることがわかりましたが、正しく構成されていませんでした。 1年以上の間、イベント通知はキューに入れられていましたが、ルーティングされていませんでした。

sys.transmission_queueを確認したところ、ターゲットデータベースのサービスブローカーが使用できず、サービスブローカーが管理上無効になっていることがわかりました。次に、sys.server_events_notificationsにクエリを実行して、どのイベント通知が設定されているかを確認し、すべてのエラーログイベントをキャプチャするという1つのエントリのみを見つけました。次に、sys.transmissions_queueにクエリを実行して、キューにあるイベントの数を確認し、そこに数百万のレコードを見つけました。

これについてクライアントと話し合い、調査結果を説明した後、最善の行動は、イベント通知を削除し、新しいブローカーを作成して現在のキューをクリアすることであることに同意しました。これを行うために、ALTER DATABASE msdbSETNEW_BROKERを実行しました。これは、数時間後、msdbの完全バックアップ後に行われました。

Transmission_queueをクリアしてイベントを削除した後、msdbを14GBから300MBに減らすことができました。この問題を修正する前は、msdbデータベースのディスクレイテンシが最も高く、クライアントで定期的なデッドロックが発生していました。この変更とその他の最適化を実装した後、クライアントのユーザーエクスペリエンスは大幅に向上しました。

ログ配布

DBAのキャリアの早い段階で、別のデータセンターのセカンダリサーバーにログシップされた数百のデータベースを持つ統合サーバーを継承しました。このサーバーは数年間稼働しており、15分ごとにログを送信していました。このインスタンスは、バックアップ履歴を削除しなかっただけでなく、ログ配布モニターの履歴を適切にクリアしていませんでした。バックアップ履歴を削除してmsdbのサイズを確認した後も、必要以上の使用済みスペースが表示されていました。スクリプトを実行して各テーブルの合計サイズを表示したところ、log_shipping_monitor_history_detail テーブルはとても大きかった。この場合、sp_cleanup_log_shipping_historyを実行できました。履歴を削除し、msdbを通常のサイズに戻します。

インデックス作成

msdbのインデックスを最適化することは、ユーザーデータベースと同じくらい重要です。システムデータベースではなく、ユーザーデータベースを最適化しているクライアントを何度も見つけました。 msdbデータベースは、SQL Serverエージェント、ログ配布、サービスブローカー、SSIS、バックアップと復元、およびその他のプロセスで頻繁に使用されるため、インデックスが高度に断片化される可能性があります。インデックス最適化ジョブにシステムデータベース、または少なくともmsdbも含まれていることを確認してください。インデックスの最適化により、msdb内の高度に断片化されたインデックスから数ギガバイトのスペースが解放されるのを見てきました。

概要

msdbを無視すると、環境のパフォーマンスに悪影響を与える可能性があります。 msdbのサイズとそれを使用するプロセスを監視して、msdbが最適に実行されることを確認することが重要です。バックアップと復元の履歴は、msdbデータベースが肥大化する最も一般的な理由ですが、データベースエンジンチューニングアドバイザー、SQL Serverエージェントの履歴、サービスブローカー、ログ配布、およびインデックスメンテナンスの欠如はすべて、msdbの過度の成長に寄与し、データベース。