Mon templog.ldf est énorme (45 Go), que faire si je dois faire quelque chose?


8

J'ai une installation SQL 2005 et mon fichier templog.ldf continue de croître pour consommer tout l'espace libre sur le lecteur sur lequel il se trouve. Parfois, cela s'arrêtera avec quelques Mo libres, mais parfois cela ira plus loin, étant le lecteur c, je pense que ce comportement peut être impliqué dans d'autres problèmes que j'ai vus.

Ma question est, que dois-je faire, je peux déplacer le journal vers un autre lecteur, mais j'ai des raisons de supposer qu'il ne fera pas simplement la même chose là-bas. Je suppose que ce comportement est probablement le résultat de quelque chose que je peux changer et que 45 Go est une taille inhabituelle pour le journal tempdb. Nous utilisons beaucoup de tables temporaires et de fonctions de valeur de table dans notre code, il y a donc beaucoup de possibilités d'utiliser tempdb, je peux comprendre la base de données tempdb en croissance mais je ne comprends pas la raison de la croissance du templog.

Jusqu'à présent, j'ai exécuté DBCC OPENTRAN ('tempdb') pour voir si de vieilles transactions traînent, elles ne le sont pas. J'ai lu comment réduire la tempdb et je l'ai fait plusieurs fois, mais je me demande vraiment si je peux faire quoi que ce soit pour empêcher que cela se produise en premier lieu ou plus de détails sur la raison pour laquelle il pourrait se développer autant dans la première place.

== MODIFICATIONS ==

1) Le tempdb utilise un modèle de récupération simple

2) La croissance de templog se produit sur quelques heures le matin lorsque nous avons des requêtes planifiées en cours d'exécution, essentiellement une charge de rapports qui court en dehors des heures de bureau pour la journée à venir. La taille du fichier augmente régulièrement au cours de cette période. Nous contrôlons le nombre de rapports simultanés exécutés en même temps, l'augmentation du nombre de rapports simultanés augmente la vitesse à laquelle le journal augmente.


Vous devriez alors regarder (et publier?) Le SQL de ces rapports.
RBarryYoung

Réponses:


3

Vérifiez vos requêtes de rapports. En avez-vous qui contiennent DISTINCT? Certains d'entre eux ont-ils une jointure cartésienne?

L'une des requêtes de rapport accède-t-elle aux serveurs liés en tant que membres d'une jointure? Si tel est le cas, le journal et la base de données tempdb peuvent augmenter.

Lorsque les rapports sont diffusés le matin, l'un d'eux se bloque-t-il?


Nous examinons plus en détail maintenant, je publierai les résultats lorsque j'aurai quelque chose de concluant. Il semble actuellement qu'un rapport se bloque mais ne libère pas sa connexion. Je pense que d'autres sont en cours mais provoquent une expansion du journal en raison de la transaction incomplète précédente.
Robin

Merci pour la réponse, mon problème est certainement dû à un rapport de plantage maintenant, j'ai limité la taille du templog. J'ai vu la croissance galopante conjointement avec un rapport défaillant ne commettant pas de transaction. Je ne sais pas s'il y a quelque chose de particulièrement mauvais dans le sql du rapport car ils fonctionnaient bien sous SQL Server 2000, mais je vais également enquêter sur ce qu'ils font.
Robin

4

Nous avons eu un problème similaire, après avoir lancé un appel PSS avec Microsoft et une enquête approfondie du problème, nous avons zoné la cause et la résolution possibles suivantes.

Cause:

La cause probable des symptômes est due aux disques / lun sur lesquels sont placées les bases de données utilisateur et qui ont de graves problèmes de réponse d'E / S; cela entraîne la fin du point de contrôle automatique sur les bases de données utilisateur.

