SQL Server ha ofrecido desde siempre facilidades para crear planes de mantenimiento, encapsulándolos a través de otros objetos que nos permitían realizar estas necesarias operaciones sin necesidad de tener que escribir una sola línea de código.
Sin embargo, debido justamente a esto, estábamos también limitados a las funcionalidades que estos objetos nos ofrecían y, lo que es peor: cuando algo fallaba, las posibilidades de arreglarlo estaba también limitadas a lo que dichos objetos exponen de cara al usuario. Y es justamente estas razones por las que siempre he recelado de crear los planes de mantenimiento por medio de estos asistentes.
La contrapartida de no querer usar esos asistentes es tener que escribir el código TSQL que se encargue de chequear la integridad, hacer el backup, desfagmentar los índices y todas aquellas tareas típicas de un plan de mantenimiento de una base de datos. Debido a ello, algunos grandes profesionales reconocidos dentro del mundillo de SQL Server siguen recomendando usar los asistentes por su facilidad de uso (aún a sabiendas de las limitaciones y problemas que tienen), ya que en aquellas empresas donde la persona responsable de las bases de datos no sea un DBA propiamente dicho, le resultará más fácil crear y programar estas tareas de este modo.
Personalmente discrepo de esta afirmación: si la empresa no tiene un DBA, o al menos una persona con unos conocimientos mínimos de SQL Server, casi el menor de sus problemas será el tener que lidiar con planes de mantenimiento: hay muchas, muchísimas cosas de las que se encarga un DBA y si esa persona responsable de los sistemas no es capaz de solucionar los problemas que puedan surgir, de poco va a servir que haya algo permita con un par de clicks realizar backups o chequeos de integridad.
Así que por tanto, sigo pensando que crearse uno los scripts TSQL que ejecuten las tareas típicas de un plan de mantenimiento es la mejor opción. Bueno, la mejor no, puesto que en vez de tener que dedicar tiempo a planificar, diseñar y ejecutar dichos scripts, podemos recurrir a alguien que ya lo haya hecho por nosotros y del cual tengamos referencias de la calidad de su trabajo. Esa es la idea de recomendar la solución de Ola Hallengren
Este gran profesional afincado en Suecia lleva años ofreciendo a la comunidad una solución totalmente gratuita para simplificar las tareas de backup, chequeos de integridad y desfragmentación de los índices de las bases de datos de una instancia. Lo que descargamos de su página no es más que un archivo de código TSQL que podemos leer sin problemas para asegurarnos de lo que ejecuta y editarlo a nuestro gusto si así lo creemos necesario.
Es una solución probada en múltiples entornos y a la que se le han concedido varios premios por lo que ofrece. Además, Ola se encarga de mantenerla constantemente actualizada (de hecho acaba de sacar una versión para SQL Server 2012), y si encuentras cualquier problema o quieres hacerle alguna sugerencia, está siempre accesible en su correo. Personalmente no encuentro ninguna razón por la cual no recomendarla, por lo que os aconsejo que entréis en su página, leáis la documentación y la probéis en una instancia de pruebas para comprobar los resultados. Estoy seguro que aunque no seas un DBA con experiencia, la seguirás prefiriendo.
