Die Bedeutung der Wartung von MSDB

MSDB ist eine Systemdatenbank, die von SQL Server verwendet wird. MSDB speichert alle Arten von Daten, z. B. Sicherungs- und Wiederherstellungsverlauf, SQL Agent-Auftragsverlauf, Verlauf der Protokollversandüberwachung, SSIS-Pakete, Database Engine Tuning Advisor-Daten und Service Broker-Warteschlangendaten. Genau wie Benutzerdatenbanken muss msdb regelmäßig gewartet werden, einschließlich Indexoptimierungen und, was noch wichtiger ist, regelmäßiger Bereinigung.

Verlauf sichern und wiederherstellen

Standardmäßig gibt es keine Methode zum Bereinigen oder Löschen von Sicherungen und zum Wiederherstellen des Verlaufs von msdb. Sie werden für immer aufbewahrt, bis Sie einen manuellen oder automatisierten Prozess zum Löschen der Daten einrichten. Wenn diese Daten nicht gelöscht werden, wächst msdb weiter, was bedeutet, dass das Lesen und Schreiben in diese Tabellen langsamer werden und die Geschwindigkeit Ihrer Sicherungsjobs beeinträchtigen kann.

Die meisten Tools von Drittanbietern und seriösen Wartungslösungen beinhalten Prozesse zum Löschen des Sicherungs- und Wiederherstellungsverlaufs, um zu verhindern, dass dies zu einem Problem wird. Eine einfache Methode, um festzustellen, ob Sie den Sicherungsverlauf löschen oder nicht, besteht darin, msdb direkt abzufragen:

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;

Wenn Sie einen Sicherungs- oder Wiederherstellungsverlauf haben, der mehr als 90 Tage zurückreicht, sollten Sie untersuchen, ob es eine gesetzliche Anforderung gibt, die vorschreibt, dass Sie die historischen Informationen über diese Sicherungen für einen bestimmten Zeitraum aufbewahren müssen. Wenn keine Anforderung besteht, sollten Sie erwägen, Daten zu löschen, die älter als ein bestimmter Zeitraum sind. Der Sicherungsverlauf ist nicht erforderlich, um Ihre Datenbanken wiederherzustellen, und wir empfehlen, ihn regelmäßig zu bereinigen, um msdb auf einer angemessenen Größe zu halten. 90 Tage oder weniger aufzubewahren ist der Bereich, den ich normalerweise Kunden empfehle.

Um einen Prozess zum Löschen des Sicherungs- und Wiederherstellungsverlaufs einzurichten, erstellen Sie einen Job, der sp_delete_backuphistory ausführt gespeicherte Prozedur in msdb und übergeben Sie ihr einen Datumsparameter. Die gespeicherte Prozedur löscht den gesamten Sicherungs- und Wiederherstellungsverlauf, der älter ist als das von Ihnen angegebene Datum. Sie können auch einen Datenbankwartungsplan erstellen und die Aufgabe Verlauf bereinigen verwenden.

Datenbank-Engine-Optimierungsratgeber

Der Database Engine Tuning Advisor, auch bekannt als DTA, ist ein Tool, das Entwickler und Datenbankadministratoren verwenden können, um eine Datenbank zu optimieren. DTA nutzt die msdb-Datenbank, um den Optimierungsverlauf und andere unterstützende Objekte zu speichern.

Ich finde routinemäßig Reste von DTA in msdb auf den Produktionsservern der Kunden. Wenn ich diese Tabellen finde, frage ich sie direkt ab, um festzustellen, ob DTA noch verwendet wird. Glücklicherweise habe ich noch keinen Client gefunden, der DTA aktiv gegen die Produktion ausführt, da dies die Leistung erheblich beeinträchtigen kann. Sobald ich den Client bestätige und mit ihm kommuniziere, lösche ich die DTA-Tabellen aus msdb. In einigen Fällen werden dadurch mehrere Gigabyte Speicherplatz frei. Als Vorsichtsmaßnahme nehme ich mir auch die Zeit, die Auswirkungen auf die Leistung zu erklären, die das Ausführen von DTA gegen die Produktion verursachen kann, und ermutige meine Kunden, dass jede zukünftige Verwendung auf einem Entwicklungsserver erfolgen sollte.

SQL Server-Agent

Gelegentlich finde ich einen Kunden, der versehentlich das Kontrollkästchen deaktiviert hat, um die Größe des Auftragsverlaufsprotokolls zu begrenzen. Dies ist ein leichter Fehler, wenn Sie einen ausgelasteten Server haben und das Protokoll so schnell überläuft, dass Sie keinen nützlichen Auftragsverlauf haben, auf den Sie bei der Fehlerbehebung von SQL Server-Agent-Aufträgen verweisen können. Ein besserer Ansatz besteht darin, die maximale Größe des Auftragsverlaufsprotokolls (in Zeilen) auf einen viel höheren Wert zu erhöhen, anstatt ihn unbegrenzt wachsen zu lassen.

