Supongo que a más de uno le chocará el título del post. En realidad no es que esté en contra de los planes de mantenimiento de las bases de datos, obviamente, sino de las herramientas que SQL Server nos proporciona para crearlos. Ciertamente resulta muy cómodo ir añadiendo tareas y enlazándolas para que se ejecuten en un flujo de trabajo concreto, todo a golpe de clics de ratón.

Sin embargo, en muchas ocasiones se queda corto. Dejando a un lado los fallos que a veces ocurren en los propios planes de mantenimiento (haciendo una búsqueda en Google por las palabras “bug maintenance plan” salen la friolera de 660.000 páginas. De acuerdo, muchas de ellas hacen referencia a los mismos problemas, pero al menos sirve para hacerse uno una idea), personalmente no me gusta la poca información de salida que proporciona su ejecución y tampoco el hecho de no saber exactamente qué instrucciones TSQL ejecuta (sí, se pueden ver, pero no modificar).

Aunque lo anterior podría ser cuestión de gustos personales, hay otros aspectos que limitan la funcionalidad de los planes de mantenimiento. Ejemplos de ello están en las tareas de backups (no puedes modificar el nombre del archivo generado) o el chequeo de integridad (no tienes más opción que la de incluir o no los índices).

Pero donde, sin duda, la tarea que me parece más limitada es la de desfragmentación de los índices: el sistema no te da ningún parámetro para diferenciar cuándo ejecutar una reorganización o cuándo una reconstrucción, no puedes indicarle un nivel de paralelismo concreto, no tiene en cuenta si el índice tiene objetos LOB para evitar el error de intentar reconstruirlo en línea, además de que no puedes modificar la instrucción que se ejecuta… En fin, un poco precario, desde mi punto de vista.

Y vale, el problema está expuesto, pero ¿y la solución? Pues sencillo: con TSQL se puede hacer cualquier cosa en SQL Server, así que lo único que hay que hacer es trabajar en nuestro propio script que haga todas las tareas de mantenimiento que nuestro sistema requiere. Bueno, en realidad no es tan sencillo, principalmente por el tiempo que requiere implementar algo así. Sin embargo, hay gente que le ha echado ganas (y conocimientos, por supuesto) para crearse dicho script y, lo mejor de todo, compartirlo con el resto de la comunidad “esequeleservesera” J

La verdad es que el trabajo de Ola Hallengren merece un gran respeto, pues no imagino el tiempo que ha dedicado a su solución (y que sigue dedicando, pues continuamente saca nuevas versiones, mejorando lo existente). Si echáis un vistazo a su web, podréis descargaros un pequeño script que, con unas pequeñas modificaciones para adaptarlo a vuestro servidor, sirve para cualquier versión de SQL Server 2005 (con SP1 mínimo) y 2008. Además existe un apartado de documentación, puesta en marcha e incluso preguntas frecuentes

Copio/pego una tabla comparativa entre los planes de mantenimiento y el script de Ola:

Area Maintenance Plans Stored procedure based solution
Logging The log file is created in the end of the Maintenance Plan execution. If the Maintenance Plan, SQL Server or server would crash then you have no log file.

The logging includes superficial information about the execution.

The log file is created in the beginning of the stored procedure execution. Log information is written as the stored procedure execution proceeds.

The logging includes start time, command text, command output and end time for each command.

Database Selection You can select databases as below.

All databases
All system databases
All user databases
A list of databases

You can select databases as below.

All databases
All system databases
All user databases
A list of databases
Exclusion of databases
Database name pattern matching

Error Handling If an error occur the Maintenance Plan continues to the next database and reports failure in the end.

If the backup fails for one database, the other databases will still be backed up.

If an error occur the stored procedure logs the error, continues to the next database and reports failure in the end.

If the backup fails for one database, the other databases will still be backed up.

Backup Compression The Maintenance Plan supports native SQL Server 2008 backup compression. The backup stored procedure supports both native SQL Server 2008 backup compression and LiteSpeed backup compression.
Online Index Rebuild In the Maintenance Plan you can select to do rebuild of indexes online or offline.

The problem with that is that if the index (or table for a clustered index) contains a LOB (large object), online rebuild is not supported and will fail.

The index optimization stored procedure supports dynamic online / offline rebuild of indexes based on LOB (large object) existence.

It supports that indexes with no LOBs are rebuilt online and indexes with LOBs are rebuilt offline.

Index Fragmentation The Maintenance Plan does not take index fragmentation into consideration when rebuilding and reorganizing indexes. The index optimization stored procedure supports dynamic rebuild / reorganization of indexes based on the fragmentation levels.

It supports that indexes with a high level of fragmentation are rebuilt, that indexes with a medium level of fragmentation are reorganized and that indexes with a low level of fragmentation are skipped.

Partitioning The Maintenance Plan rebuilds and reorganizes partitioned indexes on the table level (not partition level). The index optimization stored procedure supports both table level and partition level rebuild and reorganizition of partitioned indexes.
Documentation SQL Server Books Online Documentation

 

Actualización (15/09/09): La nueva versión disponible ya no impone la limitación de tener SP1 de SQL Server 2005 instalado

0 Shares:
Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

You May Also Like
Leer más

Cálculos de tiempo personalizados en SSAS Multidimensional

Si para ciertas cuentas no queremos sumar en los cálculos temporales, sino hacer otra operación, por ejemplo, la media, podemos definir una columna (TBAverage) que para cada cuenta indique si suma (0) o hace la media (1). La usaremos en el cubo como una medida que comprobaremos para cada nivel para detectar si esa cuenta debe sumar o hacer la media para los cálculos temporales.
Leer más

Introducción a Power Query

En esta entrada repasamos la definición de ETL, presentamos SQL Server Integration Services en el contexto de BI corporativo para dar paso a Power Query como solución de BI personal.