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

Dans SQL Server -

• Quelles sont certaines des raisons pour lesquelles le journal des transactions devient si volumineux?
• Pourquoi mon fichier journal est-il si gros?
• Quels sont les moyens d'éviter ce problème?
• Que dois-je faire lorsque je suis sur la bonne voie avec la cause sous-jacente et que je veux que le fichier de journal des transactions soit de bonne taille?

Une réponse plus courte:

Vous avez sans doute avez soit une opération longue en cours d' exécution en cours d' exécution (maintenance Index? Batch Big supprimer ou mettre à jour?) Ou si vous êtes dans le « default » ( voir plus bas sur ce qu'on entend par défaut) le mode de récupération Fullet n'ont pas pris une sauvegarde du journal (ou ne les prenez pas assez souvent).

S'il s'agit d'un problème de modèle de récupération, la réponse simple pourrait être Basculer en Simplemode de récupération si vous n'avez pas besoin de récupération à un moment donné ni de sauvegardes régulières du journal. Cependant, beaucoup de gens y répondent sans comprendre les modèles de récupération. Lisez la suite pour comprendre pourquoi c'est important et ensuite décider de ce que vous faites. Vous pouvez aussi commencer à prendre des sauvegardes de journaux et de rester dans la Fullrécupération.

Il pourrait y avoir d'autres raisons, mais ce sont les plus courantes. Cette réponse commence à explorer les deux raisons les plus courantes et vous donne quelques informations de base sur le pourquoi et le comment de ces raisons et explore d'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 en général, ces raisons sont les suivantes: Il existe un malentendu sur les modèles de récupération ou des transactions de longue durée. Lisez la suite pour plus de détails.

Principale raison 1/2: ne pas comprendre les modèles de récupération

( Être en mode de récupération complète et ne pas effectuer de sauvegarde des journaux - C’est la raison la plus courante; la grande majorité de ceux qui rencontrent ce problème le sont. )

Bien que cette réponse ne soit pas une analyse approfondie des modèles de récupération SQL Server, la question des modèles de récupération est essentielle à ce problème.

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

• Full,
• Bulk-Logged et
• Simple.

Nous allons ignorer Bulk-Loggedpour le moment, nous dirons en quelque sorte qu'il s'agit d'un modèle hybride et que la plupart des personnes qui l'utilisent y sont pour une raison et comprennent les modèles de récupération.

Les deux qui nous intéressent et leur confusion sont la cause de la majorité des cas de personnes atteintes de ce problème sont Simpleet 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 aller encore plus loin dans ce sujet, il suffit de lire le blog de Paul Randal et autant de publications que vous le souhaitez. Pour cette question, cependant:

1. Récupération sur incident / redémarrage L'
   un des objectifs du fichier journal de transaction est la récupération sur incident / redémarrage . Pour avancer et reculer le travail effectué (avance / rétablissement) avant un crash ou un redémarrage, le travail démarré mais non terminé après un crash ou un redémarrage (annulation / annulation). Le journal des transactions a pour tâche de voir qu'une transaction a démarré mais ne s'est jamais terminée (l'annulation ou le blocage / le redémarrage s'est produit avant la transaction validée). Dans cette situation, le journal a pour tâche de dire "Hé .. ceci n'est jamais vraiment terminé, annulons-le" pendant la récupération. C'est également 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 cela n'avait pas encore été durci dans votre fichier de données) et que vous dites"Hé ... c'est vraiment arrivé, avançons, faisons comme si les applications le pensaient" après un redémarrage. Maintenant, il y a plus, mais c'est l'objectif principal.

