Bazy danych systemu SQL Server

W poprzednich artykułach z serii SQL Server System Databases omówiliśmy systemowe bazy danych, które są domyślnie instalowane podczas instalacji SQL Server, zrozumieliśmy przeznaczenie każdej z tych systemowych baz danych oraz bardziej szczegółowo zbadaliśmy bazę danych Tempdb i jej utrzymanie. W tym artykule omówimy bardziej szczegółowo bazę danych MSDB wraz z często napotykanymi problemami związanymi z bazą danych MSDB i sposobami ich rozwiązywania we właściwy sposób.

Baza danych MSDB

MSDB Baza danych systemu SQL Server przechowuje wszystkie krytyczne informacje o konfiguracji i informacje historyczne związane z usługą agenta SQL Server, brokerem usług SQL Server, pocztą bazy danych, przesyłaniem dzienników, dublowaniem bazy danych itp.:

Usługa agenta serwera SQL
- Zadania SQL Server Agent – dane konfiguracyjne i szczegóły historii
- Alerty agenta SQL Server – dane konfiguracyjne
- Operatorzy agentów serwera SQL — dane konfiguracyjne
- Proxy agenta SQL Server — dane konfiguracyjne
- Powiązane informacje
Poczta bazy danych SQL Server, w tym Service Broker — dane konfiguracyjne i historyczne szczegóły dziennika poczty.
Szczegóły tworzenia i przywracania kopii zapasowej SQL Server – dane historii wszystkich zdarzeń tworzenia kopii zapasowych i przywracania bazy danych, które mają miejsce w instancji SQL Server.
Plany konserwacji, pakiety SSIS i powiązane informacje — dane konfiguracyjne, powiązane dane i dane dotyczące wykonywania wszystkich tych elementów za pośrednictwem zadań agenta SQL Server.
Konfiguracje przesyłania dziennika, profile agenta replikacji, zadania kolektora danych — dane konfiguracyjne wszystkich wspomnianych technik wysokiej dostępności.

Za każdym razem, gdy którakolwiek z powyższych krytycznych konfiguracji zostanie zmodyfikowana, zaleca się wykonanie Pełnej kopia zapasowa bazy danych MSDB, aby uniknąć utraty danych w przypadku awarii.

Mimo że usługa SQL Server Agent Service przechowuje krytyczne szczegóły konfiguracji w tabelach w MSDB SQL Server przechowuje również kilka szczegółów konfiguracyjnych w rejestrze systemu Windows. W tym celu używa rozszerzonej procedury składowanej o nazwie sp_set_sqlagent_properties .

Rzućmy okiem na lokalizację rejestru, w której SQL Server przechowuje konfiguracje usługi SQL Server Agent Service. Ważne :Ta funkcja służy wyłącznie do celów edukacyjnych i nie zalecamy zmieniania żadnych wartości konfiguracyjnych. W przeciwnym razie może to skończyć się dziwnymi błędami związanymi z usługą SQL Server Agent Service.

Otwórz Edytor rejestru wpisując regedit w wierszu poleceń:

Kliknij Enter aby otworzyć Edytor rejestru :

Teraz przejdź do ścieżki:

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

Zobacz poniższe szczegóły konfiguracji. Zaznaczony fragment odnosi się do nazwy instancji SQL Server i może się różnić w Twoim środowisku w zależności od wersji SQL Server i nazwy instancji.

Szybkie spojrzenie na rejestr wskazuje, że są przechowywane pewne parametry związane z usługą SQL Server Agent Service. Ponieważ nie zalecamy zmiany żadnych parametrów związanych z usługą SQL Server Agent Service i udostępnionych powyżej tylko w celach edukacyjnych, nie będziemy się tutaj zagłębiać.

Jeśli jednak zamierzasz zmienić dowolne właściwości usługi SQL Server Agent Service w celu spełnienia wymagań biznesowych lub produkcyjnych, możesz je zmodyfikować, klikając prawym przyciskiem myszy usługę SQL Server Agent Service i wybierając Właściwości jak pokazano poniżej.

Mimo że dostępnych jest wiele parametrów związanych z usługą SQL Server Agent Service, a zakres tego artykułu dotyczy bazy danych msdb, pominąłem je i obejmowałem tylko opcje specyficzne dla bazy danych msdb, klikając menu Historia, jak pokazano poniżej, gdzie może skonfigurować rozmiar dzienników historii zadań i historii agentów.

