Sqlserver
 sql >> Base de Dados >  >> RDS >> Sqlserver

Bancos de dados do sistema SQL Server – Manutenção do MSDB


Nos artigos anteriores da série Bancos de Dados do Sistema SQL Server, passamos pelos Bancos de Dados do Sistema que são instalados por padrão durante a Instalação do SQL Server, entendemos o propósito de cada um desses bancos de dados do sistema e exploramos o banco de dados Tempdb e sua manutenção com mais detalhes. Neste artigo, exploraremos o banco de dados MSDB com mais detalhes, juntamente com os problemas enfrentados com frequência em torno do banco de dados MSDB e como resolvê-los da maneira correta.

O banco de dados MSDB


O MSDB O banco de dados do sistema SQL Server armazena todas as informações críticas de configuração e informações históricas relacionadas ao SQL Server Agent Service, SQL Server Service Broker, Database Mail, Log Shipping, Database Mirroring, etc.:
  • Serviço do SQL Server Agent
    • Trabalhos do SQL Server Agent – ​​dados de configuração e detalhes do histórico
    • Alertas do SQL Server Agent – ​​Dados de configuração
    • Operadores do SQL Server Agent – ​​Dados de configuração
    • Proxies do SQL Server Agent – ​​Dados de configuração
    • Informações relacionadas
  • SQL Server Database Mail, incluindo Service Broker – dados de configuração e detalhes históricos do log de email.
  • Detalhes do Backup e Restauração do SQL Server – Dados do histórico de todos os eventos de Backup e Restauração do Banco de Dados que ocorrem na instância do SQL Server.
  • Planos de manutenção, pacotes SSIS e informações relacionadas – dados de configuração, dados relacionados e dados sobre a execução de todos esses itens por meio de trabalhos do SQL Server Agent.
  • Configurações de envio de log, perfis de agente de replicação, trabalhos de coletor de dados – dados de configuração de todas as técnicas de alta disponibilidade mencionadas.

Sempre que qualquer uma das configurações críticas acima for modificada, é recomendável fazer um teste Completo backup do banco de dados MSDB para evitar qualquer perda de dados se ocorrer uma falha.

Embora o SQL Server Agent Service armazene detalhes de configuração críticos em tabelas no MSDB banco de dados, o SQL Server também armazena alguns detalhes de configuração no Registro do Windows. Para isso, ele usa o procedimento armazenado estendido chamado sp_set_sqlagent_properties .

Vamos dar uma olhada rápida no local do Registro onde o SQL Server armazena as configurações do SQL Server Agent Service. Importante :isso é apenas para fins de aprendizado e não recomendamos alterar nenhum valor de configuração. Caso contrário, pode acabar em erros estranhos relacionados ao SQL Server Agent Service.

Abra o Editor de Registro digitando regedit no prompt de comando:

Clique em Entrar para abrir o Editor do Registro :

Agora, navegue até o caminho:

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

Veja os detalhes de configuração abaixo. O fragmento marcado refere-se ao nome da instância do SQL Server e pode variar em seu ambiente com base na versão do SQL Server e no nome da instância.

Uma rápida olhada no registro indica que há determinados parâmetros relacionados ao SQL Server Agent Service armazenados. Como não recomendamos alterar nenhum parâmetro relacionado ao SQL Server Agent Service e compartilhado acima apenas para fins de aprendizado, não nos aprofundaremos aqui.

No entanto, se você pretende alterar qualquer uma das propriedades do SQL Server Agent Service para atender aos requisitos comerciais ou de produção, poderá modificá-la clicando com o botão direito do mouse no SQL Server Agent Service e escolhendo Propriedades como mostrado abaixo.

Embora existam muitos parâmetros disponíveis relacionados ao SQL Server Agent Service e o escopo deste artigo esteja relacionado ao banco de dados msdb, eu os excluí e cobri apenas as opções específicas do banco de dados msdb clicando no menu Histórico, conforme mostrado abaixo, onde pode configurar o tamanho dos logs do histórico de trabalhos e do histórico do agente.

