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 |
You can select databases as below.
All databases |
| 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
