Esecuzione di operazioni di aggiornamento dei dati durante il backup di un database SQL Server di grandi dimensioni

Ho un grande database (nelle decine di milioni di record) su cui eseguirò un backup completo del database .

Tuttavia, il database è abbastanza grande da consentire l'avvio delle transazioni prima e durante, nonché il commit durante e dopo il backup.

Per esempio:

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
||----------||----------||----------||----------||----------||---------->

La mia comprensione è che non vengono utilizzati blocchi durante un backup (anche se potrebbero verificarsi altri problemi di prestazioni a causa di I / O elevati) , ma non sono sicuro di cosa posso garantire ciò che verrà commesso o meno.

Inoltre, la mia preoccupazione non è che il database si troverà in uno stato incoerente, ma piuttosto quale sarà tale stato (anche se non è deterministico, se esiste un insieme di regole che possono essere applicate in modo coerente) e come è arrivato lì ( ad esempio, quanto del file di dati viene utilizzato insieme al registro delle transazioni per creare un file di backup)?

Fondamentalmente, il backup sarà dello stato del database quando termina la porzione di lettura dei dati del backup (quindi verrà eseguito il backup di tutti i dati), oltre a qualsiasi quantità di registro delle transazioni sia necessaria per garantire la coerenza transazionale (l'inizio l'ora del registro incluso è MIN(most recent checkpoint time, oldest active transaction start time)). Paul Randal tratta questo qui (con l'aiuto di un diagramma, che rende tutto molto più semplice). Nel tuo esempio, Averrebbe eseguito il commit (o eseguito il rollback se ROLLBACK TRANSACTIONveniva emesso un anziché un COMMIT) e Bverrebbe eseguito il rollback (indipendentemente dal risultato finale di tale transazione).

(L'altro motivo per cui si tenta di eseguire i backup in un momento di inattività, oltre alla contesa I / O, è che tutto il registro delle transazioni generato durante un backup deve essere normalmente incluso nel backup.)

La fase di ripristino di un ripristino del database prende tutte le transazioni impegnate dal registro incluso nel backup e le applica al database e ripristina tutte le transazioni non impegnate. (Questo è il motivo per cui WITH RECOVERY/ WITH NORECOVERYè importante. WITH RECOVERYÈ possibile utilizzare il database, ma non è possibile applicare ulteriori backup dei log, è necessario ripristinarlo WITH NORECOVERYper eseguire il roll-in dei backup dei log. Il ripristino interrompe la catena di log eseguendo il rollback delle transazioni senza commit. )

Ulteriori letture:

• 30 miti del backup di SQL Server
• Sfatare un paio di miti su backup completi
• Registrazione e ripristino in SQL Server

Un backup completo verrà ripristinato nel momento in cui viene completata la parte di lettura dei dati del backup, meno eventuali transazioni non impegnate in quel momento.

Come accennato, il database rimane online e disponibile per la scrittura durante il backup. Il modo in cui funziona è che il sistema di backup esegue il backup di un insieme incoerente di pagine di dati (poiché richiede una quantità di tempo diversa da zero per leggere i dati): prende una copia di ogni pagina di dati man mano che arriva, indipendentemente dallo stato Un backup completo include anche i record del registro delle transazioni a partire dall'inizio della transazione attiva meno recente all'inizio del backup, fino all'ultimo record del registro al termine della parte di lettura dei dati.

Quando il backup viene ripristinato, i dati e il registro vengono ricostituiti così come sono (ricordare che le pagine di dati sono in uno stato incoerente), quindi il processo di ripetizione si verifica dall'inizio del registro delle transazioni di backup (di nuovo, all'interno del backup completo) , fino alla fine; quindi, se ripristinato con RECOVERY, l' annullamento si verifica per ripristinare tutte le transazioni non confermate al termine del backup. L' operazione di annullamento è ciò che lascia il database in uno stato transazionale coerente, pronto per l'uso. Il ripristino con NORECOVERYsalta il processo di annullamento , consentendo di ripristinare backup aggiuntivi (registro differenziale o delle transazioni).

Se il database è piuttosto grande con un carico di lavoro in scrittura pesante, potrebbe essere necessario aumentare il registro delle transazioni durante il backup se lo spazio attualmente allocato è insufficiente. Il registro non può (internamente) cancellarsi durante un backup completo, anche se si stanno eseguendo backup del registro delle transazioni, poiché i record del registro sono richiesti per il backup completo. Se si eseguono backup del registro delle transazioni mentre si verifica un backup completo, la cancellazione del registro viene automaticamente differita fino al completamento del backup completo.