La mejor manera de respaldar y truncar los registros de transacciones en un horario

No soy un DBA, pero como están las cosas, tengo que usar el sombrero de DBA y configurar planes de mantenimiento en mi instancia de SQL Server.

Entonces, durante un tiempo he estado haciendo que mi proceso SSIS durante la noche ejecute una tarea Ejecutar SQL para realizar las copias de seguridad, básicamente ejecutándose master.dbo.xp_create_subdirpara garantizar que existan las carpetas de destino, y luego BACKUP DATABASE [DbName] TO DISK = 'G:\Backups\DbName\DbName.bak' WITH INIT.

Cada vez que fallaba esa tarea, el resto del proceso abortaba y recibía una notificación, y llegaba a la mañana siguiente para notar que la unidad de registros de transacciones estaba llena, y entonces los truncaba manualmente y continuaba. .. hasta que la historia se repitió y los registros de transacciones superaron nuevamente el espacio disponible en disco.

El script "truncado manual" se ve así:

use Staging;
alter database Staging set recovery simple
alter database Staging set recovery full
dbcc shrinkfile ('Staging_log', 0, truncateonly);
go

Así que me estoy cansando de esto, y decidí intentar hacer las cosas correctamente , y seguir los pasos aquí y crear un plan de mantenimiento real :

La cosa es que nunca he hecho esto antes, así que tengo algunas preguntas:

• ¿Hacer una copia de seguridad de los registros de transacciones como este los truncará automáticamente, o hay algo más que deba hacer?
• ¿Está bien ejecutar copias de seguridad de registros de datos y transacciones al mismo tiempo? Si no es así, ¿cuál es la forma correcta de hacer esto?
• Los archivos de copia de seguridad se recogen de la noche a la mañana mediante otro proceso que toma todos los archivos del servidor y los almacena en otro lugar. ¿Sería una buena idea expirar el conjunto de copias de seguridad después de 2 días? ¿Necesito hacer que caduquen?
• Las tareas de limpieza eliminan respectivamente los archivos "antiguos" .bak y .trn en las subcarpetas de G:\Backups. ¿Tiene sentido?
• ¿Sería mejor hacer esto en SSIS, para que pueda fallar mi ETL si / cuando fallan las copias de seguridad? ¿O debería importarme mi proceso ETL?

Lo siento si son demasiadas preguntas para una publicación, si es necesario, editaré y haré varias preguntas en su lugar, creo que todas están estrechamente relacionadas.

Solo durante la noche SSIS está escribiendo, el día es todo lectura, solo necesito recuperación diaria.

Debe elegir su modelo de recuperación en función de las necesidades de su negocio:

• ¿Cuántos datos el negocio puede perder y al mismo tiempo sobrevivir?

Según la respuesta anterior, debe elegir cuidadosamente el modelo de recuperación de su base de datos .

En términos simples (sin analizar el modelo de recuperación registrada en masa) ,

• Un modelo de recuperación completa permite copias de seguridad de registros que permiten la recuperación en un momento determinado.
  • El truncamiento del registro puede ocurrir cuando realiza copias de seguridad del registro de transacciones, es decir, el espacio del archivo de registro se reutilizará después de cada copia de seguridad del registro y no se hinchará.
• Un modelo de recuperación simple solo le permite realizar copias de seguridad COMPLETAS. La recuperación en un punto en el tiempo no es posible.
  • El truncamiento del registro solo puede ocurrir cuando se produce un punto de control (manual o automático), es decir, dado que realiza copias de seguridad completas regulares, no tiene que preocuparse por el registro de transacciones, ya que CHECKPOINT se encargará de reutilizar la parte inactiva del archivo de registro.

Recuerde que el truncamiento del registro NO es una reducción física en el tamaño del archivo de registro de transacciones. Significa que la parte inactiva del archivo de registro de transacciones está marcada como reutilizable .

Por lo tanto, debe ajustar correctamente el archivo de registro de transacciones (y los archivos de datos). El crecimiento del archivo de registro iniciará los eventos de crecimiento automático (si su base de datos está configurada para crecer automáticamente como último recurso). Verifique mi respuesta - Crecimiento automático - ¿Porcentaje de uso?

Le recomiendo encarecidamente que abandone los planes de mantenimiento e implemente [una solución de mantenimiento inteligente, que es fácil, flexible y sigue las mejores prácticas] - 5 . - La solución de respaldo de Ola (y también la solución de mantenimiento de Index ).

abordemos sus preguntas:

¿Hacer una copia de seguridad de los registros de transacciones como este los truncará automáticamente, o hay algo más que deba hacer?

No agregue copias de seguridad ni las configure para que caduquen. Crean un gran desastre. Use INITy tome copias de seguridad de registros separadas con sello de fecha y hora. Facil de mantener. Use la solución de respaldo de Ola para eso. La solución también es flexible para eliminar copias de seguridad antiguas.

¿Está bien ejecutar copias de seguridad de registros de datos y transacciones al mismo tiempo? Si no es así, ¿cuál es la forma correcta de hacer esto?

Una copia de seguridad completa no tiene efecto en una copia de seguridad de T-log. Una copia de seguridad completa contiene solo el registro de transacciones suficiente para que, en caso de una restauración, la base de datos pueda ser transaccionalmente consistente con el momento en que se completó la parte de lectura de datos de la copia de seguridad completa. Comprobar: ¿cuánto registro de transacciones incluye una copia de seguridad completa?

Además, una copia de seguridad del registro durante una copia de seguridad completa no truncará el registro de transacciones. Un par de copias de seguridad de registro después de que finalice la copia de seguridad completa truncará el registro.

Los archivos de copia de seguridad se recogen de la noche a la mañana mediante otro proceso que toma todos los archivos del servidor y los almacena en otro lugar. ¿Sería una buena idea expirar el conjunto de copias de seguridad después de 2 días? ¿Necesito hacer que caduquen?

Las tareas de limpieza eliminan respectivamente los archivos "antiguos" .bak y .trn en las subcarpetas de G: \ Backups. ¿Tiene sentido? ¿Sería mejor hacer esto en SSIS, para que pueda fallar mi ETL si / cuando fallan las copias de seguridad? ¿O debería importarme mi proceso ETL?

Para los dos anteriores, use la solución de mantenimiento de respaldo de Ola. Se encargará de eliminar los archivos antiguos.