La sauvegarde d'une base de données réduit-elle la taille du journal des transactions?

J'essaie de rassembler des connaissances sur les bases de données SQL et j'ai des questions sur le fichier journal des transactions (LDF).

Tout d'abord, lorsque vous créez une base de données, vous devez définir une taille de fichier initiale pour la base de données et le fichier journal. D'après ce que je peux voir, une fois les fichiers créés sur le disque, ils auront la taille spécifiée, qu'il y ait des données réelles dans la base de données ou s'il y a eu des transactions (journaux).

Ma compréhension était que la sauvegarde d'une base de données:

1. Tronque le journal des transactions et
2. Rétrécit la taille

du fichier LDF sur le disque en "vidant" les journaux qu'il contient.

Il semble maintenant que je ne comprenais pas cela correctement car le fichier journal semble être de taille fixe. Ma vraie question va comme ceci:

Qu'est-ce que la troncature des journaux fait réellement au fichier journal (LDF)? Ce processus est censé empêcher les disques de se remplir.

Veuillez me corriger si je ne comprends pas correctement certains concepts.

Je vous remercie!

Le fichier journal des transactions (LDF) est composé de nombreux fichiers journaux virtuels (VLF) à l'intérieur. Pensez-y comme une armoire avec plusieurs tiroirs coulissants. Vous pouvez choisir un grand meuble, ou un petit - mais ce sera toujours une taille fixe avec juste un nombre différent de tiroirs.

Lorsque SQL Server fonctionne, il place vos transactions dans des tiroirs (VLF). Il commence à une extrémité de votre armoire, remplit le premier tiroir, puis lorsque l'espace est insuffisant dans ce tiroir, il passe au tiroir suivant.

Lorsque vous sauvegardez le journal des transactions, ce que vous faites réellement, c'est:

• Recherche du premier tiroir contenant des transactions qui n'ont pas encore été sauvegardées
• Copier ces transactions ailleurs
• Si ce tiroir n'est plus activement utilisé (parce que SQL Server est passé au tiroir suivant), vous marquez ce tiroir comme disponible pour être réutilisé (pensez-y comme jetant tout le contenu)

Les sauvegardes ne modifient pas la taille de votre armoire (fichier journal).

Correspondance et mixage

Sauvegarder le journal des transactions n'est pas la même chose que tronquer le fichier journal des transactions et tronquer le fichier journal des transactions n'est pas la même chose que réduire le fichier journal des transactions. Oh oui, et la sauvegarde du fichier journal des transactions ne doit pas déclencher de troncature. Selon la charge actuelle, le moteur de base de données peut décider de définir un point de contrôle, mais d'attendre un peu avec la troncature.

Expliquant

Le fichier journal des transactions est l'endroit où le moteur de base de données stocke les modifications apportées aux données dans une base de données, que la base de données soit dans le modèle de récupération SIMPLE ou dans le modèle de récupération FULL. (Important)

Désormais, le fichier journal des transactions de la base de données n'est plus un seul conteneur de stockage continu, mais une collection de fichiers journaux virtuels (VLF) qui sont créés dans un ordre séquentiel à l'intérieur du fichier journal des transactions (TLog). La taille des VLF varie en fonction de la version de SQL Server que vous utilisez actuellement et également de la taille initiale que vous avez sélectionnée lors de la création du fichier TLog et également de la taille que vous avez sélectionnée (le cas échéant) pour le paramètre de croissance automatique du Fichier TLog.

