Brad´s Sure Guide to SQL Server

Maintenance Plans
TABLA DE CONTENIDOS

Acerca del Autor

Agradecimientos

Introducción

Quien debe leer este libro

Objetivos de este libro

Ediciones de SQL Server cubiertas en este libro

Capítulo 1: Porque es importante el mantenimiento de las bases de datos?

El alcance del mantenimiento de las bases de datos.

Diferentes enfoques para el mantenimiento de las Bases de Datos.

Asistente para el Plan de Mantenimiento.

Diseñador del Plan de Mantenimiento.

Scripts T-SQL

Scripts PowerShell

Tareas principales del Plan de Mantenimiento.

Backups de Base de Datos.

Verificar la Integridad de una Base de Datos.

Mantenimiento a los Índices de una Base de Datos.

Mantenimiento a las Estadísticas de Índices y Columnas.

Eliminar Datos antiguos de MSDB.

Eliminar Copias de Seguridad Antiguas.

Que está afuera del alcance del Asistente y Diseñador de Plan de

Mantenimiento?.
 Resumen.

Capítulo 2: Antes de Crear Cualquier Plan de Mantenimiento.

Como Configurar el Correo de Base de Datos.

Como Configurar un Operador del Agente de SQL Server.

Resumen.

Capítulo 3: Introducción al Asistente de Plan de Mantenimiento.

Aprovechar el Potencial Completo del Asistente.

Investigación de los Planes de Mantenimiento Existentes.

Creación de un Plan de Mantenimiento.

Inicio del Asistente Para Planes de Mantenimiento.

Programación de Tareas de Mantenimiento.

Descripción General de las Tareas de Mantenimiento.

Selección de Tareas Básicas de Mantenimiento.

Orden de Tareas de Mantenimiento.

Configuración de Tareas Individuales.

Opciones de Informes.

Completar el Asistente.

Una Mirada Más Cercana a la Implementación del Plan de Mantenimiento.

Prueba del Plan de Mantenimiento.

Resumen.

Capítulo 4: Programación de Tareas.

Programación: Consideraciones Generales.

Evite Programar Tareas Durante los Periodos de Ocupación.

 Evitar la Superposición de Tareas.

Frecuencia de Tareas.

Programación de Tareas en el Asistente.

Propiedades de la Planificación de Trabajos.

Programación de Tareas de Mantenimiento Individuales.

Resumen

Capítulo 5: Comprobar la Integridad de la Base de Datos.

Una Visión General de la Tarea de Verificación de la Integridad de la Base

de Datos.

Cuando y con qué Frecuencia Ejecutar Controles de Integridad.

Configuración de la Tarea.

La Opción “Incluir Índices”.

Creación de la Planificación de la Tarea.

Resumen.

Capítulo 6: Tarea de Reducir la Base de Datos.

Tamaño de los Archivos de Base de Datos.

Problemas con la Tarea de Reducción de Base de Datos.

La Manera Correcta de Reducir una Base de Datos.

Resumen.

Capítulo 7: Tarea Reconstruir Índices.

Descripción General de la Tarea de Reconstruir Índices.

Cuando y con qué Frecuencia Reconstruir los Índices.

Seguimiento a la Fragmentación del Índice.

 Mantenimiento a los Índices Fuera de Línea.

Mantenimiento a los Índices en Línea.

Secuencia de Comandos para Reconstruir Índices.

Configuración de la Tarea de Reconstrucción de Índices.

Selección de la Base de Datos.

Opciones de Espacio Libre.

Opciones Avanzadas.

Creación de la Planificación de la Tarea.

Resumen.

Capítulo 8: Tarea de Reorganizar Índices.

Una Visión General de la Tarea de Reorganizar Índices.

Reorganizar Vs Reconstruir.

Cuando y con qué Frecuencia Reorganizar los Índices.

Configuración de la Tarea de Reorganizar Índices.

Selección de la Base de Datos.

Compactar Objetos Grandes.

Creación de la Planificación de la Tarea.

Resumen.

Capítulo 9: Tarea Actualización de Estadísticas.

Descripción General de la Tarea Actualización de Estadísticas.

Cuando y con qué Frecuencia Actualizar las Estadísticas.

Configuración de la Tarea de Actualización de Estadísticas.

Selección de la Base de Datos.

 La Opción de Actualización.

La Opción Tipo de Exploración.

Creación de la Planificación de la Tarea.

Resumen.

Capítulo 10: Ejecutar Tareas de las Tareas del Agente de SQL Server.

Descripción General de la Tarea de Ejecutar Tareas del Agente de SQL

Server.

Cuando y con qué Frecuencia Ejecutar Trabajos Personalizados.

Creación de Trabajos del Agente de SQL Server.

Configuración de la Tarea de Ejecución de Tareas del Agente de SQL

Server.

Selección del Trabajo.

Creación de la Planificación de la Tarea.

Resumen.

Capítulo 11: Tarea de Limpieza del Historial.

Descripción General de la Tarea Limpieza del Historial.

Cuando y con qué Frecuencia Limpiar la MSDB.

Configuración de la Tarea Limpieza del Historial.

Selección de los Datos Históricos a Eliminar.

Creación de la Planificación de la Tarea.

Resumen.

Capítulo 12: Tarea Backup (full) de la Base de Datos.

Estrategia de Copias de Seguridad: Una Breve Introducción.

 Descripción General de la Tarea Backup (full) de la Base de Datos.

Cuando y con qué Frecuencia Realizar Copias de Seguridad Completas.

Configuración de la Tarea Backup (full) de la Base de Datos.

Selección de Componentes de Base de Datos y Backups.

Almacenamiento de Archivos de Backups.

Verificar la Integridad de la Copia de Seguridad.

Establecer la Compresión de la Copia de Seguridad.

Creación de la Planificación de la Tarea.

Resumen.

Capítulo 13: Tarea Backup (Diferencial) de la Base de Datos.

Descripción General de la Tarea Backup (Diferencial) de la Base de Datos.

Cuando y con qué Frecuencia Realizar Copias de Seguridad Diferenciales.

Configuración de la Tarea Backup (Diferencial) de la Base de Datos.

Selección de Componentes de Base de Datos y Backups.

Creación de la Planificación de la Tarea.

Resumen.

Capítulo 14: Tarea Backup (Log de Transacciones) de la Base de Datos.

Descripción General de la Tarea Backup de Log de Transacciones de la

Base de Datos.

Cuando y con qué Frecuencia Realizar Copias de Seguridad del Log de

Transacciones.

Configuración de la Tarea Backup (Log de Transacciones) de la Base de

Datos.

Copia de Seguridad del Final del Log.

 Creación de la Planificación de la Tarea.

Resumen.

Capítulo 15: Tarea Limpieza de Mantenimiento.

Una Descripción General de la Tarea de Limpieza de Mantenimiento.

Cuando y con qué Frecuencia Limpiar los Archivos de Backups y Reportes.

Configuración de la Tarea de Limpieza de Mantenimiento.

Especificación del Tipo de Archivo a Eliminar.

Especificación de la Ubicación del Archivo.

Eliminar Archivos Anteriores A.

Creación de la Planificación de la Tarea.

Resumen.

Capítulo 16: Introducción al Diseñador de Plan de Mantenimiento.

Características Únicas del Diseñador de Plan de Mantenimiento.

Iniciar el Diseñador de Plan de Mantenimiento.

Explorando el Diseñador de Plan de Mantenimiento.

Explorador de Objetos.

Cuadro de Herramientas de Tareas de Mantenimiento.

Subplanes y la Superficie de Diseño.

Barra de Menú del Diseñador.

Resumen.

Capítulo 17: Configuración de Tareas de Mantenimiento con el Diseñador.

Una Nota de Precaución de Arrastrar y Soltar.

Comprobar la Integridad de la Base de Datos.

 Tarea de Reconstruir Índices.

Tarea de Reorganizar Índices.

Tarea de Actualizar Estadísticas.

Tarea de Reducir Base de Datos.

Tarea de Ejecutar Trabajos del Agente de SQL Server.

Tarea de Limpieza del Historial.

Tarea de Limpieza de Mantenimiento.

Tarea de Backup de Base de Datos.

Tarea de Ejecución de Sentencias T-SQL.

Tarea Notificación al Operador.

Resumen.

Capítulo 18: Subplanes y Precedencia.

Subplanes.

Uso de un Solo Subplan: Ventajas y Desventajas.

Uso de Múltiples Subplanes: Ventajas y Desventajas.

Uso de Subplanes.

Como Usar la Precedencia.

Resumen.

Capítulo 19: Crear y Modificar Planes de Mantenimiento con el Diseñador.

