MSDB es una base de datos del sistema utilizada por SQL Server. MSDB almacena todo tipo de datos, como el historial de copias de seguridad y restauración, el historial de trabajos del Agente SQL, el historial del monitor de envío de registros, los paquetes de SSIS, los datos del Asesor de ajuste del motor de base de datos y los datos de la cola de Service Broker. Al igual que las bases de datos de usuarios, msdb necesita un mantenimiento regular, incluidas las optimizaciones de índice y, lo que es más importante, la depuración regular.
Historial de copia de seguridad y restauración
De forma predeterminada, no existe ningún método para purgar o eliminar el historial de copias de seguridad y restauración de msdb. Se conserva para siempre hasta que configure un proceso manual o automatizado para eliminar los datos. Al no purgar estos datos, msdb seguirá creciendo, lo que significa que leer y escribir en esas tablas puede volverse más lento y afectar la velocidad de sus trabajos de copia de seguridad.
La mayoría de las herramientas de terceros y las soluciones de mantenimiento acreditadas incluyen procesos para borrar el historial de copias de seguridad y restauración para evitar que esto se convierta en un problema. Una manera fácil de saber si está depurando el historial de copias de seguridad o no es consultar msdb directamente:
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_type
FROM msdb.dbo.backupmediafamily
INNER JOIN msdb.dbo.backupset ON msdb.dbo.backupmediafamily.media_set_id = msdb.dbo.backupset.media_set_id
ORDER BY msdb.dbo.backupset.backup_finish_date; Si tiene un historial de copias de seguridad o restauración que se remonta a más de 90 días, debe investigar si existe un requisito reglamentario que exija que debe conservar la información histórica sobre esas copias de seguridad durante un período específico. Si no hay un requisito, entonces debería considerar purgar los datos anteriores a un cierto período de tiempo. El historial de copias de seguridad no es necesario para restaurar sus bases de datos y le recomendamos que lo purgue regularmente para mantener msdb en un tamaño razonable. Conservar 90 días o menos es el rango que suelo recomendar a los clientes.
Para configurar un proceso para purgar el historial de copia de seguridad y restauración, cree un trabajo que ejecute sp_delete_backuphistory procedimiento almacenado en msdb y pasarle un parámetro de fecha. El procedimiento almacenado eliminará todas las copias de seguridad y restaurará el historial anterior a la fecha que proporcione. También puede crear un Plan de mantenimiento de la base de datos y utilizar la tarea Limpiar historial.
Asesor de ajuste del motor de base de datos
El Asesor de ajuste del motor de base de datos, también conocido como DTA, es una herramienta que los desarrolladores y administradores de bases de datos pueden usar para ayudar a ajustar una base de datos. DTA aprovecha la base de datos msdb para almacenar el historial de ajustes y otros objetos de apoyo.
Rutinariamente encuentro restos de DTA en msdb en los servidores de producción de los clientes. Cuando encuentro estas tablas, las consulto directamente para determinar si todavía se está utilizando DTA. Afortunadamente, todavía tengo que encontrar un cliente que ejecute activamente DTA en producción, ya que puede afectar significativamente el rendimiento. Una vez que confirmo y me comunico con el cliente, elimino las tablas DTA de msdb. En algunos casos, esto libera varios gigabytes de espacio. Como precaución, también me tomo el tiempo para explicar el impacto en el rendimiento que puede causar la ejecución de DTA contra la producción y animo a mis clientes a que cualquier uso futuro se haga en un servidor de desarrollo.
Agente SQL Server
En ocasiones, me encuentro con un cliente que, sin darse cuenta, desmarcó la casilla para limitar el tamaño del registro del historial de trabajos. Este es un error fácil de cometer si tiene un servidor ocupado y el registro sigue moviéndose tan rápido que no tiene ningún historial de trabajo útil para consultar al solucionar problemas de trabajos del Agente SQL Server. Un mejor enfoque es aumentar el tamaño máximo del registro del historial de trabajos (en filas) a un valor mucho más alto en lugar de dejar que crezca sin restricciones.
En los casos en los que los clientes tenían un crecimiento laboral sin restricciones, la tabla sysjobhistory había crecido demasiado y era necesario purgarla. La mejor manera de purgar el historial es usar sp_purge_jobhistory y pasar un parámetro de fecha. El procedimiento almacenado eliminará todo el historial de trabajos anterior a la fecha que proporcione. Si debe mantener un número mínimo de días del historial del Agente SQL Server, limitar el registro del historial de trabajos en función de las filas no es efectivo. En su lugar, no limite el tamaño del registro del historial de trabajos y también programe un trabajo que ejecutará sp_purge_jobhistory y pasará un parámetro de fecha para la cantidad mínima de días de historial de trabajos que necesita. Es común utilizar un valor de 14 o 30 días.
Agente de servicios
Recientemente me encontré con un problema con un cliente en el que msdb había crecido a 14 GB de tamaño. Después de un intento de actualizar la instancia a un paquete de servicio actual, la actualización no pudo aplicar los scripts a msdb y provocó que msdb creciera exponencialmente nuevamente. Después de algunas investigaciones, descubrimos que Service Broker estaba habilitado para notificaciones de eventos, pero no estaba configurado correctamente. Durante más de un año, las notificaciones de eventos se pusieron en cola, pero no se enrutaron.
Al verificar sys.transmission_queue, descubrí que el agente de servicios en la base de datos de destino no estaba disponible y que el agente de servicios estaba deshabilitado administrativamente. Luego verifiqué qué notificaciones de eventos se configuraron consultando sys.server_events_notifications y encontré solo una entrada:capturar todos los eventos de registro de errores. Luego consulté sys.transmissions_queue para ver cuántos eventos había en la cola y encontré varios millones de registros allí.
Después de discutir esto con el cliente y explicar los resultados, acordamos que el mejor curso de acción era eliminar la notificación del evento y borrar la cola actual mediante la creación de un nuevo intermediario. Para ello ejecuté ALTER DATABASE msdb SET NEW_BROKER. Esto se hizo después de horas y después de una buena copia de seguridad completa de msdb.
Después de borrar la cola de transmisión y eliminar el evento, pude reducir msdb de 14 GB a 300 MB. Antes de corregir este problema, la base de datos msdb tenía la latencia de disco más alta en la instancia y el cliente experimentaba interbloqueos regulares. Después de implementar este cambio, así como otras optimizaciones, la experiencia de usuario del cliente mejoró mucho.
Envío de registros
Al principio de mi carrera de DBA, heredé un servidor de consolidación que tenía unos pocos cientos de bases de datos que se enviaban de registro a un servidor secundario en otro centro de datos. Este servidor había estado funcionando durante varios años y enviaba los registros cada 15 minutos. Esta instancia no solo sufrió por no purgar el historial de copias de seguridad, sino que tampoco borró correctamente el historial del monitor de envío de registros. Una vez que purgué el historial de respaldo y verifiqué el tamaño de msdb, todavía mostraba más espacio usado del que debería. Ejecuté un script para mostrarme el tamaño total de cada tabla y descubrí que log_shipping_monitor_history_detail la mesa era muy grande. En este caso pude ejecutar sp_cleanup_log_shipping_history para purgar el historial y hacer que msdb vuelva a su tamaño normal.
Indización
La optimización de índices en msdb es tan importante como las bases de datos de sus usuarios. Muchas veces me he encontrado con clientes que están optimizando las bases de datos de los usuarios pero no las bases de datos del sistema. Dado que la base de datos msdb es muy utilizada por el Agente SQL Server, Log Shipping, Service Broker, SSIS, copia de seguridad y restauración, y otros procesos, los índices pueden fragmentarse mucho. Asegúrese de que sus trabajos de optimización de índices también incluyan las bases de datos de su sistema, o al menos msdb. He visto optimizaciones de índices que liberan varios gigabytes de espacio de índices muy fragmentados dentro de msdb.
Resumen
Descuidar msdb puede afectar negativamente el rendimiento de su entorno. Es crucial monitorear el tamaño de msdb, así como los procesos que lo utilizan, para garantizar que funcione de manera óptima. El historial de copia de seguridad y restauración es la razón más común por la que la base de datos msdb se infla; sin embargo, el Asesor de ajuste del motor de base de datos, el historial del Agente SQL Server, el intermediario de servicios, el envío de registros y la falta de mantenimiento del índice pueden contribuir al crecimiento excesivo de msdb y afectar el rendimiento de la base de datos.
