Tempdb et son impact sur une BDD

bonjour,
pourrais-je avoir des éclairssicement sur Tempdb et son influence sur l'optimisation d'une BDD sql server 2008 ?

La base de données Tempdb est utilisée par SQL Server pour stocker, de façon temporaire, les données en cours de traitement.
Par exemple, sur de grosses requêtes, les jeux de données intermédiaires, car ne tenant pas en mémoire.

C'est par conséquent une base de données qui est extrêmement sollicitée, et dont les bonnes performances sont vitales pour l'état général du serveur.

Je ne suis pas DBA, et il y a certainement bien d'autres choses à dire, mais voici ce que j'ai pu lire ça et là :

1/ La base tempdb est détruite et recréée à chaque redémarrage de SQL Server. Sa taille par défaut est de 5 Mo, avec une croissance de 10%. Je vous laisse imaginer les nombre de resize des fichiers qui sont nécessaires pour stocker un résultat intermédiaire de 500 Mo.
=> Par conséquent, la première chose à faire, c'est de modifier la taille initiale de ses fichiers de données, pour allouer la taille maximale dès le départ (si après 48h d'utilisation elle fait 500 Mo, alors mettez cette valeur en taille initiale).

2/ La base tempdb stocke des données volatiles pendant les traitements. Par conséquent, il y a des lectures/écritures intensives dedans durant les traitements importants, qui sollicitent aussi fortement les fichiers de données des autres bases (lectures, mises à jour), mais aussi les journaux des transactions
=> Si possible tempdb doit être stockée sur un disque qui ne contient ni fichier de base de données, ni journal des transactions

3/ La base tempdb est à SQL Server un peu ce que la mémoire virtuelle est à windows.
=> Ces deux fichiers ne doivent absolument pas être sur le même disque dur physique, puisqu'en cas d'utilisation intensive de l'un, l'utilisation du second sera fortement dégradée, ce qui se traduira par des performances catastrophiques.

4/ La base tempdb contient, entre autres, les jeu de données des sous-select, les tables temporaires, les curseurs, etc.
=> Veillez le plus possible à éviter d'utiliser ces objets, pour ne faire que des requêtes ensemblistes pure, si possible avec des jointures simples : cela permet de travailler avec moins de données en mémoire (pointeurs sur les index plutôt que des jeux de données) et donc alléger la charge de tempdb

Voilà, je laisse la parole aux experts, qui auront certaienement d'autres choses plus précises à dire à ce propos.

Moi j'aurais plutôt tourner la question dans l'autre sens : Impact d'une BDD sur la base de données tempdb ? .. c'est en général plus dans ce sens là sans entrer dans le détail

A+

Merci StringBuilder pour ces informations qui sont bien précises

Depuis SQL Server 2005, la base tempdb joue un rôle important. Ce rôle ne cesse d’être promu au fil des nouvelles versions de SQL Server.
Donc, en complément de ce qui a été dit par StringBuilder, et pour aller aussi dans le sens de la question telle qu’elle est formulée, à juste titre, par mikedavem, j’ajouterai ceci :
La base tempdb est très sollicitée dans les situations, liste non exhaustive, suivantes :
- Les opérations DBCC (Exemple DBCC CHECKDB),
- La reconstruction d’index effectuée avec l’option SORT_IN_TEMPDB et/ou ONLINE,
- Utilisation du niveau d'isolation basé sur le versioning de ligne (READ_COMMITTED_SNAPSHOT ou ALLOW_SNAPSHOT_ISOLATION),
- Mise en œuvre de la CTE. En effet, une expression de table commune peut être considérée comme un ensemble de résultats provisoire défini dans l'étendue d'exécution d'une seule instruction SELECT, INSERT, UPDATE, DELETE ou CREATE VIEW. Lorsque le plan de requête d'une requête d'expression de table commune utilise un opérateur Spool pour enregistrer des résultats de requêtes intermédiaires, le moteur de base de données crée une table de travail dans tempdb pour prendre en charge cette opération.

A+

Et dans les faits même bien plus que ça. Chaque nouvelle fonctionnalité quasiment y va de sa petite worktable, donc la partie internal allocation ne cesse de grossir au gré des versions.

Pour info le webcast guss de l'année dernière sur tempdb:

http://www.youtube.com/watch?v=iTgn_...-Vchl23I6XZqNg

Une des "Best practices" concernant TempDb est comme l'a dit "StringBuilder", que les fichiers de TempDb soient stockées sur un/des disques séparés des autres BDD, et qu'elles soient "éclatéesé sur plusieurs fichiers (en fonction du nombre de CPU).
Il faut également penser a activer le Traceflag -1118
http://support.microsoft.com/kb/2154845/fr
et http://support.microsoft.com/kb/328551/fr