Estableciendo sus Objetivos de Mantenimiento.

Creación de Planes de Mantenimiento: El Panorama General.

Crear el Nuevo Plan de Mantenimiento.

Crear los Subplanes.

 Agregar las Tareas al Plan de Mantenimiento.

Configurar las Tareas del Plan de Mantenimiento.

Establecer Precedencia.

Definir Informes y Registros.

Guardar el Plan de Mantenimiento.

Probar el Plan de Mantenimiento.

Establecer las Programaciones.

Ejecutar en Producción y Hacerle Seguimiento.

Modificación de un Plan de Mantenimiento Existente.

Resumen.
ACERCA DEL AUTOR

Brad McGehee, actualmente director de Educación de DBA en Red Gate

Software, es un DBA de SQL Server, entrenador y escritor con más de 15 años de
experiencia en SQL Server y más de 6 años de experiencia de formación. Es un
MVP de Microsoft SQL Server, y fue el fundador del popular sitio de la comunidad
SQL-Server-Performance.Com, que opero desde 2000 hasta el 2006, escribiendo
más de un millón de palabras en temas de SQL Server.

Brad es un orador frecuente en SQL PASS, European PASS, SQL Connections,

SQL Teach, devLINK, SQL Bits, SQL Saturdays, TechFests, Code Camps, grupos
de usuarios de SQL Server y otros seminarios de la industria. En 2009, Brad hizo
33 presentaciones públicas a un total de 1.853 asistentes, en seis países
diferentes.

Un nombre respetado y de confianza en la literatura de SQL Server, Brad es el

autor o Coautor de más de 15 libros técnicos y más de 100 artículos publicados.
Sus libros más recientes incluyen Como Convertirse en un DBA Excepcional (2ª
Edición), Guía segura de Brad para SQL Server 2008 y Mastering SQL Server
Profiler, todos los cuales están disponibles en formato PDF en.
http://www.sqlservercentral.com/libros/

Cuando no está viajando para difundir sus conocimientos de SQL Server, Brad
disfruta de pasar tiempo con su esposa e hija en Hawái.

AGRADECIMIENTOS

Quiero agradecer a mi esposa, Verónica, y a mi hija, Anna, por su apoyo mientras

escribí este libro.

También quiero dar las gracias a Tony Davis, mi editor, por hacerme quedar bien
en la impresión.
INTRODUCCION

SQL Server tiene una reputación de ser una aplicación de base de datos sencilla
para instalar, configurar y mantener. Esto es un poco engañoso. SQL Server es
una poderosa base de datos relacional que puede manejar las necesidades de las
organizaciones más grandes y, como tal, su mantenimiento adecuado casi
ciertamente requiere la atención de un DBA experimentado.

Esta reputación, junto con el hecho de que es relativamente barato, significa que
SQL Server se ha convertido en una plataforma preferida para aplicaciones
multiusuario, y que a menudo aparece en organizaciones que no pueden darse el
lujo de tener un DBA en su personal. En muchos casos, las organizaciones tienen
instancias de SQL Server que son mantenidas por un DBA a tiempo parcial, o un
“DBA accidental”, que puede ser un administrador de red, desarrollador, contador
o incluso un empleado de oficina. En el peor de los casos, nadie está cuidando la
salud de los servidores SQL.

Millones de instancias de SQL Server se ejecutan en las oficinas de

organizaciones pequeñas y medianas, más el número total de instancias que se
ejecutan en grandes organizaciones, por lo que se supone que hay muchos DBA
accidentales por ahí, que a menudo no tienen el conocimiento, la experiencia o el
tiempo necesario para realizar el nivel de mantenimiento adecuado en su servidor
de Base de Datos SQL como le gustaría. Esto puede significar un rendimiento bajo
y una disponibilidad reducida.

Aunque no es una solución perfecta para este problema, SQL Server ofrece dos
herramientas estrechamente relacionadas que facilitan a los DBA de tiempo
parcial y no profesionales a realizar al menos el nivel de mantenimiento “mínimo
requerido” en sus instancias de SQL Server.

Estas dos herramientas son:

  Asistente para el Plan de Mantenimiento: Asistente que orienta al usuario
a través del proceso de configuración de planes básicos de mantenimiento,
con opciones limitadas.
 Diseñador de Plan de Mantenimiento: Una interfaz GUI de arrastrar y
soltar en SSMS que facilita el diseño y la creación de planes de
mantenimiento más flexibles y personalizables.

Desafortunadamente, ninguna herramienta es especialmente fácil de usar o bien

documentada. Sin embargo, con la guía que espero proporcionar en este libro,
pueden convertirse en poderosas herramientas para ayudar a los “DBA
accidentales” a realizar tareas críticas de mantenimiento, y así ayudar a garantizar
el rendimiento y la disponibilidad de SQL Server. Antes de aprender a usar estas
herramientas, a lo largo del camino recogerás un montón de buenos consejos
generales sobre el mantenimiento de las bases de datos de SQL Server.

QUIEN DEBERIA LEER ESTE LIBRO

Este libro está dirigido a los siguientes grupos de DBAs.

 DBAs Accidentales/Involuntarios: Que cayeron en el papel de DBA “por

accidente” y que no tienen un fondo fuerte en la administración de las bases
de datos.
 DBAs tiempo parcial: Cuyas tareas de DBAs son sólo una pequeña parte
de sus deberes de trabajo regulares, y cuyas habilidades de DBA van
desde principiante a intermedio.
 DBAs tiempo completo: Que están en el nivel principiante a intermedio en
términos de su conocimiento y experiencia.

Si cae en uno o más de las categorías anteriores, este libro es para usted, ya que
no solo explicara que mantenimiento de la base de datos debe hacerse, sino cómo
hacerlo correctamente mediante el Asistente para planes de mantenimiento y/o el
Diseñador de Planes de Mantenimiento.
Más generalmente, sugeriría que estas herramientas son las más convenientes
para los DBAs que:

 No son expertos de T-SQL o PowerShell, sino que son capaces de moverse

en SQL Server Management Studio (SSMS).
 Normalmente tienen 25 o menos instancias de SQL Server para
administrar.
 Normalmente tienen bases de datos que pesan menos de 100 GB.
 Probablemente están usando la edición estándar de SQL Server.
 Tienen una ventana de mantenimiento disponibles en una base diaria o
semanal (24/7 tiempo de actividad no es un requisito).

Si, por el contrario, usted es un DBA experimentado, maneja muchas instancias de

SQL Server, o bases de datos muy grandes, o un montón de usuarios
simultáneos, o necesita tiempo de actividad 24/7, estas herramientas
probablemente no son, en general, adecuadas para sus requerimientos. De hecho,
probablemente ya esté utilizando scripts T-SQL o PowerShell personalizados para
realizar el mantenimiento de la base de datos.

Dicho esto, aunque a veces son reacios a admitirlo, conozco a muchos DBA
experimentados que todavía utilizan el Asistente para Planes de Mantenimiento
y/o el Diseñador de Planes de Mantenimiento de vez en cuando. Junto con sus
sistemas de “misión crítica”, incluso los DBAs experimentados mantienen las
bases de datos de las instancias de SQL Server más pequeñas y menos activas y,
para ello, estas herramientas son la forma más rápida y sencilla de crear y
programar el conjunto de tareas de mantenimiento que ayudarán a garantizar el
buen funcionamiento de estos sistemas.
OBJETIVOS DE ESTE LIBRO

A medida que cubrí cómo utilizar el Asistente para Planes de Mantenimiento y el

Diseñador de Planes de Mantenimiento en este libro, he tratado de mantener los
siguientes objetivos en mente:

 Mantener el libro en un nivel que la mayoría de los DBA no profesionales

pueden entender.
 No sólo para cubrir la mecánica de cómo utilizar el Asistente para Planes de
Mantenimiento y el Diseñador de Planes de Mantenimiento, sino también
para ofrecer consejos prácticos sobre la mejor manera de mantener tus
bases de datos.
 Para proporcionar un enfoque tutorial fácil de leer para aprender.
 Para ofrecer muchas de las mejores prácticas del mundo real.

EDICIONES DE SQL SERVER CUBIERTAS EN ESTE

LIBRO

Este libro cubre el uso del Asistente para Planes de Mantenimiento y el Diseñador
de Planes de Mantenimiento para SQL Server 2005 y SQL Server 2008, incluidas
las ediciones Standard y Enterprise. Si está ejecutando SQL Server 2005, debería
estar en el Service Pack 2 o posterior, ya que el Service Pack 2 introdujo algunos
cambios en el Asistente para Planes de Mantenimiento y en el Diseñador de
Planes de Mantenimiento que lo acercan a SQL Server 2008.