Często napotykane problemy w bazie danych MSDB

W dowolnej instancji produkcyjnej SQL Server będziemy mieć włączone wiele zadań agenta SQL Server, wiadomości e-mail bazy danych, plany konserwacji i kopie zapasowe pełnych/transakcyjnych dzienników. W zależności od nie. baz danych w instancji lub nie. dostępnych zadań SQL Server Agent lub użycia poczty bazy danych, nasz SQL Server rozpocznie rejestrowanie informacji o historii wszystkich włączonych funkcji, zwiększając w ten sposób rozmiar MSDB Baza danych. Jeśli nie jest odpowiednio konserwowany, wpłynie to na wydajność bazy danych MSDB i operacje z tym związane.

Przejrzyjmy omówione wcześniej funkcje i tabele używane do przechowywania danych historycznych, aby zrozumieć, w jaki sposób możemy kontrolować rozmiar tych tabel.

Historia kopii zapasowych
Historia zadań SQL Server Agent
Plany konserwacji
Historia poczty bazy danych SQL Server
Pakiety SSIS

Aby dowiedzieć się, które tabele w bazie danych MSDB zajmują więcej miejsca, możemy skorzystać z raportu Wykorzystanie dysku przez najlepsze tabele który jest częścią domyślnego raportowania SQL Server w SQL Server Management Studio.

Otwórz SSMS i kliknij prawym przyciskiem myszy MSDB baza danych> Raporty > Raporty standardowe > Wykorzystanie dysku według najlepszych tabel aby wygenerować raport tabel posortowanych według użycia dysku:

Kliknij Wykorzystanie dysku według najlepszych tabel aby wyświetlić raport. Ponieważ moja instancja jest instancją rozwojową, nie ma dużych tabel, ale ten raport może pokazywać rozmiar wszystkich tabel w bazie danych posortowanych w kolejności malejącej.

Możemy również użyć poniższego zapytania, aby uzyskać rozmiary tabel w bazie danych.

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

Gdy już wiemy, które tabele zajmują więcej miejsca, możemy użyć powiązanych procedur składowanych, aby kontrolować ich rozmiar.

Historia kopii zapasowych

Podstawowym obowiązkiem administratora baz danych jest zapewnienie, że pełne kopie zapasowe i dzienniki transakcyjne są włączone we wszystkich instancjach produkcyjnych SQL Server w celu odzyskania baz danych do określonego momentu.

SQL Server przechowuje szczegóły kopii zapasowej i informacje o przywracaniu w następujących tabelach bazy danych MSDB :

plik kopii zapasowej
grupa plików kopii zapasowych
rodzina kopii zapasowych
zapasowy zestaw mediów
kopia zapasowa
przywróć plik
przywróćgrupęplików
historia przywracania

Dla znaczącego nie. baz danych w instancji SQL Server skonfigurowanych z pełnymi kopiami zapasowymi i kopiami zapasowymi dziennika transakcji, rekordy w powyższych tabelach mogą rosnąć szybciej.

W ten sposób SQL Server udostępnia dwie systemowe procedury składowane w bazie MSDB baza danych do kontrolowania rozmiaru powyższych tabel:

sp_delete_backuphistory – usuwa dane historii kopii zapasowych w powyższych 8 tabelach na podstawie najstarszej daty parametr.
sp_delete_database_backuphistory – usuwa dane historii kopii zapasowych w powyższych 8 tabelach na podstawie nazwy bazy danych .

Składnia wykonywania powyższych systemowych procedur składowanych:

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

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

Kiedy wykonujemy którąkolwiek z opisanych powyżej procedur składowanych w bazie danych zawierającej ogromne rekordy w tabelach historii kopii zapasowych, możemy zablokować lub zauważyć, że rekordy są usuwane bardzo powoli. Aby rozwiązać ten problem, tworzymy poniższy brakujący indeks w zestawie kopii zapasowej stół. Można go zidentyfikować za pomocą planu wykonania procedury składowanej, aby szybciej wykonać dowolną z naszych procedur składowanych.

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

Historia zadań SQL Server Agent

