MANTENIMIENTO DE BASE DE DATOS MSDB
En este artículo, Pablo F. Dueñas te ofrece una una solución para el mantenimiento de la msdb de SQL Server, información de gran utilidad para los administradores de Bases de Datos.
La base de datos msdb es usada por SQL Server para guardar varios historiales. Hay que tener esto en cuenta para acotar su crecimiento y que no empiece a dar problemas su tamaño. Hay unos mantenimientos que son estándar, pero otro hay que añadirlo.
Lo primero que tenemos que aclarar es la diferencia que hay entre dos tareas que pueden originar confusión. Aunque no tiene que ver con el mantenimiento de la base de datos msdb, si se usan planes de mantenimiento, se tiene la opción de crear un registro mediante ficheros de texto plano. Si descuidamos dichos ficheros, se van acumulando y pueden llegar a ocupar bastante tamaño y poner en riesgo el espacio en el volumen correspondiente. Esto es debido a que los ficheros se suelen guardar en el mismo volumen de la instalación de SQL Server, al que no se le suele dejar mucho espacio libre.
Además, por defecto se guardan en el mismo directorio donde está la traza por defecto y los registros de errores. Si este directorio está lleno de ficheros, nos va a complicar la vida el analizar una traza o buscar un registro de error. Por ello es importante mantener un límite en el número de ficheros que se conservan.
Afortunadamente los planes de mantenimiento tienen esta tarea especial para realizar esta acción. Se llama Limpieza de mantenimiento y dentro de las opciones hay que elegir Informes de texto de planes de mantenimiento. Se elige la carpeta donde se están dejando dichos informes y el periodo de retención que se desea.
Sí que hay una tarea específica para msdb llamada Limpieza de historial. Esta tarea nos quita bastante trabajo pues las opciones nos permiten mantener la mayor parte del historial que se guarda en msdb.
Cada vez que se hace una copia se seguridad de una base de datos, se guardan registros informando de los datos pertinentes a dicha copia. Nos interesan los últimos para, por ejemplo, verificar los tamaños y ver si hay algún problema con las que tienen modo de recuperación completo. Pero no necesitamos el historial de toda la vida del servidor.
Los trabajos del Agente SQL Server también tienen su propio historial, que también incluye varias tablas relacionadas. Este componente nos quita la complejidad de borrar coordinadamente los datos antiguos.
Por último, aunque los planes de mantenimiento puedan guardar los datos en ficheros de texto plano, también hay unas tablas donde se guarda su historial de ejecución. De nuevo este componente nos ayuda en mantener a raya la cantidad de información que guardamos.
Si usamos correo electrónico de base de datos, se va guardando el historial completo de cada correo, que puede llegar a ser varios gigas dependiendo de la cantidad que se envíe. Como el correo es una herramienta muy útil para automatizar procesos y así saber cuándo se ha hecho algo, cuándo se ha producido un evento o cuándo ha fallado un trabajo del Agente SQL Serve, por poner algunos ejemplos, mantener solo la última información es importante para que la msdb no empiece a llenar el disco duro y para una mejor eficiencia en las consultas que se le hagan. Al fin y al cabo, no es necesario, de nuevo, mantener toda la información desde que se creó la instancia de Servidor de Base de datos.
Sin embargo, para esta información no hay un componente en los planes de mantenimiento que nos ayude directamente a acotarla. Necesitaremos crear un proceso que utilice ciertos procedimientos almacenados del sistema para limpiar el historial. Por lo tanto, usaremos en el plan de mantenimiento una tarea Ejecutar instrucción T-SQL donde pondremos el código.
Pero, para facilitar cambios a dicho código y estandarizarlo en todas las instancias, es preferible tener una base de datos especial de administración donde vayan los procesos generales de las instancias. En dicha base de datos vamos a crear un procedimiento almacenado que mantenga el registro del correo. Así, la tarea quedaría:
El primer procedimiento es sysmail_delete_mailitems_sp que «elimina de forma permanente los mensajes de correo electrónico de las tablas internas del Correo electrónico de base de datos». Este procedimiento almacenado elimina no solo los mensajes, sino también los archivos adjuntos relacionados. De los dos parámetros que tiene, nos interesa el primero @sent_before al que pasaremos la fecha del primer correo que queremos conservar. En nuestro caso estamos dejando los tres últimos meses.
El segundo procedimiento limpia los eventos del registro. Es decir, los correos y sus adjuntos son independientes del registro que se lleva del correo. Según la política de empresa, podemos usar un periodo de retención de registros distinto del contenido de los correos. En este caso vamos a tener una política única.
El procedimiento sysmail_delete_log_sp «elimina todos los eventos del registro del correo electrónico de base de datos que cumplan un criterio». De nuevo el criterio es la fecha del correo cuyo tope pasamos en el parámetro @logged_before.
Por último, podemos añadir un registro de la actividad. Por un lado cogemos la actividad del primer procedimiento de la tabla sysmail_log, y de la del segundo solo podemos usar la función del sistema @@ROWCOUNT para ver el número de entradas que se eliminan.
En base a estos dos procedimientos de Correo electrónico de base de datos, podemos construir un procedimiento almacenado que se ejecute junto con el resto de componentes en el plan de mantenimiento semanal o mensual. Veamos un ejemplo:
Dentro del mantenimiento es tan importante mantener «aceitada» la base de datos como contener el crecimiento de los distintos ficheros. En este artículo hemos visto como mantener a raya los distintos rastros que se van dejando, haciendo énfasis en aquel para el que no hay una tarea en los planes de mantenimiento: el Correo electrónico de base de datos.
Dejar un comentario
¿Quieres unirte a la conversación?¡Siéntete libre de contribuir!