Todas las capturas de pantalla y ejemplos son de SQL Server 2008, que, en
ocasiones, varia de SQL Server 2005. Cuando hay diferencias significativas, les
señalare.

SQL Server 2000 y anteriores no están cubiertos porque los Planes de

Mantenimiento cambiaron sustancialmente entre SQL Server 2000 y SQL Server
20005. Aunque la implementación cambió bastante, las recomendaciones de
mantenimiento de la base de datos que hago en este libro todavía se aplican a
SQL Server 2000 y versiones anteriores.
CAPITULO 1: POR QUÉ ES IMPORTANTE EL
MANTENIMIENTO DE LAS BASES DE DATOS?

Más veces de lo que puedo contar, he visto una empresa instalar bases de datos
de SQL Server sin primero crear cualquier forma de plan de mantenimiento. Estos
servidores tararear alegremente sin el menor problema. Es decir, hasta que haya
un problema. En este punto, el rendimiento de las consultas disminuye
drásticamente o los servidores se quedan sin espacio en disco o, en casos
extremos, las bases de datos se corrompen. Y oh, por cierto, nadie se molestó en
configurar un plan de copia de seguridad, por lo que no hay copias de seguridad
para restaurar. ¡Vaya!.

El objetivo de implementar un plan de mantenimiento de la base de datos es

ayudar a prevenir los tipos de problemas que acabamos de describir. Si se
implementa correctamente, un plan de mantenimiento de la base de datos puede
ayudar a asegurar que las bases de datos de SQL Server funcionen
adecuadamente y, en caso de que exista un problema, proporcionar las copias de
seguridad necesarias para minimizar la perdida de datos. Otro beneficio de
implementar un plan de mantenimiento de la base de datos es que ayuda a
prevenir, o detectar tempranamente, muchos tipos diferentes de problemas
relacionados con la base de datos. Al ser proactivo con un buen plan de
mantenimiento, el tiempo dedicado a solucionar problemas después del hecho a
menudo se reduce.

En este capítulo, revisaremos algunas de las tareas de mantenimiento de bases

de datos más importantes con las que un DBA debe estar relacionado, como las
copias de seguridad de la base de datos y las comprobaciones de integridad, que
se incluirán en prácticamente todos los planes de mantenimiento de la base de
datos.

A continuación consideraremos las cuatro herramientas principales disponibles

para implementar estas tareas de mantenimiento. Nos centraremos en las dos
herramientas que están en el corazón de este libro, a saber, el Asistente para el
Plan de Mantenimiento de la base de datos y el Diseñador de Plan de
Mantenimiento, pero también consideraremos las opciones de utilizar secuencias
de comandos de T-SQL y PowerShell.

EL ALCANCE DEL MANTENIMIENTO DE LA BASE DE

DATOS

Si pidiera a diez DBA diferentes que definieran “mantenimiento de la base de

datos”, probablemente obtendría diez respuestas diferentes. El problema es que el
término “mantenimiento de bases de datos” no está claramente definido dentro de
la comunidad de DBA. Tomado literalmente, el término se refiere al mantenimiento
de las bases de datos de SQL Server. Sin embargo, la mayoría de los DBA
confieren al término un significado más general, que abarca el mantenimiento no
sólo de las bases de datos, sino también de las instancias de SQL Server en las
que residen, del sistema operativo y del cuadro físico en el que se ejecuta SQL
Server.

Cada parte del entorno de SQL Server más grande debe gestionarse y
mantenerse cuidadosamente para garantizar un alto nivel de rendimiento y
disponibilidad. Sin embargo, para los propósitos de este libro, voy a interpretar el
término literalmente y definirlo como sigue:

**********************************************************************************************

Definición: Plan de Mantenimiento de la Base de Datos

Un plan de mantenimiento de bases de datos es un conjunto de tareas específicas

y proactivas que deben realizarse regularmente en las bases de datos para
garantizar su adecuado rendimiento y disponibilidad.

**********************************************************************************************
En otras palabras, este libro se centra únicamente en las bases de datos y en
cómo utilizar el Asistente para Planes de Mantenimiento y el Diseñador de Planes
de Mantenimiento para realizar el mantenimiento básico de la base de datos.

Por importantes que sean, este libro no cubre otros problemas relacionados con la
salud del ecosistema de SQL Server más amplio. Como tal, mientras que todo lo
que en este libro es importante, es sólo un subconjunto de todas las cosas que un
DBA necesita hacer para mantener servidores SQL sanos. Para obtener
información sobre estos temas más amplios, realice una búsqueda en internet en
“Practicas recomendadas de SQL Server” para encontrar información adicional.

Mi meta en este libro, de hecho la meta del Asistente y Diseñador de Plan de

Mantenimiento, es cubrir aquellas tareas críticas de mantenimiento de bases de
datos que, como mínimo, deben aplicarse a todas las bases de datos para
asegurar un rendimiento y disponibilidad adecuados. Es suficiente el rendimiento
“adecuado” en lugar de “optimo”? Esto, en última instancia, es una decisión de
negocios, basada en la naturaleza de la función de negocio que soporta una base
de datos determinada, y en la cantidad de tiempo, recursos y dinero que la
organización está preparada para invertir. Si una organización no tiene los
recursos (o no está dispuesta a gastarlos), entonces, hasta cierto punto, tiene que
aceptar un rendimiento más lento y una menor disponibilidad de sus servidores
SQL.

Esta es una elección perfectamente racional. Muchas instancias de SQL Server,

especialmente aquellas con bases de datos pequeñas o un pequeño número de
usuarios, a menudo no necesitan ser “optimizadas a la perfección” para el
rendimiento o incluso estar altamente disponibles. Si una consulta dura 15
segundos para devolver un resultado, o si una base de datos va hacia abajo
durante un par de horas, o incluso un día, la organización va a seguir funcionando.
En tales casos, los Planes de Mantenimiento cubiertos en este libro serán
suficientes para asegurar que las bases de datos funcionen sin problemas y con
un rendimiento aceptable. También serán adecuados para el público objetivo
principal de este libro; a saber, DBAs accidentales o DBAs de tiempo completo
que están empezando y que gestionan instalaciones de SQL Server de menor
importancia no críticas.

El mismo argumento no se aplica a las bases de datos que soportan funciones

empresariales de misión crítica. En estos casos, también tendrá que invertir
tiempo en crear planes de mantenimiento más flexibles y potentes, probablemente
utilizando secuencias de comandos de T-SQL o PowerShell, en lugar de utilizar el
Asistente o Diseñador de Planes de Mantenimiento de Bases de Datos. Por
supuesto, las organizaciones que optan por tener servidores SQL de alto
rendimiento y altamente disponibles tienen que hacer una gran inversión de
recursos para lograr este objetivo. No hay un plan de mantenimiento correcto o
incorrecto; sólo diferentes opciones basadas en diferentes necesidades.

DIFERENTES ENFOQUES PARA EL MANTENIMIENTO DE

BASES DE DATOS

Hay muchas maneras diferentes que los DBA pueden optar por realizar el
mantenimiento de la base de datos. En esta sección, echaremos un vistazo a
cuatro de estas opciones, incluyendo sus pros y sus contras. Esto debería
permitirle determinar la opción que mejor se adapte a sus necesidades
particulares.

Como se señaló anteriormente, el enfoque de este libro está en las dos primeras
herramientas: el Asistente para Planes de Mantenimiento y el Diseñador de Planes
de Mantenimiento.

ASISTENTE PARA PLAN DE MANTENIMIENTO

El Asistente para Plan de Mantenimiento es una de las dos herramientas que SQL
Server proporciona para crear planes de mantenimiento.
**********************************************************************************************

Una nota sobre la terminología

SQL Server utiliza el término “Plan de Mantenimiento” (observe la capitalización)

para referirse a un plan de mantenimiento de base de datos creado mediante el
Asistente para Planes de Mantenimiento o el Diseñador de Planes de
Mantenimiento.

**********************************************************************************************

Bajo las cubiertas, cada Plan de mantenimiento toma la forma de un paquete

SSIS, que se programa para ejecutarse en uno o más trabajos del Agente de SQL
Server y realizará las diversas tareas que conforman un plan de mantenimiento de
la base de datos. Veremos esto en más detalle en el Capítulo 3.

El objetivo del Asistente para Planes de Mantenimiento es guiarlo paso a paso, a

