Comment réduire la taille de la sauvegarde du journal des transactions après une sauvegarde complète?

J'ai trois plans de maintenance configurés pour s'exécuter sur une instance de SQL Server 2005:

• Optimisations hebdomadaires des bases de données suivies d'une sauvegarde complète
• Sauvegarde différentielle quotidienne
• Sauvegarde du journal des transactions horaire

Les sauvegardes de journaux horaires varient généralement entre quelques centaines de Ko et 10 Mo selon le niveau d'activité, les différences journalières atteignent généralement 250 Mo environ à la fin de la semaine et la sauvegarde hebdomadaire est d'environ 3,5 Go.

Le problème que j’ai, c’est que les optimisations antérieures à la sauvegarde complète semblent avoir pour conséquence que la prochaine sauvegarde du journal des transactions dépasse de 2x la taille de la sauvegarde complète, dans ce cas 8 Go, avant de revenir à la normale.

En dehors de cela BACKUP LOG <DatabaseName> WITH TRUNCATE_ONLY, y a-t-il un moyen de réduire la taille de cette sauvegarde de journal ou d'empêcher l'enregistrement des optimisations dans le journal des transactions, car elles seront sûrement comptabilisées dans la sauvegarde complète précédente?

Certaines suggestions intéressantes ici, qui semblent toutes montrer un malentendu sur le fonctionnement des sauvegardes de journaux. Une sauvegarde de journal contient TOUT le journal de transactions généré depuis la sauvegarde de journal précédente, quels que soient les sauvegardes complètes ou différentielles effectuées entre-temps. L'arrêt des sauvegardes de journal ou le passage à des sauvegardes complètes quotidiennes n'aura aucun effet sur la taille des sauvegardes de journal. La seule chose qui affecte le journal des transactions est une sauvegarde du journal, une fois que la chaîne de sauvegarde du journal a démarré.

