Discussion :

[Baquardie]

Bonjour,

Hier soir j'ai eu une job (Cube C8) qui a rempli mon fichier database tmpdb, ce qui a résulté que nous n'avions plus du tout d'espace disque.

Nous regardons ce matin pour trouver des solutions pour ne plus que cela survienne.

Entres autres je sais qu'une des best practice est de mettre tmpdb sur un disque à part.

C'est bien beau faire ça, mais notre question est : Si jamais tmpdb grossi et rempli son disque à lui, que se passe-t-il niveau SQL ? Est-ce que le serveur continue de rouler comme il faut pareil ?

Deuxième question, si jamais l'équipe d'infrastructure me dit qu'ils ne veulent pas sont pas capable de me donner un disque à part, je peux mettre une taille maximale sur tmpdb. Mais encore une fois, que se passe-t-il si le fichier atteint la dite taille. Est-ce que le serveur peut ensuite avoir des difficultés à fonctionner ?

Merci beaucoup !

[mikedavem]

C'est bien beau faire ça, mais notre question est : Si jamais tmpdb grossi et rempli son disque à lui, que se passe-t-il niveau SQL ? Est-ce que le serveur continue de rouler comme il faut pareil ?

Le serveur continuera de fonctionner mais toutes les requêtes qui utiliseront tempdb ne pourront plus s'exécuter.

Deuxième question, si jamais l'équipe d'infrastructure me dit qu'ils ne veulent pas sont pas capable de me donner un disque à part, je peux mettre une taille maximale sur tmpdb. Mais encore une fois, que se passe-t-il si le fichier atteint la dite taille. Est-ce que le serveur peut ensuite avoir des difficultés à fonctionner ?

Même réponse. Maintenant tu peux essayer de répartir tes fichiers de bases de données tempdb sur plusieurs disques en cas de besoin mais je pense que la vrai question est connaître la cause d'un tempdb plein ? Est-ce que cela t'arrive souvent ? Est-ce arrivé de manière exceptionnelle ? Quelle taille as-tu alloué à tempdb ? ...

++

[Baquardie]

Bonjour,

Merci pour la réponse.

Non cela n'arrive pas souvent, je dirais aux 6-8 mois environ. Cette fois-ci c'est un cube C8 (Cognos) qui est resté "collé" au serveur pendant 2hrs de temps...

Au début de la journée tmpdb avait 60 gig et à la fin il était rendu à 260gig. En fait il a pris tot l'espace disque qui restait. En bizounnant un peu j'ai réussi à le réduit à 160 gig, mais j'aimerais quand même retourner au 60 gig de départ, taille qui lui permet de bien fonctionner dans notre environnement de production. Je crains ne pas avoir le choix de repartir le service ce week-end.

Cela dit, j'ai décidé de mettre une taille maximale au fichier tmpdb, pour éviter que mon disque de data se retrouve plein.

Je vais par contre moniter la taille de tmpdb pour recevoir un alerte si jamais ça se reproduit....

Qu'en pensez vous.

[StringBuilder]

Euh... Le tempdb c'est pas la base de travail de SQL Server, c'est à dire là où il stocke les informations en cours de lecture dans les requêtes ?

Vous devez avoir des requêtes sacrément monstrueuses pour arriver à une telle consommation.

Je me demande si votre problème ne se situe pas plutôt là. Car déjà 60 Go, je trouve ça monstrueux, mais 260 Go, ça sent quand même le produit cartésien entre plusieurs grosses tables...

A moins que vous ne fassiez qu'une grosse transaction dans une table temporaire lors de l'extraction de votre cube ?

En tout cas, le problème me semble plus venir de l'utilisation de la base que de sa configuration.

http://msdn.microsoft.com/fr-fr/library/ms190768.aspx

Vous trouverez ici quelques informations sur les raisons possible d'une explosion du tempdb (même si l'article s'applique à SQL Server 2000, les grandes lignes sont toujours parfaitement valables)

http://sqlserver2000.databases.aspfa...happening.html

Ca me laisse quand même un avant goût de "tiens, je lance un traitement sur l'ensemble de ma base de données, et je ne fait surtout pas de traitements unitaires"

[mikedavem]

Euh... Le tempdb c'est pas la base de travail de SQL Server, c'est à dire là où il stocke les informations en cours de lecture dans les requêtes ?

Pas exactement ... il ne stocke que les objets temporaires et éventuellement les wortables , workfiles servant aux opérations d'agrégation, de tri, de certains jointures etc ...

Mais bon vu le contexte (Cognos etc ...) je pense en effet qu'il doit y avoir des opérations qui rapatrient un certain volume de données avec des opérations de tri, de group by ou des opérations de hashage qui doivent être exécutées dans tempdb :-)

++

[SQLpro]

Euh... Le tempdb c'est pas la base de travail de SQL Server, c'est à dire là où il stocke les informations en cours de lecture dans les requêtes ?

Vous devez avoir des requêtes sacrément monstrueuses pour arriver à une telle consommation.

Le problème c'est justement l'utilisation d'outils comme Cognos qui sont des technologies aujourd’hui éculées et obsolètes.
En effet depuis quelques années déjà, SQL Server dispose d'un moteur OLAP qui permet de faire des cubes pré calculées donc du "vrai" OLAP là ou Cognos fait du pseudo OLAP sur des bases relationnelles c'est à dire du ROLAP !

Bref utiliser du Cognos pour quelques dizaines de Go de base, ça passe encore mais avec plusieurs centaines de Go vous courrez droit dans le mur !

En comparaison, je suis à peu près persuadé que ce traitement ne mettrait pas plus de 2 à 3 minutes sur une base SSAS !!!

Hélas j'ai plusieurs clients encore récalcitrant dans le même cas de figure !

A +