Pourquoi le journal des transactions continue-t-il de croître ou de manquer d'espace?

Question

Celui-ci semble être une question courante dans la plupart des forums et sur le Web, il est posé ici dans de nombreux formats qui ressemblent généralement à ceci:

Dans SQL Server -

• Quelles sont les raisons pour lesquelles le journal des transactions devient si volumineux?
• Pourquoi mon fichier journal est-il si gros?
• Quels sont les moyens d'empêcher ce problème de se produire?
• Que dois-je faire lorsque je suis sur la bonne voie avec la cause sous-jacente et que je souhaite mettre mon fichier journal des transactions à une taille saine?

Answer 1

Une réponse plus courte:

Vous avez probablement soit une transaction de longue durée en cours d'exécution (maintenance de l'index? Suppression ou mise à jour par lots?) Ou vous êtes dans le mode de récupération "par défaut" (plus de détails sur ce que l'on entend par défaut) de Full et n'avez pas a pris une sauvegarde de journal (ou ne les prend pas assez fréquemment).

S'il s'agit d'un problème de modèle de récupération, la réponse simple pourrait être Passer en mode de récupération Simple si vous n'avez pas besoin d'une récupération ponctuelle et de sauvegardes de journal régulières. Beaucoup de gens, cependant, en font leur réponse sans comprendre les modèles de récupération. Lisez la suite pour comprendre pourquoi c'est important, puis décidez de ce que vous faites. Vous pouvez également commencer à prendre des sauvegardes de journaux et rester dans la récupération Full.

Il pourrait y avoir d'autres raisons, mais ce sont les plus courantes. Cette réponse commence à plonger dans les deux raisons les plus courantes et vous donne quelques informations de base sur le pourquoi et le comment derrière les raisons et explore d'autres autres raisons.

---

Une réponse plus longue: Quels scénarios peuvent faire en sorte que le journal continue de croître? Il existe de nombreuses raisons, mais généralement ces raisons sont des deux modèles suivants: Il y a un malentendu sur les modèles de récupération ou il y a des transactions de longue durée. Lisez la suite pour plus de détails.

Raison principale 1/2: ne pas comprendre les modèles de récupération

( Être en mode de récupération complète et ne pas prendre sauvegardes de journaux - C'est la plus courante raison - la grande majorité de ceux qui connaissent ce problème le sont. )

Bien que cette réponse ne soit pas une plongée en profondeur dans les modèles de récupération SQL Server, le sujet des modèles de récupération est essentiel à ce problème.

Dans SQL Server, il existe trois modèles de récupération :

• Full,
• Bulk-Logged et
• Simple.

Nous ignorerons Bulk-Logged pour l'instant, nous dirons en quelque sorte qu'il s'agit d'un modèle hybride et la plupart des personnes qui sont dans ce modèle sont là pour une raison et comprennent les modèles de récupération.

Les deux qui nous tiennent à cœur et leur confusion sont à l'origine de la majorité des cas de personnes ayant ce problème: Simple et Full.

Entracte: récupération en général

Avant de parler des modèles de récupération: parlons de la récupération en général. Si vous voulez approfondir ce sujet, lisez simplement le blog de Paul Randal et autant de publications que vous le souhaitez. Pour cette question, cependant:

1. Récupération après un crash/redémarrage
   L'un des objectifs du fichier journal des transactions est de récupération après incident/redémarrage . Pour le déroulement en avant et le retour en arrière du travail qui a été effectué (avancer/refaire) avant un crash ou redémarrer et le travail qui a été commencé mais pas terminé après un crash ou redémarrer (revenir en arrière/annuler). C'est le travail du journal des transactions de voir qu'une transaction a commencé mais jamais terminée (annulation ou plantage/redémarrage survenu avant la validation de la transaction). Dans cette situation, c'est le travail du journal de dire "Hé .. ce n'est jamais vraiment fini, revenons en arrière" pendant la récupération. C'est aussi le travail du journal de voir que vous avez terminé quelque chose et que votre application cliente a été informée qu'elle était terminée (même si elle n'avait pas encore durci votre fichier de données) et dire "Hey .. c'est vraiment arrivé, passons à autre chose, faisons comme les applications pensent que c'était " après un redémarrage. Maintenant, il y a plus, mais c'est le but principal.

2. Récupération ponctuelle
   L'autre objectif d'un fichier journal des transactions est de pouvoir nous donner la possibilité de récupérer à un point dans le temps en raison d'un "oups" dans une base de données ou pour garantir un point de récupération en cas de panne matérielle impliquant les données et/ou les fichiers journaux d'une base de données. Si ce journal des transactions contient les enregistrements des transactions qui ont été démarrées et terminées pour la récupération, SQL Server peut et utilise ensuite ces informations pour obtenir une base de données où elle se trouvait avant qu'un problème ne se produise. Mais ce n'est pas toujours une option disponible pour nous. Pour que cela fonctionne, nous devons avoir notre base de données dans le bon modèle de récupération , et nous devons prendre des sauvegardes de journal .

Modèles de récupération

Sur les modèles de récupération:

• Modèle de récupération simple
  Donc, avec l'introduction ci-dessus, il est plus facile de parler de Simple Recovery modèle en premier. Dans ce modèle, vous dites à SQL Server: "Je suis d'accord avec vous en utilisant votre fichier journal des transactions pour le crash et la reprise de la récupération ..." (Vous n'avez vraiment pas le choix. Cherchez propriétés ACID et cela devrait avoir un sens rapidement.) "... mais une fois que vous n'en avez plus besoin à cette fin de récupération après un crash/redémarrage, allez-y et réutilisez le fichier journal."

  SQL Server écoute cette demande dans Simple Recovery et ne conserve que les informations dont il a besoin pour effectuer une récupération après panne/redémarrage. Une fois que SQL Server est sûr qu'il peut récupérer car les données sont durcies dans le fichier de données (plus ou moins), les données qui ont été durcies ne sont plus nécessaires dans le journal et sont marquées pour la troncature - ce qui signifie qu'elles sont réutilisées.

• Modèle de récupération complète
  Avec Full Recovery, vous dites à SQL Server que vous souhaitez pouvoir récupérer à un moment précis, tant que votre fichier journal est disponible ou à un moment spécifique couvert par une sauvegarde de journal. Dans ce cas, lorsque SQL Server atteint le point où il serait sûr de tronquer le fichier journal dans le modèle de récupération simple, il ne le fera pas. Au lieu de cela Il permet au fichier journal de continuer à croître et lui permettra de continuer à croître, jusqu'à ce que vous effectuiez une sauvegarde du journal (ou que vous manquiez d'espace sur votre lecteur de fichier journal) dans des circonstances normales.

Passer de Simple à Complet a un Gotcha.

Il y a des règles et des exceptions ici. Nous parlerons en détail des transactions de longue durée ci-dessous.

Mais une mise en garde à garder à l'esprit pour le mode de récupération complète est la suivante: si vous passez simplement en Full Recovery, mais n'effectuez jamais de sauvegarde complète initiale, SQL Server n'honorera pas votre demande d'être en Full Recovery modèle. Votre journal des transactions continuera de fonctionner comme il l'a fait dans Simple jusqu'à ce que vous passiez au modèle de récupération complète ET que vous preniez votre premier Full Backup.

Le modèle de récupération complète sans sauvegarde de journal est incorrect.

Alors, quelle est la raison la plus courante de croissance incontrôlée des billes? Réponse: Être en mode de récupération complète sans avoir de sauvegarde de journal.

Cela se produit tout le temps pour les gens.

Pourquoi est-ce une erreur si courante?

Pourquoi ça arrive tout le temps? Parce que chaque nouvelle base de données obtient son paramètre de modèle de récupération initial en consultant la base de données du modèle.

Le paramètre initial du modèle de récupération du modèle est toujours Full Recovery Model - jusqu'à ce que et à moins que quelqu'un ne change cela. Vous pouvez donc dire que le "modèle de récupération par défaut" est Full. De nombreuses personnes ne le savent pas et leurs bases de données s'exécutent dans Full Recovery Model sans sauvegarde de journal, et donc un fichier journal de transactions beaucoup plus volumineux que nécessaire. C'est pourquoi il est important de modifier les valeurs par défaut lorsqu'elles ne fonctionnent pas pour votre organisation et ses besoins)

Le modèle de récupération complète avec trop peu de sauvegardes de journaux est mauvais.

Vous pouvez également vous mettre en difficulté ici en ne prenant pas les sauvegardes de journaux assez fréquemment.
Prendre une sauvegarde de journal par jour peut sembler correct, cela nécessite une restauration nécessitant moins de commandes de restauration, mais en gardant à l'esprit la discussion ci-dessus, ce fichier journal continuera de croître et de grandir jusqu'à ce que vous effectuiez des sauvegardes de journal.

Comment connaître la fréquence de sauvegarde des journaux dont j'ai besoin?

Vous devez considérer la fréquence de sauvegarde de vos journaux avec deux choses à l'esprit:

1. Besoins de récupération - Cela devrait, espérons-le, être le premier. Dans le cas où le lecteur hébergeant votre journal des transactions devient défectueux ou que vous obtenez une corruption grave qui affecte votre sauvegarde du journal, combien de données peuvent être perdues? Si ce nombre ne dépasse pas 10 à 15 minutes, vous devez effectuer la sauvegarde du journal toutes les 10 à 15 minutes, fin de la discussion.
2. Croissance des journaux - Si votre organisation est en mesure de perdre plus de données en raison de la possibilité de recréer facilement ce jour-là, vous pouvez être en mesure d'avoir une sauvegarde de journal beaucoup moins fréquemment que 15 minutes. Peut-être que votre organisation va bien toutes les 4 heures. Mais vous devez regarder combien de transactions vous générez en 4 heures. Le fait de permettre au journal de continuer de croître au cours de ces quatre heures fera-t-il un fichier journal trop volumineux? Cela signifie-t-il que vos sauvegardes de journaux prennent trop de temps?

---

Raison principale 2/2: Transactions de longue durée

( "Mon modèle de récupération fonctionne bien! Le journal continue de grandir! )

Cela peut également être une cause de croissance non contrôlée et non restreinte des billes. Peu importe le modèle de récupération, mais il apparaît souvent sous la forme "Mais je suis dans le modèle de récupération simple - pourquoi mon journal continue-t-il de grandir?!"

La raison ici est simple: si SQL utilise ce journal de transactions à des fins de récupération comme je l'ai décrit ci-dessus, il doit alors revenir au début d'une transaction.

Si vous avez une transaction qui prend beaucoup de temps ou fait beaucoup de modifications, le journal ne peut pas tronquer au point de contrôle pour aucune des modifications qui sont encore dans les transactions ouvertes ou qui ont commencé depuis le début de cette transaction.

Cela signifie qu'une grande suppression, la suppression de millions de lignes dans une instruction de suppression est une transaction et que le journal ne peut pas tronquer tant que cette suppression n'est pas terminée. Dans Full Recovery Model, cette suppression est enregistrée et cela pourrait être un grand nombre d'enregistrements de journal. Même chose avec le travail d'optimisation d'index pendant les fenêtres de maintenance. Cela signifie également qu'une mauvaise gestion des transactions et le fait de ne pas surveiller et de fermer les transactions ouvertes peuvent vraiment nuire à vous et à votre fichier journal.

Que puis-je faire à propos de ces transactions de longue durée?

Vous pouvez vous sauver ici en:

• Dimensionner correctement votre fichier journal pour tenir compte du pire des cas, comme votre maintenance ou vos opérations d'envergure connues. Et lorsque vous développez votre fichier journal, vous devez consulter ce guidance (et les deux liens vers lesquels elle vous envoie) par Kimberly Tripp. Le bon dimensionnement est super critique ici.
• Surveiller votre utilisation des transactions. Ne démarrez pas une transaction dans votre serveur d'applications et commencez à avoir de longues conversations avec SQL Server et risquez d'en laisser une ouverte trop longtemps.
• Regarder les transactions implicites dans vos instructions DML. Par exemple: UPDATE TableName Set Col1 = 'New Value' est une transaction. Je n'ai pas mis de BEGIN TRAN là et je n'ai pas à le faire, c'est toujours une transaction qui est automatiquement validée une fois terminée. Par conséquent, si vous effectuez des opérations sur un grand nombre de lignes, envisagez de regrouper ces opérations en segments plus faciles à gérer et de donner au journal le temps de récupérer. Ou pensez à la bonne taille pour y faire face. Ou peut-être envisager de modifier les modèles de récupération pendant une fenêtre de chargement en bloc.

---

Ces deux raisons s'appliquent-elles également à l'envoi de journaux?

Réponse courte: oui. Réponse plus longue ci-dessous.

Question: "J'utilise l'envoi de journaux, donc mes sauvegardes de journaux sont automatisées ... Pourquoi est-ce que je constate toujours une croissance du journal des transactions?"

Réponse: lisez la suite.

Qu'est-ce que l'expédition de journaux?

L'envoi de journaux est exactement ce que cela ressemble - vous envoyez vos sauvegardes de journaux de transactions à un autre serveur à des fins de reprise après sinistre. Il y a une initialisation mais après cela le processus est assez simple:

• Un travail pour sauvegarder le journal sur un serveur,
• un travail pour copier cette sauvegarde du journal et
• un travail pour le restaurer sans récupération (NORECOVERY ou STANDBY) sur le serveur de destination.

Il existe également des tâches à surveiller et à alerter si les choses ne se déroulent pas comme vous les avez planifiées.

Dans certains cas, vous ne souhaiterez effectuer la restauration de l'envoi des journaux qu'une fois par jour ou tous les trois jours ou une fois par semaine. C'est bon. Mais si vous effectuez cette modification sur tous les travaux (y compris les travaux de sauvegarde et de copie des journaux), cela signifie que vous attendez tout le temps pour effectuer une sauvegarde des journaux. Cela signifie que vous aurez beaucoup de croissance de journaux - parce que vous êtes en mode de récupération complète sans sauvegardes de journaux - et cela signifie probablement aussi un gros fichier journal à copier. Vous devez uniquement modifier le calendrier du travail de restauration et laisser les sauvegardes et les copies de journaux se produire plus fréquemment, sinon vous souffrirez du premier problème décrit dans cette réponse.

---

Dépannage général via les codes d'état

Il y a des raisons autres que ces deux, mais ce sont les plus courantes. Quelle que soit la cause: il existe un moyen d'analyser la raison de cette croissance/absence de troncature inexpliquée et de voir ce qu'elles sont.

En interrogeant le sys.databases vue catalogue, vous pouvez voir des informations décrivant la raison pour laquelle votre fichier journal peut attendre d'être tronqué/réutilisé.

Il y a une colonne appelée log_reuse_wait avec un ID de recherche du code anomalie et un log_reuse_wait_desc colonne avec une description de la raison de l'attente. À partir des livres référencés, l'article en ligne contient la majorité des raisons (celles que vous êtes susceptible de voir et celles que nous pouvons expliquer. Les manquantes sont soit hors d'usage soit à usage interne) avec quelques notes sur l'attente italique :

• 0 = rien
  À quoi cela ressemble. Ne devrait pas attendre

• 1 = point de contrôle
  En attente d'un point de contrôle. Cela devrait arriver et tout devrait bien se passer - mais il y a des cas à rechercher ici pour des réponses ou des modifications ultérieures.

• 2 = Sauvegarde du journal
  Vous attendez qu'une sauvegarde du journal se produise. Soit vous les avez planifiés et cela arrivera bientôt, soit vous avez le premier problème décrit ici et vous savez maintenant comment le résoudre

• 3 = Sauvegarde ou restauration active
  Une opération de sauvegarde ou de restauration est en cours d'exécution sur la base de données

• 4 = transaction active
  Il y a une transaction active qui doit se terminer (de toute façon - ROLLBACK ou COMMIT) avant que le journal puisse être sauvegardé. C'est la deuxième raison décrite dans cette réponse.

• 5 = Mise en miroir de la base de données
  Soit un miroir prend du retard ou subit une certaine latence dans une situation de mise en miroir haute performance, soit la mise en miroir est interrompue pour une raison quelconque

• 6 = réplication
  Il peut y avoir des problèmes avec la réplication qui pourraient provoquer cela - comme un agent de lecture de journal qui ne fonctionne pas, une base de données pensant qu'elle est marquée pour la réplication qui ne l'est plus et diverses autres raisons. Vous pouvez également voir cette raison et c'est parfaitement normal car vous regardez au bon moment, tout comme les transactions sont consommées par le lecteur de journal

• 7 = Création d'un instantané de base de données
  Vous créez un instantané de base de données, vous le verrez si vous regardez juste au bon moment lors de la création d'un instantané

• 8 = Analyse des journaux
  Je n'ai pas encore rencontré de problème avec ce fonctionnement indéfiniment. Si vous regardez assez longtemps et assez souvent, vous pouvez voir cela se produire, mais cela ne devrait pas être une cause de croissance excessive du journal des transactions, comme je l'ai vu.

• 9 = Un réplica secondaire AlwaysOn Availability Groups applique les enregistrements du journal des transactions de cette base de données à une base de données secondaire correspondante. À propos de la description la plus claire à ce jour ..

Answer 2

Étant donné que je ne suis pas vraiment satisfait de l'une des réponses sur Stack Overflow , y compris la suggestion la plus votée, et parce qu'il y a certaines choses que j'aimerais aborder, la réponse de Mike le fait non, je pensais que j'apporterais ma contribution ici aussi. J'ai également placé une copie de cette réponse.

La réduction de la taille d'un fichier journal doit vraiment être réservée aux scénarios où il a rencontré une croissance inattendue qui ne devrait pas se reproduire. Si le fichier journal atteint à nouveau la même taille, il n'y a pas grand-chose à faire en le réduisant temporairement. Maintenant, selon les objectifs de récupération de votre base de données, ce sont les actions que vous devez prendre.

Tout d'abord, effectuez une sauvegarde complète

Ne modifiez jamais votre base de données sans vous assurer de pouvoir la restaurer en cas de problème.

Si vous vous souciez de la récupération ponctuelle

(Et par récupération ponctuelle, je veux dire que vous vous souciez de pouvoir restaurer sur autre chose qu'une sauvegarde complète ou différentielle.)

Vraisemblablement, votre base de données est en mode de récupération FULL. Sinon, assurez-vous que c'est:

ALTER DATABASE yourdb SET RECOVERY FULL;

Même si vous effectuez des sauvegardes complètes régulières, le fichier journal augmentera et augmentera jusqu'à ce que vous effectuiez une sauvegarde log - c'est pour votre protection, pour ne pas ronger inutilement votre espace disque. Vous devez effectuer ces sauvegardes de journaux assez fréquemment, selon vos objectifs de récupération. Par exemple, si vous avez une règle d'entreprise qui stipule que vous pouvez vous permettre de perdre pas moins de 15 minutes de données en cas de sinistre, vous devez avoir un travail qui sauvegarde le journal toutes les 15 minutes. Voici un script qui générera des noms de fichiers horodatés en fonction de l'heure actuelle (mais vous pouvez également le faire avec des plans de maintenance, etc., ne choisissez aucune des options de réduction dans les plans de maintenance, elles sont horribles).

DECLARE @path NVARCHAR(255) = N'\\backup_share\log\yourdb_' 
  + CONVERT(CHAR(8), GETDATE(), 112) + '_'
  + REPLACE(CONVERT(CHAR(8), GETDATE(), 108),':','')
  + '.trn';

BACKUP LOG foo TO DISK = @path WITH INIT, COMPRESSION;

Notez que \\backup_share\ Doit se trouver sur une machine différente qui représente un périphérique de stockage sous-jacent différent. Les sauvegarder sur la même machine (ou sur une autre machine qui utilise les mêmes disques sous-jacents, ou un autre VM qui se trouve sur le même hôte physique) ne vous aide pas vraiment, car si la machine explose, vous avez perdu votre base de données et ses sauvegardes. Selon votre infrastructure réseau, il peut être plus judicieux de sauvegarder localement, puis de les transférer vers un autre emplacement en arrière-plan; dans les deux cas, vous souhaitez les retirer de la machine de base de données principale le plus rapidement possible.

Maintenant, une fois que vous avez des sauvegardes de journaux régulières en cours d'exécution, il devrait être raisonnable de réduire le fichier journal à quelque chose de plus raisonnable que ce qu'il a fait exploser jusqu'à présent. Cela signifie pas signifie exécuter SHRINKFILE maintes et maintes fois jusqu'à ce que le fichier journal soit de 1 Mo - même si vous sauvegardez fréquemment le journal, il doit toujours contenir la somme de toutes les transactions simultanées qui peuvent se produire. Les événements de croissance automatique des fichiers journaux sont coûteux, car SQL Server doit mettre à zéro les fichiers (contrairement aux fichiers de données lorsque l'initialisation instantanée des fichiers est activée), et les transactions utilisateur doivent attendre pendant que cela se produit. Vous voulez faire cette routine de croissance-rétrécissement-croissance-rétrécissement le moins possible, et vous ne voulez certainement pas faire payer vos utilisateurs.

Notez que vous devrez peut-être sauvegarder le journal deux fois avant qu'une réduction ne soit possible (merci Robert).

Donc, vous devez trouver une taille pratique pour votre fichier journal. Personne ici ne peut vous dire ce que c'est sans en savoir beaucoup plus sur votre système, mais si vous avez fréquemment réduit le fichier journal et qu'il a de nouveau augmenté, un bon filigrane est probablement 10 à 50% plus élevé que le plus gros qu'il ait été. . Supposons que cela représente 200 Mo et que vous souhaitiez que les événements de croissance automatique ultérieurs soient de 50 Mo, vous pouvez ajuster la taille du fichier journal de cette façon:

USE [master];
GO
ALTER DATABASE Test1 
  MODIFY FILE
  (NAME = yourdb_log, SIZE = 200MB, FILEGROWTH = 50MB);
GO

Notez que si le fichier journal est actuellement> 200 Mo, vous devrez peut-être exécuter ceci en premier:

USE yourdb;
GO
DBCC SHRINKFILE(yourdb_log, 200);
GO

Si vous ne vous souciez pas de la récupération ponctuelle

S'il s'agit d'une base de données de test et que vous ne vous souciez pas de la récupération ponctuelle, vous devez vous assurer que votre base de données est en mode de récupération SIMPLE.

ALTER DATABASE yourdb SET RECOVERY SIMPLE;

Le fait de mettre la base de données en mode de récupération SIMPLE garantira que SQL Server réutilise des parties du fichier journal (essentiellement en supprimant progressivement les transactions inactives) au lieu de croître pour conserver un enregistrement de all = transactions (comme FULL la récupération le fait jusqu'à ce que vous sauvegardiez le journal). CHECKPOINT événements aideront à contrôler le journal et à s'assurer qu'il n'a pas besoin de croître à moins que vous ne génériez beaucoup d'activité t-log entre CHECKPOINTs.

Ensuite, vous devez vous assurer que cette croissance du journal est vraiment due à un événement anormal (par exemple, un nettoyage de printemps annuel ou la reconstruction de vos plus gros indices), et non à une utilisation quotidienne normale. Si vous réduisez le fichier journal à une taille ridiculement petite et que SQL Server n'a qu'à le développer à nouveau pour s'adapter à votre activité normale, qu'avez-vous gagné? Avez-vous pu utiliser l'espace disque que vous avez libéré temporairement? Si vous avez besoin d'un correctif immédiat, vous pouvez exécuter ce qui suit:

USE yourdb;
GO
CHECKPOINT;
GO
CHECKPOINT; -- run twice to ensure file wrap-around
GO
-- 200 MB
DBCC SHRINKFILE(yourdb_log, 200);
GO

Sinon, définissez une taille et un taux de croissance appropriés. Selon l'exemple du cas de récupération ponctuelle, vous pouvez utiliser le même code et la même logique pour déterminer la taille de fichier appropriée et définir des paramètres de croissance automatique raisonnables.

Certaines choses que vous ne voulez pas faire

• Sauvegardez le journal avec l'option TRUNCATE_ONLY Puis SHRINKFILE. D'une part, cette option TRUNCATE_ONLY A été déconseillée et n'est plus disponible dans les versions actuelles de SQL Server. Deuxièmement, si vous êtes dans le modèle de récupération FULL, cela détruira votre chaîne de journaux et nécessitera une nouvelle sauvegarde complète.

• Détachez la base de données, supprimez le fichier journal et rattachez-le . Je ne peux pas souligner à quel point cela peut être dangereux. Votre base de données peut ne pas remonter, elle peut apparaître comme suspecte, vous devrez peut-être revenir à une sauvegarde (si vous en avez une), etc. etc.

• Utilisez l'option "réduire la base de données" . DBCC SHRINKDATABASE Et l'option du plan de maintenance pour faire de même sont de mauvaises idées, surtout si vous n'avez vraiment besoin que de résoudre un problème de journal. Ciblez le fichier que vous souhaitez ajuster et ajustez-le indépendamment, en utilisant DBCC SHRINKFILE Ou ALTER DATABASE ... MODIFY FILE (Exemples ci-dessus).

• Réduisez le fichier journal à 1 Mo . Cela semble tentant car, hé, SQL Server me laisse le faire dans certains scénarios, et regarde tout l'espace qu'il libère! À moins que votre base de données ne soit en lecture seule (et c'est le cas, vous devez la marquer comme telle en utilisant ALTER DATABASE), Cela entraînera absolument de nombreux événements de croissance inutiles, car le journal doit prendre en charge les transactions actuelles quel que soit le modèle de récupération . Quel est l'intérêt de libérer temporairement cet espace, juste pour que SQL Server puisse le récupérer lentement et douloureusement?

• Créez un deuxième fichier journal . Cela soulagera temporairement le lecteur qui a rempli votre disque, mais cela revient à essayer de réparer un poumon perforé avec un pansement. Vous devez traiter le fichier journal problématique directement au lieu d'ajouter simplement un autre problème potentiel. Outre la redirection d'une activité du journal des transactions vers un autre lecteur, un deuxième fichier journal ne fait vraiment rien pour vous (contrairement à un deuxième fichier de données), car un seul des fichiers peut être utilisé à la fois. Paul Randal explique également pourquoi plusieurs fichiers journaux peuvent vous mordre plus tard .

Etre pro-actif

Au lieu de réduire votre fichier journal à une petite quantité et de le laisser se développer automatiquement en continu à un petit taux par lui-même, définissez-le sur une taille raisonnablement grande (qui acceptera la somme de votre plus grand ensemble de transactions simultanées) et définissez une croissance automatique raisonnable en tant que solution de rechange, de sorte qu'il ne doive pas croître plusieurs fois pour satisfaire des transactions uniques et qu'il soit relativement rare qu'il doive jamais croître pendant les opérations commerciales normales.

Les pires paramètres possibles sont une croissance de 1 Mo ou une croissance de 10%. Assez drôle, ce sont les valeurs par défaut pour SQL Server (dont je me suis plaint et demandé des modifications en vain ) - 1 Mo pour les fichiers de données et 10% pour les fichiers journaux. Le premier est beaucoup trop petit de nos jours et le second conduit à des événements de plus en plus longs à chaque fois (par exemple, votre fichier journal est de 500 Mo, la première croissance est de 50 Mo, la prochaine croissance est de 55 Mo, la prochaine croissance est de 60,5 Mo , etc. etc. - et sur les E/S lentes, croyez-moi, vous remarquerez vraiment cette courbe).

Lectures complémentaires

S'il vous plaît ne vous arrêtez pas ici; Bien que la plupart des conseils que vous voyez sur la réduction des fichiers journaux soient intrinsèquement mauvais et même potentiellement désastreux, certaines personnes se soucient davantage de l'intégrité des données que de la libération d'espace disque.

• n article de blog que j'ai écrit en 2009, quand j'ai vu quelques articles "voici comment réduire le fichier journal" .

• n article de blog écrit par Brent Ozar il y a quatre ans, pointant vers plusieurs ressources, en réponse à un article de SQL Server Magazine qui devrait pas avoir été publié .

• n article de blog de Paul Randal expliquant pourquoi la maintenance des journaux est importante et pourquoi vous ne devriez pas non plus réduire vos fichiers de données .

• Mike Walsh a une excellente réponse ci-dessus, bien sûr, couvrant également certains de ces aspects, y compris les raisons pour lesquelles vous ne pourrez peut-être pas réduire votre fichier journal immédiatement .

Answer 3

Vous pouvez également voir le contenu de votre fichier journal. Pour ce faire, vous pouvez utiliser le fn_dblog Non documenté, ou un lecteur de journal des transactions, tel que ApexSQL Log .

Il ne montre pas la réorganisation de l'index, mais il montre tous les événements DML et divers DDL: ALTER, CREATE, DROP, déclencheur activer/désactiver, accorder/révoquer les autorisations, objet Renommer.

Avertissement: je travaille pour ApexSQL en tant qu'ingénieur de support

Answer 4

Il s'agit du problème le plus fréquemment rencontré pour presque tous les administrateurs de base de données où les journaux augmentent et remplissent le disque.

• Quelles sont les raisons pour lesquelles le journal des transactions devient si volumineux?

1. Transaction active longue
2. Transactions de journalisation élevées comme la reconstruction d'index, la réorganisation, l'insertion en bloc, les suppressions, etc.
3. Toute réplication de type HA, mise en miroir configurée, qui contient le journal et ne lui permet pas de libérer l'espace du journal

• Pourquoi mon fichier journal est-il si gros?

Vérifiez le log_reuse_wait_desc colonne dans sys.databases table pour savoir ce qui empêche les journaux de tronquer:

select name, log_reuse_wait_desc 
from sys.databases

• Quels sont les moyens d'empêcher ce problème de se produire?

Les sauvegardes de journaux vous aideront à contrôler la croissance des journaux, sauf si quelque chose empêche la réutilisation des journaux.

• Que dois-je faire lorsque je suis sur la bonne voie avec la cause sous-jacente et que je souhaite mettre mon fichier journal des transactions à une taille saine?

Si vous avez identifié la cause réelle du problème, essayez de le corriger en conséquence, comme expliqué dans la page ci-dessous.

https://www.brentozar.com/archive/2016/03/my-favorite-system-column-log_reuse_wait_desc/

La planification de sauvegardes de journaux appropriées est le meilleur moyen de gérer la croissance des journaux, sauf dans une situation inhabituelle.