La seule exception à cette règle concerne les cas où la chaîne de sauvegarde du journal a été rompue (en accédant par exemple au modèle de récupération SIMPLE, en rétablissant un instantané de base de données, en tronquant le journal à l'aide de BACKUP LOG WITH NO_LOG / TRUNCATE_ONLY), auquel cas la première sauvegarde en journal contiendra tout le journal des transactions depuis la dernière sauvegarde complète - ce qui relance la chaîne de sauvegarde du journal; ou si la chaîne de sauvegarde du journal n'a pas été démarrée - lorsque vous basculez sur FULL pour la première fois, vous utilisez une sorte de modèle de récupération pseudo-SIMPLE jusqu'à la première sauvegarde complète.

Pour répondre à votre question initiale, sans entrer dans le modèle de récupération SIMPLE, vous devrez vous arrêter en sauvegardant tout le journal des transactions. Selon les actions que vous effectuez, vous pouvez effectuer des sauvegardes de journal plus fréquentes pour réduire leur taille ou créer une base de données plus ciblée.

Si vous pouvez publier des informations sur les opérations de maintenance que vous effectuez, je peux vous aider à les optimiser. Faites-vous, par hasard, des reconstructions d’index suivies d’une base de données de réduction afin de récupérer l’espace utilisé par les reconstructions d’index?

Si vous n'avez aucune autre activité dans la base de données pendant la maintenance, vous pouvez procéder comme suit:

• assurez-vous que l'activité de l'utilisateur est arrêtée
• effectuer une sauvegarde finale du journal (cela vous permet de récupérer jusqu'au démarrage de la maintenance)
  • passer au modèle de récupération SIMPLE
  • effectuer la maintenance - le journal sera tronqué à chaque point de contrôle
  • basculer vers le modèle de récupération COMPLET et effectuer une sauvegarde complète
  • continuer comme d'habitude

J'espère que cela vous aidera - dans l'attente de plus d'informations.

Merci

[Éditer: après toute la discussion sur le point de savoir si une sauvegarde complète peut modifier la taille d’une sauvegarde de journal ultérieure (elle ne le peut pas), j’ai créé un article de blog complet avec des informations générales et un script qui le prouve. Vérifiez-le à l' adresse https://www.sqlskills.com/blogs/paul/misconceptions-around-the-log-and-log-backups-how-to-convince-yourself/]

Vous pouvez les réduire, mais ils ne feront que croître à nouveau, ce qui finira par provoquer la fragmentation du disque. La reconstruction et la défragmentation d’index génèrent des journaux de transactions très volumineux. Si vous n'avez pas besoin de la possibilité de récupération à un point dans le temps, vous pouvez passer au mode de récupération simple et supprimer complètement les sauvegardes du journal des transactions.

J'imagine que vous utilisez un plan de maintenance pour les optimisations. Vous pouvez le changer pour utiliser un script qui effectue la défragmentation d'index uniquement lorsqu'un certain niveau de fragmentation est atteint et vous ne risquez donc pas d'être affecté par les performances. Cela générerait des journaux beaucoup plus petits.

Je sauterais les différentiels quotidiens en faveur des sauvegardes complètes quotidiennes BTW.

Votre dernière question était: "En dehors de BACKUP LOG WITH TRUNCATE_ONLY, existe-t-il un moyen de réduire la taille de cette sauvegarde du journal, ou d'empêcher que les optimisations soient enregistrées dans le journal des transactions, car elles seront certainement prises en compte intégralement sauvegarde ils précèdent? "

Non, mais voici une solution de contournement. Si vous savez que les tâches de maintenance d'index ne seront les seules activités de cette base de données à ce moment-là, vous pouvez alors arrêter les sauvegardes du journal des transactions avant le début de la maintenance de l'index. Par exemple, certains de mes serveurs le samedi soir, les horaires de travail se présentent comme suit:

• 21h30 - La sauvegarde du journal des transactions s'exécute.
• 21h45: la sauvegarde du journal des transactions est exécutée pour la dernière fois. L’horaire s’arrête à 9h59.
• 22h00 - la tâche de maintenance de l'index commence et comporte des arrêts intégrés qui doivent être terminés avant 11h30.
• 23h30 - le travail de sauvegarde complète commence et se termine en moins de 30 minutes.
• 12:00 AM - les sauvegardes du journal des transactions recommencent toutes les 15 minutes.

Cela signifie que je n'ai pas de possibilité de récupération à un point dans le temps entre 21h45 et 23h30, mais le gain en retour est une performance plus rapide.

Réponse facile: modifiez votre travail d'optimisation hebdomadaire pour qu'il s'exécute de manière plus équilibrée tous les soirs. Ré-indexez les tables le dimanche soir, le lundi soir etc ... pour trouver un bon équilibre, votre log sera environ 1/6 de la taille moyenne. Bien sûr, cela fonctionne mieux si vous n'utilisez pas le travail de maintenance d'index intégré de ssis.

L’inconvénient de cela et de son importance en fonction de la charge de travail de votre base de données, c’est que l’optimiseur et la réutilisation des plans de requête sont dévastateurs.

Mais si vous ne vous souciez que de la taille de votre journal t-journal sur une base hebdomadaire, séparez-le jour après jour ou heure par heure et exécutez les sauvegardes entre les comptes t-log.

Vous pouvez également rechercher un outil tiers (Litespeed de Quest, Sauvegarde SQL de Red Gate, Hyperbac) pour réduire la taille des sauvegardes et des journaux. Ils peuvent se payer rapidement en économies de bande.

On peut probablement supposer que vos "optimisations" incluent les reconstructions d'index. Effectuer ces tâches uniquement sur une base hebdomadaire peut s'avérer acceptable sur une base de données ne contenant pas beaucoup de mises à jour et d'insertions. Toutefois, si vos données sont extrêmement fluides, vous souhaiterez peut-être procéder de différentes manières:

1. Reconstruisez ou réorganisez vos index tous les soirs si votre emploi du temps le permet et si l'impact est acceptable. Lors de l'exécution de ces tâches de maintenance des index nocturnes, ne ciblez que les index fragmentés à plus de 30% pour les reconstructions et de l'ordre de 15 à 30% pour les modifications.

2. Ces tâches sont des transactions journalisées, donc si vous êtes préoccupé par la croissance des journaux, je vous recommanderais donc ce que Paul a recommandé. La sauvegarde finale du journal des transactions avant la maintenance de l'index, basculez sur Récupération simple, puis sur le processus de maintenance, puis revenez sur Récupération complète, suivie d'une sauvegarde complète des données.

J'adopte une approche zen dans mes fichiers journaux: ils ont la taille souhaitée. Tant qu'ils n'ont pas subi de croissance excessive en raison de mauvaises pratiques de sauvegarde comparées à l'activité de base de données, c'est le mantra par lequel je vis.

En ce qui concerne les scripts effectuant la maintenance discrétionnaire des index, recherchez en ligne: il en existe une tonne. Andrew Kelly en a publié un bon dans SQL Magazine il y a environ un an. SQLServerPedia contient des scripts de Michelle Ufford et le dernier numéro de SQL Magazine (juillet 2009, je crois) contient également un article complet sur le sujet. L’essentiel est de trouver celui qui vous convient le mieux et de le personnaliser avec un minimum de personnalisations.

Pouvez-vous spécialement sauvegarder votre journal des transactions à différents moments de l'optimisation de votre base de données? La taille totale des journaux de transaction serait la même, mais chacun serait plus petit, ce qui pourrait éventuellement vous aider.

Pouvez-vous faire une optimisation plus ciblée de la base de données pour créer moins de transactions (quelqu'un en a parlé, mais je ne suis pas sûr que les implications aient été expliquées). Tels que tolérer une certaine quantité de fragmentation ou d'espace gaspillé pendant un moment. Si 40% de vos tables ne sont que 5% fragmentées, ne pas les toucher peut économiser un peu d'activité.