través de la creación de un Plan de Mantenimiento, sin necesidad de realizar
ninguna codificación, lo que facilita y agiliza todo el proceso. Aunque el Asistente
no incluye todas las posibles funciones u opciones de mantenimiento de la base
de datos, incluye las tareas básicas de mantenimiento de bases de datos que
todos los DBA deben realizar en sus servidores SQL. Como tal, es a menudo una
herramienta apropiada para el DBA de tiempo parcial / accidental, o incluso para
DBAs de tiempo completo. Por ejemplo, si las bases de datos son pequeñas, el
número de usuarios es bajo, no se requiere disponibilidad de servidor alta y hay
ventanas de mantenimiento disponibles, esta herramienta es más que adecuada
en la mayoría de los casos.

También tiene las siguientes ventajas:

 El Plan de Mantenimiento resultante puede ser modificado y ampliado:

Si es necesario, utilizando el Diseñador de Plan de Mantenimiento. Muchos
DBA utilizan el Asistente para crear su plan de mantenimiento “base” y, a
continuación, utilizan el Diseñador para ajustarlo.
  La herramienta incluye una opción para crear planes de
mantenimiento de múltiples servidores: Lo que significa que puede crear
planes de mantenimiento para varios servidores en un solo paso. Sin
embargo esta característica es difícil de configurar y tiene algunos
problemas de compatibilidad hacia atrás, por lo que puede no funcionar
para todos os entornos de SQL Server. Como tal, tienden a evitar su uso.
La misma característica está disponible en el Diseñador de Plan de
Mantenimiento y se discute brevemente en el Capítulo 16 (aunque tiene los
mismos inconvenientes).

De muchas maneras, el Asistente para Planes de Mantenimiento alcanza su

objetivo de facilitar la creación de planes de mantenimiento de bases de datos. Sin
embargo, se queda corto en algunas áreas, y puede causar problemas para los
incautos. El asistente asume que entiende completamente cada opción que le
ofrece a usted, y cómo cada uno afecta a sus bases de datos. Si usted no
entiende las opciones, y adivina su significado, es muy fácil crear un plan de
mantenimiento que funciona terriblemente. Por desgracia, el Asistente no es lo
suficientemente inteligente como para evitar tomas estas pobres decisiones. Sin
embargo, en este libro, voy a explicar todas esas opciones para que pueda utilizar
la herramienta a su máxima ventaja, y evitar tales problemas de rendimiento.

Tan útil como la herramienta puede ser, los DBA deben ser plenamente
conscientes de lo que puede y no puede hacer. Después de haber creado algunos
planes de mantenimiento con el Asistente, algunos DBA novatos confían en
asumir que sus bases de datos se mantienen completamente. Como ya hemos
contado, el Asistente para Planes de Mantenimiento solo realiza tareas de
mantenimiento básico, en lugar de todas las posibles tareas de mantenimiento de
base de datos que deben considerarse para una base de datos o servidor
determinado. Por ejemplo, sólo porque se crean copias de seguridad con el
Asistente, esto no garantiza que las copias de seguridad sean buenas
(restaurables) o que se hayan desplazado del servidor para protegerlas si la
instancia de SQL Server experimenta un fallo de disco. Tales tareas (otros
ejemplos se tratan un poco más adelante en este capítulo) deben realizarse fuera
del Asistente para planes de mantenimiento.

El Asistente también tiene las siguientes deficiencias específicas:

 Número limitado de opciones de mantenimiento de la base de datos:

Si se necesita opciones de mantenimiento de bases de datos que no se
proporcionan, tendrá que recurrir a scripts de T-SQL o PowerShell, o utilizar
scripts para algunas tareas y el Asistente para otros.
 Falta de granularidad: Por ejemplo, el Asistente para plan de
mantenimiento no puede determinar qué índices necesitan reconstruirse y
cuales no necesitan ser reconstruidos y, por lo tanto, tiene que
reconstruirlos. Por lo tanto, a menudo se necesita más tiempo para ejecutar
un plan de mantenimiento creado con el Asistente que un plan
personalizado creado mediante scripts de T-SQL o PowerShell.
 Incapacidad para ejecutar múltiples tareas: Cada tipo de tarea de
mantenimiento dentro de un plan de mantenimiento solo puede configurarse
para ejecutarse una vez dentro de dicho plan. Esto puede hacer que
algunas tareas sean más difíciles de lo que necesitan. Por ejemplo, la tarea
de mantenimiento diseñada para eliminar archivos de copia de seguridad
antiguos, sólo puede eliminar un tipo de archivo a la vez, como BAK o TRN,
y no ambos al mismo tiempo. Debido a esto, puede que tenga que crear
varios planes de mantenimiento sólo para realiza tareas sencillas como
esta.
 No hay scripts para otras instancias: Los planes de mantenimiento
creados con el asistente no se pueden secuencias y mover a otras
instancias de SQL Server, aunque pueden crearse planes de
mantenimiento multi-servidores.
 Bugs en algunas versiones anteriores del Asistente: Si utiliza SQL
Server 2005 Service Pack 2 o superior, o SQL Server 2008, entonces no
debería tener problemas.
Algunos DBA experimentados le dirán que los “DBA reales” no utilizan el Asietente
para Planes de Mantenimiento y, en su lugar, escriben sus planes de
mantenimiento de bases de datos desde cero, utilizando scripts T-SQL o
PowerShell. En realidad, esto no es cierto. Muchos “DBA reales” utilizan el
Asistente para Planes de Mantenimiento, cuando es apropiado. Gran parte de este
libro se dedicará a informarle cuando es pertinente utilizar el Asistente para Planes
de Mantenimiento y cuando no es pertinente.

DISEÑADOR DE PLAN DE MANTENIMIENTO

Si busca el “Diseñador de Planes de Mantenimiento” en los libros de pantalla, no
encontrará nada que se refiera a este nombre exacto. Esto se debe a que tuve
que proporcionar un nombre para una característica de SQL Server que no parece
tener un nombre oficial consistentemente utilizado. A veces se denomina “Nuevo
Plan de Mantenimiento”, o “Pestaña de Diseño del Plan de Mantenimiento”, y otras
veces como “Plan del Diseñador de Plan de Mantenimiento”.

Esencialmente, el Diseñador de Plan de Mantenimiento es una interfaz GUI de

arrastrar y soltar que se encuentra en SSMS, basada en la superficie de
Diseñador de Servicios de Integración de SQL Server (SSIS), que permite a los
DBA diseñar manualmente y crear planes de mantenimiento desde cero o
modificar Planes de mantenimiento Creado originalmente con el Asistente para
plan de mantenimiento.

El Diseñador de Plan de Mantenimiento ofrece más funciones que el Asistente y

esto, junto con el elemente de tener un control manual, significa que el DBA puede
crear planes de mantenimiento más completos, flexibles y personalizados que lo
que es posible con el Asistente.
**********************************************************************************************

NOTA

Los capítulos 16 a 19 cubren detalladamente del Diseñador de planes de

mantenimiento, después de investigar el Asistente para planes de mantenimiento.
La funcionalidad ofrecida por cada herramienta se superpone sustancialmente, de
modo que una vez conozca las características del Asistente para Planes de
Mantenimiento, ya conocerá la mayoría de las funciones del Diseñador de Plan de
Mantenimiento.

**********************************************************************************************

Una ventaja del Diseñador sobre el Asistente, en mi opinión, es que te muestra el

código T-SQL que se ejecutará cuando se ejecuta una tarea de mantenimiento.
Este código puede ayudarle a comprender mejor exactamente lo que está
haciendo la tarea y también puede utilizarse como un ejemplo de cómo utilizar T-
SQL para crear sus propios planes de mantenimiento, si decide escribir su propio
T-SQL para mejorar sus planes de mantenimiento. Además, la herramienta
Diseñador tiene las siguientes ventajas específicas:

 Capacidad de control de flujo: El diseñador le permite crear rutas de

ejecución de ramificación basadas en la lógica condicional. Por ejemplo,
puede especificarse que, si falla una tarea de mantenimiento en particular,
se envía un mensaje de correo electrónico al equipo DBA, notificándoles el
problema.
 Ejecución de varias tareas: A diferencia del asistente, puede ejecutar una
tarea varias veces desde dentro del mismo plan de mantenimiento. Esto
soluciona el problema descrito anteriormente con el Asistente para planes
de mantenimiento. Ahora, dentro de un solo plan, puede eliminar archivos
BAK y TRN dentro de un Plan de Mantenimiento único.
 Dos tareas adicionales, solo en el Diseñador: Una tarea de ejecución de
instrucciones T-SQL le permite crear una tarea de mantenimiento que
puede hacer prácticamente cualquier cosa, y que se ejecute desde dentro
 de un plan de mantenimiento. Una tarea de Notificar al Operador
proporciona un medio poderoso para notificar a un DBA si una tarea de
mantenimiento no se ejecuta correctamente.