Références:
- Modification importante de l'algorithme de création de VLF dans SQL Server 2014 (SQLSkills.com)
- Numéros de séquence VLF initiaux et taille du fichier journal par défaut (SQLSkills.com)
- À l'intérieur du moteur de stockage: Plus d'informations sur la nature circulaire du journal (SQLSkills. com)
_{... et peut-être dans l'ordre inverse}

Lorsque les données sont modifiées dans la base de données, le moteur de base de données écrit ces modifications dans le TLog de la base de données correspondante pour maintenir la cohérence transactionnelle. Ceci est également connu comme ACID - atomicité, cohérence, isolement, durabilité . Les transcations réelles de ces modifications sont stockées dans les VLF du TLog (fichier). Lorsqu'un VLF est plein, les transactions les plus récentes seront stockées dans le prochain VLF disponible dans un ordre séquentiel.

Exceptions

Cependant si la fin du fichier TLog est atteinte, les modifications seront stockées dans le premier VLF au début du fichier TLog. (expliqué dans Inside the Storage Engine: Plus d'informations sur la nature circulaire du journal )

Lorsqu'aucun VLF disponible n'est libre de stocker de nouvelles transactions et si le paramètre de croissance automatique est configuré, le moteur de base de données augmentera le fichier TLog selon la quantité définie et créera des VLF supplémentaires en fonction de la taille définie dans les paramètres de croissance automatique et de la formule expliqué dans Modification importante de l'algorithme de création VLF dans SQL Server 2014 . D'autres transactions peuvent ensuite être stockées dans le VLF suivant à l'intérieur du fichier TLog.

Sauvegarde du fichier TLog

Lorsque vous déclenchez une sauvegarde du fichier TLog, tout ce que vous faites est de dire au moteur de base de données de

• jetez un oeil au fichier TLog
• déterminer quand la dernière sauvegarde du journal des transactions a eu lieu (LSN: numéro de séquence du journal; pour plus de recherche)
• définir un point de contrôle dans le fichier TLog ( points de contrôle de base de données (SQL Server) )
• stocker une copie de sauvegarde du fichier TLog sur disque / bande tout en conservant la trace du LSN précédent et du dernier LSN engagé juste avant la fin de la sauvegarde
• transférer toutes les modifications dans la "base de données"
• marquer les VLF comme réutilisables

Jusqu'à présent, aucun espace n'a été libéré à l'intérieur du fichier TLog pour le moteur de base de données à réutiliser ...

Troncature automatique du fichier TLog

... mais si le moteur de base de données a des cycles à épargner et n'est pas soumis à une pression très élevée, il consultera occasionnellement le fichier TLog, remarquera le point de contrôle et libérera les VLF pour réutilisation. L'espace à l'intérieur du fichier TLog est toujours utilisé par les VLF (même taille, même emplacement) mais ils sont libres d'être réutilisés.

Ceci est documenté dans la troncature du journal des transactions :

Sauf en cas de retard pour une raison quelconque, la troncature du journal se produit automatiquement comme suit: - Sous le modèle de récupération simple, après un point de contrôle.

• Sous le modèle de récupération complète ou le modèle de récupération enregistré en bloc, après une sauvegarde du journal, si un point de contrôle s'est produit depuis la sauvegarde précédente. Pour plus d'informations, voir «Troncature du journal sous les modèles de récupération complets et journalisés en bloc», plus loin dans cette rubrique.

Il y a des cas où cela ne se produit pas:

Bien que automatique, la troncature du journal peut être retardée par divers facteurs. Pour plus d'informations sur ce qui peut retarder la troncature du journal, consultez Facteurs pouvant retarder la troncature du journal .

Visualisation de la troncature du journal

La troncature du journal peut être observée lorsque vous interrogez la taille TLog à l'aide d'instructions SQL ou du rapport Espace de base de données dans l'interface utilisateur SSMS. Vous remarquerez peut-être que l'espace utilisé dans le fichier TLog ne représente que 1% de la taille du fichier TLog disponible.

Pour rétrécir ou ne pas rétrécir

La recommandation générale est de ne pas réduire le fichier TLog, car il a grandi pour une certaine raison et peut éventuellement repousser à la taille qu'il était auparavant. Mais c'est une histoire pour un autre post. Il existe de bonnes raisons, notamment lorsque vous recréez la taille des VLF dans votre fichier TLog.

Répondre à vos questions

Inline juste sous vos hypothèses et questions

Ma compréhension était que la sauvegarde d'une base de données:

• Tronque le journal des transactions et

C'est une fausse hypothèse. La sauvegarde de votre base de données (FULL, DIFFERENTIAL) ne fait rien avec les fichiers TLog. Une sauvegarde COMPLÈTE créera un état cohérent de votre base de données avec les transactions validées du fichier TLog. Une sauvegarde DIFF créera un état cohérent de toutes les sauvegardes TLog antérieures depuis la dernière sauvegarde COMPLÈTE de votre base de données.

Cependant, une sauvegarde TLOG créera une sauvegarde des transactions validées à partir du fichier TLog, définissant un point de contrôle et éventuellement (lorsqu'elle n'est pas sous une charge importante) libérant les VLF pour réutilisation.

• Rétrécit la taille

Non, si l'on considère les sauvegardes FULL et DIFF. Non, lorsque l'on considère les sauvegardes TLOG, mais cela libérera les VLF dans le fichier TLog, si le moteur de base de données a du temps à perdre.

Qu'est-ce que la troncature des journaux fait réellement au fichier journal (LDF)? Ce processus est censé empêcher les disques de se remplir.

La troncature des journaux permet de réutiliser les VLF. C'est tout.

Ce processus peut avoir l'avantage d'empêcher le fichier tlogs de croissance IF paramètres de croissance automatique ont été définis.

Si aucun paramètre de croissance automatique n'a été défini , car votre processus d'ingénierie des exigences a déterminé que le fichier TLog aurait une taille fixe, le pire des cas est que le TLog se remplit car aucune sauvegarde TLog ne se produit et donc aucun VLF n'est libéré. Le TLog ne peut pas croître et les VLF ne sont pas libérés pour permettre l'écriture d'autres transactions dans le fichier TLog (ou VLF en interne).

Bien que Brent Ozar vous ait déjà expliqué à quoi ressemble le fichier journal des transactions, je vais me concentrer sur vos certaines questions

Ma compréhension était que la sauvegarde d'une base de données:

• Tronque le journal des transactions et
• Rétrécit la taille

La sauvegarde complète ne fait rien pour les journaux de transactions dans n'importe quel modèle de récupération. Dans le modèle de récupération complète lorsque vous effectuez une sauvegarde du journal des transactions, il tronque le journal. S'il vous plaît noter que si une transaction de longue durée est toujours là détenant les VLF ou selon l'explication de Brent a toujours besoin des tiroirs, une autre transaction ne peut pas réutiliser le tiroir ou, en termes techniques, elle ne serait pas tronquée afin qu'elle puisse être réutilisée.

Il ne réduit pas non plus le journal des transactions. Pour réduire les journaux, vous devez utiliser la dbcc shrinkfilecommande

Qu'est-ce que la troncature des journaux fait réellement au fichier journal (LDF)? Ce processus est censé empêcher les disques de se remplir.

Il rend le fichier journal réutilisable afin que d'autres transactions puissent l'utiliser ou selon l'analogie de Brent, quelqu'un d'autre peut utiliser les tiroirs pour y conserver des trucs.

Après avoir parcouru la réponse, je vous recommande fortement de lire le journal des transactions sur SQLSKILLS.com