Recent a fost o surpriză să aflu că într-unul dintre departamentele uriașei companii în care lucrez, utilizarea profiler-ului SQL este interzisă în timpul programului de lucru.
Nu știu cum reușesc să analizeze problemele de performanță care apar exact în timpul programului de lucru. Într-adevăr, vizualizările de performanță nu oferă adesea o imagine clară, mai ales dacă sunt afectate una sau două proceduri sau interogări, fără a solicita în mod special serverul. O interogare mică, care se execută de câteva ori pe oră și durează 10 secunde în loc de una (dar care face foarte multe lucruri importante pentru client devine foarte nervoasă) cu siguranță nu va apărea în vizualizările DMV. Iar un select cu CROSS APPLY pe texte ale interogărilor solicită serverul destul de mult.
Cu toate acestea, mă interesează să înțeleg de unde provine această frică. În unele companii profiler-ului SQL este un instrument de lucru, iar în altele este evitat ca focul (am lucrat o vreme în consultanță și am putut compara). Sunt aproape sigur că a fost astfel:
Houston, avem probleme. Baza de date este încetinită. Rezolvă
Aici sunt atât de multe bifări… Ce am nevoie?
Bine, voi bifa tot și apoi voi decide.
Ce rămâne în mintea conducerii superioare? Cineva a folosit profiler-ului SQL și totul s-a oprit. Iar apoi își povestesc unii altora la o partidă de golf.
Apropo, o notă de particularitate este dată de încercarea de a înregistra astfel de ‘întotdeauna scriem’ trace-uri nu în fișier, ci în baza de date pe același server – odată am fost martor la un astfel de caz.
Dar la voi cum stau lucrurile? Vă rog să participați la sondaj
Numai utilizatorii înregistrați pot participa la sondaj. , vă rugăm.
Este permis să rulați profiler-ul SQL pe PROD la voi?
Suntem o companie mică, totul este simplu pentru noi
Adminii de producție, desigur, pot
Adminii de producție pot după aprobări și plecând capul
Sfinte, sfinte, sfinte
Au votat 4 utilizatori. S-au abținut 3 utilizatori.
Sursa: habr.com
