Системни бази данни на SQL Server

В предишните статии от серията системни бази данни на SQL Server ние преминахме през системните бази данни, които се инсталират по подразбиране по време на инсталацията на SQL Server, разбрахме целта на всяка от тези системни бази данни и проучихме базата данни Tempdb и нейната поддръжка по-подробно. В тази статия ще разгледаме базата данни MSDB по-подробно, заедно с често срещаните проблеми около базата данни MSDB и как да ги разрешим по правилния начин.

База данни MSDB

MSDB Системната база данни на SQL Server съхранява цялата критична информация за конфигурацията и историческа информация, свързана с SQL Server Agent Service, SQL Server Service Broker, Database Mail, Log Shipping, Database Mirroring и др.:

Услуга за агент на SQL Server
- Задачи на агент на SQL Server – Данни за конфигурацията и подробности за историята
- Сигнали за агент на SQL Server – Конфигурационни данни
- Агентни оператори на SQL Server – Конфигурационни данни
- Прокси сървъри на SQL Server – Конфигурационни данни
- Свързана информация
Поща с база данни на SQL Server, включително Service Broker – Конфигурационни данни и исторически регистрационни данни за поща.
Подробности за архивиране и възстановяване на SQL Server – Данни за историята на всички събития за архивиране и възстановяване на база данни, случващи се в екземпляр на SQL Server.
Планове за поддръжка, SSIS пакети и свързана информация – Данни за конфигурацията, свързани данни и данните за изпълнението на всички тези елементи чрез задания на агент на SQL Server.
Конфигурации за доставка на регистрационни файлове, профили на агент за репликация, задачи за събиране на данни – Данни за конфигурацията на всички споменати техники за висока достъпност.

Всеки път, когато някоя от горните критични конфигурации бъде променена, се препоръчва да направите Пълен архивиране на базата данни MSDB, за да се избегне загуба на данни, ако възникне повреда.

Въпреки че SQL Server Agent Service съхранява важни подробности за конфигурацията в таблици в MSDB база данни, SQL Server също така съхранява няколко подробности за конфигурацията в системния регистър на Windows. За това той използва разширената съхранена процедура с име sp_set_sqlagent_properties .

Нека разгледаме бързо местоположението на системния регистър, където SQL Server съхранява конфигурации на SQL Server Agent Service. Важно :Това е само за учебни цели и не препоръчваме промяна на стойности на конфигурацията. В противен случай може да се стигне до странни грешки, свързани с услугата за агент на SQL Server.

Отворете Редактора на системния регистър като напишете regedit в командния ред:

Щракнете върху Enter за да отворите Редактора на системния регистър :

Сега отидете до пътя:

Компютър\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL13.MSSQLSERVER\SQLServerAgent

Вижте подробностите за конфигурацията по-долу. Маркираният фрагмент се отнася до името на екземпляра на SQL Server и може да варира във вашата среда в зависимост от версията на SQL Server и името на екземпляра.

Бърз преглед на регистъра показва, че има съхранени определени параметри, свързани с услугата за агент на SQL Server. Тъй като не препоръчваме промяна на параметри, свързани с услугата SQL Server Agent и споделени по-горе само за учебни цели, тук няма да се гмуркаме дълбоко в това.

Въпреки това, ако възнамерявате да промените някое от свойствата на SQL Server Agent Service, за да отговаря на изискванията за бизнес или производство, тогава можете да го промените, като щракнете с десния бутон върху услугата SQL Server Agent и изберете Properties както е показано по-долу.

Въпреки че има много налични параметри, свързани с SQL Server Agent Service и обхватът на тази статия е свързан с базата данни msdb, аз ги изключих и обхващах само опциите, специфични за базата данни msdb, като щракнете върху менюто История, както е показано по-долу, където ние може да конфигурира размера на регистрите на хронологията на заданията и историята на агента.

Често срещани проблеми в базата данни MSDB

Във всеки производствен екземпляр на SQL Server ще имаме активирани много работни места за агенти на SQL Server, имейли за база данни, планове за поддръжка и пълно/транзакционно архивиране на регистрационни файлове. В зависимост от бр. на бази данни в инстанцията или бр. от налични работни места за агент на SQL Server или използване на поща на база данни, нашият SQL Server ще започне да регистрира хронологията на всички активирани функции, като по този начин увеличава размера на MSDB база данни. Ако не се поддържа правилно, това ще повлияе на производителността на базата данни MSDB и операциите, свързани с това.

Нека прегледаме функциите, обсъдени по-рано, и таблиците, използвани за съхраняване на исторически данни, за да разберем как можем да поддържаме размера на тези таблици под контрол.

История на архивиране
История на заданията на агент на SQL сървър
Планове за поддръжка
SQL Server Database Mail History
SSIS пакети

За да разберем кои таблици в базата данни MSDB заемат повече място, можем да използваме Отчетите за използване на диска от най-добрите таблици който идва като част от отчитането по подразбиране на SQL Server в SQL Server Management Studio.

Отворете SSMS и щракнете с десния бутон върху MSDB база данни> Отчети > Стандартни отчети > Използване на диска по топ таблици за генериране на отчет за таблици, сортирани по използване на диск:

Щракнете върху Използване на диска по топ таблици за да видите отчета. Тъй като моят екземпляр е такъв за разработка, няма огромни таблици, но този отчет може да покаже размера на всички таблици в база данни, сортирани в низходящ ред.

Можем също да използваме заявката по-долу, за да получим размерите на таблиците в база данни.

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

