Sqlserver
 sql >> Datenbank >  >> RDS >> Sqlserver

SQL Server-Systemdatenbanken – MSDB-Wartung

In den vorherigen Artikeln der Reihe „SQL Server-Systemdatenbanken“ haben wir die Systemdatenbanken durchgesehen, die standardmäßig während der SQL Server-Installation installiert werden, den Zweck jeder dieser Systemdatenbanken verstanden und die Tempdb-Datenbank und ihre Wartung ausführlicher untersucht. In diesem Artikel werden wir die MSDB-Datenbank ausführlicher untersuchen, zusammen mit den häufig auftretenden Problemen rund um die MSDB-Datenbank und wie man sie richtig löst.

Die MSDB-Datenbank

Die MSDB Die SQL Server-Systemdatenbank speichert alle kritischen Konfigurationsinformationen und Verlaufsinformationen in Bezug auf SQL Server Agent Service, SQL Server Service Broker, Datenbank-E-Mail, Protokollversand, Datenbankspiegelung usw.:

  • SQL Server Agent-Dienst
    • SQL Server Agent Jobs – Konfigurationsdaten und Verlaufsdetails
    • SQL Server Agent Alerts – Konfigurationsdaten
    • SQL Server Agent Operators – Konfigurationsdaten
    • SQL Server Agent Proxys – Konfigurationsdaten
    • Zugehörige Informationen
  • SQL Server-Datenbank-E-Mail, einschließlich Service Broker – Konfigurationsdaten und historische E-Mail-Protokolldetails.
  • Details zur SQL Server-Sicherung und -Wiederherstellung – Verlaufsdaten aller Datenbanksicherungs- und -wiederherstellungsereignisse, die in der Instanz von SQL Server stattfinden.
  • Wartungspläne, SSIS-Pakete und zugehörige Informationen – Konfigurationsdaten, zugehörige Daten und die Daten zur Ausführung all dieser Elemente über SQL Server-Agent-Jobs.
  • Protokollversandkonfigurationen, Replikations-Agent-Profile, Datenkollektorjobs – Konfigurationsdaten aller erwähnten Hochverfügbarkeitstechniken.

Wann immer eine der oben genannten kritischen Konfigurationen geändert wird, wird empfohlen, eine Full zu nehmen Sicherung der MSDB-Datenbank, um Datenverluste im Fehlerfall zu vermeiden.

Obwohl der SQL Server Agent-Dienst wichtige Konfigurationsdetails über Tabellen in der MSDB speichert Datenbank speichert SQL Server auch einige Konfigurationsdetails in der Windows-Registrierung. Dafür verwendet es die erweiterte Stored Procedure namens sp_set_sqlagent_properties .

Werfen wir einen kurzen Blick auf den Registrierungsort, an dem SQL Server Konfigurationen des SQL Server Agent-Dienstes speichert. Wichtig :Dies dient nur zu Lernzwecken, und wir empfehlen, keine Konfigurationswerte zu ändern. Andernfalls kann es zu seltsamen Fehlern im Zusammenhang mit dem SQL Server Agent-Dienst kommen.

Öffnen Sie den Registrierungs-Editor indem Sie regedit eingeben in der Eingabeaufforderung:

Klicken Sie auf Eingabe um den Registrierungseditor zu öffnen :

Navigieren Sie nun zum Pfad:

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL13.MSSQLSERVER\SQLServerAgent

Sehen Sie sich die folgenden Konfigurationsdetails an. Das markierte Fragment bezieht sich auf den SQL Server-Instanznamen und kann je nach SQL Server-Version und Instanzname in Ihrer Umgebung variieren.

Ein kurzer Blick in die Registrierung zeigt, dass bestimmte Parameter im Zusammenhang mit dem SQL Server Agent-Dienst gespeichert sind. Da wir nicht empfehlen, Parameter zu ändern, die sich auf den SQL Server Agent-Dienst beziehen und oben nur zu Lernzwecken geteilt werden, werden wir hier nicht weiter darauf eingehen.

Wenn Sie jedoch beabsichtigen, eine der Eigenschaften des SQL Server-Agentendiensts zu ändern, um Geschäfts- oder Produktionsanforderungen zu erfüllen, können Sie sie ändern, indem Sie mit der rechten Maustaste auf den SQL Server-Agentendienst klicken und Eigenschaften auswählen wie unten gezeigt.