2. Récupération ponctuelle
   L'autre objectif d'un fichier journal de transactions est de pouvoir nous permettre de récupérer à un moment donné en raison d'un "oups" dans une base de données ou de garantir un point de récupération en cas de défaillance matérielle. impliquant les fichiers de données et / ou les journaux d'une base de données. Si ce journal de transactions contient les enregistrements des transactions qui ont été démarrées et terminées pour la récupération, SQL Server peut ensuite utiliser ces informations pour obtenir une base de données à l'endroit 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 effectuer des sauvegardes de journaux .

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 Recoverymodèle en premier. Dans ce modèle, vous dites SQL Server: « Je suis bien avec vous en utilisant votre fichier journal des transactions pour accident et la récupération de redémarrage ... » (Vous avez vraiment pas le choix il rechercher. Propriétés ACID et qui devrait donner un sens rapidement.) "... mais une fois que vous n'en avez plus besoin pour cet objectif de récupération après reprise sur incident / redémarrage, continuez 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 incident / redémarrage. Une fois que SQL Server est sûr de pouvoir récupérer parce que les données sont consolidées (plus ou moins) dans le fichier de données, les données qui ont été renforcées ne sont plus nécessaires dans le journal et sont marquées pour être tronquées, ce qui signifie qu'elles sont réutilisées.

• Modèle de récupération complète
  Avec Full Recovery, vous indiquez à SQL Server que vous souhaitez pouvoir effectuer une récupération à un moment donné, à condition que votre fichier journal soit disponible ou à un moment précis couvert par une sauvegarde du journal. Dans ce cas, lorsque SQL Server atteindra le point où il serait prudent de tronquer le fichier journal dans le modèle de récupération simple, il ne le fera pas. Au lieu de cela, il laisse le fichier journal continuer de croître et continuera de croître jusqu'à ce que vous sauvegardiez le 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 des transactions longues en profondeur ci-dessous.

Voici toutefois un inconvénient à garder à l’esprit pour le mode de récupération complète: si vous passez simplement en Full Recoverymode, mais ne prenez jamais une sauvegarde complète initiale, SQL Server n’acceptera pas votre demande d’être dans le Full Recoverymodèle. Votre journal des transactions continuera de fonctionner comme il est entré Simplejusqu'à 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 les sauvegardes du journal est incorrect.

C’est donc la raison la plus courante de la croissance incontrôlée des grumes? Réponse: être en mode de récupération complète sans aucune sauvegarde de journal.

Cela arrive tout le temps aux gens.

Pourquoi est-ce une erreur si commune?

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

Le modèle de récupération initial du modèle est toujours Full Recovery Model- jusqu'à et sauf si quelqu'un le modifie. Vous pouvez donc dire que le "modèle de récupération par défaut" est Full. Beaucoup de gens ne le savent pas et leurs bases de données s'exécutent Full Recovery Modelsans aucune sauvegarde de journal, et par conséquent un fichier journal de transaction 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 avoir des problèmes ici en ne prenant pas assez souvent les sauvegardes des journaux.
Effectuer une sauvegarde de journal par jour peut sembler bien, cela signifie qu'une restauration nécessite moins de commandes de restauration, mais en gardant à l'esprit la discussion ci-dessus, ce fichier journal continuera de croître jusqu'à ce que vous en effectuiez des sauvegardes.

Comment savoir quelle est la fréquence de sauvegarde du journal dont j'ai besoin?

Vous devez tenir compte de la fréquence de sauvegarde de votre journal en tenant compte de deux éléments:

1. Besoins de rétablissement - Cela devrait, espérons-le, être le premier. Dans l'éventualité où le lecteur hébergeant votre journal des transactions deviendrait défectueux ou si vous subissiez une corruption grave affectant votre sauvegarde du journal, combien de données pourraient être perdues? Si ce nombre ne dépasse pas 10-15 minutes, vous devez sauvegarder le journal toutes les 10-15 minutes, fin de la discussion.
2. Croissance du journal - Si votre organisation est en mesure de perdre plus de données en raison de sa capacité à recréer facilement ce jour-là, une sauvegarde du journal beaucoup moins fréquente peut-être bien moins de 15 minutes. Peut-être que votre organisation va bien toutes les 4 heures. Mais vous devez regarder le nombre de transactions que vous générez en 4 heures. Autoriser le journal à continuer de croître au cours de ces quatre heures rendra-t-il un fichier journal trop volumineux? Cela signifie-t-il que vos sauvegardes de journal prennent trop de temps?

