MSDB е системна база данни, използвана от SQL Server. MSDB съхранява всякакви данни, като хронология на архивиране и възстановяване, история на заданията на SQL агент, хронология на мониторинга на доставката на дневници, SSIS пакети, данни от съветника за настройка на Database Engine и данни за опашката на Service Broker. Точно като потребителските бази данни, msdb се нуждае от редовна поддръжка, включително оптимизации на индекси и, което е по-важно, редовно прочистване.
Архивиране и възстановяване на историята
По подразбиране няма метод за изчистване или изтриване на историята на архивиране и възстановяване от msdb. Пази се завинаги, докато не настроите ръчен или автоматизиран процес за изтриване на данните. Ако не изчистите тези данни, msdb ще продължи да расте, което означава, че четенето и записването в тези таблици може да стане по-бавно и да повлияе на скоростта на вашите задачи за архивиране.
Повечето инструменти на трети страни и реномирани решения за поддръжка включват процеси за изчистване на историята на архивиране и възстановяване, за да се предотврати това да се превърне в проблем. Лесен начин да разберете дали почиствате историята на архивирането или не е да потърсите директно msdb:
SELECT CONVERT(CHAR(100), SERVERPROPERTY('Servername')) КАТО сървър, msdb.dbo.backupset.database_name, msdb.dbo.backupset.backup_finish_date, CASE msdb..backupset.type WHEN 'D' THEN База данни' КОГАТО 'L' THEN 'Log' END КАТО backup_typeFROM msdb.dbo.backupmediafamilyINNER JOIN msdb.dbo.backupset ON msdb.dbo.backupmediafamily.media_set_id =msdb.dbo.backupset.media_set.damsdb. /предварително>
Ако имате история на архивиране или възстановяване, датираща повече от 90 дни, тогава трябва да проучите дали има регулаторно изискване, което изисква да съхранявате историческата информация за тези архиви за определен период. Ако няма изискване, тогава трябва да помислите за изчистване на данни, по-стари от определен период от време. Архивната история не е необходима, за да възстановите вашите бази данни и ние препоръчваме да я почиствате редовно, за да поддържате msdb в разумен размер. Запазването на 90 дни или по-малко е диапазонът, който обикновено препоръчвам на клиентите.
За да настроите процес за изчистване на историята на архивирането и възстановяването, създайте задание, което изпълнява sp_delete_backuphistory съхранена процедура в msdb и й предайте параметър за дата. Съхранената процедура ще изтрие цялата история на архивиране и възстановяване, по-стара от датата, която сте посочили. Можете също да създадете план за поддръжка на база данни и да използвате задачата за почистване на хронологията.
Съветник за настройка на базата данни
Database Engine Tuning Advisor, известен също като DTA, е инструмент, който разработчиците и администраторите на бази данни могат да използват, за да помогнат при настройването на база данни. DTA използва базата данни msdb за съхраняване на хронология на настройките и други поддържащи обекти.
Рутинно намирам остатъци от DTA в msdb на производствените сървъри на клиентите. Когато намеря тези таблици, ги питам директно, за да определя дали DTA все още се използва. За щастие, все още не съм намерил клиент, който активно изпълнява DTA срещу производството, тъй като това може значително да повлияе на производителността. След като потвърдя и комуникирам с клиента, пускам DTA таблиците от msdb. В някои случаи това освобождава няколко гигабайта пространство. Като предпазна мярка също отделям време да обясня въздействието върху производителността, което изпълнението на DTA срещу производството може да причини и насърчавам клиентите си, че всяка бъдеща употреба трябва да се извършва на сървър за разработка.
Агент на SQL сървър
Понякога ще намеря клиент, който по невнимание е премахнал отметката от квадратчето, за да ограничи размера на дневника на историята на заданията. Това е лесна грешка, която можете да направите, ако имате зает сървър и регистрационният файл продължава да се преобръща толкова бързо, че нямате полезна история на заданията, за да направите справка при отстраняване на неизправности на задания на SQL Server Agent. По-добър подход е да увеличите максималния размер на дневника на историята на заданията (в редове) до много по-висока стойност, вместо да го оставите да расте неограничено.
В случаите, когато клиентите са имали неограничен растеж на работните места, таблицата на sysjobhistory е нараснала прекалено голяма и трябва да бъде прочистена. Най-добрият начин да изчистите историята е да използвате sp_purge_jobhistory и предайте параметър за дата. Съхранената процедура ще изтрие цялата история на заданията, по-стара от предоставената от вас дата. Ако трябва да съхранявате минимален брой дни история на агента на SQL Server, ограничаването на дневника на хронологията на заданията въз основа на редове не е ефективно. Вместо това, не ограничавайте размера на дневника на хронологията на заданията и също така насрочете задание, което ще изпълнява sp_purge_jobhistory и ще предаде параметър за дата за минималния брой дни на хронологията на заданията, от които се нуждаете. Обичайно е да се използва стойност от 14 или 30 дни.
Брокер на услуги
Наскоро срещнах проблем с клиент, при който msdb нарасна до 14GB. След опит за актуализиране на екземпляра до текущ сервизен пакет, надстройката не успя да приложи скриптовете към msdb и накара msdb да нарасне отново експоненциално. След известно проучване открихме, че Service Broker е активиран за известия за събития, но не е правилно конфигуриран. Повече от година известията за събития бяха на опашка, но не бяха пренасочени.
При проверката на sys.transmission_queue установих, че посредникът на услугите в целевата база данни е недостъпен и брокерът на услуги е административно деактивиран. След това проверих какви известия за събития са настроени чрез запитване към sys.server_events_notifications и открих само един запис:улавяне на всички събития в регистъра за грешки. След това попитах sys.transmissions_queue, за да видя колко събития са в опашката и намерих няколко милиона записа там.
След като обсъдихме това с клиента и обяснихме констатациите, ние се съгласихме, че най-добрият начин на действие е да премахнем известието за събитие и да изчистим текущата опашка чрез създаване на нов брокер. За да направя това, изпълних ALTER DATABASE msdb SET NEW_BROKER. Това беше направено след часове и след добро пълно архивиране на msdb.
След изчистване на transfer_queue и премахване на събитието успях да намаля msdb от 14GB на 300MB. Преди да коригира този проблем, базата данни msdb имаше най-голямо забавяне на диска в екземпляра и клиентът изпитваше редовни блокирания. След прилагането на тази промяна, както и други оптимизации, потребителското изживяване на клиента значително се подобри.
Изпращане на дневници
В началото на кариерата си в DBA наследих сървър за консолидиране, който имаше няколкостотин бази данни, които бяха изпратени в лог към вторичен сървър в друг център за данни. Този сървър работеше и работеше от няколко години и изпращаше регистрационните файлове на всеки 15 минути. Този екземпляр не само страда от неизчистване на архивната история, но и не изчиства правилно историята на монитора за доставка на журнали. След като изчистих историята на архивирането и проверих размера на msdb, той все още показваше повече използвано пространство, отколкото трябва. Пуснах скрипт, за да ми покаже общия размер на всяка таблица и открих, че log_shipping_monitor_history_detail масата беше много голяма. В този случай успях да стартирам sp_cleanup_log_shipping_history за да изчистите историята и да върнете msdb до нормален размер.
Индексиране
Оптимизирането на индекси в msdb е също толкова важно, колкото и вашите потребителски бази данни. Много пъти съм намирал клиенти, които оптимизират потребителските бази данни, но не и системните бази данни. Тъй като базата данни msdb се използва силно от SQL Server Agent, Log Shipping, Service Broker, SSIS, архивиране и възстановяване и други процеси, индексите могат да бъдат силно фрагментирани. Уверете се, че вашите задачи за оптимизация на индекси включват и вашите системни бази данни или поне msdb. Виждал съм оптимизациите на индекси да освобождават няколко гигабайта пространство от силно фрагментирани индекси в msdb.
Резюме
Пренебрегването на msdb може да повлияе негативно на производителността на вашата среда. От решаващо значение е да наблюдавате размера на msdb, както и процесите, които го използват, за да гарантирате, че той работи оптимално. Историята на архивиране и възстановяване е най-честата причина за раздуване на базата данни msdb, но съветникът за настройка на Database Engine, историята на агента на SQL Server, брокера на услугите, доставката на регистрационни файлове и липсата на поддръжка на индекси могат да допринесат за прекомерен растеж на msdb и да повлияят на производителността на базата данни.
