¿Cómo reduzco el tamaño de la copia de seguridad del registro de transacciones después de una copia de seguridad completa?

Tengo tres planes de mantenimiento configurados para ejecutarse en una instancia de SQL Server 2005:

• Optimizaciones semanales de la base de datos seguidas de una copia de seguridad completa
• Copia de seguridad diferencial diaria
• Copias de seguridad de registro de transacciones por hora

Las copias de seguridad de registro por hora suelen estar entre unos pocos cientos de Kb y 10Mb dependiendo del nivel de actividad, los diferenciales diarios generalmente crecen hasta alrededor de 250Mb al final de la semana, y la copia de seguridad semanal es de aproximadamente 3.5Gb.

El problema que tengo es que las optimizaciones antes de la copia de seguridad completa parecen estar causando que la próxima copia de seguridad del registro de transacciones crezca a más del doble del tamaño de la copia de seguridad completa, en este caso 8Gb, antes de volver a la normalidad.

Aparte de BACKUP LOG <DatabaseName> WITH TRUNCATE_ONLYeso, ¿hay alguna manera de reducir el tamaño de esa copia de seguridad del registro, o evitar que las optimizaciones se registren en el registro de transacciones, ya que seguramente se contabilizarán en la copia de seguridad completa que preceden?

Algunas sugerencias interesantes aquí, que parecen mostrar malentendidos sobre cómo funcionan las copias de seguridad de registros. Una copia de seguridad de registro contiene TODOS los registros de transacciones generados desde la copia de seguridad de registro anterior, independientemente de qué copias de seguridad completas o diferenciales se tomen en el ínterin. Detener las copias de seguridad de registros o pasar a copias de seguridad completas diarias no tendrá ningún efecto en los tamaños de las copias de seguridad de registros. Lo único que afecta el registro de transacciones es una copia de seguridad del registro, una vez que la cadena de copia de seguridad del registro ha comenzado.

La única excepción a esta regla es si la cadena de respaldo de registro se ha roto (por ejemplo, yendo al modelo de recuperación SIMPLE, revertiendo desde una instantánea de la base de datos, truncando el registro usando BACKUP LOG WITH NO_LOG / TRUNCATE_ONLY), en cuyo caso la primera copia de respaldo de registro contendrá todo el registro de transacciones desde la última copia de seguridad completa, que reinicia la cadena de copia de seguridad del registro; o si la cadena de respaldo de registro no se ha iniciado: cuando cambia a COMPLETO por primera vez, opera en una especie de modelo de recuperación pseudo SIMPLE hasta que se toma el primer respaldo completo.

Para responder a su pregunta original, sin entrar en el modelo de recuperación SIMPLE, tendrá que hacer una copia de seguridad de todo el registro de transacciones. Dependiendo de las acciones que esté tomando, podría realizar copias de seguridad de registros más frecuentes para reducir su tamaño o hacer una base de datos más específica.

Si puede publicar información sobre las operaciones de mantenimiento que está realizando, puedo ayudarlo a optimizarlas. ¿Está usted, por casualidad, haciendo reconstrucciones de índice seguidas de una base de datos reducida para reclamar el espacio utilizado por las reconstrucciones de índice?

Si no tiene otra actividad en la base de datos mientras se realiza el mantenimiento, puede hacer lo siguiente:

• asegúrese de detener la actividad del usuario
• tome una copia de seguridad del registro final (esto le permite recuperarse hasta el punto de inicio del mantenimiento)
  • cambiar al modelo de recuperación SIMPLE
  • realizar mantenimiento: el registro se truncará en cada punto de control
  • cambie al modelo de recuperación COMPLETO y realice una copia de seguridad completa
  • continuar como siempre

Espero que esto ayude, esperando más información.

Gracias

