Exécution d'opérations de mise à jour des données lors de la sauvegarde d'une grande base de données SQL Server

J'ai une grande base de données (dans les dizaines de millions d'enregistrements) sur laquelle je vais effectuer une sauvegarde complète de la base de données .

Cependant, la base de données est suffisamment volumineuse pour que les transactions puissent démarrer avant et pendant, ainsi que la validation pendant et après la sauvegarde.

Par exemple:

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

Ma compréhension est qu'aucun verrou n'est utilisé pendant une sauvegarde (bien que d'autres problèmes de performances puissent survenir en raison, par exemple, d'E / S élevées) , mais je ne suis pas sûr de ce que je peux garantir ce qui sera validé ou non.

De plus, je ne crains pas que la base de données soit dans un état incohérent, mais plutôt ce que cet état sera (même s'il n'est pas déterministe, s'il existe un ensemble de règles qui peuvent être appliquées de manière cohérente) et comment il y est arrivé ( par exemple, quelle proportion du fichier de données est utilisée avec le journal des transactions pour créer un fichier de sauvegarde)?

Essentiellement, la sauvegarde aura l'état de la base de données lorsqu'elle aura terminé la partie de lecture des données de la sauvegarde (donc toutes les données seront sauvegardées), plus la quantité de journal de transactions requise pour garantir la cohérence transactionnelle (le début heure du journal inclus est MIN(most recent checkpoint time, oldest active transaction start time)). Paul Randal en parle ici (à l'aide d'un diagramme, ce qui rend tout cela beaucoup plus facile). Dans votre exemple, Aserait engagé (ou annulé si un a ROLLBACK TRANSACTIONété émis au lieu d'un COMMIT) et Bserait annulé (quel que soit le résultat final de cette transaction).

(L'autre raison pour laquelle vous essayez de faire des sauvegardes à un moment calme, à l'exception des conflits d'E / S, c'est que tout le journal des transactions généré pendant une sauvegarde doit normalement être inclus avec la sauvegarde.)

La phase de récupération d'une restauration de base de données prend toutes les transactions validées du journal inclus dans la sauvegarde et les applique à la base de données, et annule toutes les transactions non validées. (C'est pourquoi WITH RECOVERY/ WITH NORECOVERYest important. WITH RECOVERYEt vous pouvez utiliser la base de données, mais vous ne pouvez pas appliquer de sauvegardes de journal supplémentaires, vous devez la restaurer WITH NORECOVERYpour effectuer des sauvegardes de journal. La récupération rompt la chaîne de journaux en annulant les transactions non validées. )

Lectures complémentaires:

• 30 mythes sur la sauvegarde SQL Server
• Démystifier quelques mythes autour des sauvegardes complètes
• Journalisation et récupération dans SQL Server

Une sauvegarde complète sera restaurée au moment où la partie de lecture des données de la sauvegarde se termine, moins toutes les transactions non validées à ce moment.

Comme vous l'avez mentionné, la base de données reste en ligne et disponible pour l'écriture pendant la sauvegarde. Comment cela fonctionne, le système de sauvegarde sauvegarde un ensemble incohérent de pages de données (car il faut un temps non nul pour lire les données) - il prend une copie de chaque page de données au fur et à mesure, quel que soit son état dans. Une sauvegarde complète comprend également les enregistrements du journal des transactions à partir du début de la transaction active la plus ancienne au début de la sauvegarde, jusqu'au dernier enregistrement du journal à la fin de la partie de lecture des données.

Lorsque la sauvegarde est restaurée, les données et le journal sont reconstitués tels quels (rappelez-vous que les pages de données sont dans un état incohérent), puis le processus de rétablissement se produit depuis le début du journal des transactions sauvegardé (à nouveau, à l'intérieur de la sauvegarde complète) , jusqu'au bout; puis, si vous avez restauré avec RECOVERY, une annulation se produit pour annuler toutes les transactions non validées au moment où la sauvegarde est terminée. L' opération d' annulation est ce qui laisse la base de données dans un état transactionnellement cohérent, prête à l'emploi. La restauration avec NORECOVERYignore le processus d' annulation , vous permettant de restaurer des sauvegardes supplémentaires (différentiel ou journal des transactions).

Notez que si la base de données est assez volumineuse avec une charge de travail d'écriture importante, le journal des transactions peut avoir besoin de croître pendant la sauvegarde s'il n'y a pas suffisamment d'espace actuellement alloué. Le journal ne peut pas (en interne) s'effacer pendant une sauvegarde complète, même si vous effectuez des sauvegardes du journal des transactions, car les enregistrements de journal sont requis pour la sauvegarde complète. Si vous effectuez des sauvegardes du journal des transactions pendant une sauvegarde complète, l'effacement des journaux est différé automatiquement jusqu'à la fin de la sauvegarde complète.