Problemas frequentes no banco de dados MSDB


Em qualquer instância de produção do SQL Server, teremos muitos trabalhos do SQL Server Agent, emails de banco de dados, planos de manutenção e backups de log completo/transacional habilitados. Dependendo do nº. de bancos de dados na instância ou o no. dos trabalhos do SQL Server Agent disponíveis ou do uso do Database Mail, nosso SQL Server começará a registrar as informações do histórico de todos os recursos habilitados, aumentando assim o tamanho do MSDB base de dados. Se não for mantido adequadamente, isso afetará o desempenho do banco de dados MSDB e as operações relacionadas a ele.

Vamos revisar os recursos discutidos anteriormente e as tabelas usadas para armazenar dados de histórico para entender como podemos manter o tamanho dessas tabelas sob controle.
  • Histórico de backup
  • Histórico de trabalhos do SQL Server Agent
  • Planos de manutenção
  • Histórico do SQL Server Database Mail
  • Pacotes SSIS

Para descobrir quais tabelas no banco de dados MSDB ocupam mais espaço, podemos usar os relatórios Uso de disco por tabelas principais que vem como parte do relatório padrão do SQL Server no SQL Server Management Studio.

Abra o SSMS e clique com o botão direito do mouse em MSDB banco de dados> Relatórios > Relatórios padrão > Uso do disco pelas principais tabelas para gerar o relatório de tabelas ordenadas por Disk Usage:

Clique em Uso do disco pelas principais tabelas para visualizar o relatório. Como minha instância é de desenvolvimento, não há tabelas enormes, mas este relatório pode mostrar o tamanho de todas as tabelas em um banco de dados classificado em ordem decrescente.

Também podemos usar a consulta abaixo para obter os tamanhos das tabelas em um banco de dados.
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

Assim que soubermos quais tabelas ocupam mais espaço, podemos usar os procedimentos armazenados relacionados para manter seu tamanho sob controle.

Histórico de backup


A principal responsabilidade do DBA é garantir que os backups completos e os logs transacionais sejam habilitados em todas as instâncias do Production SQL Server para recuperar os bancos de dados em um determinado momento.

O SQL Server armazena os detalhes de backup e as informações de restauração nas tabelas de banco de dados MSDB a seguir :
  • arquivo de backup
  • grupo de arquivos de backup
  • família de mídia de backup
  • conjunto de mídia de backup
  • backup
  • arquivo de restauração
  • restaurar grupo de arquivos
  • história de restauração

Para um não significativo. de bancos de dados na instância do SQL Server configurada com backups completos e backups de log transacional, os registros nas tabelas acima podem aumentar mais rapidamente.

Assim, o SQL Server fornece dois procedimentos armazenados do sistema no MSDB banco de dados para controlar o tamanho das tabelas acima:
  • sp_delete_backuphistory – exclui os dados do histórico de backup nas 8 tabelas acima com base na data mais antiga parâmetro.
  • sp_delete_database_backuphistory – exclui os dados do histórico de backup nas 8 tabelas acima com base no nome do banco de dados .

A sintaxe para executar os procedimentos armazenados do sistema acima:
exec msdb.dbo.sp_delete_backuphistory @oldest_date = 'oldest_date'
exec msdb.dbo.sp_delete_database_backuphistory @database_name = 'database_name'

Quando executamos qualquer um dos procedimentos armazenados descritos acima em um banco de dados contendo registros enormes nas tabelas de histórico de backup, podemos ficar bloqueando ou perceber que os registros são excluídos muito lentamente. Para resolver isso, criamos o índice ausente abaixo no backupset tabela. Ele pode ser identificado por meio do plano de execução do procedimento armazenado para executar qualquer um de nossos procedimentos armazenados mais rapidamente.
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

Histórico de trabalhos do SQL Server Agent