Por supuesto, el inconveniente más obvio de usar el Diseñador es que es un

procedimiento manual y por lo tanto es más lento, y algo más difícil de aprender
que el Asistente.

A pesar de ofrecer una mayor flexibilidad que el Asistente, el Diseñador todavía no

puede igualar la potencia y la flexibilidad de los scripts de T-SQL y PowerShell. De
hecho, aparte de la capacidad de agregar lógica condicional, la capacidad de
ejecutar una tarea varias veces dentro de un plan y la adición de dos tareas más,
el Diseñador sufre de la mayoría de las deficiencias enumeradas para el Asistente.

Muchos DBAs pueden comenzar usando el Asistente para Planes de

Mantenimiento pero, una vez que lo han dominado, a menudo toman el tiempo
para aprender las características adicionales del Diseñador de Plan de
Mantenimiento, porque el salto de aprender el Asistente al Diseñador no es grande
y, al mismo tiempo, están ganando mayor flexibilidad al crear planes de
mantenimiento.

SCRIPTS T-SQL

Hoy en día, la mayoría de los DBAs de tiempo completo y experimentado usan

secuencias de comandos T-SQL, en combinación con trabajos del SQL Server
Agent, para realizar el mantenimiento de su base de datos. Esto se debe que los
scripts T-SQL ofrecen 100% de flexibilidad cuando se trata de mantener la base
de datos; usted puede hacer prácticamente cualquier cosa que desee o necesite
hacer.

Por ejemplo, si especifica la tarea Rebuild Index en el Asistente para plan de

mantenimiento, reconstruirá automáticamente todos los índices de una base de
datos. Si bien esto logra el trabajo de reconstruir índices, es un proceso que
requiere muchos recursos. La solución ideal es ejecutar una secuencia de
comandos que identifica sólo los índices muy fragmentados y los reconstruye,
pero deja a los demás en orden, conservando así los recursos del servidor.
Desafortunadamente, no puede hacer esto con el Asistente para plan de
mantenimiento; se requieren scripts T-SQL o PowerShell personalizados.

Además, los scripts T-SQL ofrecen las siguientes ventajas:

 Acceso al Sistema Operativo: T-SQL ofrece la posibilidad de acceder al

sistema operativo (OS), aunque no siempre es fácil o tan flexible como le
gustaría. Esta es una opción utilizada por algunos DBA para eliminar
antiguos archivos BAK y TRN.
 Portabilidad: Los scripts T-SQL correctamente escritos se pueden mover
fácilmente de un servidor a otro.
 Compartir Scripts: Muchos DBA comparten scripts T-SQL genéricos de
mantenimiento de bases de datos en varios sitios de la comunidad, por lo
que no es necesario reinventar la rueda. Por supuesto, no desea ejecutar
un script en su propio servidor a menos que entienda completamente lo que
hace. Todavía necesita un buen conocimiento de T-SQL antes de usar el
script T-SQL de otra persona. Echa un vistazo a estas URL para ver
ejemplos de algunos scripts libremente disponibles de T-SQL utilizados
para realizar el mantenimiento de la base de datos:
 https://ola.hallengren.com/
 http://sqlfool.com/2009/06/index-defrag-script-v30/
 http://www.grics.qc.ca/YourSqlDba/index_en.shtml
 http://www.simple-talk.com/sql/database-administration/sql-server-
tacklebox-free-ebook/

Por supuesto, todo esto supone un sólido conocimiento práctico del lenguaje T-
SQL, así como una buena comprensión de los internos de SQL Server. Para la
mayoría de las personas, esto implica una larga curva de aprendizaje. Codificación
de scripts T-SQL puede ser de mucho tiempo, y propenso a errores. A veces la
depuración de estos scripts lleva más tiempo que escribirlos. Además, si no tiene
cuidado con la forma en que escribe sus scripts de mantenimiento, es posible que
cuando la próxima versión de SQL Server se publique sus scripts pueden
necesitar ser modificados (a veces sustancialmente) para trabajar con la nueva
versión.

Por último, a parte de las herramientas de terceros, no hay una forma fácil de
automatizar la ejecución de sus scripts de mantenimiento de T-SQL en varios
servidores. Para eso, necesitarás aprender PowerShell.

Mientras que los scripts T-SQL podrían ser la elección de la mayoría de los DBA
hoy en día, no crea que esta sea la única opción que se tenga. Si desea mantener
el mantenimiento de la base de datos de forma sencilla, el Asistente para planes
de mantenimiento y el Diseñador de planes de mantenimiento pueden funcionar
perfectamente. Sin embargo, si necesita una opción aún más flexible que T-SQL,
considere el uso de scripts de PowerShell.

SCRIPTS POWERSHELL

PowerShell es el lenguaje de secuencias de comandos de Shell de línea de

comando más reciente de Microsoft que permite a los DBA acceder
completamente a los modelo de objetos tanto del sistema operativo como de SQL
Server. También soporta una lógica mucho más compleja que T-SQL y tiene mejor
manejo de errores. Esta combinación le permite crear scripts de mantenimiento de
bases de datos, puede utilizarse fácilmente para realizar el mantenimiento a las
bases de datos en varios servidores SQL.

Microsoft ha estado promoviendo ávidamente PowerShell, aunque la adopción ha

sido lenta, la razón principal es que implica aprender un lenguaje de scripting
orientado a objetos completamente nuevo, que es muy ajeno a muchos DBAs.
Además, de esto, el DBA aún necesita conocer los componentes internos de T-
SQL y SQL Server, así como los objetos de administración de SQL Server (SMO)
y el modelo de objetos de SO (suponiendo que decida aprovechar la capacidad de
PowerShell para acceder al sistema operativo).
Esta es una curva de aprendizaje empinada y significa que los scripts de
PowerShell, inicialmente al menos, pueden ser aún más lentos para escribir y
depurar que T-SQL. Además, mientras que el script de mantenimiento apropiado
de T-SQL puede ejecutarse en la mayoría de los servidores SQL Server, es
posible que muchos servidores antiguos no tengan instalado PowerShell.

A medida que pasa el tiempo, estoy adivinando que verá más y más DBAs
empezando a pasar de los scripts de T-SQL a los scripts de PowerShell,
especialmente aquellos que gestionan un gran número de instancias de SQL
Server. Esto continuara siendo un movimiento lento, hasta que más DBAs no sólo
se familiaricen con el poder y la flexibilidad de PowerShell, sino que dominen la
gran cantidad de conocimientos necesarios para sacar el máximo provecho de
ella.

Mientras tanto, el cuerpo de la comunidad de scripts está empezando a crecer.

Para obtener ejemplos de cómo utilizar PowerShell para realizar el mantenimiento
de la base de datos, consulte este proyecto CodePlex.com.

http://sqlpsx.codeplex.com/

Alternativamente, puede visitar http://www.simple-talk.com y hacer una búsqueda

de “powershell”, para encontrar muchos artículos sobre el tema.

TAREAS PRINCIPALES DEL PLAN DE MANTENIMIENTO

Como se explicó anteriormente, la intención básica del Asistente para planes de

mantenimiento y del Diseñador de Planes de Mantenimiento es permitirle
configurar las tareas de mantenimiento de bases de datos “principales” que deben
realizarse en más o menos todas las bases de datos de SQL Server. Estas tareas
se revisan en las siguientes secciones.
BACKUPS DE BASE DE DATOS

Tan obvio como suena este consejo, es sorprendente la cantidad de servidores

SQL que me he encontrado con que no tienen copias de seguridad adecuadas. Si
la base de datos se corrompe, y usted no tiene una copia de seguridad
restaurable, entonces probablemente terminará perdiendo sus datos.

Es fundamental que cualquier plan de mantenimiento tenga en cuenta los

siguientes dos tipos de copia de seguridad:

 Copia de Seguridad de Base de Datos Completa: Realiza una copia de

seguridad de los archivos de datos (mdf) de dicha base de datos. Las
copias de seguridad completas son el núcleo de cualquier plan de
recuperación de desastres.
 Copia de Seguridad de Log de Transacciones: Realiza una copia de
seguridad de los archivos de logs (ldf) de dicha base de datos.

