Di recente, con un certo stupore, ho scoperto che in uno dei dipartimenti della grande azienda in cui lavoro è vietato avviare SQL profiler durante l'orario lavorativo.
Non so come riescano a gestire l'analisi dei problemi di performance che si verificano proprio durante l'euro di lavoro. Le performance views spesso non forniscono un quadro chiaro, specialmente se a trottare sono una o due procedure o query, senza particolamente caricare il server. Una piccola query, che viene eseguita diverse volte all'ora e dura 10 secondi invece di uno (ma che fa qualcosa di molto importante per il cliente che si innervosisce molto) non apparirà nei DMV views. E un select con CROSS APPLY sui testi delle query carica notevolmente il server.
Tuttavia, mi interessa capire da dove proviene questa paura. In alcune aziende SQL profiler è uno strumento di lavoro, in altre lo temono come il fuoco (per un certo tempo ho fatto consulenze e ho potuto confrontare). Sono quasi sicuro che fosse così:
Houston, abbiamo un problema. Il database è lento. Occupati tu.
Ci sono così tante spunte... Cosa mi serve?
Va bene, metterò tutte le spunte e poi deciderò.
Cosa rimane nella mente dei vertici aziendali? Qualcuno ha avviato SQL profiler e tutto si è fermato. E poi lo raccontano l'uno all'altro al tavolo da golf.
A proposito, un particolare interesse lo suscita il tentativo di registrare tali ‘scriviamo tutto’ i trace non in un file, ma nel database stesso server – una volta sono stato testimone di un caso simile.
E da voi come sono le cose? Partecipate al sondaggio per favore
Solo gli utenti registrati possono partecipare al sondaggio. , per favore.
È possibile eseguire SQL profiler su PROD?
Siamo una piccola azienda, per noi è tutto semplice
Ovviamente gli admin di produzione possono
Gli admin di produzione possono dopo approvazioni e piegarsi
Santo, santo, santo
Hanno votato 4 utenti. Si sono astenuti 3 utenti.
Fonte: habr.com