Principale raison 2/2: Transactions à long terme

( "Mon modèle de récupération est bien! Le journal est toujours en croissance! )

Cela peut également être une cause de croissance de grumes incontrôlée et non restreinte. Quel que soit le modèle de récupération, il apparaît souvent sous la forme «Mais je suis dans un modèle de récupération simple - pourquoi mon journal continue-t-il de croître?!

La raison en est simple: si SQL utilise ce journal de transactions à des fins de récupération, comme indiqué ci-dessus, il doit 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 en cours ou qui ont commencé depuis le début de cette transaction.

Cela signifie qu'une suppression volumineuse, qui supprime des millions de lignes dans une instruction de suppression, constitue une transaction et que le journal ne peut effectuer aucune troncation avant la suppression complète. Dans Full Recovery Model, cette suppression est enregistrée et il pourrait y avoir beaucoup d'enregistrements de journal. Même chose avec l'optimisation d'index pendant les fenêtres de maintenance. Cela signifie également que la mauvaise gestion des transactions et le fait de ne pas surveiller et fermer les transactions en cours peuvent vraiment vous nuire ainsi qu'à votre fichier journal.

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

Vous pouvez vous sauver ici par:

• Dimensionnement correct de votre fichier journal pour tenir compte du pire des scénarios, comme votre maintenance ou les opérations volumineuses connues. Et lorsque vous développez votre fichier journal, vous devez vous reporter à ces conseils (et aux deux liens auxquels elle vous envoie) de Kimberly Tripp. Dimensionnement correct est super critique ici.
• Regarder votre utilisation des transactions. Ne démarrez pas de transaction sur votre serveur d'applications, commencez à avoir de longues conversations avec SQL Server et risquez de les laisser ouvertes trop longtemps.
• Regarder les transactions implicites dans vos instructions DML. Par exemple: UPDATE TableName Set Col1 = 'New Value'est une transaction. Je n’en ai pas mis un BEGIN TRANet je n’y suis pas obligé, c’est toujours une transaction qui s’engage automatiquement lorsque cela est fait. Par conséquent, si vous effectuez des opérations sur un grand nombre de lignes, envisagez de regrouper ces opérations en plusieurs morceaux plus gérables et de donner au temps de journalisation le temps de récupérer. Ou considérez la bonne taille pour faire face à cela. Ou alors, envisagez 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, de sorte que mes sauvegardes de journaux sont automatisées ... Pourquoi la croissance du journal des transactions continue-t-elle à se produire?"

Réponse: lisez la suite.

Qu'est-ce que l'envoi de journaux?

L’envoi de journaux correspond à ce que cela ressemble: vous envoyez vos sauvegardes du journal des transactions à un autre serveur à des fins de récupération d’identité. Il y a quelques initialisations mais après cela le processus est assez simple:

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

Il y a aussi des tâches à surveiller et à alerter si les choses ne se passent pas comme prévu.

Dans certains cas, vous souhaiterez peut-être uniquement effectuer la restauration de l'envoi de journaux une fois par jour, tous les trois jours ou une fois par semaine. C'est bon. Mais si vous apportez cette modification à tous les travaux (y compris les travaux de sauvegarde et de copie de journal), cela signifie que vous attendez tout ce temps pour effectuer une sauvegarde du journal. 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 que cela signifie probablement aussi un fichier journal volumineux à copier. Vous ne devez modifier que la planification du travail de restauration et laisser les sauvegardes et les copies du journal 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-là, mais ce sont les plus courantes. Indépendamment de la cause: il existe un moyen d’analyser la raison de cette croissance inexacte du log / manque de troncature et de voir ce qu’elles sont.

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

Il existe une colonne appelée log_reuse_waitavec un ID de recherche du code de motif et une log_reuse_wait_desccolonne avec une description du motif de l'attente. Parmi les ouvrages en ligne mentionnés, citons la majorité des raisons (celles que vous êtes susceptible de voir et celles que nous pouvons expliquer. Les manquants sont soit inutilisables, soit destinés à un usage interne), avec quelques notes sur les délais d'attente. italiques :

• 0 = Rien
  Ce que cela ressemble .. Ne devrait pas attendre

• 1 = Point de contrôle
  En attente d'un point de contrôle. Cela devrait se produire 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 ait lieu. Soit vous les avez planifiées 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 Une transaction active doit être terminée (dans un sens ROLLBACKou dans l'autre COMMIT) pour 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
  Un miroir passe derrière ou sous une certaine latence dans une situation de mise en miroir haute performance ou la mise en miroir est suspendue pour une raison quelconque