Obwohl viele Parameter im Zusammenhang mit dem SQL Server Agent-Dienst verfügbar sind und sich der Umfang dieses Artikels auf die msdb-Datenbank bezieht, habe ich diese ausgeschlossen und nur die Optionen behandelt, die für die msdb-Datenbank spezifisch sind, indem ich auf das Menü Verlauf klicke, wie unten gezeigt, wo wir kann die Größe der Auftragsverlaufsprotokolle und des Agentenverlaufs konfigurieren.

Häufig auftretende Probleme in der MSDB-Datenbank

In jeder Produktionsinstanz von SQL Server sind viele SQL Server-Agent-Jobs, Datenbank-E-Mails, Wartungspläne und vollständige/Transaktionsprotokollsicherungen aktiviert. Je nach Nr. von Datenbanken in der Instanz oder der Nr. der verfügbaren SQL Server-Agent-Jobs oder der Datenbank-E-Mail-Nutzung beginnt unser SQL Server mit der Protokollierung der Verlaufsinformationen aller aktivierten Funktionen, wodurch die Größe der MSDB erhöht wird Datenbank. Wenn dies nicht ordnungsgemäß gewartet wird, wirkt sich dies auf die Leistung der MSDB-Datenbank und die damit verbundenen Vorgänge aus.

Sehen wir uns die zuvor besprochenen Funktionen und die zum Speichern von Verlaufsdaten verwendeten Tabellen an, um zu verstehen, wie wir die Größe dieser Tabellen unter Kontrolle halten können.

  • Backup-Verlauf
  • Auftragsverlauf des SQL Server-Agents
  • Wartungspläne
  • E-Mail-Verlauf der SQL Server-Datenbank
  • SSIS-Pakete

Um herauszufinden, welche Tabellen in der MSDB-Datenbank mehr Platz beanspruchen, können wir die Datenträgernutzung nach Top-Tabellenberichten verwenden die als Teil der SQL Server-Standardberichterstellung in SQL Server Management Studio enthalten ist.

Öffnen Sie SSMS und klicken Sie mit der rechten Maustaste auf MSDB Datenbank> Berichte > Standardberichte > Festplattennutzung nach Top-Tabellen um den Bericht der Tabellen nach Festplattennutzung sortiert zu erstellen:

Klicken Sie auf Festplattennutzung nach Top-Tabellen um den Bericht anzuzeigen. Da es sich bei meiner Instanz um eine Entwicklungsinstanz handelt, gibt es keine großen Tabellen, aber dieser Bericht kann die Größe aller Tabellen in einer Datenbank in absteigender Reihenfolge sortiert anzeigen.

Wir können auch die folgende Abfrage verwenden, um die Tabellengrößen innerhalb einer Datenbank abzurufen.

SELECT -- TOP(10)
	  SCHEMA_NAME(o.[schema_id]) Schema_name
	, o.name object_name
    , total_size = CAST(SUM(au.total_pages) * 8. / 1024 AS DECIMAL(18,2))
    , total_rows = SUM(CASE WHEN i.index_id IN (0, 1) AND au.[type] = 1 THEN p.[rows] END)
FROM sys.objects o 
JOIN sys.indexes i ON o.[object_id] = i.[object_id]
JOIN sys.partitions p ON i.[object_id] = p.[object_id] AND i.index_id = p.index_id
JOIN sys.allocation_units au ON p.[partition_id] = au.container_id
WHERE i.is_disabled = 0
AND i.is_hypothetical = 0
AND o.Type in ('S','U','V')
GROUP BY o.name, SCHEMA_NAME(o.[schema_id])
ORDER BY 3 DESC

Sobald wir wissen, welche Tabellen mehr Platz beanspruchen, können wir die zugehörigen gespeicherten Prozeduren verwenden, um ihre Größe unter Kontrolle zu halten.

Backup-Verlauf

Die Hauptverantwortung des DBA besteht darin, sicherzustellen, dass vollständige Sicherungen und Transaktionsprotokolle in allen Produktionsinstanzen von SQL Server aktiviert sind, um die Datenbanken zu einem bestimmten Zeitpunkt wiederherzustellen.

SQL Server speichert die Sicherungsdetails und die Wiederherstellungsinformationen in den folgenden MSDB-Datenbanktabellen :

  • Sicherungsdatei
  • Dateigruppe sichern
  • Backup-Medienfamilie
  • Backup-Mediensatz
  • Sicherungssatz
  • Datei wiederherstellen
  • Dateigruppe wiederherstellen
  • Verlauf wiederherstellen

