Version imprimable
Bonjour à tous,
Pouvez vous m'aider concernant la base systeme tempdb.mdf
J'ai un serveur MS sql server 2005 dédié pour une application métier.
La base de l'application sur le serveur fait au total : 70Go
Cependant la taille de tempdb.mdf fait 144 Go ca me parait énorme.
Que dois je faire ? Essayer de réduire ce tempdb ? Scruter les requetes qui augmentent tempdb , et si oui, quelle requete ? Ne rien faire..
Il vous manque peut etre des infos?
Merci de vos conseils
Bonjour
oui il faudrait réussir à capturer les requêtes qui causent cet agrandissement (souvent la conséquence d' ORDER BY, GROUP BY ou de la création de tables temporaires). Une fois les requêtes identifiées et corrigées, vous pourrez réduire la taille de la base tempdb.
Sur ce blog, un article qui vous permettra d'identifier ces requêtes : http://blog.capdata.fr/index.php/sql...s-dans-tempdb/
Bonjour et merci pour la réponse.
j'ai suivi l'article et j'ai des résultats dans la table tempdb.guest.monitorTempdb
Ca tourne depuis 24H00 maintenant (job toutes les mn)
Cependant, je ne sais pas comment interpreter ce résultat?
J'ai fait une extraction en format xls. Voir PJ.
Hello Johns,
La trace indique que ta tempdb fait 186Gb (144 ?), et que 11,5Gb sont pris par des tables tempo globales :
- ##Hagresso_AGRTPS29541
- ##Hagresso_AGRTPS29547
- ##Hagresso_AGRTPS29571
Il faudrait voir comment ces tables sont construites, et y-a-t-il une raison particulière de les créer en global temporary, plutôt qu'en tables temporaires de session (qui sont automatiquement nettoyées).
David B.
merci de la réponse :)
Sur le disque, le fichier tempdb.mdf fait 181 Go
Sur le disque, le fichier templog.ldf fait 2.26 Go
La taille initiale du fichier tempdb.mdf (nom logique tempdev) dans les prorietés : 186 000 Mo (Croissance illimitée par 100 Mo)
La taille initiale du fichier temlog.ldf (nom logique templog) dans les prorietés : 1 Mo (Croissance illimitée par 10 pour cent)
Attention, c'est un logiciel "métier" d'un éditeur, je ne sais pas si je vais avoir la réponse de la raison particulière de les créer en global temporary...
Veux tu une extractions de la structure des tables ? Sachant qu'il y en a énormément.
A priori je dirais que tu n'as pas besoin d'avoir une tempdb de cette taille là. Le minimum requis pour tempdb est d'avoir une taille suffisante pour stocker le database snapshot interne au dbcc checkdb:
'Estimated Space needed for CHECKTABLES' donnera la valeur minimale. Ensuite, si elle est inférieure à la taille totale renvoyée dans la trace (11,5Gb actuellement), il faudra prendre au moins 15Gb comme taille de départ, avec une croissance autorisée par pas de 1Gb par exemple, jusqu'à une limite inférieure à celle du disque sur lequel se trouve tempdb.mdfCode:
2
Il faudrait t'assurer aussi que ton compte de service (le compte windows qui exécute le service MSSQLSERVER) possède le privilège 'Perform Volume Maintenance Tasks ' ou 'Effectuer des tâches de maintenance de volume', pour ne pas bloquer lorsque le fichier de tempdb va potentiellement grossir. (http://msdn.microsoft.com/en-us/library/ms175935.aspx).
Pour les tables globales temporaires, c'est une question à poser à l'éditeur.
Note: Repasser tempdb à 15Gb signifie redémarrer l'instance.
David B.
Il n'y a qu'une base sur ce serveur dédié. Et c'est justement cette base qui a fait grossir le tempdb.
J'ai peur que si je fixe la taille à 15Go, elle grossise jusqu'a la taille actuelle.
La commande vient de me retourner :
Si KB veut dire Kilobyte, 1381522 KB vaut 165 Mo (C'est étrange, non ?)Citation:
3572 pour Estimated TEMPDB space needed for CHECKALLOC (KB)
1381522 pour Estimated TEMPDB space needed for CHECKTABLES (KB)
Pour information, le serveur a été rédémarré ce lundi matin.
Le "compte" qui execute le service SQL Server (MSSQLSERVER) c'est : Système local
Je vais en profiter pour poser la question à l'éditeur
je pense que c'est ce qu'il y a de mieux à faire, en lui donnant la liste des requêtes qui posent problème.Citation:
Je vais en profiter pour poser la question à l'éditeur
1) 1,3Gb minimum pour faire passer un dbcc checkdb().
Actuellement tempdb fait 186Gb mais l'espace réellement utilisé est sûrement moins important. Tu peux le voir en faisant un:
Elle peut regrossir si tu lui en laisses la possibilité, et si tu fixes une valeur limite tu empêches de remplir un drive sous windows.Code:
2
3
4
2) Il faut laisser le job avec la capture tourner pendant un moment pour voir ce qui fait grandir cette base. Si les tables temporaires globales ne sont pas vidées, il doit rester une connexion qui y fait référence. Pose la question à ton éditeur.
3) SYSTEM LOCAL doit avoir le privilège en question, donc ça va.
David B.
Pouvez vous me confirmer que ce sont les requetes qui sont dans la trace qui posent problèmes ?
Les tables ## occupent un espace dans tempdb qui s'élève à 11,5Gb.
David B.
Il se peut que le
soit également une cause de prise de place dans tempdb.Code:GROUP BY m.voucher_ref , m.sequence_ref , m.client
Voici la réponse de l'éditeur :
rien d’anormal dans tout ça, sous Sqlserver le datafile temporaire n’est ‘purgé’ uniquement après l’avoir sauvegardé, si vous ne sauvegardez jamais ce datafile et bien sa taille augmentera. Il faut donc régulièrement sauvegarder ce datafile pour qu’il retrouve une taille raisonnable, cette tache fait partie de l’administration des bases de données.
Les requêtes que vous avez identifiées sont obligatoires pour le bon fonctionnement du logiciel Agresso et ne peuvent être modifiées.
(Bien sur, je sauvegarde le journal tous les jours)
... :cry:
J'imagine que tu lui a précisé qu'il s'agissait de tempdb. Donc pas besoin de sauvegarde, de plus sa préconisation :
...s'applique aux journaux de transactions et seulement dans un cas précis qui ne concerne pas tempdb.Citation:
Envoyé par Johns
Pour que tu puisses avancer et avoir une idée précise de l'utilisation de tempdb, il faut mesurer l'espace utilisé dans tempdb sur un historique d'au minimum un mois, si vous avez des traitements trimestriels ou semestriels particuliers, il faudrait mesurer cette utilisation sur une période plus longue encore. Tu peux utiliser dbcc showfilestats pour archiver la valeur de UsedExtents dans une table de monitoring par exemple. (cf l'article pointé par Emmanuel).
Si la valeur de usedextents rapporté en Mb (1 extent = 64Kb) ne dépasse pas les 20 Gb sur un ou deux mois par exemple, tu peux baisser la taille de ton enveloppe pour tempdb et redémarrer.
David B.