Mantener bases de datos 24x7 es un tema bastante amplio con muchas opciones a considerar. Este amplio tema tiene muchos elementos a considerar, pero podemos intentar tocar algunos de los puntos más importantes.
Lo que primero querrá identificar es que, si bien muchas operaciones son 24x7, generalmente hay momentos de baja actividad. Puede aprovechar estos tiempos para ejecutar su mantenimiento para reducir la interferencia que tendrá en la base de datos. El segundo es que deberá reservar un tiempo para interrupciones completas (para cosas como paquetes de servicios o migraciones de bases de datos), por lo que deberá negociar ventanas de mantenimiento completas con su administración. Para elementos específicos, deberá considerar y planificar cada uno, así como aprovechar sus herramientas adecuadamente. La parte importante es que debe PLANIFICAR cada uno de estos, cualquier ejemplo que proporcione es muy "sus millas pueden variar".
Copias de seguridad
Las copias de seguridad generalmente no tendrán un gran impacto en las cargas de trabajo, pero deben tenerse en cuenta ya que pueden consumir una gran cantidad de E / S. Deberá programarlos de manera adecuada y controlar la cantidad de tiempo que se tarda en completar. El mayor obstáculo aquí es que en una operación 24x7, es probable que no pueda realizar copias de seguridad nocturnas completas todas las noches de la semana. Deberá planificar cuándo puede completar, cuándo tomar diferenciales y los períodos de retención para ambos en combinación con sus copias de seguridad de registros.
Como ejemplo, ejecuto copias de seguridad completas de todas mis bases de datos el domingo por la noche (actividad más baja), diferenciales en todas las otras noches (lunes a sábado). Mantengo las últimas dos semanas de fulls y diffs en el disco, registros de los últimos dos días. Esto me da suficiente flexibilidad para la recuperación, pero es posible que tenga que recuperar copias de seguridad de la cinta si es necesario.
Mantenimiento de índices / estadísticas
Este es el tipo más común de mantenimiento activo con el que tendrá que lidiar. No puedes evitarlo, pero puedes mitigar el impacto. La regla general inicial es que solo debe hacer mantenimiento en los objetos que lo necesitan. Las pautas generales son solo reconstruir índices que tengan más del 30% de fragmentación y más de 1000 páginas . Si tiene estadísticas de actualización automática , esto se encargará de la mayor parte del mantenimiento de sus estadísticas, pero un trabajo nocturno para mantener las cosas sincronizadas no es una mala idea.
Si tiene Enterprise Edition, también tiene acceso a algunas otras opciones para administrar el mantenimiento. El principal es la reconstrucción de índices en línea , que le permitirá reconstruir índices mientras todavía están en uso (esencialmente, construye el índice uno al lado del otro, luego lo intercambia). También puede aprovechar la partición de tablas "grandes" para reducir la cantidad de tiempo de reconstrucción necesaria.
Su mejor opción para este tipo de mantenimiento, si no tiene scripts personalizados que manejen estas mejores prácticas, es usar los scripts de mantenimiento de Ola Hallengren . Estos son bastante fáciles de configurar y tienen muchas de estas pautas integradas.
Verificaciones de consistencia de DBCC
Dependiendo de su carga de trabajo general, es posible que las comprobaciones de DBCC sean demasiado perjudiciales para su operación. Hay dos formas comunes de minimizar el impacto de DBCC en sus bases de datos:
PHYSICAL_ONLY- Ejecutar esta opción verificará sus bases de datos a nivel de página física y evitará la verificación completa más invasiva. Esto cubrirá la identificación de los tipos más probables de corrupción.- Comprobación de una copia restaurada: si tiene espacio, puede restaurar la base de datos a otra instancia y ejecutar una comprobación DBCC contra la copia restaurada. Esto contará la misma historia sobre su base de datos en vivo, pero obviamente no interferirá con la actividad. Algunas otras alternativas aquí están ejecutando DBCC contra una copia enviada de registro o una base de datos reflejada.
Esta publicación de blog proporciona más detalles sobre sus opciones.
Trabajos por lotes / ETL
Esto realmente se reduce a cómo diseñas tus procesos. Su ETL siempre puede interferir con las tablas OLTP en vivo (como cualquier otra aplicación), por lo que algunas claves a tener en cuenta:
- Programe dicho trabajo alrededor de su otro mantenimiento y en períodos de baja actividad.
- Ajuste el trabajo correctamente para que esté agrupado tanto para el rendimiento como para que el lote no sea tan grande que bloquee su mesa durante horas. Ejemplos de los extremos del espectro: Row-by-agonizing-row (RBAR) versus una eliminación de un solo millón de filas.
- Use tablas de escenario y fuera de línea su procesamiento de datos cuando sea apropiado. Solo toque las cosas en vivo cuando sea absolutamente necesario.
Conclusión
Nuevamente, hay mucho terreno por recorrer aquí. Esta no es una guía completa, sino una descripción general de alto nivel de algunos enfoques. Ni siquiera he discutido las opciones de alta disponibilidad (como Grupos de disponibilidad y Clústeres de conmutación por error). Deberá revisar cada elemento y elaborar un plan sobre cómo manejarlo. En muchos sentidos, también deberá iterar y refinar su trabajo a medida que avanza.
Recursos adicionales:
Prácticas recomendadas de mantenimiento de SQL Skills VLDB