• 6 = Réplication
  Il peut y avoir des problèmes de réplication qui pourraient en être la cause, comme par exemple un agent de lecture de journal qui ne s'exécute pas, une base de données pensant qu'elle est marquée pour une réplication qui ne l'est plus et pour diverses autres raisons. Vous pouvez également voir cette raison et c'est parfaitement normal, car vous regardez au bon moment, juste au moment où les transactions sont consommées par le lecteur de journaux.

• 7 = Création d'instantané de base de données
  Vous créez un instantané de base de données. Vous verrez ceci si vous regardez au bon moment lorsqu'un instantané est créé.

• 8 = Analyse du journal
  Je n'ai pas encore rencontré de problème. Si vous regardez assez longtemps et assez souvent, cela se produit, mais cela ne devrait pas être une cause de la croissance excessive du journal des transactions, ce que j'ai vu.

• 9 = Un réplica secondaire des groupes de disponibilité AlwaysOn 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 ..

Puisque je ne suis vraiment pas satisfait des réponses concernant Stack Overflow , y compris la suggestion la plus fortement votée, et parce que je voudrais aborder quelques points que la réponse de Mike ne dit pas, je pensais pouvoir vous fournir mon entrée ici aussi. J'ai placé une copie de cette réponse là aussi.

Réduire la taille d'un fichier journal doit en réalité être réservé aux scénarios dans lesquels il a connu une croissance inattendue, ce qui ne devrait pas se reproduire. Si le fichier journal croîtra à la même taille, le travail ne sera pas beaucoup réduit en le réduisant temporairement. Désormais, en fonction des objectifs de récupération de votre base de données, vous devez prendre les mesures suivantes.

Tout d'abord, faire une sauvegarde complète

N'apportez jamais de modifications à votre base de données sans vous assurer que vous pouvez la restaurer en cas de problème.

Si vous vous souciez de la récupération à un moment donné

(Et par récupération ponctuelle, je veux dire que vous tenez à pouvoir restaurer n'importe quoi autre qu'une sauvegarde complète ou différentielle.)

Vraisemblablement, votre base de données est en FULLmode de récupération. Si non, alors assurez-vous qu'il est:

ALTER DATABASE yourdb SET RECOVERY FULL;

Même si vous effectuez des sauvegardes complètes régulières, le fichier journal grandira jusqu'à ce que vous effectuiez une sauvegarde du journal - ceci est votre protection, pas pour nuire inutilement à votre espace disque. Vous devez effectuer ces sauvegardes de journal assez souvent, en fonction de vos objectifs de récupération. Par exemple, si une règle de gestion indique que vous pouvez vous permettre de perdre pas moins de 15 minutes de données en cas de sinistre, vous devez disposer d'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 affreuses).

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 être sur un autre ordinateur qui représente un périphérique de stockage sous-jacent différent. Les sauvegarder sur le même ordinateur (ou sur un autre ordinateur utilisant les mêmes disques sous-jacents, ou un ordinateur virtuel différent hébergeant le même hôte physique) ne vous aide pas vraiment, car si l'ordinateur explose, vous perdez votre base de données. et ses sauvegardes. En fonction de votre infrastructure réseau, il peut être plus judicieux de sauvegarder localement, puis de les transférer à un emplacement différent dans les coulisses; dans les deux cas, vous souhaitez les extraire de la base de données principale le plus rapidement possible.