Maintenant, le point de contrôle sur tempdb se produit uniquement lorsque le journal tempdb est plein à 70% et qu'il a également une priorité inférieure aux points de contrôle de la base de données utilisateur. Ainsi, efficacement lorsqu'un point de contrôle automatique sur la ou les bases de données utilisateur est émis et tente de se terminer, en raison d'une utilisation intensive de tempdb, le fichier journal tempdb se remplit rapidement; à 70% d'utilisation du journal, le point de contrôle tempdb se produit mais est placé en file d'attente derrière le point de contrôle de la base de données utilisateur.

Dans le temps qu'il faut au point de contrôle de la base de données utilisateur pour terminer, le fichier journal tempdb continue d'être rempli et si la croissance automatique est définie, le fichier journal se développe lorsqu'il nécessite plus d'espace. C'est la raison pour laquelle le fichier journal continue de croître.

En résumé, la cause racine la plus possible des symptômes que vous décrivez est due à une mauvaise réponse des E / S des disques / lun pour votre utilisateur et / ou la base de données / fichiers journaux tempdb.

Solution:

Nous avons contourné le problème pendant que nous réglions le sous-système d'E / S en configurant une alerte qui se déclenchait lorsque le fichier journal tempdb était plein à 75% et, en réponse, exécutait un travail qui forçait un "CHECKPOINT" manuel (qui a priorité sur le système automatique) points de contrôle), effaçant le journal tempdb l'empêchant de croître automatiquement indéfiniment. C'est toujours une bonne idée de laisser le fichier journal sur la croissance automatique pour toute autre éventualité. En outre, je vous recommande fortement d'envisager de réduire la taille du fichier journal tempdb à quelque chose de significatif selon votre environnement après avoir installé le correctif.

J'espère que cela t'aides.


C'était la solution sur une instance SQL 2000 mal configurée dont j'ai hérité où toutes les données et les fichiers journaux se trouvaient sur un seul disque. Nous ne pouvons pas ajouter de stockage, j'ai donc dimensionné le fichier en fonction de l'utilisation et j'ai un travail qui exécute un point de contrôle toutes les 30 minutes.
Your_comment_is_not_funny

1

Quel est le modèle de récupération défini sur la base de données temporaire? S'il n'est pas défini sur Simple, définissez-le sur Simple. Cela devrait l'empêcher de croître. S'il est déjà défini sur Simple, je dirais qu'il y a un problème sous-jacent qui doit être résolu et que toute tentative de réduction du fichier ne fait que traiter les symptômes du problème et non la cause première.


oui, il est réglé sur une récupération simple, je vérifiais simplement que lorsque j'ai écrit le message, j'ai oublié de l'inclure dans ce qui précède.
Robin

Je viens de vérifier nos fichiers templog.ldf et ils mesurent environ 60 Mo. Nous avons un fichier tempdb pour chaque processeur du serveur. Avez-vous essayé de créer des fichiers supplémentaires pour tempdb? La recommandation est d'avoir un fichier pour chaque processeur (y compris les processeurs hyperhtreading). Notre serveur possède deux processeurs dual core avec hyperthreading, nous avons donc 8 fichiers tempdb.
joeqwerty

C'est la recommandation pour SQL Server 2000. la recommandation pour 2005 est considérablement inférieure à cela. Quoi qu'il en soit, cela n'a aucun effet sur l'espace total une fois que vous avez dépassé la taille par défaut.
RBarryYoung

C'est un autre cas de contestation d'informations. Cet article pour SQL 2005 recommande un rapport un à un des fichiers aux cœurs de processeur: msdn.microsoft.com/en-us/library/ms175527(SQL.90).aspx Bien que cet article pour SQL 2008 recommande la même chose: msdn. microsoft.com/en-us/library/ms175527.aspx
joeqwerty

Mon hypothèse était que s'il y avait plusieurs fichiers Templog, ils n'atteindraient pas une taille aussi massive.
joeqwerty

1

J'ai passé les dernières heures à lire et à prendre des notes à ce sujet

http://technet.microsoft.com/en-gb/library/cc966545.aspx