In den Fällen, in denen Clients unbegrenztes Jobwachstum hatten, war die sysjobhistory-Tabelle übermäßig groß geworden und musste gelöscht werden. Der beste Weg, den Verlauf zu löschen, ist die Verwendung von sp_purge_jobhistory und übergeben Sie einen Datumsparameter. Die gespeicherte Prozedur löscht den gesamten Auftragsverlauf, der älter ist als das von Ihnen angegebene Datum. Wenn Sie eine Mindestanzahl von Tagen des SQL Server-Agent-Verlaufs aufbewahren müssen, ist die Begrenzung des Auftragsverlaufsprotokolls basierend auf Zeilen nicht effektiv. Beschränken Sie stattdessen nicht die Größe des Auftragsverlaufsprotokolls und planen Sie auch einen Auftrag, der sp_purge_jobhistory ausführt und einen Datumsparameter für die erforderliche Mindestanzahl von Tagen des Auftragsverlaufs übergibt. Es ist üblich, einen Wert von 14 oder 30 Tagen zu verwenden.

Service-Broker

Kürzlich bin ich auf ein Problem mit einem Client gestoßen, bei dem msdb auf 14 GB angewachsen war. Nach dem Versuch, die Instanz auf ein aktuelles Service Pack zu aktualisieren, schlug das Upgrade fehl, die Skripts auf msdb anzuwenden, und führte dazu, dass msdb erneut exponentiell anwuchs. Nach einiger Recherche stellten wir fest, dass Service Broker für Ereignisbenachrichtigungen aktiviert, aber nicht richtig konfiguriert war. Über ein Jahr lang wurden Ereignisbenachrichtigungen in die Warteschlange gestellt, aber nicht weitergeleitet.

Beim Überprüfen der sys.transmission_queue stellte ich fest, dass der Service Broker in der Zieldatenbank nicht verfügbar war und der Service Broker administrativ deaktiviert war. Ich habe dann überprüft, welche Ereignisbenachrichtigungen eingerichtet wurden, indem ich sys.server_events_notifications abgefragt habe, und habe nur einen Eintrag gefunden:alle Fehlerprotokollereignisse erfassen. Ich habe dann sys.transmissions_queue abgefragt, um zu sehen, wie viele Ereignisse in der Warteschlange waren, und dort mehrere Millionen Datensätze gefunden.

Nachdem wir dies mit dem Kunden besprochen und die Ergebnisse erläutert hatten, waren wir uns einig, dass die beste Vorgehensweise darin bestand, die Ereignisbenachrichtigung zu löschen und die aktuelle Warteschlange zu löschen, indem ein neuer Broker erstellt wurde. Dazu habe ich ALTER DATABASE msdb SET NEW_BROKER ausgeführt. Dies geschah nach Stunden und nach einer guten vollständigen Sicherung von msdb.

Nachdem ich die transmission_queue gelöscht und das Ereignis entfernt hatte, konnte ich msdb von 14 GB auf 300 MB reduzieren. Vor der Behebung dieses Problems wies die msdb-Datenbank die höchste Datenträgerlatenz auf der Instanz auf, und auf dem Client kam es regelmäßig zu Deadlocks. Nach der Implementierung dieser Änderung sowie anderer Optimierungen hat sich die Benutzererfahrung des Clients erheblich verbessert.

Protokollversand

Zu Beginn meiner DBA-Karriere habe ich einen Konsolidierungsserver geerbt, der einige hundert Datenbanken hatte, die per Protokollversand an einen sekundären Server in einem anderen Rechenzentrum übertragen wurden. Dieser Server war mehrere Jahre in Betrieb und versendete die Protokolle alle 15 Minuten. Diese Instanz litt nicht nur darunter, dass der Sicherungsverlauf nicht gelöscht wurde, sondern auch der Protokollversand-Überwachungsverlauf wurde nicht ordnungsgemäß gelöscht. Nachdem ich den Sicherungsverlauf gelöscht und die Größe von msdb überprüft hatte, zeigte es immer noch mehr belegten Speicherplatz als es sollte. Ich habe ein Skript ausgeführt, um mir die Gesamtgröße jeder Tabelle anzuzeigen, und festgestellt, dass das log_shipping_monitor_history_detail Tisch war sehr groß. In diesem Fall konnte ich sp_cleanup_log_shipping_history ausführen um den Verlauf zu löschen und msdb wieder auf die normale Größe zu bringen.

Indizierung

Die Optimierung von Indizes in msdb ist genauso wichtig wie Ihre Benutzerdatenbanken. Oft habe ich Kunden gefunden, die Benutzerdatenbanken optimieren, aber nicht die Systemdatenbanken. Da die msdb-Datenbank stark von SQL Server-Agent, Protokollversand, Service Broker, SSIS, Sicherung und Wiederherstellung und anderen Prozessen verwendet wird, können die Indizes stark fragmentiert werden. Stellen Sie sicher, dass Ihre Indexoptimierungsjobs auch Ihre Systemdatenbanken oder zumindest msdb umfassen. Ich habe gesehen, dass Indexoptimierungen mehrere Gigabyte Speicherplatz von stark fragmentierten Indizes in msdb freigeben.

Zusammenfassung

Die Vernachlässigung von msdb kann sich negativ auf die Leistung Ihrer Umgebung auswirken. Es ist wichtig, die Größe von msdb sowie die Prozesse, die es verwenden, zu überwachen, um sicherzustellen, dass es optimal funktioniert. Der Sicherungs- und Wiederherstellungsverlauf ist der häufigste Grund für das Aufblähen der msdb-Datenbank, jedoch können Database Engine Tuning Advisor, SQL Server Agent-Verlauf, Service Broker, Protokollversand und mangelnde Indexwartung zu einem übermäßigen Wachstum von msdb beitragen und die Leistung von die Datenbank.