Discussion :

[Bernardos]

Bonjour,
comme j'en discutais dans une autre discussion.
Chez un de mes clients, la trace par défaut se remplit avec object:created et object:deleted tous liés à tempdb
j'ai 4 fichiers de 20 Mo plus le fichier en cours
le dernier fichier date d'il y a 15 minutes!
Ce qui veut dire que les ç!"é'§ç!èç!&é de dévellopeurs et d'analyste font des procédures avec table temporaire, j'imagine
Du coup ma trace par défaut si précieuse est inexploitable et en plus ca fait une activité de dingue sur mon disque.
je vais aller gueler un coup dans le bureau d'à coté mais le phénomène ne va pas se résorber en 5 minutes.
Que faire à part désactiver la trace par défaut?
Peut-on configurer les évènements récoltés?
Merci d'avance
Cordialement,
Loïc

[SQLpro]

Que faire à part désactiver la trace par défaut?

Solution drastique.... supprimer tempdb !!!!

Nan je déconne .....

A +

[Bernardos]

Solution drastique.... supprimer tempdb !!!!

lol. moi j'envisage plutôt de supprimer les mecs qui ont développés ça
donc je conclus qu'il n'y a pas moyen de configurer le trace par défaut pour qu'il ne capte plus ces 2 évenements?

[elsuket]

Ce qui veut dire que les ç!"é'§ç!èç!&é de dévellopeurs et d'analyste font des procédures avec table temporaire, j'imagine

On peut leur en vouloir, mais ça ne résout pas le problème.
On sait que les bases de données sont mal enseignées à l'école, souvent par manque de temps, et pour se "rattraper" on a deux possibilités : formation, rarement justifiable auprès de la hiérarchie, ou l'auto-formation.
On peut aussi décider de former les Développeurs : cela permet souvent de se rendre compte de l'intérêt de ceux-ci pour la bases de données, même s'il peut toujours y avoir des exceptions.
En tout cas ce sont ces défauts qui font manger les DBAs et consultants, donc au final, pourquoi s'en plaindre ?

donc je conclus qu'il n'y a pas moyen de configurer le trace par défaut pour qu'il ne capte plus ces 2 évenements?

Malheureusement non. La seule chose que l'on peut faire, c'est désactiver la trace.
Il me paraît plus important d'analyser la trace pour exposer aux Développeurs les lots de requêtes qui en créent le plus, pour qu'elles soient corrigées.
Capturer l'effet sur l'exécution de la charge avant et après, pour en montrer les bénéfices

@++

[Badplayer1603]

Pour prendre (un peu) la défense des développeurs, ce n'est pas forcement un problème de formation.
J'ai suivi une formation orsys (optimisation sqlserver 2008 à 2014) où le formateur préconisait l'utilisation de table temporaire dans les procs (avec des best practice malgré tout).
Comme je me forme à coté, j'ai pris ses conseils avec reculs mais d'autres personnes ayant reçu cette formation les ont surement pris au 1er degrés et doivent vendre ça à leur collègue comme une méthode conseillé par un DBA!


edit : du coup c'est un problème de formateur

[SQLpro]

Comme je suis à l'origine de c cours chez Orsys... J'aurais bien aimé que vous me disiez quel est le formateur qui vous a dit cela (en mail privé SVP)...

A +

[Badplayer1603]

Bonjour,

c'est fait.
je suppose qu'il n'a pas eu le temps de détailler les limites d'utilisation.