O SQL Server armazena todo o histórico de trabalhos do SQL Server Agent no msdb.dbo.sysjobhistory tabela. Além disso, o SQL Server tem um procedimento armazenado do sistema chamado msdb.dbo.sp_purge_jobhistory que ajuda a manter o sysjobhistory tamanho da mesa sob controle.

A sintaxe para executar o sp_purge_jobhistory procedimento armazenado será:
exec msdb.dbo.sp_purge_jobhistory @job_name = 'job_name', @job_id = 'job_id', @oldest_date ='oldest_date'

Todos os 3 parâmetros são opcionais, e recomendamos executar o procedimento acima passando o oldest_date parâmetro para manter o sysjobhistory tamanho da mesa sob controle.

Planos de manutenção


O SQL Server armazena os detalhes de todos os planos de manutenção nas tabelas abaixo:
  • msdb.dbo.sysmaintplan_log
  • msdb.dbo.sysmaintplan_logdetail

O SQL Server tem um procedimento armazenado interno chamado msdb.dbo.sp_maintplan_delete_log para manter os tamanhos dessas 2 tabelas sob controle.

A sintaxe para executar o procedimento será:
exec msdb.dbo.sp_maintplan_delete_log @plan_id = '', @subplan_id = '', @oldest_Time = 'oldest_datetime'

Todos os 3 parâmetros são opcionais. Recomendamos executar o procedimento acima, passando o parâmetro old_time para manter o tamanho das duas tabelas acima sob controle.

Histórico do SQL Server Database Mail


O SQL Server armazena todos os logs de histórico do Database Mail nas tabelas abaixo:
  • sysmail_mailitems
  • sysmail_log
  • sysmail_attachments
  • sysmail_attachments_transfer

Para manter esses tamanhos de tabela de histórico sob controle, o SQL Server oferece 2 procedimentos armazenados do sistema denominados msdb.dbo.sysmail_delete_mailitems_sp e msdb.dbo.sysmail_delete_log_sp.

A sintaxe para executar esses procedimentos armazenados será:
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

Para ambos os procedimentos, todos os parâmetros são opcionais. No entanto, é recomendável usar o enviado_antes ou logged_befor e parâmetros para excluir os registros mais antigos com base no período de retenção.

Em alguns cenários, se todas as tabelas relacionadas ao Database Mail forem enormes, executar o comando delete procedimento correrá para sempre. Uma maneira mais rápida de lidar com o problema é excluir a restrição de chave estrangeira em sysmail_attachments e sysmail_send_retries tabelas, trunque as 4 tabelas acima e recrie as 2 chaves estrangeiras de volta em sysmail_attachments e sysmail_send_retries tabelas como mostrado abaixo:
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

Pacotes SSIS


O SQL Server armazena todos os SSIS(*.dtsx) pacotes nos pacotes msdb.dbo.sysssis tabela. Esta tabela é uma tabela de configuração, no entanto, em casos aleatórios, é provável que haja muitos pacotes SSIS despejados na tabela. Isso faz com que o tamanho desta tabela cresça enorme.

Nesses casos, precisamos identificar se existem pacotes indesejados e excluí-los para manter os sysssispackages tamanho da mesa sob controle.

O resultado final


O SQL Server não tem trabalhos internos para lidar com a tarefa de exclusão em todas as tabelas discutido acima. Ainda assim, temos o parâmetro de data mais antigo disponível para todos os procedimentos acima.

Portanto, a abordagem recomendada para lidar com o tamanho da tabela MSDB sob controle seria definir um período de retenção com base no número de dias e criar um novo trabalho do SQL Server Agent para executar o script abaixo de forma programada:
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;

Conclusão


Aprendemos sobre a lista de tabelas que podem crescer mais rapidamente no MSDB banco de dados e como manter o tamanho dessas tabelas sob controle. Derivamos um script útil com a lista de procedimentos a serem executados regularmente para evitar que o MSDB banco de dados crescendo para um tamanho enorme também. Espero que este artigo seja útil para sua automação e que essas informações libertem sua mente das manutenções do banco de dados MSDB e se concentrem em outras atividades.