¿Copia de seguridad del registro de transacciones en serie o en paralelo?

Estamos usando SQL Server 2012 Standard Edition. También uso los scripts de Ola Hallengren para proporcionar un marco fácil y más flexible para hacer copias de seguridad y mantenimiento.

Esta pregunta no se trata tanto de los guiones de Ola como de una mejor práctica. Me doy cuenta de que la respuesta final es "depende de los requisitos de su empresa". Pero estoy tratando de buscar el consejo de la comunidad sobre la mejor manera de cumplir con lo que entiendo de los requisitos de nuestra empresa.

Deseo configurar copias de seguridad del registro de transacciones por cada 15 minutos. De esta manera, esperamos no perder más de 15 minutos de datos. ¿Debo configurar un trabajo que use ALL_DATABASES? ¿O es mejor configurar un trabajo para cada base de datos y comenzarlos todos en paralelo? Pregunto, porque tengo la sensación de que veo cómo funciona el script de Ola que las copias de seguridad se inician en serie. La desventaja de la serie sería que cada copia de seguridad sucesiva espera hasta que se complete la otra. Potencialmente, esto podría aumentar la cantidad de tiempo entre las copias de seguridad (es decir, más de 15 minutos). Además, mi preocupación sería que una falla en una copia de seguridad impida que ocurran las demás, y no quisiera que ese sea el caso. Me gustaría que los demás continúen retrocediendo.

Entonces, ¿es cierto que los scripts de Ola se ejecutan en serie y también una falla detiene las copias de seguridad sucesivas?

¿Y es mejor tener un trabajo para cada base de datos? o un solo trabajo que hace todo? Mi inclinación es hacia trabajos separados, pero deseo entender qué tienden a hacer los DBA de SQL Server en general.

¿Debo configurar un trabajo que use ALL_DATABASES? ¿o es mejor configurar un trabajo para cada base de datos y comenzarlos todos en paralelo?

Sugeriría configurar un trabajo que respaldaría los registros de transacciones (en serie). Esto también aseguraría que la copia de seguridad no utilice mucho la E / S porque está ejecutando una copia de seguridad para la base de datos de una en una.

¿Cuáles podrían ser posibles inconvenientes al correr en paralelo?

1. Supongamos que tiene 50 bases de datos y programa una copia de seguridad del registro de transacciones de todas las bases de datos y todas comienzan a ejecutarse en paralelo, esto definitivamente va a utilizar mucha E / S. Y si el disco en el que está realizando una copia de seguridad de archivos tiene otros archivos de datos, verá lentitud. He visto que la copia de seguridad se vuelve lenta cuando se ejecuta una consulta deficiente que solicita gran cantidad de E / S junto con el trabajo de copia de seguridad.

2. Una vez más, suponga que tiene 50 bases de datos, ¿no sería difícil administrar 50 trabajos en el agente de SQL Server y cuál sería la condición si tiene 100-200 bases de datos? Simplemente no me gustaría cuando abra el agente de SQL Server y vea muchos trabajos, solo mantenlo simple. Estoy seguro de que el mismo caso sería contigo.

La desventaja de la serie sería que cada copia de seguridad sucesiva espera hasta que se complete la otra. Potencialmente, esto podría aumentar la cantidad de tiempo entre las copias de seguridad (es decir, más de 15 minutos).

Las copias de seguridad del registro de transacciones son en su mayoría pequeñas y si tiene una base de datos ocupada que produce muchos registros, es posible que deba cambiar la frecuencia de la copia de seguridad. En general, he visto que la copia de seguridad del registro de transacciones se completa bien cuando la frecuencia es de 15 minutos. No creo que deba preocuparte.

Además, mi preocupación sería que una falla en una copia de seguridad impida que ocurran las demás, y no quisiera que ese sea el caso

Yo diría que no te preocupes por eso. Las copias de seguridad del registro de transacciones simplemente no pueden fallar a menos que haya cometido algún error. Los errores pueden ser

1. El propietario que ejecuta el trabajo se elimina de AD

2. Alguien cambió el modelo de recuperación de la base de datos.

3. Espacio insuficiente en el disco

Aparte de lo anterior, no he visto ningún motivo para que falle la copia de seguridad del registro de transacciones. Es muy robusto, puede confiar en él.

En general, siempre ejecute sus copias de seguridad de T-log en serie; muchas de mis instancias tienen un par de docenas de bases de datos, y varias que son muy activas, y las copias de seguridad del registro de transacciones solo toman unos segundos en total; hasta medio minuto más o menos cuando está particularmente ocupado.

Ejecutar copias de seguridad en paralelo solo sería realmente beneficioso si se cumplen todas las condiciones siguientes:

• Sus bases de datos y archivos de registro están en ejes independientes únicos (o en discos de estado sólido en cualquier combinación)

  • Solo para las copias de seguridad de T-log, solo los archivos de registro tendrían que cumplir este requisito.

• Sus objetivos de copia de seguridad para cada base de datos están en ejes separados.

• No está utilizando SAN HBA o iSCSI compartido u otro ancho de banda entre la instancia de SQL Server y los medios.

• es decir, el IOPS lee la base de datos A y escribe la copia de seguridad A NO use los mismos discos que lee la base de datos B y escribe la copia de seguridad B.

Si todo esto es cierto, entonces es posible que algún grado de paralelismo disminuya la cantidad de tiempo calendario total. Si todo esto no es cierto, lo más probable es que provoque que uno o más conjuntos de discos se bloqueen, y sus copias de seguridad paralelas en realidad tomarán más tiempo calendario que el serial, pero también pueden causar fragmentación del sistema de archivos del sistema operativo o del nivel de almacenamiento, porque ¡estás escribiendo Backup A y Backup B al mismo tiempo!

No se preocupe si una copia de seguridad falla y el resto tiene éxito; si alguna falla, debe verificar todo de todos modos, y las únicas veces que he visto fallar las copias de seguridad se deben a:

• Falla del disco

• Falla del software de compresión Hyperbac / Litespeed / Third Party (si tiene software entre SQL y el disco que falla)

  • Como advertencia, la falla puede tomar la forma de un trabajo de respaldo que nunca finaliza, por lo que es valioso realizar algunas comprobaciones de "trabajos que se ejecutan más de lo esperado" que envía alertas.

• Error del producto de cifrado (si tiene software entre SQL y el disco que falla)

• Falla de la red (si los archivos de la base de datos, o más probablemente los archivos de respaldo, están en la red)

• Permisos

  • más común con instalaciones nuevas

  • o nuevas ubicaciones de respaldo

  • cambiar el usuario del Servicio SQL Server (que es lo que necesita los permisos para las copias de seguridad normales)

  • bloquear al usuario del servicio SQL Server porque lo usa más de una instancia de SQL Server

• Errores de configuración

• Fallo de alimentación

• Bloqueo del sistema operativo

La mayoría de los cuales no afectará a uno y no a los demás a menos que también se cumplan las condiciones anteriores.

Solo para agregar, Ola diseña sus scripts donde si una copia de seguridad de la base de datos no puede hacer una copia de seguridad por cualquier razón, se intentan las siguientes. Como se indicó anteriormente, podría tener una alerta configurada para informarle de la falla del trabajo, ya que la tarea de respaldo aún fallaría, incluso si solo una copia de seguridad de la base de datos fallara de todas las bases de datos del usuario, suponiendo que está haciendo una copia de seguridad de todas las bases de datos (una trabajo para todos).