SQL Server przechowuje całą historię zadań agenta SQL Server w msdb.dbo.sysjobhistory stół. Ponadto SQL Server ma systemową procedurę składowaną o nazwie msdb.dbo.sp_purge_jobhistory która pomaga zachować sysjobhistory rozmiar stołu pod kontrolą.

Składnia uruchamiania sp_purge_jobhistory procedura składowana będzie:

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

Wszystkie 3 parametry są opcjonalne i zalecamy wykonanie powyższej procedury przez przekazanie oldest_date parametr aby zachować sysjobhistory rozmiar stołu pod kontrolą.

Plany konserwacji

SQL Server przechowuje szczegóły wszystkich planów konserwacji w poniższych tabelach:

msdb.dbo.sysmaintplan_log
msdb.dbo.sysmaintplan_logdetail

SQL Server ma wbudowaną procedurę składowaną o nazwie msdb.dbo.sp_maintplan_delete_log aby mieć pod kontrolą rozmiary tych 2 tabel.

Składnia do wykonania procedury będzie następująca:

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

Wszystkie 3 parametry są opcjonalne. Zalecamy wykonanie powyższej procedury z przekazaniem parametru old_time, aby utrzymać pod kontrolą rozmiar powyższych dwóch tabel.

Historia poczty bazy danych SQL Server

SQL Server przechowuje wszystkie dzienniki historii poczty bazy danych w poniższych tabelach:

sysmail_mailitems
sysmail_log
sysmail_attachments
sysmail_attachments_transfer

Aby utrzymać te rozmiary tabel historii pod kontrolą, SQL Server oferuje 2 systemowe procedury składowane o nazwie msdb.dbo.sysmail_delete_mailitems_sp i msdb.dbo.sysmail_delete_log_sp.

Składnia do wykonania tych procedur składowanych będzie następująca:

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

W przypadku obu procedur wszystkie parametry są opcjonalne. Zaleca się jednak użycie sent_before lub zalogowany_przed e parametry do usuwania starszych rekordów na podstawie okresu przechowywania.

W kilku scenariuszach, jeśli wszystkie tabele związane z pocztą bazy danych są ogromne, uruchom usuń procedura będzie działać na zawsze. Szybszym sposobem rozwiązania tego problemu jest usunięcie ograniczenia klucza obcego w sysmail_attachments i sysmail_send_retries tabele, skróć powyższe 4 tabele i ponownie utwórz 2 klucze obce w sysmail_attachments i sysmail_send_retries stoły jak pokazano poniżej:

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

Pakiety SSIS

SQL Server przechowuje wszystkie SSIS(*.dtsx) pakiety w msdb.dbo.sysssispackages stół. Ta tabela jest tabelą konfiguracji, jednak w losowych przypadkach istnieje duże prawdopodobieństwo, że zrzucono na nią wiele pakietów SSIS. Powoduje to, że rozmiar tego stołu staje się ogromny.

W takich przypadkach musimy określić, czy są jakieś niechciane pakiety i usunąć te pakiety, aby zachować sysssispackages rozmiar stołu pod kontrolą.

Dolna linia

SQL Server nie ma wbudowanych zadań do obsługi zadania usuwania we wszystkich tabelach omówione powyżej. Mimo to mamy najstarszy parametr daty dostępne dla wszystkich powyższych procedur.

Dlatego zalecane podejście do kontrolowania rozmiaru tabeli MSDB byłoby zdefiniowanie okresu przechowywania na podstawie liczby dni i utworzenie nowego zadania agenta SQL Server w celu wykonania poniższego skryptu zgodnie z harmonogramem:

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;

Wniosek

Dowiedzieliśmy się o liście tabel, które mogą rosnąć szybciej w MSDB bazy danych i jak kontrolować rozmiar tych tabel. Opracowaliśmy przydatny skrypt z listą procedur do regularnego wykonywania, aby zapobiec MSDB baza danych również rośnie do ogromnych rozmiarów. Mam nadzieję, że ten artykuł będzie pomocny dla Twojej automatyzacji, a te informacje uwolnią Twój umysł od konserwacji bazy danych MSDB i skoncentrują się na innych czynnościach.

Bazy danych systemu SQL Server – Konserwacja MSDB