Plan de mantenimiento del servidor SQL: mejores prácticas en tareas y programación

Tengo la tarea de diseñar un plan de mantenimiento para nuestras bases de datos Sql Server 2005. Sé que para las copias de seguridad quiero hacer una copia de seguridad diaria completa de la base de datos y copias de seguridad del registro de transacciones cada 15 minutos. Mi problema es averiguar qué otras tareas quiero hacer y con qué frecuencia debo hacerlas.

Entonces, hasta ahora tengo esto en mente. Corrígeme si hay algún defecto en mi pensamiento o una mejor manera de hacerlo.

1. Copia de seguridad: todas las tablas, copia de seguridad completa (diariamente)
2. Copia de seguridad: tablas seleccionadas, copia de seguridad completa (cada hora)
3. Copia de seguridad: registros de transacciones (cada 15 minutos)
4. Verifique la integridad de la base de datos (diariamente)
5. Reorganizar índice (diario)
6. Actualizar estadísticas (diariamente)
7. Reducir la base de datos (semanal)
8. Índice de reconstrucción (semanal)
9. Limpieza de mantenimiento (diaria)

Recordé haber leído hace algún tiempo (cuando configuré un plan similar en otro trabajo) que algunas de estas tareas no necesitan ejecutarse diariamente o no deberían ejecutarse diariamente. En cuanto a cuáles, se me escapa. Podría usar una pequeña guía para crear un mejor plan de mantenimiento que reduzca la pérdida de datos en un desastre, pero no gravará el sistema cuando se ejecute durante las horas pico (y también aumente el rendimiento).

Josh

Esta es una tarea muy común para todos los DBA y la respuesta correcta NO es la misma para todos y para cada servidor. Como muchas otras cosas, depende de lo que necesites.

Definitivamente no quieres ejecutar "Shrink Database" como ya se sugirió. Es MALO al rendimiento y la referencia a continuación le mostrará por qué. Provoca fragmentación del disco y del índice, y esto puede conducir a problemas de rendimiento. Es mejor preasignar un gran tamaño para los archivos de datos y registros para que el crecimiento automático NO se active.

No entendí tu # 2. tablas seleccionadas copia de seguridad completa. ¿Puedes dar más detalles sobre esto?

Al reorganizar el índice, actualizar las estadísticas y reconstruir el índice, debe tener cuidado con cómo lo hace; de ​​lo contrario, terminará utilizando más recursos y también tendrá problemas de rendimiento.

Cuando reconstruye índices, las estadísticas de los índices se actualizan con fullscan, pero si actualiza las estadísticas después de eso, se actualizarán nuevamente con una muestra predeterminada (que depende de varios factores, generalmente el 5% de la tabla cuando el tamaño de la tabla> 8 MB) que puede conducir a problemas de rendimiento. Dependiendo de la edición que tenga, puede hacer reconstrucciones de índices en línea. La forma correcta de realizar esta actividad es verificar la cantidad de fragmentación y, dependiendo de eso, realizar la reconstrucción del índice o reorganizar el índice + actualizar las estadísticas. Y también es posible que desee identificar qué tablas necesitan actualizar las estadísticas con mayor frecuencia e intentar actualizar las estadísticas con más frecuencia.

Los planes de mantenimiento están bien, pero es difícil obtener lo mejor de ellos haciendo estas personalizaciones a menos que pueda iniciar sesión en SSIS y modificar los MP. Es por eso que prefiero NO usarlos y usar los scripts gratuitos de Ola Hallengren que son más robustos que los MP. Además, recomendaría ponerse al día con el artículo de referencia de Paul Randal sobre este tema.

Ref: http://technet.microsoft.com/en-us/magazine/2008.08.database.aspx

Esta NO es una respuesta integral a su pregunta, sino un buen punto de partida. HTH y háganos saber si tiene alguna pregunta / comentario adicional.

Compartiré mi experiencia, incluso si ya has aceptado una respuesta. Tal vez sea útil :-).

1. Copia de seguridad diaria completa (diaria): excelente, pero no olvide comprobar el espacio y eliminar los archivos antiguos después de un tiempo predefinido.
2. Copia de seguridad de tablas seleccionadas (por hora): no entiendo por qué necesita esto, es mejor que vaya con copias de seguridad diferenciales. ¿Cómo respalda solo ciertas tablas: SSIS, scripts, bcp? Con respecto a las copias de seguridad de diff, no lo programe con demasiada frecuencia, ya que robará la función de copias de seguridad de registro.
3. Copias de seguridad del registro de transacciones (cada 15 minutos): excelente, ¿está seguro de que necesita para todas las bases de datos? ¿Todas las bases de datos usan el modelo de recuperación completa o no?
4. Verifique la integridad de db: sí, pero debe asegurarse de no matar su entorno. Las declaraciones de verificación de DBCC son bastante egoístas en recursos y escanean dbs completos, por lo que deben programarse durante las horas libres.
5. Reorganice el índice (diariamente): no lo fuerce, hágalo solo si es necesario. Verifique el índice de DMV con respecto a la fragmentación y reorganice solo en función de las necesidades. Movería todas las operaciones de índice y estadísticas en una sola tarea semanal.
6. Actualizar estadísticas (diariamente): consulte mi respuesta a una pregunta anterior. En lugar de forzar la actualización de todas las estadísticas, todos los días, será mejor que verifique cuándo se actualizaron las estadísticas por última vez y solo en algunos casos actualícelas.
7. Reducir la base de datos (semanalmente) - Oh, no. Lea el artículo de Paul Randal sobre la reducción de archivos.
8. Reconstruir índice (semanalmente) - ver 5.

