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

38

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?

sql-server sql-server-2005 Dave
la source
1
+1 Ce vote a été voté à cause des échanges d'idées produits par cette question.
MarlonRibunal

Réponses:

35

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

Paul Randal
la source
4
Paul - totalement en désaccord. Il suffit de ne pas faire de sauvegarde des journaux lors de la maintenance de l'index. Le journal augmentera et la prochaine sauvegarde complète sera plus grande, mais les performances des sauvegardes t-log ne se produiront pas en même temps que vos tâches de maintenance d'index. Pouvez-vous voir le mérite de cela? Vous conviendrez sûrement que des sauvegardes et des opérations de maintenance d'index simultanées t-log provoqueraient des pertes de performances.
Brent Ozar
6
Non, je ne serais toujours pas d'accord. Je préférerais effectuer des sauvegardes de journal plus fréquentes afin qu'elles soient plus petites, plutôt qu'un seul monstre après la maintenance. Des sauvegardes de journaux de taille disproportionnée peuvent entraîner des problèmes de copie sur le réseau (par exemple, pour des sauvegardes hors site ou l'envoi de journaux). S'il n'y a aucune activité de l'utilisateur et que les sauvegardes de journal ne sont plus nécessaires, alors peut - être , mais si le système se bloque et que vous devez effectuer une sauvegarde en bout de journal, cela prendra beaucoup de temps, ce qui fait partie de votre temps d'indisponibilité. . Je devrais faire un blog à ce sujet.
Paul Randal
Et même cela n'aidera pas la question initiale de l'OP qui était de savoir comment réduire la taille de la sauvegarde du journal après la maintenance de l'index. En fait, cela pourrait potentiellement l'agrandir en fonction des opérations effectuées.
Paul Randal
5

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.

SqlACID
la source
Je suppose que je pourrais simplement faire un TRONCATE LOG directement à la fin de la sauvegarde complète, mais cela ne semble pas exactement la meilleure méthode. J'espérais des solutions de rechange ... Quels seraient les avantages de faire des sauvegardes complètes quotidiennes plutôt que diffs? Cela semble simplement utiliser plus d'espace pour un bénéfice relativement faible. Je ne peux pas non plus passer à la restauration simple, car j’ai besoin du niveau de granularité indiqué par les sauvegardes des journaux horaires. Enfin, je ne vois pas en quoi le transfert des optimisations dans un script aiderait certainement le même problème, mais moins fréquemment.
Dave
J'ai voté contre cela à cause de la suggestion de sauter les diffs et de passer aux pleins quotidiens. Pourquoi? Fulls a 3,5 Go alors que les diffs ne sont que 250Mo. La stratégie de sauvegarde me convient parfaitement. La suppression de diffs signifie beaucoup plus de stockage pour seulement 1 Go. Une toute petite accélération du temps de restauration.
Paul Randal
2
La situation de chacun est différente, il n'y a rien de mal avec les diffs, mais à moins que l'espace soit restreint, si vous avez besoin de récupérer rapidement, il vaut mieux avoir une étape que deux.
SqlACID
1
@Dave Voir la réponse de Jeremy, créez une procédure stockée pour défragmenter des fichiers spécifiques, découpez-la en fragments plus petits.
SqlACID
3

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.

Brent Ozar
la source
Et vous devez passer à SIMPLE juste avant 22 heures, n'est-ce pas? Sinon, la sauvegarde du journal 12h00 contiendra tous les journaux générés entre 22h00 et 12h00.
Paul Randal
Oops a oublié de mentionner que j'ai également voté en négatif, car vous n'avez pas mentionné le fait d'être dans SIMPLE. Le fait de rester dans BULK_LOGGED ne changera même pas la taille de la prochaine sauvegarde du journal, car toutes les étendues de données modifiées par les opérations à journalisation minimale seront récupérées. Wow - voté chaque réponse à cela jusqu'à présent.
Paul Randal
NON , ne passez certainement pas à la simplicité. Il a demandé quelle était la taille de ses sauvegardes du journal des transactions, pas la taille de ses sauvegardes complètes ou de son fichier de journal des transactions.
Brent Ozar
Comment vos activités réduisent-elles la taille des sauvegardes du journal des transactions? Ils contiendront tout depuis la sauvegarde du journal précédent, sauf si vous interrompez la chaîne de sauvegarde du journal, puis que vous la redémarrez avec la sauvegarde complète.
Paul Randal
Sauf si votre travail de maintenance d'index ne fait rien ...
Paul Randal
3

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.


la source
2

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.

Steve Jones
la source
2

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.

Tim Ford
la source
2

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

ErikE
la source