Maintenant, une fois que les sauvegardes de journal sont en cours d’exécution, il devrait être raisonnable de réduire le fichier de journal à quelque chose de plus raisonnable que ce qui a été explosé jusqu’à présent. Cela ne signifie pas que SHRINKFILEvous devez répéter l'opération jusqu'à ce que le fichier journal atteigne 1 Mo. Même si vous sauvegardez fréquemment le journal, il doit tout de même contenir la somme de toutes les transactions simultanées pouvant avoir lieu. Les événements d'autogrow 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 de fichier est activée), et les transactions utilisateur doivent attendre pendant que cela se produise. Vous voulez faire cette routine de croissance-rétraction-croissance-réduction le moins possible, et vous ne voulez certainement pas que vos utilisateurs paient pour cela.

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

Il vous faut donc une taille pratique pour votre fichier journal. Personne ici ne peut vous dire ce qu’il en est sans en savoir plus sur votre système, mais si vous réduisez fréquemment le fichier journal et que celui-ci grossit à nouveau, un bon filigrane est probablement 10 à 50% plus élevé que le plus volumineux qu’il ait été. . Supposons que cela représente 200 Mo et que vous souhaitiez que tous les événements de croissance automatique ultérieurs soient de 50 Mo. Vous pouvez ensuite ajuster la taille du fichier journal de la manière suivante:

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 d'abord l'exécuter:

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

Si vous ne vous souciez pas de la récupération à un moment donné

S'il s'agit d'une base de données de test et que vous ne vous préoccupez pas de la récupération à un moment donné, vous devez vous assurer que votre base de données est en SIMPLEmode de récupération.

ALTER DATABASE yourdb SET RECOVERY SIMPLE;

Le fait de mettre la base de données en SIMPLEmode de récupération garantit que SQL Server réutilise des parties du fichier journal (essentiellement en éliminant progressivement les transactions inactives) au lieu de s’agrandir pour conserver un enregistrement de toutes les transactions (comme le fait la FULLrécupération jusqu’à ce que vous sauvegardiez le journal). CHECKPOINTles événements vous aideront à contrôler le journal et à vous assurer qu'il n'a pas besoin de croître sauf si vous générez beaucoup d'activité t-log entre CHECKPOINTs.

