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 Sql Server 2005:
- Optimisations hebdomadaires de la base de données suivies d'une sauvegarde complète
- Sauvegarde différentielle quotidienne
- Sauvegardes du journal des transactions toutes les heures
Les sauvegardes de journaux horaires se situent généralement entre quelques centaines Kb et 10 Mo en fonction du niveau d'activité, les écarts quotidiens atteignent généralement environ 250 Mo à la fin de la semaine, et la sauvegarde hebdomadaire est d'environ 3,5 Gb.
Le problème que j'ai, c'est que les optimisations avant la sauvegarde complète semblent entraîner la croissance de la prochaine sauvegarde du journal des transactions à plus de 2x la taille de la sauvegarde complète, dans ce cas 8 Go, avant de revenir à la normale.
Autre que BACKUP LOG <DatabaseName> 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 sûrement prises en compte dans la sauvegarde complète qu'elles précèdent?
Quelques suggestions intéressantes ici, qui semblent toutes montrer un malentendu sur le fonctionnement des sauvegardes de journaux. Une sauvegarde de journal contient TOUS les journaux de transactions générés depuis la sauvegarde de journal précédente, quelles que soient les sauvegardes complètes ou différentielles effectuées entre-temps. L'arrêt des sauvegardes de journaux ou le passage à des sauvegardes complètes quotidiennes n'auront aucun effet sur la taille des sauvegardes de journaux. 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 est si la chaîne de sauvegarde du journal a été rompue (par exemple, en passant au modèle de récupération SIMPLE, en revenant d'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 du journal contiendra tout le journal des transactions depuis la dernière sauvegarde complète - qui redémarre la chaîne de sauvegarde du journal; ou si la chaîne de sauvegarde des journaux n'a pas été démarrée - lorsque vous passez en FULL pour la première fois, vous opérez dans une sorte de modèle de récupération pseudo-SIMPLE jusqu'à ce que la première sauvegarde complète soit effectuée.
Pour répondre à votre question d'origine, sans entrer dans le modèle de récupération SIMPLE, vous allez devoir aspirer en sauvegardant tout le journal des transactions. Selon les actions que vous effectuez, vous pouvez effectuer des sauvegardes de journaux plus fréquentes pour réduire leur taille ou effectuer 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. Êtes-vous en train de faire des reconstructions d'index suivies d'une base de données réduite pour 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 effectuer les opérations suivantes:
- assurez-vous que l'activité de l'utilisateur est arrêtée
- prendre une sauvegarde finale du journal (cela vous permet de récupérer jusqu'au point de 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
- passer au modèle de récupération complète 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
[Modifier: après toute la discussion sur la question de savoir si une sauvegarde complète peut modifier la taille d'une sauvegarde de journal ultérieure (elle ne peut pas), j'ai mis en place un article de blog complet avec du matériel de fond et un script qui le prouve. Découvrez-le sur 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, entraînant éventuellement une fragmentation du disque. Les reconstructions d'index et les défragmentation créent des journaux de transactions très volumineux. Si vous n'avez pas besoin d'une récupérabilité ponctuelle, vous pouvez passer en mode de récupération simple et supprimer entièrement 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 n'indexe les défragmentation que lorsqu'un certain niveau de fragmentation est atteint et que vous ne risquez probablement pas de perdre 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: "Autre que le JOURNAL DE SAUVEGARDE AVEC 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 sûrement comptabilisées car dans la sauvegarde complète ils précèdent? "
Non, mais voici une solution de contournement. Si vous savez que les seules activités de cette base de données à ce moment-là seront les travaux de maintenance d'index, vous pouvez arrêter les sauvegardes du journal des transactions avant le démarrage de la maintenance d'index. Par exemple, certains de mes serveurs le samedi soir, les horaires de travail ressemblent à ceci:
- 9:30 PM - la sauvegarde du journal des transactions s'exécute.
- 9:45 PM - la sauvegarde du journal des transactions s'exécute pour la dernière fois. La planification s'arrête à 9:59.
- 10:00 PM - le travail de maintenance d'index commence et a des arrêts intégrés pour se terminer avant 11:30.
- 11:30 PM - le travail de sauvegarde complète commence et se termine en moins de 30 minutes.
- 12:00 - les sauvegardes du journal des transactions recommencent toutes les 15 minutes.
Cela signifie que je n'ai pas de récupérabilité ponctuelle entre 9h45 et 23h30, mais le gain est une performance plus rapide.
Réponse simple: modifiez votre travail d'optimisation hebdomadaire pour qu'il s'exécute de manière plus équilibrée tous les soirs. c'est-à-dire réindexer les tables a-e le dimanche soir, f - l le lundi soir etc ... trouvez un bon équilibre, votre journal sera à peu près 1/6 de la taille en moyenne. Bien sûr, cela fonctionne mieux si vous n'utilisez pas le travail de maintenance d'index ssis intégré.
L'inconvénient de cela et il est important en fonction de la charge que subit votre base de données, c'est qu'il fait des ravages avec l'optimiseur et la réutilisation des plans de requête.
Mais si vous vous souciez uniquement de la taille de votre t-log sur une base hebdomadaire, divisez-le de jour en jour ou d'heure en heure et exécutez les sauvegardes de t-log entre les deux.
Vous pouvez également rechercher un outil tiers (Litespeed de Quest, SQL Backup de Red Gate, Hyperbac) pour réduire la taille des sauvegardes et des journaux. Ils peuvent se rentabiliser rapidement en économisant des bandes.
Pouvez-vous sauvegarder spécialement votre journal des transactions à différents moments de l'optimisation de votre base de données? La taille totale des t-logs serait la même, mais chacune serait plus petite, ce qui pourrait vous aider d'une manière ou d'une autre.
Pouvez-vous faire une optimisation de base de données plus ciblée afin de créer moins de transactions (quelqu'un l'a mentionné 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 perdu pendant un certain temps. Si 40% de vos tables ne sont fragmentées qu'à 5%, ne pas les toucher pourrait économiser pas mal d'activité.
On peut probablement supposer que vos "optimisations" incluent des reconstructions d'index. Seule l'exécution de ces tâches sur une base hebdomadaire peut être acceptable sur une base de données qui ne rencontre pas beaucoup de mises à jour et d'inserts, mais si vos données sont très fluides, vous voudrez peut-être faire quelques choses:
Reconstruisez ou réorganisez vos index tous les soirs si votre emploi du temps le permet et si l'impact est acceptable. Lorsque vous effectuez ces tâches de maintenance d'index tous les soirs, ciblez uniquement les index qui sont fragmentés au-delà de 30% pour les reconstructions et de 15 à 30% pour les réorganisations.
Ces tâches sont des transactions enregistrées, donc si vous êtes préoccupé par la croissance des journaux, je recommanderais ce que Paul a recommandé. La sauvegarde finale du journal des transactions avant la maintenance de l'index, passer à la récupération simple, suivie du processus de maintenance, puis revenir à la récupération complète suivie d'une sauvegarde complète des données devrait faire l'affaire.
J'adopte une approche zen pour mes fichiers journaux: ils ont la taille qu'ils souhaitent. Tant qu'ils n'ont pas subi une croissance effrénée en raison de mauvaises pratiques de sauvegarde par rapport à l'activité de base de données qui est le mantra par lequel je vis.
Quant aux scripts qui effectuent la maintenance discrétionnaire de l'index en ligne: il y en a une tonne. Andrew Kelly en a publié un décent 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. Le point est de trouver celui qui fonctionne bien pour vous et de le faire vôtre avec un minimum de personnalisations.