Mientras que la mayoría de la gente entiende por qué las copias de seguridad
completas de la base de datos son importantes, algunas no entienden
completamente la razón detrás de las copias de seguridad del log de
transacciones. El propósito de las copias de seguridad del log de transacciones es
doble. En primer lugar, sirven para hacer una copia de seguridad de todas las
transacciones que se han registrado en el archivo log de transacciones desde la
última copia de seguridad de log. En caso de un desastre, estas copias de
seguridad de logs se pueden aplicar a una copia restaurada de una copia de
seguridad completa de la base de datos y cualquier transacción que se haya
producido después de la copia de seguridad completa será “activada” para
restaurar los datos a un punto dado en el tiempo. Así que minimice cualquier
pérdida de datos. Por ejemplo, si realiza una copia de seguridad del log de
transacciones una vez por hora (y tiene una copia de seguridad completa valida),
teóricamente, lo máximo que podría perder equivaldría a una hora de
transacciones.
En segundo lugar, para las bases de datos que utilizan el modelo de recuperación
completa o en bloque, esta acción trunca el log de transacciones para que no
crezca demasiado. Muchos DBA de tiempo parcial / accidental realizan copias de
seguridad completas en sus bases de datos, pero no realizan copias de seguridad
del log de transacciones. Como resultado, el log de transacciones no se trunca y
crece y crece hasta que la unidad en loa que se ejecuta se queda sin espacio en
disco, haciendo que SQL Server deje de funcionar.

Es responsabilidad de cada DBA asegurar que todas las bases de datos estén
debidamente respaldadas y protegidas.

VERIFICAR LA INTEGRIDAD DE UNA BASE DE DATOS

Es posible que los datos de una base de datos SQL Server se corrompan, tal vez
debido a un fallo en el subsistema de disco o algún otro evento. Aunque no es
común que una base de datos se dañe físicamente de esta manera, la posibilidad
debe ser considerada. La corrupción de datos puede ocurrir sólo en un área
específica de la base de datos, y es posible que el daño no se pueda descubrir
durante algún tiempo, generalmente sólo cuando se hace un intento de consultar
los datos dañados. Entre el momento en que ocurrió el daño y el momento en que
fue descubierto, muchos días pueden haber pasado, y cada una de las copias de
seguridad realizadas durante este tiempo incluirá los datos dañados.

Cuanto más tiempo el daño permanezca sin descubrir, más fuera de fecha será la
copia de seguridad intacta más reciente. Si se eliminan las copias de seguridad
antiguas en un horario regular, es posible que no tenga una copia intacta. En
cualquier caso puede terminar perdiendo una gran cantidad de datos, por lo que
es importante para los DBA comprobar periódicamente la integridad física de sus
bases de datos mediante el comando DBCC CHECKDB.
MANTENIMIENTO A LOS INDICES DE UNA BASE DE
DATOS

Con el tiempo, a medida que los índices se someten a modificaciones de datos

(INSERT, UPDATE y DELETE), la fragmentación del índice puede ocurrir en forma
de espacios en las páginas de datos que crean espacio vacío desperdiciado y en
un ordenamiento lógico de los datos que ya no coincide con Ordenamiento físico
de los datos.

Ambas formas de fragmentación son subproductos normales de modificaciones de

datos, pero, por desgracia, ambas pueden perjudicar el rendimiento de SQL
Server. El espacio perdido reduce el número de filas que se pueden almacenar en
la caché de datos de SQL Server, lo que puede dar lugar a una mayor E/S de
disco. El problema de ordenación de la página de índice también provoca una
actividad adicional del disco, ya que a menudo se necesita más trabajo para
encontrar los datos en el disco y moverlos a la caché de datos, que si las páginas
estuvieran en orden físico.

SQL Server no corrige automáticamente los problemas de fragmentación de

índice. La única manera de eliminar el espacio perdido y restaurar el orden
correcto de la página es reconstruir o reorganizar los índices de forma regular.
Esto requiere que el DBA cree un trabajo de mantenimiento para realizar estas
tareas.

MANTENIMIENTO A LAS ESTADISTICAS DE INDICES Y

COLUMNAS

El optimizador de consultas utiliza estadísticas de índices y columnas como parte

de su proceso de evaluación, ya que trata de determinar un plan de ejecución de
consultas óptimo. Si las estadísticas son antiguas o incompletas, el Optimizador
de consultas podría crear un plan de ejecución ineficiente, lo que ralentiza
considerablemente el rendimiento de una consulta. En teoría, las estadísticas de
índices y columnas son auto-sostenibles, pero este proceso de auto-
mantenimiento no es perfecto en la práctica.

Para asegurar de que el optimizador tiene las estadísticas más completas y

actuales a su disposición, el DBA debe crear una tarea de mantenimiento para
asegurarse de que se actualizan periódicamente, ya sea reconstruyendo los
índices o actualizando las estadísticas utilizando los comandos UPDATE
STATISTICS o Sp_updatestats.

ELIMINAR DATOS ANTIGUOS DE MSDB

La base de datos msdb de SQL Server almacena datos históricos sobre varias
actividades, como detalles acerca de copias de seguridad, trabajos del Agente de
SQL Server y ejecución del Plan de Mantenimiento. Si se deja desatendido, la
base de datos msdb puede crecer con el tiempo hasta un tamaño considerable,
desperdiciando espacio en disco y ralentizando las operaciones que utilizan la
base de datos msdb. En la mayoría de los casos, estos datos no necesitan ser
guardados durante un periodo largo, y deben eliminarse usando comandos como
sp_delete_backuphistory, sp_purge_jobhistory y sp_maintplan_delete_log.

ELIMINAR COPIAS DE SEGURIDAD ANTIGUAS

Si bien la realización de copias de seguridad de base de datos es importante, no

es necesario mantenerlas para siempre. De hecho, si no limpia los archivos de
copia de seguridad más antiguos, los discos duros de SQL Server se llenarán
rápidamente, causando todo tipo de problemas. Es tarea del DBA asegurarse de
que las copias de respaldo innecesarias se eliminan de un servidor SQL de forma
regular.
QUE ESTA AFUERA DEL ALCANCE DEL ASISTENTE Y
DISEÑADOR DE PLAN DE MANTENIMIENTO?

Si bien los Planes de Mantenimiento son una forma conveniente de realizar gran
parte de su trabajo de mantenimiento de la base de datos, ni el Asistente ni el
Diseñador pueden hacer todo su trabajo para usted. Aunque las tareas incluidas
en los Planes de mantenimiento son una buena primera puesta en marcha, el
Asistente y el diseñador no tienen la intención de permitirle realizar todas las
tareas de mantenimiento que podrían incluirse en su estrategia de mantenimiento
de la base de datos.

Por ejemplo, las siguientes tareas de mantenimiento de base de datos importantes

adicionales no están cubiertas por el Asistente o Diseñador:

 Identificar y eliminar la fragmentación física de archivos.

 Identificar índices perdidos, duplicados o no utilizados.
 Proteger copias de seguridad para que estén disponibles cuando sea
necesario.
 Comprobar que las copias de seguridad son buenas y pueden ser
restauradas.
 Monitorear el desempeño
 Supervisar los mensajes de error de SQL Server y del sistema operativo.
 Controlar el espacio restante en disco.
 Y mucho, mucho más.

La moraleja de la historia es que, si bien los Planes de mantenimiento son una

herramienta útil para muchos DBA, no son la herramienta perfecta para todos los
DBA y solo realizara un subconjunto de las tareas de mantenimiento de base de
datos necesarias. Si el Asistente para planes de mantenimiento o Diseñador
satisface sus necesidades, utilícelos. Por otro lado, si no cumplen adecuadamente
con sus necesidades, entonces no las use. Los scripts T-SQL o PowerShell
creados por encargo ofrecen en cambio mucha más potencia y flexibilidad. Si bien
puede haber una curva de aprendizaje empinada para crear scripts
personalizados, este es el conocimiento que podrá utilizar en otros lugares como
un DBA, y no va a perder.

RESUMEN

En este capítulo hemos aprendido qué es el mantenimiento de la base de datos y

por qué es importante, y hemos considerado las tareas básicas de mantenimiento
de bases de datos que comprenderán casi todos los planes de mantenimiento de
la base de datos.

También exploramos cuatro maneras diferentes de realizar el mantenimiento de la

base de datos, incluyendo el uso del Asistente de Plan de Mantenimiento y el
Diseñador de Mantenimiento, que son las herramientas en las que nos
centraremos en este libro, así como scripts de T-SQL y PowerShell.

En los siguientes capítulos, aprendemos cómo crear planes de mantenimiento

usando el Asistente para planes de mantenimiento. A medida que aprendamos a
usar el Asistente, también estaremos aprendiendo mucha información que se
aplica al Diseñador de Plan de Mantenimiento, ya que ambas herramientas
realizan tareas similares y ofrecen opciones de configuración similares.
CAPITULO 2: ANTES DE CREAR PLANES DE
MANTENIMIENTO….

Tanto el Asistente de Plan de Mantenimiento como el Diseñador de Plan de

