Discussion :

[SQL_EVAN]

Bonjour tous,

Je suis assez débutant dans le monde de BDDs. J'ai récemment adopté un système de BDDs et je un problème avec la taille de la base tempDB:

Plus précisement nous avons une baie de disques sytème blade et dedans on a plusieurs partitions. Les données des bases de prod sont sur un autre disque avec assez d'éspace. Par contre le disque qui heberge nos bases systèmes fait que 90Go.

Notre système (un site web) est très transactionnel et donc le tempDB fait 46Go sur le disque. Récemment on a lancé une tâche planifiée de mauvaise architecture et le tempDB a gonflé jusqu'au point que le disque était absolument plein. J'ai du donc redémarrer l'instance pour restaurer le service.

Par contre la base tempDB fait toujours 46Go (ou il utilise actuellement 1.5Go)

Les autre devs me demandent de faire un SHRINKDATABASE sur le tempDB mais je suis pas persuadé que cela soit une bonne chose à faire.

Vous avez des suggestions?

[SQLpro]

Vous avez raison de ne pas être persuadé que cela soit une bonne chose à faire. Les développeurs sont généralement nuls en matière d'admin de SGBDR !

Si tempdb a autant cru, c'est qu'elle est beaucoup utilisée, soit pour des objets explicite (création de tables temporaires, de variables tables ou d'UDF table) ou implicite (GROUP BY, ORDER BY, calcul d'agrégat sur des requêtes volumineuses, utilisation de trigger, du niveau d’isolation SNAPSHOT, de curseurs.......).

Donc vous avez deux solutions pour résoudre le problème :
1) faire en sorte que vos développeurs travaillent proprement en faisant du code ensembliste et non itératif (donc interdire les curseur, les tables temporaires, les variables table, les UDF table...) et minimisent l'utilisation des déclencheurs et du niveau d'isolation SNAPSHOT...
2) déplacer les fichiers de le tempdb sur d'autres disques, MS recommandant d'avoir le JT sur un agrégat très rapide (RAID 0+1 ou 10) et plusieurs fichiers de données, d'égale grandeur sur différents axes physiques.

A lire : http://blog.developpez.com/sqlpro/p8...t-le-stocakge/

A +

[SQL_EVAN]

Merci de votre réponse! Je pensait qu'effectivement la solution se trouve dans le déplacement des fichiers tempDB sur un autre disque ou nous avons pas mal d'espace restant. La question est maintenant : lequel des disques.

Cette manip va forcement demander un redémarrage de l'instance. Combien de temps dois-je envisager pour cela? C'est une instance de prod alors c'est moyen de le faire.

[SQLpro]

Vous pouvez utiliser la commande ALTER DATABASE tempdb MODIFY FILE en production. Cela ne fait que modifier les métadonnées préventivement (pas de déplacement des fichiers).
Puis programmer un redémarrage de l'instance SQL via une tâche planifiée cette nuit par le planif de windows.
N'oubliez pas de la retirer le lendemain !
Et supprimez les anciens fichiers de tempdb devenus obsolètes...

A +

[elsuket]

Et n'oubliez pas de vérifier que le compte de service qui exécute SQL Server a le droit Perform volume maintenance tasks, de sorte que l'allocation des fichiers de TempDB se fasse rapidement

@++