След като разберем кои таблици заемат повече място, можем да използваме свързаните съхранени процедури, за да поддържаме размера им под контрол.

История на архивиране

Основната отговорност на DBA е да гарантира, че пълните архиви и регистрационните файлове на транзакциите са активирани във всички производствени екземпляри на SQL Server за възстановяване на базите данни до определен момент.

SQL Server съхранява данните за архивиране и информацията за възстановяване в следните таблици на базата данни MSDB :

резервно копие
backupfilegroup
backupmediafamily
backupmediaset
резервно копие
файл за възстановяване
restorefilegroup
история на възстановяване

За значително не. от бази данни в екземпляра на SQL Server, конфигуриран с Пълно архивиране и архивиране на регистрационни файлове на транзакциите, записите в горните таблици могат да се увеличат по-бързо.

По този начин SQL Server предоставя две системни съхранени процедури в MSDB база данни, за да контролирате размера на горните таблици:

sp_delete_backuphistory – изтрива данните от историята на архивирането в горните 8 таблици въз основа на най-старата дата параметър.
sp_delete_database_backuphistory – изтрива данните от историята на архивирането в горните 8 таблици въз основа на името на базата данни .

Синтаксисът за изпълнение на горните системни съхранени процедури:

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

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

Когато изпълним някоя от съхранените процедури, описани по-горе, в база данни, съдържаща огромни записи в таблиците с хронология на архивиране, може да получим блокиране или да забележим, че записите се изтриват много бавно. За да разрешим този проблем, създаваме по-долу липсващ индекс на резервния набор маса. Може да се идентифицира чрез плана за изпълнение на съхранената процедура, за да изпълни някоя от нашите съхранени процедури по-бързо.

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

История на заданията на агент на SQL сървър

SQL Server съхранява цялата история на заданията на агент на SQL Server в msdb.dbo.sysjobhistory маса. Също така, SQL Server има системна съхранена процедура с име msdb.dbo.sp_purge_jobhistory което помага за запазване на sysjobhistory размерът на таблицата е под контрол.

Синтаксисът за стартиране на sp_purge_jobhistory съхранената процедура ще бъде:

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

Всичките 3 параметъра са по избор и бихме препоръчали да изпълните горната процедура, като подадете най-старата_дата параметър за да запазите sysjobhistory размерът на таблицата е под контрол.

Планове за поддръжка

SQL Server съхранява подробностите за всички планове за поддръжка в таблиците по-долу:

msdb.dbo.sysmaintplan_log
msdb.dbo.sysmaintplan_logdetail

SQL Server има вградена съхранена процедура с име msdb.dbo.sp_maintplan_delete_log за да държите под контрол размерите на тези 2 таблици.

Синтаксисът за изпълнение на процедурата ще бъде:

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

Всичките 3 параметъра са по избор. Препоръчваме ви да изпълните горната процедура, като подадете параметъра oldest_time, за да запазите размера на горните две таблици под контрол.

SQL Server Database Mail History

SQL Server съхранява всички дневници на хронологията на Database Mail в следните таблици:

sysmail_mailitems
sysmail_log
sysmail_attachments
sysmail_attachments_transfer

За да поддържа тези размери на таблиците за история под контрол, SQL Server предлага 2 системни съхранени процедури с име msdb.dbo.sysmail_delete_mailitems_sp и msdb.dbo.sysmail_delete_log_sp.

Синтаксисът за изпълнение на тези съхранени процедури ще бъде:

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

И за двете процедури всички параметри са по избор. Препоръчително е обаче да използвате sent_before или влезли_преди д параметри за изтриване на по-старите записи въз основа на периода на съхранение.

В няколко сценария, ако всички таблици, свързани с Database Mail са огромни, се изпълнява delete процедура ще работи завинаги. По-бърз начин за справяне с проблема е да изтриете ограничението за външния ключ на sysmail_attachments и sysmail_send_retries таблици, съкратете горните 4 таблици и създайте отново 2-та външни ключа в sysmail_attachments и sysmail_send_retries маси както е показано по-долу:

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 пакети

SQL Server съхранява всички SSIS(*.dtsx) пакети в msdb.dbo.sysssispackages маса. Тази таблица е конфигурационна таблица, но в случайни случаи има вероятност да има много SSIS пакети, изхвърлени върху таблицата. Това води до увеличаване на размера на тази таблица.

В тези случаи трябва да установим дали има нежелани пакети и да изтрием тези пакети, за да запазим sysssispackages размерът на таблицата е под контрол.

Изводът

SQL Server няма вградени задачи за справяне със задачата за изтриване във всички таблици обсъдено по-горе. Все пак имаме най-стария параметър за дата достъпни за всички горепосочени процедури.

Следователно, препоръчителният подход за управление на размера на MSDB таблица под контрол би било да се дефинира период на задържане въз основа на броя дни и да се създаде нова задача на SQL Server Agent, за да се изпълни скриптът по-долу по график:

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;

Заключение

Научихме за списъка с таблици, които могат да растат по-бързо в MSDB база данни и как да поддържате размера на тези таблици под контрол. Изведохме удобен скрипт със списъка с процедури, които да изпълняваме редовно, за да предотвратим MSDB базата данни също нараства до огромен размер. Надяваме се, че тази статия ще бъде полезна за вашата автоматизация и тази информация ще освободи ума ви от поддръжката на базата данни MSDB и ще се съсредоточи върху други дейности.

Системни бази данни на SQL Server – Поддръжка на MSDB