MSDB é um banco de dados do sistema usado pelo SQL Server. O MSDB armazena todos os tipos de dados, como histórico de backup e restauração, histórico de trabalho do SQL Agent, histórico do monitor de envio de logs, pacotes SSIS, dados do Orientador de Otimização do Mecanismo de Banco de Dados e dados da fila do Service Broker. Assim como os bancos de dados do usuário, o msdb precisa de manutenção regular, incluindo otimizações de índice e, mais importante, limpeza regular.
Histórico de backup e restauração
Por padrão, não há método para limpar ou excluir o histórico de backup e restauração do msdb. Ele é mantido para sempre até que você configure um processo manual ou automatizado para excluir os dados. Ao não limpar esses dados, o msdb continuará crescendo, o que significa que a leitura e a gravação nessas tabelas podem se tornar mais lentas e afetar a velocidade de seus trabalhos de backup.
A maioria das ferramentas de terceiros e soluções de manutenção respeitáveis incluem processos para limpar o histórico de backup e restauração para evitar que isso se torne um problema. Uma maneira fácil de saber se você está limpando o histórico de backup ou não é consultar o msdb diretamente:
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 ' Database' WHEN 'L' THEN 'Log' END AS backup_typeFROM msdb.dbo.backupmediafamilyINNER JOIN msdb.dbo.backupset ON msdb.dbo.backupmediafamily.media_set_id =msdb.dbo.backupset.media_set_idORDER BY msdb.dbo.backupset.backup_finish_date;
Se você tiver um histórico de backup ou restauração com mais de 90 dias, deverá investigar se há um requisito regulatório que obrigue a manter as informações históricas sobre esses backups por um período específico. Se não houver um requisito, você deve considerar a limpeza de dados anteriores a um determinado período de tempo. O histórico de backup não é necessário para restaurar seus bancos de dados e recomendamos limpá-lo regularmente para manter o msdb em um tamanho razoável. Manter 90 dias ou menos é o intervalo que normalmente recomendo aos clientes.
Para configurar um processo para limpar o histórico de backup e restauração, crie uma tarefa que execute o sp_delete_backuphistory procedimento armazenado em msdb e passe um parâmetro de data. O procedimento armazenado excluirá todo o histórico de backup e restauração anterior à data fornecida. Você também pode criar um Plano de Manutenção de Banco de Dados e usar a tarefa Limpar Histórico.
Consultor de Otimização do Mecanismo de Banco de Dados
O Orientador de Otimização do Mecanismo de Banco de Dados, também conhecido como DTA, é uma ferramenta que os desenvolvedores e administradores de banco de dados podem usar para ajudar a ajustar um banco de dados. O DTA aproveita o banco de dados msdb para armazenar o histórico de ajustes e outros objetos de suporte.
Rotineiramente encontro restos de DTA no msdb nos servidores de produção dos clientes. Quando encontro essas tabelas, consulto-as diretamente para determinar se o DTA ainda está sendo usado. Felizmente, ainda não encontrei um cliente executando o DTA ativamente na produção, pois isso pode afetar significativamente o desempenho. Depois de confirmar e me comunicar com o cliente, descarto as tabelas DTA do msdb. Em alguns casos, isso libera vários gigabytes de espaço. Como precaução, também aproveito o tempo para explicar o impacto no desempenho que a execução do DTA na produção pode causar e incentivar meus clientes que qualquer uso futuro deve ser feito em um servidor de desenvolvimento.
Agente do SQL Server
De vez em quando, encontro um cliente que inadvertidamente desmarcou a caixa para limitar o tamanho do log do histórico de trabalho. Este é um erro fácil de cometer se você tiver um servidor ocupado e o log continuar rolando tão rapidamente que você não tem nenhum histórico de trabalho útil para referenciar ao solucionar problemas de trabalhos do SQL Server Agent. Uma abordagem melhor é aumentar o tamanho máximo do log do histórico de tarefas (em linhas) para um valor muito mais alto, em vez de deixá-lo crescer sem restrições.
Nos casos em que os clientes tiveram crescimento irrestrito de empregos, a tabela sysjobhistory ficou excessivamente grande e precisou ser eliminada. A melhor maneira de limpar o histórico é usar sp_purge_jobhistory e passe um parâmetro de data. O procedimento armazenado excluirá todo o histórico de trabalho anterior à data fornecida. Se você precisar manter um número mínimo de dias de histórico do SQL Server Agent, limitar o log do histórico de trabalho com base em linhas não será eficaz. Em vez disso, não limite o tamanho do log de histórico de trabalho e também agende um trabalho que executará sp_purge_jobhistory e passará um parâmetro de data para o número mínimo de dias de histórico de trabalho que você precisa. É comum usar um valor de 14 ou 30 dias.
Corretor de Serviços
Recentemente, encontrei um problema com um cliente em que o msdb cresceu para 14 GB de tamanho. Após uma tentativa de atualizar a instância para um service pack atual, a atualização falhou ao aplicar os scripts ao msdb e fez com que o msdb crescesse exponencialmente novamente. Após algumas pesquisas, descobrimos que o Service Broker estava habilitado para notificações de eventos, mas não estava configurado corretamente. Por mais de um ano, as notificações de eventos estavam sendo enfileiradas, mas não estavam sendo roteadas.
Ao verificar o sys.transmission_queue, descobri que o service broker no banco de dados de destino não estava disponível e o service broker estava desabilitado administrativamente. Em seguida, verifiquei quais notificações de eventos foram configuradas consultando sys.server_events_notifications e encontrei apenas uma entrada:capturar todos os eventos de log de erros. Em seguida, consultei sys.transmissions_queue para ver quantos eventos estavam na fila e encontrei vários milhões de registros lá.
Depois de discutir isso com o cliente e explicar as descobertas, concordamos que o melhor curso de ação era descartar a notificação do evento e limpar a fila atual criando um novo agente. Para isso executei ALTER DATABASE msdb SET NEW_BROKER. Isso foi feito depois de horas e após um bom backup completo do msdb.
Depois de limpar o transmit_queue e remover o evento, consegui reduzir o msdb de 14 GB para 300 MB. Antes de corrigir esse problema, o banco de dados msdb tinha a maior latência de disco na instância e o cliente estava enfrentando bloqueios regulares. Após implementar essa mudança, além de outras otimizações, a experiência do usuário do cliente melhorou bastante.
Envio de Log
No início da minha carreira de DBA, herdei um servidor de consolidação que tinha algumas centenas de bancos de dados que foram Log Shipps para um servidor secundário em outro datacenter. Esse servidor estava funcionando há vários anos e enviava os logs a cada 15 minutos. Essa instância não apenas sofreu por não limpar o histórico de backup, mas também não estava limpando corretamente o histórico do monitor de envio de logs. Depois de limpar o histórico de backup e verificar o tamanho do msdb, ele ainda mostrava mais espaço usado do que deveria. Executei um script para me mostrar o tamanho total de cada tabela e descobri que o log_shipping_monitor_history_detail mesa era muito grande. Nesse caso, consegui executar sp_cleanup_log_shipping_history para limpar o histórico e fazer com que o msdb volte ao tamanho normal.
Indexação
Otimizar índices no msdb é tão importante quanto seus bancos de dados de usuários. Muitas vezes encontrei clientes que estão otimizando bancos de dados de usuários, mas não os bancos de dados do sistema. Como o banco de dados msdb é muito usado pelo SQL Server Agent, Log Shipping, Service Broker, SSIS, backup e restauração e outros processos, os índices podem ficar altamente fragmentados. Certifique-se de que seus trabalhos de otimização de índice também incluam seus bancos de dados do sistema ou, pelo menos, msdb. Já vi otimizações de índice liberarem vários gigabytes de espaço de índices altamente fragmentados no msdb.
Resumo
Negligenciar o msdb pode afetar negativamente o desempenho do seu ambiente. É crucial monitorar o tamanho do msdb, bem como os processos que o utilizam, para garantir que ele funcione de maneira ideal. O histórico de backup e restauração é o motivo mais comum para o banco de dados msdb inchar, no entanto, o Orientador de Otimização do Mecanismo de Banco de Dados, o histórico do SQL Server Agent, o agente de serviço, o envio de logs e a falta de manutenção de índice podem contribuir para o crescimento excessivo do msdb e afetar o desempenho do o banco de dados.