Für ein deutliches Nein. von Datenbanken in der SQL Server-Instanz, die mit vollständigen Sicherungen und Transaktionsprotokollsicherungen konfiguriert sind, können die Datensätze in den obigen Tabellen schneller zunehmen.

Daher stellt SQL Server zwei gespeicherte Systemprozeduren in der MSDB bereit Datenbank, um die Größe der obigen Tabellen zu steuern:

  • sp_delete_backuphistory – löscht die Backup-Verlaufsdaten in den obigen 8 Tabellen basierend auf dem ältesten Datum Parameter.
  • sp_delete_database_backuphistory – löscht die Backup-Verlaufsdaten in den obigen 8 Tabellen basierend auf dem Datenbanknamen .

Die Syntax zum Ausführen der oben genannten gespeicherten Systemprozeduren:

exec msdb.dbo.sp_delete_backuphistory @oldest_date = 'oldest_date'
exec msdb.dbo.sp_delete_database_backuphistory @database_name = 'database_name'

Wenn wir eine der oben beschriebenen gespeicherten Prozeduren auf einer Datenbank ausführen, die riesige Datensätze in den Sicherungsverlaufstabellen enthält, werden wir möglicherweise blockiert oder bemerken, dass die Datensätze sehr langsam gelöscht werden. Um dies zu beheben, erstellen wir den unten stehenden fehlenden Index auf dem Backupset Tisch. Es kann über den Ausführungsplan der gespeicherten Prozedur identifiziert werden, um eine unserer gespeicherten Prozeduren schneller auszuführen.

IF NOT EXISTS (SELECT * FROM sys.indexes WHERE OBJECT_ID = OBJECT_ID('[dbo].[backupset]') AND name = 'IX_BackupSet_FinDate_MediaSet')
CREATE NONCLUSTERED INDEX IX_BackupSet_FinDate_MediaSet ON backupset(backup_finish_date) 
INCLUDE (media_set_id)
GO

Auftragsverlauf des SQL Server-Agenten

SQL Server speichert den gesamten SQL Server-Agent-Auftragsverlauf in msdb.dbo.sysjobhistory Tisch. Außerdem verfügt SQL Server über eine gespeicherte Systemprozedur namens msdb.dbo.sp_purge_jobhistory das hilft, die sysjobhistory zu behalten Tabellengröße unter Kontrolle.

Die Syntax zum Ausführen von sp_purge_jobhistory gespeicherte Prozedur wird sein:

exec msdb.dbo.sp_purge_jobhistory @job_name = 'job_name', @job_id = 'job_id', @oldest_date ='oldest_date'

Alle 3 Parameter sind optional, und wir empfehlen, das obige Verfahren auszuführen, indem Sie das älteste_Datum übergeben Parameter um die sysjobhistory zu behalten Tabellengröße unter Kontrolle.

Wartungspläne

SQL Server speichert die Details aller Wartungspläne in den folgenden Tabellen:

  • msdb.dbo.sysmaintplan_log
  • msdb.dbo.sysmaintplan_logdetail

SQL Server verfügt über eine integrierte gespeicherte Prozedur namens msdb.dbo.sp_maintplan_delete_log um die Größe dieser 2 Tabellen unter Kontrolle zu halten.

Die Syntax zum Ausführen der Prozedur lautet:

exec msdb.dbo.sp_maintplan_delete_log @plan_id = '', @subplan_id = '', @oldest_Time = 'oldest_datetime'

Alle 3 Parameter sind optional. Wir empfehlen, das obige Verfahren auszuführen und den Parameter „oldest_time“ zu übergeben, um die Größe der beiden obigen Tabellen unter Kontrolle zu halten.

E-Mail-Verlauf der SQL Server-Datenbank

SQL Server speichert alle Datenbank-E-Mail-Verlaufsprotokolle in den folgenden Tabellen:

  • sysmail_mailitems
  • sysmail_log
  • sysmail_attachments
  • sysmail_attachments_transfer

Um diese Verlaufstabellengrößen unter Kontrolle zu halten, bietet SQL Server zwei gespeicherte Systemprozeduren mit dem Namen msdb.dbo.sysmail_delete_mailitems_sp und msdb.dbo.sysmail_delete_log_sp.

Die Syntax zum Ausführen dieser gespeicherten Prozeduren lautet:

exec msdb.dbo.sysmail_delete_mailitems_sp @sent_before = 'oldest_datetime', @sent_status = NULL
exec msdb.dbo.sysmail_delete_log_sp @logged_before = 'oldest_datetime', @event_type = NULL