Ensuite, vous devez vous assurer de manière absolue que cette croissance du journal est réellement due à un événement anormal (par exemple, un nettoyage annuel du printemps 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 doit simplement le faire croître à nouveau pour s'adapter à votre activité normale, qu'avez-vous gagné? Avez-vous pu utiliser cet espace disque libéré temporairement? Si vous avez besoin d'une solution immédiate, vous pouvez exécuter les opérations suivantes:

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. Conformément à l'exemple du cas de récupération à un point dans le temps, 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 TRUNCATE_ONLYoption, puisSHRINKFILE . D'une part, cette TRUNCATE_ONLYoption est obsolète et n'est plus disponible dans les versions actuelles de SQL Server. Deuxièmement, si vous êtes dans FULLun modèle de récupération, 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 reconnectez-vous . Je ne peux pas souligner à quel point cela peut être dangereux. Votre base de données peut ne pas remonter, être 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 SHRINKDATABASEet l'option du plan de maintenance consistant à faire de même est une mauvaise idée, surtout si vous ne devez réellement résoudre qu'un problème de journal. Ciblez le fichier que vous souhaitez ajuster et réglez-le indépendamment, en utilisant DBCC SHRINKFILEou ALTER DATABASE ... MODIFY FILE(exemples ci-dessus).

• Réduction de la taille du fichier journal 1 Mo . Cela semble tentant car, hé, SQL Server me permet de le faire dans certains scénarios et de regarder tout l’espace qu’il libère! À moins que votre base de données ne soit en lecture seule (vous devez la marquer comme telle ALTER DATABASE), cela entraînera inévitablement de nombreux événements de croissance inutiles, car le journal doit prendre en compte les transactions en cours, quel que soit le modèle de récupération. Quel est l'intérêt de libérer temporairement cet espace, pour que SQL Server puisse le récupérer lentement et péniblement?

• 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 directement le fichier journal problématique au lieu d’ajouter un autre problème potentiel. Hormis la redirection de certaines activités du journal des transactions vers un autre lecteur, un deuxième fichier journal ne vous aide vraiment pas (contrairement à un deuxième fichier de données), puisqu'un seul des fichiers peut être utilisé à la fois. Paul Randal explique également pourquoi plusieurs fichiers journaux peuvent vous piquer plus tard .

Etre pro-actif

Plutôt que de réduire votre fichier journal à une petite quantité et de le laisser continuer à s’auto-administrer automatiquement à un faible taux, réglez-le sur une taille relativement grande (taille qui tiendra compte de la somme de votre plus grand nombre de transactions simultanées) et définissez une quantité automatique raisonnable. il s'agit d'une solution de remplacement, de sorte qu'elle n'ait pas besoin de croître plusieurs fois pour satisfaire des transactions isolées et qu'il soit relativement rare qu'elle ait à croître au cours d'opérations commerciales normales.

Les pires paramètres possibles sont une croissance de 1 Mo ou 10%. Curieusement, ce sont les valeurs par défaut pour SQL Server (pour lesquelles je me suis plaint et qui ont demandé des modifications inutiles ): 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 dernier entraîne chaque fois des événements de plus en plus longs (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 là; Bien que la plupart des conseils que vous voyez sur la réduction des fichiers journaux soient intrinsèquement mauvais, voire potentiellement désastreux, certaines personnes se soucient davantage de l'intégrité des données que de la libération d'espace disque.

• Un billet de blog je l' ai écrit en 2009, quand j'ai vu quelques « voici comment réduire le fichier journal » messages surgissent .

• Un article de blog écrit par Brent Ozar il y a quatre ans, faisant référence à de multiples ressources, en réponse à un article de SQL Server Magazine qui n'aurait pas dû être publié .

• Un article de Paul Randal sur un blog expliquant pourquoi la maintenance de t-log est importante et pourquoi vous ne devriez pas réduire vos fichiers de données non plus .

• Mike Walsh a bien sûr une excellente réponse à proposer ci-dessus, 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 .

Vous pouvez également voir le contenu de votre fichier journal. Pour ce faire, vous pouvez utiliser fn_dblogun lecteur de journaux de transactions non documenté, tel que ApexSQL Log .

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

Disclaimer: Je travaille pour ApexSQL en tant qu'ingénieur support

Il s'agit du problème le plus fréquemment rencontré par la quasi-totalité des administrateurs de base de données où les journaux croissent et remplissent le disque.

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

1. Longue transaction active
2. Les transactions de journalisation élevée telles que la reconstruction d'index, la réorganisation, l'insertion en bloc, les suppressions, etc.
3. Tout type de réplication à haute disponibilité, mise en miroir configurée qui conserve le journal et ne lui permet pas de libérer l'espace du journal

• Pourquoi mon fichier journal est-il si gros?

Recherchez la log_reuse_wait_descolonne c dans le sys.databasestableau pour savoir ce qui retient les journaux de tronquer:

select name, log_reuse_wait_desc 
from sys.databases

• Quels sont les moyens d'éviter ce problème?

Les sauvegardes de journaux vous aideront à contrôler la croissance des journaux sauf si quelque chose empêche les journaux d'être réutilisés.

• Que dois-je faire lorsque je suis sur la bonne voie avec la cause sous-jacente et que je veux que le fichier de journal des transactions soit de bonne taille?

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/

Disposer de sauvegardes de journaux appropriées est le meilleur moyen de gérer la croissance des journaux, sauf dans des situations inhabituelles.