Mantenimiento tienen la capacidad de enviar correos electrónicos a los DBAs,
proporcionándoles información sobre el estado de los Planes de Mantenimiento
que se han ejecutado. El número de correos electrónicos y su contenido varían
según la herramienta que utilice para configurar estas notificaciones por correo
electrónico.

En el caso del Asistente para plan de mantenimiento, puede configurar una opción
que le enviara un correo electrónico cada vez que se ejecute un plan de
mantenimiento, que incluye información estándar sobre qué plan se ejecutó y qué
pasos se ejecutaron e informe cualquier error que haya ocurrido. Una vez
configurada esta opción, enviara un correo electrónico cada vez que se ejecute el
plan de mantenimiento y siempre incluirá la misma información estándar.

El diseñador de Plan de Mantenimiento, por otro lado, tiene más opciones. En

primer lugar, permite al DBA configurar las condiciones bajo las cuales se enviarán
las notificaciones por correo electrónico. Por ejemplo, en lugar de enviar siempre
un correo electrónico, como lo hace el Asistente para planes de mantenimiento
cuando se ejecuta un plan de mantenimiento, el Diseñador de planes de
mantenimiento puede enviar correos electrónicos basados en lógica condicional.
Por lo tanto, si sólo desea recibir correos electrónicos si falla un plan de
mantenimiento, y no todo el tiempo, puede configurarlo. Además, el Diseñador de
Plan de Mantenimiento le permite crear mensajes de correo electrónico
personalizados, de modo que cuando reciba un mensaje de correo electrónico,
sepa exactamente cuál es el problema, en lugar de tener que consultar u informe
largo.

En cualquier caso, antes de poder recibir mensajes de correo electrónico de los

Planes de mantenimiento, creados con el Asistente para planes de mantenimiento
o con el Diseñador de planes de mantenimiento, hay dos pasos preliminares de
configuración que debe seguir:

1. Configurar el corre de la Base de Datos.

2. Cree uno o más operadores de SQL Server Agent, que recibirán las
notificaciones por correo electrónico.

Estos dos pasos se describen en detalle en este capítulo. Cuando lo hayas

completado, podrá seleccionar la opción “Informe de correo electrónico” al crear
un nuevo plan de mantenimiento. Si tiene planes de mantenimiento existentes que
no informan por correo electrónico, puede modificarlos, puede hacerlo utilizando el
Diseñador de planes de mantenimiento, como se describe en el Capítulo 19.

COMO CONFIGURAR EL CORREO DE BASE DE DATOS

Aunque hay un par de maneras diferentes de configurar el correo de base de

datos, la manera más fácil es utilizar el Asistente para configuración de correo de
base de datos desde SSMS. Para iniciar este Asistente, vaya a la carpeta
Administración del servidor apropiado, haga clic en el Botón secundario en Correo
de base de datos, como se muestra en la Figura 2.1.
Figura 2.1 Uso del Asistente para configuración de correo de base de datos
para configurar el correo de base de datos por primera vez.

Haga clic en Siguiente para pasar a la pantalla inicial y el Asistente comenzara con
la pantalla Seleccionar Tarea de Configuración, como se muestra en la Figura
2.2.
Figura 2.2 El Asistente para la configuración del correo de base de datos
realiza varias tareas diferentes.

Para configurar el correo de base de datos para su uso por el Asistente de

mantenimiento, seleccione la opción Setup Database Mail by performing the
following tasks. El asistente incluso lista las tres tareas que deben completarse
para configurar Database Mail, que se explican en breve. Haga clic en Siguiente
para continuar.

Si el correo de la base de datos aún no se ha habilitado para esta instancia de

SQL Server, verá la pantalla que se muestra en la Figura 2.3. Si se ha habilitado,
no verá la pantalla.
Figura 2.3 Antes de poder configurar Database Mail, primero debe habilitarlo.

Suponiendo que el correo de base de datos no se haya activado para esta

instancia de SQL Server y vea la pantalla anterior, haga clic en Sí y se activara el
correo de base de datos. La siguiente pantalla, mostrada en la Figura 2.4, le
pedirá que cree un perfil de Correo de Base de Datos.

Un perfil es una colección de una o más cuentas SMTP que SQL Server puede
utilizar para enviar mensajes. En otras palabras, cuando SQL Server desea enviar
un mensaje, el mensaje se envía al perfil y, a continuación, el perfil es responsable
de ver que el correo electrónico se entrega realmente. Para la tolerancia a fallos,
un perfil puede incluir más de una cuenta SMTP. Por ejemplo, si el perfil intenta
enviar un correo electrónico utilizando una cuenta SMTP, pero no funciona, el
perfil intentara enviar el correo electrónico con una segunda cuenta SMTP,
suponiendo que esté disponible. Los perfiles también se pueden utilizar como
medida de seguridad, permitiendo o impidiendo que alguien lo utilice para enviar
correo.
Figura 2.4 El primer paso al configurar Database Mail es crear un nuevo
perfil.

Para crear un perfil nuevo, debe introducir un nombre de perfil, una descripción
opcional y, a continuación, agregar y configurar una o más cuentas SMTP. En este
ejemplo, crearemos y configuraremos una sola cuenta SMTP.
**********************************************************************************************

Varios Perfiles de Correo

Database Mail puede tener varios perfiles para satisfacer una amplia variedad de
tolerancia a fallos y necesidades de seguridad. Aquí, sólo necesita un solo perfil
para usarlo en sus Planes de Mantenimiento.

**********************************************************************************************

Introduzca un nombre de perfil descriptivo, como “Planes de Mantenimiento”. Si su

instancia de SQL Server tiene varios perfiles de correo, probablemente desee
introducir una descripción del uso previsto de este perfil en particular, para que no
los confunda.

A continuación, cree y configure las cuentas SMTP que utilizara Database Mail
para enviar los mensajes de correo electrónico de su plan de mantenimiento. Para
crear y configurar una cuenta SMTP, haga clic en el botón Agregar… y aparecerá
la pantalla Nueva Cuenta de Correo de la Base de Datos, como se muestra en
la Figura 2.5.
Figura 2.5 Es probable que tenga que rastrear la configuración del servidor
SMTP antes de poder completar esta pantalla.

Si nunca ha configurado un cliente de correo electrónico antes, esta pantalla

puede parecer un poco confusa. Esencialmente, usted que decir a Database Mail
qué servidor de correo debe usar para entregar mensajes de correo electrónico de
sus Planes de Mantenimiento. Si no está seguro, envíe la captura de pantalla que
se muestra en la Figura 2.5 al administrador de correo electrónico de su
organización, para que él o ella sepan qué configuración de SMTP necesita.

Cuando solicita al administrador de correo electrónico la configuración de SMTP,

también debe solicitar que se configure una cuenta de correo electrónico especial
para que sea utilizada por SQL Server. Por ejemplo, es posible que tenga
configurada una cuenta llamada sqlserver@myorganization.com o
sqlserveragent@... o maintenanceplan@... o algún otro nombre descriptivo, de
modo que cuando reciba un correo electrónico de Database Mail, sepa de donde
vino.

Echemos un vistazo a cada opción, comenzando con los atributos básicos de la

cuenta SMTP

 Account name: La cuenta SMTP debe tener un nombre para que pueda
distinguirse de otras cuentas SMTP utilizadas en el mismo perfil. Puesto
que está creando una sola cuenta SMTP para su perfil, como usted lo llame
no es importante. sin embargo, si decide tener dos cuentas SMTP, para
fines de tolerancia a fallos, entonces tendrá que nombrarlos
descriptivamente para que pueda distinguir fácilmente uno de otro. Por
ejemplo, puede utilizar el nombre del servidor SMTP como nombre de
cuenta, ya que es una buena manera de distinguir una cuenta SMTP de
otra.
 Description: Este cuadro de texto opcional se puede dejar vacío o puede
utilizarse para documentar sus ajustes. Por ejemplo, puede introducir el
nombre de la persona que proporcionó la configuración de SMTP, para que
sepa a quién volver en caso de cualquier problema.
 Outgoing Mail Server (SMTP): Esto especifica los atributos del servidor
SMTP que enviara el correo electrónico, incluyendo estas seis opciones:
 E-mail address: La cuenta de correo electronico que se ha
configurado para su uso con el correo de la base de datos de SQL
Server (por ejemplo, sqlserver@myorganization.com).
 Display Name: El nombre para mostrar de la dirección de correo
electrónico. Es probable que desee darle el mismo nombre que la
parte de usuario de la dirección de correo electrónico, como “SQL
Server”, aunque puede utilizar cualquier nombre que elija que le
recordará de dónde viene el correo electrónico.
  Reply e-mail: La dirección de correo electrónico utilizada si alguien