Bei beiden Verfahren sind alle Parameter optional. Es wird jedoch empfohlen, sent_before zu verwenden oder angemeldet_vor e Parameter zum Löschen der älteren Datensätze basierend auf der Aufbewahrungsfrist.

In wenigen Szenarien, wenn alle Tabellen, die sich auf Datenbank-E-Mail beziehen, sehr groß sind, wird delete ausgeführt Verfahren wird ewig laufen. Eine schnellere Möglichkeit, das Problem zu lösen, besteht darin, die Fremdschlüsseleinschränkung für sysmail_attachments zu löschen und sysmail_send_retries Tabellen, kürzen Sie die obigen 4 Tabellen und erstellen Sie die 2 Fremdschlüssel wieder auf sysmail_attachments und sysmail_send_retries Tabellen wie unten gezeigt:

USE MSDB;

ALTER TABLE [dbo].[sysmail_attachments] DROP [FK_sysmail_mailitems_mailitem_id];
GO
ALTER TABLE [dbo].[sysmail_send_retries] DROP [FK_mailitems_mailitem_id];
GO

TRUNCATE TABLE [dbo].[sysmail_attachments];
TRUNCATE TABLE [dbo].[sysmail_send_retries];
TRUNCATE TABLE [dbo].[sysmail_mailitems];
TRUNCATE TABLE [dbo].[sysmail_log];

ALTER TABLE [dbo].[sysmail_attachments]  WITH CHECK ADD  CONSTRAINT [FK_sysmail_mailitems_mailitem_id] FOREIGN KEY([mailitem_id])
REFERENCES [dbo].[sysmail_mailitems] ([mailitem_id])
ON DELETE CASCADE;
ALTER TABLE [dbo].[sysmail_attachments] CHECK CONSTRAINT [FK_sysmail_mailitems_mailitem_id];
GO

ALTER TABLE [dbo].[sysmail_send_retries]  WITH CHECK ADD  CONSTRAINT [FK_mailitems_mailitem_id] FOREIGN KEY([mailitem_id])
REFERENCES [dbo].[sysmail_mailitems] ([mailitem_id])
ON DELETE CASCADE;
ALTER TABLE [dbo].[sysmail_send_retries] CHECK CONSTRAINT [FK_mailitems_mailitem_id];
GO

SSIS-Pakete

SQL Server speichert alle SSIS(*.dtsx) Pakete in den msdb.dbo.sysssispackages Tisch. Diese Tabelle ist eine Konfigurationstabelle, aber in zufälligen Fällen besteht die Möglichkeit, dass viele SSIS-Pakete auf der Tabelle abgelegt werden. Dadurch wird die Größe dieser Tabelle enorm.

In diesen Fällen müssen wir feststellen, ob unerwünschte Pakete vorhanden sind, und diese Pakete löschen, um die sysssispackages zu behalten Tabellengröße unter Kontrolle.

Das Endergebnis

SQL Server verfügt nicht über integrierte Jobs, um die Aufgabe des Löschens in allen Tabellen zu bewältigen oben diskutiert. Trotzdem haben wir den ältesten Datumsparameter für alle oben genannten Verfahren verfügbar.

Daher der empfohlene Ansatz, um die MSDB-Tabellengröße unter Kontrolle zu halten wäre, einen Aufbewahrungszeitraum basierend auf der Anzahl der Tage zu definieren und einen neuen SQL Server-Agent-Auftrag zu erstellen, um das folgende Skript planmäßig auszuführen:

declare @retention_date datetime = '2021-04-01'
exec msdb.dbo.sp_delete_backuphistory @oldest_date = @retention_date;
exec msdb.dbo.sp_purge_jobhistory @oldest_date = @retention_date;
exec msdb.dbo.sp_maintplan_delete_log @oldest_Time = @retention_date;
exec msdb.dbo.sysmail_delete_mailitems_sp @sent_before = @retention_date;
exec msdb.dbo.sysmail_delete_log_sp @logged_before = @retention_date;

Schlussfolgerung

Wir haben von der Liste der Tabellen erfahren, die in der MSDB schneller wachsen können Datenbank und wie man die Größe dieser Tabellen unter Kontrolle hält. Wir haben ein praktisches Skript mit der Liste der regelmäßig auszuführenden Prozeduren abgeleitet, um die MSDB zu verhindern Datenbank wächst auch zu einer riesigen Größe. Ich hoffe, dass dieser Artikel für Ihre Automatisierung hilfreich ist und dass diese Informationen Sie von der Wartung der MSDB-Datenbank befreien und sich auf andere Aktivitäten konzentrieren können.