MSDB to systemowa baza danych używana przez SQL Server. MSDB przechowuje wszelkiego rodzaju dane, takie jak historia tworzenia kopii zapasowych i przywracania, historia zadań agenta SQL, historia monitora wysyłania dziennika, pakiety SSIS, dane Doradcy dostrajania aparatu bazy danych i dane kolejki Service Broker. Podobnie jak bazy danych użytkowników, msdb wymaga regularnej konserwacji, w tym optymalizacji indeksów i, co ważniejsze, regularnego czyszczenia.
Historia tworzenia kopii zapasowych i przywracania
Domyślnie nie ma metody usuwania lub usuwania kopii zapasowych i przywracania historii z msdb. Są przechowywane na zawsze, dopóki nie skonfigurujesz ręcznego lub zautomatyzowanego procesu usuwania danych. Bez usuwania tych danych msdb będzie nadal rósł, co oznacza, że odczytywanie i zapisywanie w tych tabelach może stać się wolniejsze i wpłynąć na szybkość zadań tworzenia kopii zapasowych.
Większość narzędzi innych firm i renomowanych rozwiązań do konserwacji obejmuje procesy usuwania historii kopii zapasowych i przywracania, aby zapobiec problemowi. Łatwym sposobem sprawdzenia, czy usuwasz historię kopii zapasowych, czy nie, jest bezpośrednie zapytanie 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 ' Baza danych' KIEDY 'L' THEN 'Log' KONIEC JAKO backup_typeFROM msdb.dbo.backupmediafamilyINNER DOŁĄCZ msdb.dbo.backupset ON msdb.dbo.backupmediafamily.media_set_id =msdb.dbo.backupset.media_set_idZAMÓWIENIE WG msdb.dbo.backupset_.backup; /pre>
Jeśli masz historię tworzenia kopii zapasowych lub przywracania danych sprzed ponad 90 dni, należy sprawdzić, czy istnieje wymóg prawny nakazujący przechowywanie informacji historycznych o tych kopiach zapasowych przez określony czas. Jeśli nie ma takiego wymagania, należy rozważyć wyczyszczenie danych starszych niż określony okres czasu. Historia kopii zapasowej nie jest potrzebna do przywrócenia baz danych i zalecamy regularne jej czyszczenie, aby zachować rozsądny rozmiar msdb. Przechowywanie 90 dni lub mniej to zakres, który zazwyczaj polecam klientom.
Aby skonfigurować proces czyszczenia kopii zapasowej i historii przywracania, utwórz zadanie, które wykonuje sp_delete_backuphistory procedura składowana w msdb i przekaż jej parametr daty. Procedura składowana usunie całą historię tworzenia kopii zapasowych i przywracania starszą niż podana data. Można również utworzyć plan konserwacji bazy danych i użyć zadania Oczyszczanie historii.
Doradca dostrajania silnika bazy danych
Doradca dostrajania aparatu bazy danych, znany również jako DTA, to narzędzie, którego deweloperzy i administratorzy bazy danych mogą używać do dostrajania bazy danych. DTA wykorzystuje bazę danych msdb do przechowywania historii strojenia i innych obiektów pomocniczych.
Rutynowo znajduję pozostałości DTA w msdb na serwerach produkcyjnych klientów. Kiedy znajduję te tabele, wysyłam do nich bezpośrednio zapytanie, aby określić, czy DTA jest nadal używane. Na szczęście nie udało mi się jeszcze znaleźć klienta, który aktywnie używa DTA przeciwko produkcji, ponieważ może to znacząco wpłynąć na wydajność. Po potwierdzeniu i komunikacji z klientem usuwam tabele DTA z msdb. W niektórych przypadkach zwalnia to wiele gigabajtów miejsca. Na wszelki wypadek poświęcam również czas, aby wyjaśnić wpływ na wydajność, jaki może powodować uruchamianie DTA w środowisku produkcyjnym, i zachęcić moich klientów, aby jakiekolwiek przyszłe użycie odbywało się na serwerze programistycznym.
Agent serwera SQL
Czasami znajdę klienta, który nieumyślnie odznaczył pole, aby ograniczyć rozmiar dziennika historii pracy. Jest to łatwy błąd do popełnienia, jeśli masz zajęty serwer, a dziennik jest tak szybko przewijany, że nie masz żadnej przydatnej historii zadań, do której można się odnieść podczas rozwiązywania problemów z zadaniami SQL Server Agent. Lepszym podejściem jest zwiększenie maksymalnego rozmiaru dziennika historii zadań (w wierszach) do znacznie wyższej wartości, zamiast pozostawiania go w sposób nieograniczony.
W przypadkach, w których klienci mieli nieograniczony wzrost liczby miejsc pracy, tabela sysjobhistory rozrosła się nadmiernie i należało ją wyczyścić. Najlepszym sposobem na wyczyszczenie historii jest użycie sp_purge_jobhistory i przekaż parametr daty. Procedura składowana usunie całą historię zadań starszą niż podana przez Ciebie data. Jeśli musisz zachować minimalną liczbę dni historii agenta programu SQL Server, ograniczenie dziennika historii zadań na podstawie wierszy nie jest skuteczne. Zamiast tego nie ograniczaj rozmiaru dziennika historii zadań, a także zaplanuj zadanie, które będzie uruchamiać sp_purge_jobhistory i przekazywać parametr daty dla minimalnej liczby dni historii zadań, które są potrzebne. Często używa się wartości 14 lub 30 dni.
Broker usług
Ostatnio napotkałem problem z klientem, w którym msdb rozrósł się do 14 GB. Po próbie zaktualizowania wystąpienia do bieżącego dodatku Service Pack uaktualnienie nie powiodło się, stosując skrypty do msdb i spowodowało ponowne wykładniczy wzrost msdb. Po kilku badaniach odkryliśmy, że Service Broker był włączony dla powiadomień o zdarzeniach, ale nie był poprawnie skonfigurowany. Przez ponad rok powiadomienia o zdarzeniach były ustawiane w kolejce, ale nie były kierowane.
Podczas sprawdzania sys.transmission_queue stwierdziłem, że broker usług w docelowej bazie danych był niedostępny, a broker usług został administracyjnie wyłączony. Następnie sprawdziłem, jakie powiadomienia o zdarzeniach zostały skonfigurowane, odpytując sys.server_events_notifications i znalazłem tylko jeden wpis:przechwyć wszystkie zdarzenia dziennika błędów. Następnie zapytałem sys.transmissions_queue, aby zobaczyć, ile zdarzeń jest w kolejce i znalazłem tam kilka milionów rekordów.
Po omówieniu tego z klientem i wyjaśnieniu ustaleń ustaliliśmy, że najlepszym sposobem działania jest usunięcie powiadomienia o zdarzeniu i wyczyszczenie bieżącej kolejki poprzez utworzenie nowego brokera. W tym celu wykonałem ALTER DATABASE msdb SET NEW_BROKER. Zostało to zrobione po godzinach i po dobrej pełnej kopii zapasowej msdb.
Po wyczyszczeniu kolejki transmission_queue i usunięciu zdarzenia udało mi się zmniejszyć msdb z 14 GB do 300 MB. Przed naprawieniem tego problemu baza danych msdb miała największe opóźnienie dysku w wystąpieniu, a klient doświadczał regularnych zakleszczeń. Po wdrożeniu tej zmiany, a także innych optymalizacji, doświadczenie użytkownika klienta znacznie się poprawiło.
Wysyłka dziennika
Na początku mojej kariery DBA odziedziczyłem serwer konsolidacyjny, który miał kilkaset baz danych, które były przesyłane w dzienniku na serwer pomocniczy w innym centrum danych. Ten serwer działał od kilku lat i wysyłał logi co 15 minut. Ta instancja nie tylko ucierpiała z powodu braku wyczyszczenia historii kopii zapasowych, ale także nie wyczyściła prawidłowo historii monitora Log Shipping. Kiedy wyczyściłem historię kopii zapasowych i sprawdziłem rozmiar msdb, nadal pokazywało więcej używanego miejsca niż powinno. Uruchomiłem skrypt, który pokazał mi całkowity rozmiar każdej tabeli i stwierdziłem, że log_shipping_monitor_history_detail stół był bardzo duży. W tym przypadku udało mi się uruchomić sp_cleanup_log_shipping_history aby wyczyścić historię i przywrócić msdb do normalnego rozmiaru.
Indeksowanie
Optymalizacja indeksów w msdb jest tak samo ważna jak bazy danych użytkowników. Wielokrotnie spotykałem klientów, którzy optymalizują bazy danych użytkowników, ale nie bazy systemowe. Ponieważ baza danych msdb jest intensywnie wykorzystywana przez agenta SQL Server, Log Shipping, Service Broker, SSIS, tworzenie kopii zapasowych i przywracanie oraz inne procesy, indeksy mogą być bardzo pofragmentowane. Upewnij się, że zadania optymalizacji indeksu obejmują również bazy danych systemu lub przynajmniej msdb. Widziałem, jak optymalizacje indeksów zwalniają kilka gigabajtów miejsca z mocno pofragmentowanych indeksów w msdb.
Podsumowanie
Zaniedbanie msdb może negatywnie wpłynąć na wydajność środowiska. Monitorowanie rozmiaru msdb, a także procesów, które z niego korzystają, ma kluczowe znaczenie, aby zapewnić jego optymalne działanie. Historia tworzenia kopii zapasowych i przywracania jest najczęstszą przyczyną rozrostu bazy danych msdb, jednak Doradca dostrajania aparatu bazy danych, historia agenta SQL Server, broker usług, przesyłanie dzienników i brak konserwacji indeksu mogą przyczynić się do nadmiernego wzrostu msdb i wpłynąć na wydajność bazy danych.