debe responder a un correo electrónico enviado desde la dirección
de correo electrónico indicada anteriormente. El correo de la base de
datos no puede responder a los mensajes de correo electrónico que
recibe, por lo que puede dejar esta opción vacía o agregar su propia
dirección de correo electrónico, por si alguien responde a un correo
electrónico recibido de SQL Server.
 Server Name: El nombre del servidor de correo SMTP.
Generalmente se parece a algo como mail.myorganization.com.
 Port number: El número de puerto utilizado por el servidor SMTP de
su organización. Los servidores de correo electrónico se comunican
a través de puertos TCP/IP específicos, y el número de puerto
predeterminado, 25, es el que se utiliza más comúnmente, pero
puede que no sea el que utiliza su empresa.
 This Server requieres a secure connection (SSL): Algunos
servidores SMTP requieren que se active SSL para una seguridad
adicional. Sólo seleccione esta opción si se le indica que lo haga.

La mitad inferior de la pantalla es donde especificamos las opciones de

autenticación SMTP. En la mayoría de los casos, antes de que un servidor SMTP
acepte un correo electrónico, el remitente debe iniciar sesión en el servidor SMTP
con una cuenta de correo electrónico. Esto se hace para evitar que los spammers
accedan al servidor SMTP y lo utilicen. Averigüe que modelo de autenticación
utiliza su organización y complete la información apropiada, de la siguiente
manera:

 Windows Authentication using Database Engine service credentials:

Esta opción no se utiliza comúnmente, pero si es así, debe asegurarse de
que la cuenta utilizada para el servicio Motor de Base de Datos tiene
permisos para enrutar el correo al servidor SMTP.
 Basic authentication: Este es el método de autenticación más común y
requiere que proporcione un nombre de usuario y una contraseña. En la
 mayoría de los casos, el nombre de usuario será la dirección de correo
electrónico que ha introducido anteriormente y la contraseña será la
contraseña utilizada para esta dirección de correo electrónico.
 Anonymous authentication: Esta opción se utiliza raramente porque
permite a cualquiera acceder al servidor SMTP.

Habiendo introducido valores para todos los ajustes, la pantalla se verá similar a la
mostrada en la Figura 2.6

Figura 2.6: Si la configuración de SMTP no se establece correctamente, el

correo de base de datos no funcionará.
Cuando esté satisfecho con la información de la cuenta, al hacer clic en Aceptar,
volverá a la pantalla de perfil de correo original, que mostrará la cuenta SMTP que
acaba de configurar, como se muestra en la Figura 2.7.

Figura 2.7: Aunque solo está configurando una cuenta, puede ver que se
pueden configurar varias cuentas si lo desea.

Para continuar con el Asistente para la configuración del correo de la base de

datos, haga clic en Siguiente para acceder a la pantalla Administrar Seguridad
del Perfil que se muestra en la Figura 2.8
Figura 2.8: Debe especificar si un perfil de correo es público o privado.

Como se muestra en la Figura 2.8, se ha creado su Perfil de Mantenimiento (se

denomina (“Planes de Mantenimiento”). Ahora tiene que asignar el perfil como
público o privado. Un perfil privado sólo es utilizable por usuarios o roles
específico, mientras que un perfil público permite que cualquier usuario o función
(con acceso a msdb) envíe correo. Para mantener la configuración tan simple
como sea posible, haga público el perfil del Plan de mantenimiento, seleccionando
la casilla de verificación en Público y luego haga clic en Siguiente para pasar a la
pantalla Configurar Parámetros del Sistema, que se muestra en la Figura 2.9.
Figura 2.9: Tiene la oportunidad de configurar parámetros adicionales de
Database Mail.

La última opción del Asistente para la configuración del correo de la base de datos
le permite establecer los valores de parámetros específicos del correo de base de
datos para el perfil. En general, dejaremos estas opciones con sus valores
predeterminados. El único que sugiero que considere cambiar es el valor del
parámetro Account Retry Attempts. De forma predeterminada, este valor es 1, lo
que significa que sólo hay un intento de enviar un correo electrónico. Si el servidor
SMTP está inactivo cuando se va a enviar un correo electrónico y no hay cuentas
SMTP alternativas disponibles, el correo electrónico no se entregara. Si desea
añadir algo de robustez al correo de base de datos y asegurarse de que el correo
se entregara en caso de que el servidor SMTP se detenga durante un breve
periodo de tiempo, puede optar por aumentar este valor a un número superior,
como 10. Si lo hace, y no cambia ninguno de los ajustes restantes, entonces el
corre de base de datos intentara hasta 10 veces, esperando60 segundos entre los
intentos, antes de que se dé por vencido.

Ahora está listo, así que haga clic en Siguiente para ir a la pantalla de resumen,
que se muestra en la Figura 2.10.

Figura 2.10: Ahora ha terminado de configurar el correo de la base de datos.

Después de una revisión rápida de la pantalla de resumen, haga clic en Finalizar y

aparecerá en la pantalla de configuración final… (Figura 2.11), indicando que su
perfil y su cuenta SMTP han sido creados.
Figura 2.11: Si todo ha ido bien, vera muchas entradas “Success”.

Si la pantalla Configurar…informa de éxito, el Correo de base de datos se ha

configurado correctamente para la instancia de SQL Server – o lo tiene? Aunque
los estados de Success son excelentes, todavía no sabemos si el correo de base
de datos se ha configurado correctamente. Por ejemplo, tal vez haya un error
topográfico en la dirección de correo electrónico o contraseña, que se hace al
ingresar la información de SMTP. Si lo hubiera, Database Mail no tendrá ninguna
forma de saber esto. En resumen, esto significa que usted necesita probar la
configuración.

Para probar que el correo de la base de datos realmente está funcionando como
se esperaba, cierre la pantalla de Configuring…, luego haga clic con el botón
derecho en la carpeta Database Mail, tal como lo hizo cuando inicio el Database
Mail Wizard y seleccione Send Test E-Mail, como se muestra en la Figura 2.12.

Figura 2.12: Para asegurarse de que el correo de base de datos realmente

funciona, debe enviar un correo electrónico de prueba.

Aparecerá la pantalla Send Test E-Mail, mostrada en la Figura 2.13.

Figura 2.13. Debe introducir su dirección de correo electrónico para ver si un
correo electrónico de prueba se puede enviar correctamente desde el correo
de base de datos.

Observe que la primera opción es Perfil de Correo de Base de Datos y tiene un

cuadro desplegable junto a él. Esto se utiliza para seleccionar el perfil que desea
utilizar para enviar el correo electrónico de prueba. En este caso, debe utilizar el
perfil que acaba de crear, que era Plan de Mantenimiento. Si el perfil que desea
probar no está seleccionado, puede seleccionarlo seleccionándolo en el cuadro
desplegable.

Rellene el campo “Para” con su dirección de correo electrónico y haga clic en

Enviar correo electrónico de prueba (esta casilla aparecerá atenuada hasta que
ingrese una dirección de correo electrónico). Aparecerá la pantalla mostrada en la
Figura 2.14.
Figura 2.14. Esta pantalla puede utilizarse para ayudar a diagnosticar
problemas de correo electrónico si no recibe el correo electrónico de prueba.

Después de presionar Enviar prueba de correo electrónico, el correo electrónico

de prueba se enviara a la cuenta designada. La pantalla de la Figura 2.14 le indica
que se envió (el número del correo electrónico enviado no tiene importancia), así
que compruebe su cliente de correo electrónico y compruebe que el mensaje fue
recibido. Si el servidor SMTP está ocupado o el cliente de correo electrónico sólo
realiza sondeos de correo electrónico cada pocos minutos, puede que tenga que
esperar un poco antes de que aparezca. Si no ve el correo electrónico después de
un tiempo, asegúrese de revisar su carpeta de correo no deseado para ver si
termino ahí.

Una vez que recibes el correo electrónico, sabes que el correo de base de datos
se ha configurado correctamente y estás listo para continuar con el siguiente paso,
que es configurar un operador. Si su correo nunca llega, pruebe a hacer clic en el
botón Troubleshoot….., como se muestra en la Figura 2.14, que le envía a los
artículos de Libros en pantalla que le guían a través del proceso de solución de
problemas.
COMO CONFIGURAR UN AGENTE OPERADOR EN UN
SERVIDOR DE SQL.

Cuando configuramos un plan de mantenimiento para enviar un correo electrónico,

creado con el Asistente para planes de mantenimiento o el Diseñador de planes
de mantenimiento, no podemos ingresar una dirección de correo electrónico
directamente en el plan de mantenimiento. En su lugar, configuramos los correos
electrónicos que se enviaran a un operador.

En su lugar, configuramos los correos electrónicos que se enviarán a un operador.