Realizar operaciones de actualización de datos mientras realiza una copia de seguridad de una gran base de datos de SQL Server

Tengo una gran base de datos (en las decenas de millones de registros) en la que voy a realizar una copia de seguridad completa de la base de datos .

Sin embargo, la base de datos es lo suficientemente grande como para que las transacciones puedan comenzar antes y durante, así como comprometerse durante y después de la copia de seguridad.

Por ejemplo:

T0 = Transaction A start
T1 = Full database backup start
T2 = Transaction B start (will not deadlock with A)
T3 = Transaction A commit/rollback (does not matter, does it?)
T4 = Full database backup end
T5 = Transaction B commit/rollback (again, does not matter, does it?)

T0          T1          T2          T3          T4          T6
||----------||----------||----------||----------||----------||---------->

Tengo entendido que no se usan bloqueos durante una copia de seguridad (aunque pueden surgir otros problemas de rendimiento debido, por ejemplo, a una E / S alta) , pero no estoy seguro de qué puedo garantizar lo que se comprometerá o no.

Además, mi preocupación no es que la base de datos esté en un estado inconsistente, sino más bien cuál será ese estado (incluso si no es determinista, si hay un conjunto de reglas que pueden aplicarse de manera consistente) y cómo llegó allí ( por ejemplo, ¿qué parte del archivo de datos se usa junto con el registro de transacciones para crear un archivo de respaldo?

Esencialmente, la copia de seguridad estará en el estado de la base de datos cuando termine la porción de lectura de datos de la copia de seguridad (por lo que se realizará una copia de seguridad de todos los datos), más cualquier cantidad de registro de transacciones que se requiera para garantizar la coherencia transaccional (el inicio El tiempo del registro incluido es MIN(most recent checkpoint time, oldest active transaction start time)). Paul Randal cubre esto aquí (con la ayuda de un diagrama, que lo hace todo mucho más fácil). En su ejemplo, Ase confirmaría (o se revertiría si ROLLBACK TRANSACTIONse emitiera un en lugar de a COMMIT) y Bse revertiría (independientemente del resultado final de esa transacción).

(La otra razón por la que intenta hacer copias de seguridad en un momento tranquilo, aparte de la contención de E / S, es que todo el registro de transacciones generado durante una copia de seguridad normalmente debe incluirse con la copia de seguridad).

La fase de recuperación de una restauración de la base de datos toma todas las transacciones confirmadas del registro incluido en la copia de seguridad y las aplica a la base de datos, y revierte todas las transacciones no confirmadas. (Esto es por qué WITH RECOVERY/ WITH NORECOVERYes importante. WITH RECOVERYY puede usar la base de datos, pero no puede aplicar más copias de seguridad de registros, debe restaurarla WITH NORECOVERYpara poder incorporar copias de seguridad de registros. La recuperación rompe la cadena de registros al revertir las transacciones no confirmadas. )

Otras lecturas:

• 30 mitos de copia de seguridad de SQL Server
• Desacreditando un par de mitos sobre las copias de seguridad completas
• Registro y recuperación en SQL Server

Una copia de seguridad completa se restaurará en el momento en que se complete la porción de lectura de datos de la copia de seguridad, menos cualquier transacción no confirmada en ese momento.

Como mencionó, la base de datos permanece en línea y disponible para escribir mientras se realiza la copia de seguridad. Lo que funciona es que el sistema de copia de seguridad realiza una copia de seguridad de un conjunto inconsistente de páginas de datos (ya que lleva una cantidad de tiempo distinta de cero para leer los datos): toma una copia de cada página de datos a medida que llega, independientemente del estado en que se encuentre. in. Una copia de seguridad completa también incluye registros de registro de transacciones que comienzan desde el inicio de la transacción activa más antigua al comienzo de la copia de seguridad, hasta el último registro de registro cuando se completa la porción de lectura de datos.

Cuando se restaura la copia de seguridad, los datos y el registro se reconstituyen tal cual (recuerde que las páginas de datos están en un estado inconsistente), luego el proceso de rehacer ocurre desde el comienzo del registro de transacciones respaldado (nuevamente, dentro de la copia de seguridad completa) , hasta el final; luego, si restauró con RECOVERY, se produce deshacer para revertir cualquier transacción no confirmada en el momento en que finalizó la copia de seguridad. La operación de deshacer es lo que deja la base de datos en un estado transaccionalmente consistente, lista para usar. Restaurar con NORECOVERYomite el proceso de deshacer , lo que le permite restaurar copias de seguridad adicionales (registro diferencial o de transacciones).

Tenga en cuenta que si la base de datos es bastante grande con una gran carga de trabajo de escritura, el registro de transacciones puede necesitar crecer durante la copia de seguridad si no hay suficiente espacio asignado actualmente. El registro no puede (internamente) borrarse durante una copia de seguridad completa, incluso si está realizando copias de seguridad del registro de transacciones, ya que los registros de registro son necesarios para la copia de seguridad completa. Si está realizando copias de seguridad del registro de transacciones mientras se realiza una copia de seguridad completa, la eliminación del registro se aplaza automáticamente hasta que se complete la copia de seguridad completa.