Pourquoi ne puis-je pas réduire le fichier journal en mode de récupération complète
J'ai un fichier journal de 302 Mo.
J'ai effectué une sauvegarde du journal qui a laissé le fichier journal presque libre (je peux le voir dans le rapport standard d'utilisation du disque)
Si j'essaye de courir
DBCC SHRINKFILE (N'AdventureWorks2014_Log' , 0, TRUNCATEONLY)
ou
DBCC SHRINKFILE (N'AdventureWorks2014_Log' , 0)
le fichier affiche toujours 302 Mo.
Je sais que je peux changer la base de données en récupération simple, puis exécuter l'une des commandes ci-dessus et revenir à la récupération complète (puis effectuer une sauvegarde complète pour vous assurer que la base de données n'est pas en mode de récupération pseudo-simple =)
Cependant, pourquoi ne puis-je pas réduire le fichier en mode de récupération complète?
Je sais que la réduction n'est pas quelque chose que vous devriez faire, mais dans ma base de données du monde réel, puisque personne n'avait jamais sauvegardé le journal des transactions, il était passé à 30 Go et maintenant des sauvegardes régulières du journal ont été mises en place pour empêcher la croissance de ce niveau
Cependant, pourquoi ne puis-je pas réduire le fichier en mode de récupération complète?
Il fonctionne comme prévu . Vous avez juste besoin de mieux comprendre ce qui se passe, afin de pouvoir décider quelle est la mesure appropriée à prendre.
Ça, ou vous essayez juste de le réduire au mauvais moment (voir ma note # 7 ci-dessous).
Tout d'abord, le "fichier journal" est un peu inapproprié: SQL utilise le journal des transactions comme "espace de travail" pour tout ce qu'il fait, donc sa taille sera toujours non nulle . D'après mon expérience, je m'attends normalement à ce que le journal de transfert soit compris entre 10% et 25% de la taille des fichiers de données, selon le mode de récupération que vous utilisez et le type d'activité sur la base de données. Vous n'avez pas mentionné la taille de votre fichier de données, donc je ne peux pas juger si 302 Mo est gros (ça ne me semble pas très gros).
Concernant le mode de récupération, la question clé est la suivante: si vous devez récupérer la base de données (en raison d'une urgence), aurez-vous besoin d'une récupération "ponctuelle"? Ou une restauration de la dernière sauvegarde complète est-elle suffisante?
Mis à part certaines situations inhabituelles (réplication/CDC/mise en miroir/groupes de disponibilité), votre choix de mode de récupération est plus une décision commerciale que technique. Dans les deux modes, SQL Server utilise le journal des transactions pour les transactions en cours, la différence est ce qui se passe ensuite:
- Mode de récupération COMPLET : Lorsqu'une transaction est terminée, elle reste en place dans le journal de transfert jusqu'à ce que vous effectuiez une sauvegarde du journal de transactions . Cela a tendance à augmenter la taille du journal (selon la fréquence à laquelle vous exécutez les sauvegardes de journal), mais signifie que vous pouvez effectuer une récupération "ponctuelle" en cas de sinistre: vous pouvez restaurer la dernière sauvegarde complète, puis utiliser les sauvegardes du journal de transfert à "faire avancer" juste avant le sinistre.
- Mode de récupération SIMPLE : Lorsqu'une transaction est terminée, l'espace utilisé dans le journal de transfert est immédiatement disponible pour être réutilisé par des transactions ultérieures. Cela maintient le fichier journal des transactions (comparativement) petit, mais signifie que votre seul choix en cas de sinistre est de restaurer à partir de la dernière sauvegarde complète.
Dans certaines entreprises, vous utiliserez FULL pour toutes les bases de données de production et SIMPLE pour tous les environnements QA/DEV. Ou peut-être que certaines bases de données spécifiques, comme celles utilisées pour les rapports et/ou le traitement des données, n'ont pas besoin d'une récupération complète, car vous pouvez simplement réexécuter le traitement de la veille pour vous mettre à jour. Mais comme je l'ai dit, c'est une question de décision commerciale/d'analyse des risques, pas vraiment une question technique.
Donc, si vous n'avez pas besoin d'une récupération ponctuelle, passez-la en mode simple et laissez-la de cette façon.
Si vous avez besoin d'une récupération ponctuelle, passez-la en mode complet et exécutez des sauvegardes régulières des journaux de transfert tout au long de la journée, en fonction de vos besoins en matière de risque/récupération. L'heure est populaire, mais certaines personnes les recommandent beaucoup plus souvent .
Un dernier point auquel j'ai fait allusion auparavant: une fois que vous avez sélectionné le mode de récupération correct, vous devrez peut-être encore réduire un journal surdimensionné. Quelques points à garder à l'esprit:
- Encore une fois, assurez-vous d'avoir choisi le bon modèle de récupération
- Si vous exécutez en mode COMPLET, assurez-vous que vous exécutez des sauvegardes fréquentes des journaux de transfert
- Choisissez une taille cible raisonnable pour le journal, n'essayez jamais de le réduire à zéro. Je le redimensionne généralement en fonction de la taille totale des fichiers de données (ou au moins de l'espace utilisé dans les fichiers de données)
- Lisez et comprenez ce conseil important sur VLF size . Cela pourrait fournir plus de conseils sur la décision d'une taille de journal raisonnable, ou vous donner une meilleure méthode pour obtenir votre journal à cette taille.
- N'utilisez jamais
SHRINKDATABASE, utilisez toujoursSHRINKFILE - En mode simple et en mode complet, il est possible que le fin du fichier journal soit actuellement utilisé par SQL pour une transaction active. Si tel est le cas, il ne diminuera pas autant que vous le souhaitez. Réduisez-le à nouveau quelques minutes plus tard, et si la transaction est terminée, cela devrait mieux fonctionner la deuxième fois.
- Avec un journal de transfert particulièrement têtu en mode de récupération complète, j'ai eu de la chance de faire
SHRINKFILE, immédiatement suivi d'une sauvegarde du journal des transactions, immédiatement suivi d'un autreSHRINKFILE.
Votre question dit "J'ai fait une sauvegarde du journal" indiquant une sauvegarde . Si ce n'est pas déjà fait, effectuez quelques sauvegardes, puis essayez de réduire le journal. Il n'est pas rare que certaines transactions ne soient pas effacées avec une seule sauvegarde. J'en ai fait 3 ou 4 parfois avant qu'ils ne s'éclaircissent.
Exécutez ensuite DBCC LOGINFO pour voir à quoi ressemblent les fichiers VLF. Vous pouvez lire Pourquoi les fichiers journaux virtuels ne sont-ils pas toujours alloués dans l'ordre? pour en savoir un peu plus sur les VLF
La chose pertinente à savoir sur les fichiers journaux de transactions SQL Server est qu'ils sont écrits de manière circulaire. Cela va simplifier les choses et laisser de côté certains détails comme les fichiers journaux virtuels (comment ils sont réellement gérés en interne), mais c'est un fac-similé raisonnable de la réalité.
Imaginez que vous créez une base de données et lui donnez un fichier journal des transactions de 100 Mo. Les transactions seront écrites à partir du début du fichier. Supposons que vous disposiez alors de 50 Mo d'activité de transaction. Vous utilisez maintenant les 50 premiers Mo du journal des transactions de 100 Mo. Ensuite, vous effectuez une sauvegarde du journal des transactions. Maintenant, vous n'utilisez presque pas d'espace dans le journal des transactions; pratiquement tout est disponible pour (ré) utilisation. Mais que se passe-t-il si vous essayez de réduire le journal à, disons, 20 Mo? Cela le réduira à (environ) 50 Mo.
En effet, la partie active du journal se trouve autour de cette marque de 50 Mo et SQL Server ne réduira pas le journal au-delà de l'endroit où il est actuellement actif. Pensez-y un peu comme la tête de lecture sur une cassette, et SQL Server ne fera/ne pourra rien faire avec une bande qui est déjà sur la bobine réceptrice.
C'est pourquoi la réduction du journal des transactions est souvent un processus en deux étapes: vous effectuez la première sauvegarde et la réduction (coupez toute la bande vide après la tête de lecture), puis vous générez une activité de transaction afin que SQL Server soit obligé de boucler autour du début du fichier journal (rembobiner la bande), et enfin faire n autre sauvegarde et rétrécir (couper plus de bande vide pour atteindre votre taille cible).
Notez qu'il existe sont d'autres situations qui peuvent vous empêcher de réutiliser (et donc de réduire) les journaux. Habituellement, vous pouvez trouver la raison en consultant le log_reuse_wait_desc colonne dans master.sys.databases. La réplication transactionnelle, la mise en miroir de bases de données et les groupes de disponibilité AlwaysOn sont des coupables courants.
Si vous travaillez avec le modèle de récupération complète, par définition, vous avez besoin de sauvegardes du journal des transactions. Si vous n'en avez pas besoin, il est inutile d'avoir un modèle de récupération complète.
Vous n'êtes pas censé faire rétrécir votre chemin. De plus, cela réduit les performances.
Je suggère de prendre une sauvegarde du journal des transactions et de décider ensuite si vous avez besoin de Full ou si vous pouvez aller au modèle de récupération simple.
Vous pouvez également vérifier les transactions actives, peut-être avec dm_exec_sessions, et jeter un œil à votre niveau de fragmentation sur les index pour voir si vous avez une configuration qui ne vous aide pas à réduire.