Il y a beaucoup de détails et des suggestions de problèmes de dépannage. Il semble qu'à moins que votre tempdb ne soit en expansion et ne cesse de croître, il prend probablement juste la quantité d'espace dont il a besoin et aurait dû être configuré pour être de cette taille au départ. Il y a une section sur l'estimation de l'espace requis pour votre tempdb ainsi que sur le suivi de ce qui pourrait occuper de l'espace dans tempdb. À la suite de cela, la première chose que je vais faire est de déplacer tempdb vers un lecteur plus grand et de voir ce qui se passe à partir de là.

Il y a une section intitulée «Espace requis pour la journalisation tempdb» qui indique quelles fonctionnalités utilisent le journal, il y a une autre section précédente qui détaille le sur-ensemble de fonctionnalités qui utilisent tempdb.

La section intitulée «Surveillance des E / S» a quelques idées sur les compteurs de performances à surveiller, un rapide coup d'œil sur mon serveur les a mis dans le territoire que vous avez probablement obtenu un io-goulot d'étranglement. Je vais les surveiller pendant un certain temps et voir comment les choses se déroulent. Le fichier journal tempdb était également en fait à moins de 50% d'utilisation, ce qui correspond à l'idée qu'il s'est développé sous charge ce matin et a conservé cet espace depuis.

Je vais de l'avant en partant du principe que la taille à laquelle elle a grandi est la taille dont elle a besoin, surveillez cette taille à l'avenir et assurez-vous qu'il y a de la place pour la croissance sur n'importe quel disque. Comme suggéré par certains ici, je vais examiner ce qui s'exécute lorsque le journal temporaire se développe et voir si quelque chose peut y être modifié. Je garderai également un œil sur ces compteurs de performance io pour voir si quelque chose doit être traité.

Il y avait une autre section intéressante intitulée «Mise à niveau vers SQL Server 2005» qui indique que tempdb est utilisé pour plus de choses en 2005 qu'en 2000 (à la fois de nouvelles fonctionnalités et des fonctionnalités existantes qui n'utilisaient pas auparavant tempdb). J'ai récemment mis à niveau vers 2005, cela pourrait donc être une des raisons pour lesquelles cela est soudainement devenu un problème. Je ne me souviens pas avoir vu cela ailleurs en ce qui concerne la mise à niveau vers 2005, ce qui est un peu pénible.


0

Cela est probablement dû à une requête de jointure croisée hors de contrôle. Le mieux est d'utiliser Profiler pour le trouver, puis de le corriger.

L'autre façon de le trouver consiste à restreindre la taille du fichier journal TempDB, puis à attendre quelle requête échoue. Cependant, je parie qu'il échoue déjà et que personne ne vous le dit.


0

Si vous redémarrez le moteur SQL, le fichier sera défini à la taille initiale. Vous devez mettre une taille maximale sur tous vos fichiers de croissance automatique.


0

Certaines requêtes SQL ou proc stockés font de mauvaises choses - la seule chose que vous pouvez faire est de profiler la tempdb pour attraper l'événement "Database: Log File Auto Grow", et lorsque cela se produit, utilisez le profileur et des requêtes sur des tables comme sysprocesses pour trouver quel est le mauvais processus.

Malheureusement, il s'agit d'un travail de détective à l'ancienne pour retracer le processus des voyous.

Avez-vous essayé de redimensionner le ou les fichiers journaux tempdb avec DBCC SHRINKFILE ()? Si oui, combien de temps faut-il pour passer de [très petite valeur] à 45 Go ou plus?


Veuillez consulter l'édition 2 ci-dessus pour plus de détails sur la vitesse de croissance du fichier. Notez que cela est basé sur un redémarrage après les heures de bureau avant le lendemain et les rapports planifiés mentionnés. Le fait qu'il croît progressivement sur quelques heures suggère que ce n'est pas un processus qui se comporte mal mais une combinaison de toute la charge simultanée. Peut-être que la taille à laquelle il atteint est juste celle dont il a besoin.
Robin
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.