[Editar: después de toda la discusión sobre si una copia de seguridad completa puede alterar el tamaño de una copia de seguridad de registro posterior (no puede), armé una publicación de blog completa con material de antecedentes y un script que lo demuestra. Compruébelo en https://www.sqlskills.com/blogs/paul/misconceptions-around-the-log-and-log-backups-how-to-convince-yourself/]

Podría reducirlos, pero volverán a crecer y eventualmente causarán la fragmentación del disco. Las reconstrucciones y desfragmentaciones de índice crean registros de transacciones muy grandes. Si no necesita la capacidad de recuperación en un punto en el tiempo, puede cambiar al modo de recuperación simple y eliminar por completo las copias de seguridad del registro de transacciones.

Supongo que está utilizando un plan de mantenimiento para las optimizaciones, podría cambiarlo para usar un script que indexe desfragmentados solo cuando se alcance un cierto nivel de fragmentación y probablemente no sufrirá ningún impacto en el rendimiento. Esto generaría registros mucho más pequeños.

Me saltaría los diferenciales diarios a favor de las copias de seguridad completas diarias, por cierto.

Su pregunta final fue: "Aparte del REGISTRO DE COPIA DE SEGURIDAD CON TRUNCATE_ONLY, ¿hay alguna forma de reducir el tamaño de la copia de seguridad de ese registro, o evitar que las optimizaciones se registren en el registro de transacciones, ya que seguramente se contabilizarán en su totalidad? copia de seguridad que preceden?

No, pero aquí hay una solución alternativa. Si sabe que las únicas actividades en esa base de datos en ese momento serán los trabajos de mantenimiento del índice, puede detener las copias de seguridad del registro de transacciones antes de que comience el mantenimiento del índice. Por ejemplo, algunos de mis servidores los sábados por la noche, los horarios de trabajo se ven así:

• 9:30 PM: se ejecuta la copia de seguridad del registro de transacciones.
• 9:45 PM: la copia de seguridad del registro de transacciones se ejecuta por última vez. El horario se detiene a las 9:59.
• 10:00 PM: el trabajo de mantenimiento de índice comienza y tiene paradas incorporadas para finalizar antes de las 11:30.
• 11:30 PM: el trabajo de copia de seguridad completa comienza y finaliza en menos de 30 minutos.
• 12:00 AM - las copias de seguridad del registro de transacciones comienzan nuevamente cada 15 minutos.

Eso significa que no tengo capacidad de recuperación en un momento dado entre las 9:45 y las 11:30 p.m., pero la recompensa es un rendimiento más rápido.

Respuesta fácil: cambie su trabajo de optimización semanal para que se ejecute de manera más equilibrada todas las noches. es decir, vuelva a indexar las tablas ae el domingo por la noche, f - l el lunes por la noche, etc ... encuentre un buen equilibrio, su registro será aproximadamente 1/6 del tamaño en promedio. Por supuesto, esto funciona mejor si no está utilizando el trabajo de mantenimiento del índice ssis incorporado.

La desventaja de esto y es importante dependiendo de la carga que experimente db es que causa estragos en el optimizador y la reutilización de los planes de consulta.

Pero si lo único que le importa es el tamaño de su t-log semanalmente, divídalo de un día a otro o de una hora a otra y ejecute las copias de seguridad de t-log en el medio.

También puede buscar una herramienta de terceros (Litespeed de Quest, SQL Backup de Red Gate, Hyperbac) para reducir el tamaño de las copias de seguridad y los registros. Pueden pagarse rápidamente en ahorros de cinta.

Probablemente se puede suponer que sus "optimizaciones" incluyen reconstrucciones de índice. Solo realizar estas tareas semanalmente puede ser aceptable en una base de datos que no encuentre una gran cantidad de actualizaciones e inserciones, sin embargo, si sus datos son muy fluidos, es posible que desee hacer un par de cosas:

1. Reconstruya o reorganice sus índices todas las noches si su horario lo permite y si el impacto es aceptable. Cuando se realizan estas tareas de mantenimiento de índice nocturno, solo se dirigen a aquellos índices que están fragmentados más allá del 30% para reconstrucciones y en el rango de 15-30% para reorganizaciones.

2. Estas tareas son transacciones registradas, por lo que si le preocupa el crecimiento del registro, recomendaría lo que Paul recomendó. La copia de seguridad del registro de transacciones final antes del mantenimiento del índice, cambie a Recuperación simple, seguido del proceso de mantenimiento y luego vuelva a Recuperación completa seguida de una copia de seguridad de datos completa.

Tomo un enfoque zen para mis archivos de registro: son del tamaño que quieren tener. Siempre y cuando no hayan soportado un crecimiento abrumador debido a las malas prácticas de respaldo en comparación con la actividad de la base de datos, ese es el mantra por el que vivo.

En cuanto a los scripts que realizan el mantenimiento del índice discrecional, busque en línea: hay un montón por ahí. Andrew Kelly publicó uno decente en la revista SQL hace aproximadamente un año. SQLServerPedia tiene algunos scripts de Michelle Ufford, y el último número de SQL Magazine (julio de 2009, creo) también tiene un artículo completo sobre el tema. El punto es encontrar uno que funcione bien para usted y personalizarlo con personalizaciones mínimas.

¿Puede hacer una copia de seguridad de su registro de transacciones en varios puntos durante la optimización de su base de datos? El tamaño total de los t-logs sería el mismo, pero cada uno sería más pequeño, posiblemente ayudándolo de alguna manera.

¿Puede hacer una optimización de base de datos más específica para que se creen menos transacciones (alguien mencionó esto pero no estoy seguro de las implicaciones que se explicaron). Como tolerar una cierta cantidad de fragmentación o espacio desperdiciado por un tiempo. Si el 40% de sus tablas están fragmentadas solo en un 5%, no tocarlas podría ahorrar bastante actividad.