9. Limpieza de mantenimiento (diaria) - está bien con eso.

10. Será mejor que también agregue una tarea para verificar sus copias de seguridad: hay una versión del comando RESTORE (verificar solo ... si recuerdo correctamente), digamos semanalmente, aunque lo prefiero a diario.

Menciona que desea estar protegido en caso de pérdida de datos, por lo que diría que necesita agregar las bases de datos del sistema en este procedimiento de mantenimiento. Y también tenga cuidado de hacer una copia de seguridad de los archivos en una máquina diferente al servidor mismo. Mantenga en algún lugar un archivo con qué hacer en caso de que necesite reconstruir master db, msdb..etc. ¡Buena suerte con tu tarea!

Respuesta tardía pero podría ser útil para otros lectores.

Tenga en cuenta que hay muchas tareas de mantenimiento o informes que puede crear, que conllevan riesgos ocultos asociados con ellas.

¿Qué pasaría cuando una unidad se llena durante las copias de seguridad diferenciales que se realizan diariamente? ¿Y qué pasa si un trabajo de reconstrucción de índice se ejecuta de forma inusual? ¿Qué tal si un proceso de carga de datos causa una contención de recursos extensa, poniendo de rodillas las operaciones normales? Todos estos son eventos planificados, pero pueden causar una interrupción considerable en los procesos que estamos tratando de salvaguardar.

Siempre considere cómo interactúan los diferentes trabajos y cronometra de manera tal que no haya superposición en tareas sensibles o intensivas en recursos.

Sugiero leer este artículo primero: http://www.sqlshack.com/removing-the-risk-from-important-maintenance-tasks-in-sql-server/

Describe cómo realizar tareas de mantenimiento importantes en SQL Server, sin riesgos. Por ejemplo, puede crear controles simples en sus trabajos de mantenimiento que verifiquen los recursos disponibles, así como lo que requerirá una operación antes de la ejecución. Esto le permite asegurarse de que su entorno pueda manejar lo que está a punto de hacer y abortar con un error significativo si los recursos son inadecuados.

1. Se ve bien

2. Puede beneficiarse de hacer copias de seguridad diferenciales aquí. Míralos con seguridad

3. Se ve bien

4. Se ve bien

5. Como se indicó anteriormente, las reducciones de la base de datos son malas porque crean fragmentación física de sus datos y archivos de registro, lo que provoca más lecturas de E / S aleatorias.

5, 6 y 8: ver a continuación.

Estos realmente van de la mano, ya que los índices dependen de estadísticas actualizadas, y el orden de estas operaciones es bastante importante. El método de referencia que utilizo, que ciertamente no funciona para todos, es que realizo dos rondas de mantenimiento del índice. Primero, hago los índices agrupados y luego los índices no agrupados. El método que utilizo para ambos es el siguiente. Si un índice es lo suficientemente grande y fragmentado (sys.dm_db_index_physical_stats), reconstruiré el índice (que incluye una actualización de estadísticas con exploración completa). Si un índice es demasiado pequeño para una reconstrucción o no está lo suficientemente fragmentado para una reconstrucción (menos de 100 páginas y entre 5% y 15% de fragmentación), primero realizaré una reorganización de índice. Luego realizaré una actualización de estadísticas con escaneo completo.

Ahora, esto cubre las estadísticas de índice, pero no hace nada para columnas de estadísticas. Semanalmente, actualizaré las estadísticas de columna.

¡Espero que esto haya ayudado de alguna manera!

Incliné su comentario sobre "la pérdida de datos podría tener ramificaciones legales aquí".

Entonces, definitivamente desea obtener una poderosa herramienta de terceros (como DPM) que pueda manejar las copias de seguridad (y recuperarse de eventos catastróficos en un instante y un mínimo esfuerzo) mucho más rápido y mucho mejor que cualquier script que pueda ejecutar en Internet.

Tener copias de seguridad es una cosa. Saber cómo usarlos en una emergencia es otra.

No olvide que si está a punto de restaurar una copia de seguridad después de una falla importante, probablemente ya esté bajo una carga de estrés y presión. No necesita la carga adicional de desenterrar y escribir sin problemas la instrucción RESTORE DATABASE con 12 archivos de registro de transacciones ... Y rezar para que no le falle ...

En mi lugar de trabajo, puedo recuperar / restaurar una base de datos de 350 Gb en cualquier punto dentro de un período de 5 minutos durante la última semana usando DPM. Con una interfaz GUI. Vale la pena, en mi libro.

Por lo demás, definitivamente mire el script de índice de Ola Hallengren y ajuste los parámetros a sus necesidades. Personalmente, lo combiné con una tarea programada que hace que se ejecute durante una hora cada noche sin volver a escanear, por lo que maneja los peores índices cada vez, y fuerza un nuevo escaneo completo de la fragmentación todos los sábados, o cuando todos los índices en la lista han sido desfragmentados

Por último, agrego mi voz al grupo "no reducir sus archivos automáticamente, nunca". File Shrink es solo una herramienta para usar esporádicamente cuando ocurre un evento irregular que sobregraba sus registros o archivos DB (bucle infinito o similar). No se supone que sea una herramienta de mantenimiento. Si tiene presión de espacio en el disco, la reducción solo retrasará lo inevitable de todos modos.