Le journal des transactions se rétrécira-t-il automatiquement dans SQL Server?

Lorsque la base de données SQL Server en mode SIMPLE, vous n'avez pas à vous soucier des bakcups du journal des transactions. Mais dans un mode SIMPLE, le journal des transactions semble augmenter comme il le fait en mode COMPLET. Est-ce que tronquer automatiquement à un moment donné? Ou dois-je le tronquer / rétrécir manuellement?

Il sera tronqué automatiquement mais c'est très différent de rétrécir. La troncature récupère l'espace du journal pour la réutilisation, la réduction physique réduit la taille du fichier pour libérer de l'espace sur le système d'exploitation. Si votre journal a atteint sa taille actuelle, il est probable qu'il repoussera si vous le réduisez.

Je vous suggère de vous familiariser avec l'utilisation typique et maximale des journaux pour votre système. La requête ci-dessous (pas la mienne, optimisée à partir des scripts DMV Glen Berrys) peut être exécutée manuellement ou vous pouvez capturer la sortie dans une table via un travail d'agent. Si vous le connectez à une table pendant une semaine environ, vous obtiendrez une image de l'utilisation typique et, plus important encore, lorsqu'un processus entraîne une croissance du journal au-delà de ce que vous attendez.

SELECT 
     db.[name] AS [Database Name]
   , db.recovery_model_desc AS [Recovery Model]
   , db.log_reuse_wait_desc AS [Log Reuse Wait Description]
   , ls.cntr_value AS [Log Size (KB)]
   , lu.cntr_value AS [Log Used (KB)]
   , CAST(
        CAST(lu.cntr_value AS FLOAT) / CAST(ls.cntr_value AS FLOAT) 
        AS DECIMAL(18,2)
     ) * 100 AS [Log Used %]
   , db.[compatibility_level] AS [DB Compatibility Level]
   , db.page_verify_option_desc AS [Page Verify Option]
   , db.is_auto_create_stats_on, db.is_auto_update_stats_on
   , db.is_auto_update_stats_async_on, db.is_parameterization_forced
   , db.snapshot_isolation_state_desc, db.is_read_committed_snapshot_on
FROM sys.databases AS db
   INNER JOIN sys.dm_os_performance_counters AS lu 
     ON db.name = lu.instance_name
   INNER JOIN sys.dm_os_performance_counters AS ls 
     ON db.name = ls.instance_name
WHERE lu.counter_name LIKE N'Log File(s) Used Size (KB)%' 
   AND ls.counter_name LIKE N'Log File(s) Size (KB)%'
   AND ls.cntr_value > 0 
OPTION (RECOMPILE);

La troncature du journal des transactions décrit à la fois quand et pourquoi la troncature du journal se produit.

Si les enregistrements du journal n'étaient jamais supprimés du journal des transactions, il remplirait éventuellement tout l'espace disque disponible pour les fichiers journaux physiques. La troncature du journal libère automatiquement de l'espace dans le journal logique pour la réutilisation par le journal des transactions.

Facteurs pouvant retarder la troncature du journal est une référence utile pour comprendre pourquoi votre journal peut ne pas être tronqué et donc devenir plus volumineux que prévu.

Non et non

• il ne rétrécira pas ou ne tronquera pas (au sens physique LDF, il le fera logiquement)
• il doit être de la taille pour ne pas rétrécir

Si vous le réduisez, il se développera à nouveau et vous aurez un fichier fragmenté

Comme mentionné précédemment, non, il ne se rétrécira pas automatiquement. Il nettoiera cependant quelques déchets.

La raison en est que dans le modèle de récupération complète, vous dites à SQL que vous souhaitez effectuer des sauvegardes tlog pour une récupération ponctuelle, il conserve donc un enregistrement de toutes les transactions effectuées sur une base de données.

Puisque vous lui dites que vous voulez une récupération ponctuelle, vous devez effectuer des sauvegardes complètes et des sauvegardes de tlog. Au fur et à mesure que vous effectuez vos sauvegardes tlog, il videra le contenu du journal (en plus de l'extrémité arrière) et recommencera.

Il peut être utile de considérer ces fichiers comme des conteneurs.

Ma suggestion est que si les tlogs sont devenus volumineux et ingérables, coupez une sauvegarde complète. Passer au SIMPLE récupérer modèle et RÉTRÉCISSEMENT le fichier tlogs. Revenez au modèle de récupération complète et effectuez la maintenance de la fragmentation *. Comme d'autres l'ont signalé, ce n'est pas la meilleure des pratiques et conduira à des niveaux élevés de fragmentation.

Planifiez et commencez un régime de sauvegarde après cela.

* Index reconstruire / réorganiser les opérations et la défragmentation au niveau du disque . Cela ne fait pas partie de la maintenance des journaux: vous conservez vos journaux T en les sauvegardant. Ce sont des conteneurs qui se développent lorsqu'ils approchent de leur capacité. Reconstruire / réorganiser peut aider à récupérer d'une mauvaise gestion des journaux conduisant à une utilisation importante du lecteur.