Funzionalità obsolete da eliminare dalla tua cassetta degli attrezzi - Parte 2

Nel mio ultimo post, ho illustrato un motivo per cui dovresti smettere di usare tabelle di sistema deprecate come sysprocesses . Questo non era per motivi di prestazioni, direttamente o semplicemente per seguire le best practice documentate di Microsoft, ma ruotava maggiormente attorno alle decisioni che potresti prendere quando hai accesso solo ad alcuni dati.

Questa volta, voglio parlare di una funzionalità inclusa negli strumenti client di SQL Server che non dovremmo utilizzare in questi giorni, non solo perché è deprecata ma, soprattutto, perché ha il potenziale per eliminare completamente un server:

Profilatore SQL Server

Da SQL Server 2012 (e, in misura molto minore, da SQL Server 2008), la soluzione più completa e flessibile per il monitoraggio degli eventi in un'istanza di SQL Server è stata Extended Events. D'altra parte, da quando è stato inventato per la prima volta (più o meno nel periodo in cui ho iniziato la mia carriera), SQL Server Profiler è stato uno dei modi più prolifici per mettere accidentalmente in ginocchio un server.

Non molto tempo fa, a noi è successa una cosa del genere. Uno sviluppatore ha apportato una modifica alla propria applicazione per ridurre il numero di viaggi di andata e ritorno che stavano effettuando. Hanno eseguito l'applicazione localmente e nel nostro ambiente di sviluppo, utilizzando Profiler con una traccia filtrata, per confermare che le modifiche funzionassero come previsto. Lascia che ti ricordi a questo punto che la documentazione ufficiale per SQL Server Profiler include il seguente avviso:

Ad ogni modo, quando hanno distribuito la nuova versione della loro applicazione alla produzione e hanno indirizzato il server di produzione con la stessa traccia filtrata, non è andata così bene. Il loro filtro con caratteri jolly sul nome dell'applicazione non teneva conto delle altre applicazioni (con nomi simili) che si connettevano a questo server e hanno immediatamente iniziato a catturare molte più informazioni di quante la loro finestra di Profiler aperta potesse gestire. Ciò ha comportato un aumento catastrofico del tempo di connessione per tutti gli utenti e le applicazioni che si connettono a quell'istanza. Sarebbe un eufemismo dire che le denunce sono state presentate.

Quando il colpevole è stato determinato e abbiamo ricevuto una risposta dallo sviluppatore, puoi vedere che il tempo di connessione è tornato alla normalità quasi immediatamente dopo aver interrotto la traccia del Profiler (fai clic per ingrandire):

Un mini disastro di SQL Server Profiler

Questo è sicuramente uno scenario in cui la vecchia istruzione "ha funzionato sulla mia macchina" non significa in alcun modo che funzionerà bene su un server di produzione occupato. E questo incidente ha portato a una conversazione attiva sulla modifica del trigger di accesso già esistente su tutti i server nel nostro ambiente per bloccare semplicemente il nome dell'applicazione che Profiler passa nella stringa di connessione.

Forse questo non è un problema di Profiler. (Ma in un certo senso lo è.)

Non sono qui per suggerire che altri strumenti di monitoraggio, inclusi gli eventi estesi, non possano essere utilizzati in modo inappropriato per arrestare un server in un modo simile (o peggio!). Ci sono molte opportunità per influenzare inavvertitamente un'istanza di SQL Server, in modi davvero negativi, senza toccare SQL Server Profiler.

Ma Profiler è noto per questo tipo di sintomi a causa del modo in cui consuma dati. È un'interfaccia utente con una griglia che presenta nuove righe man mano che le riceve; sfortunatamente, fa attendere SQL Server durante il rendering prima di consentire a SQL Server di trasmettere più righe. Questo comportamento è simile al modo in cui SQL Server Management Studio può rallentare le query e causare ASYNC_NETWORK_IO elevati attende mentre tenta di eseguire il rendering di una grande quantità di output nella propria griglia. Questa è una semplificazione (e non deve essere confusa con il modo in cui è possibile far comportare la traccia SQL sottostante, che spiega Greg Gonzalez (@SQLsensei) in "Don't Fear the Trace"), ma è esattamente ciò che porta a il tipo di scenario mostrato sopra:quel collo di bottiglia ha un effetto a cascata su qualsiasi altro processo che tenta di fare qualcosa nello stesso percorso di codice di quello che stai tracciando (incluso il tentativo di stabilire una connessione).

Paura degli eventi estesi?

Non essere. È giunto il momento di abbandonare Profiler e abbracciare il presente . Non mancano tutorial e guide, incluso QuickStart di Microsoft e diversi articoli proprio qui su questo sito.

Se hai tracce esistenti su cui fai affidamento, Jonathan Kehayias (@SQLPoolBoy) ha uno script davvero utile per convertire una traccia esistente in eventi estesi. Puoi comunque sentirti libero di configurare la traccia originale con l'interfaccia utente di Profiler, se è lì che ti senti più a tuo agio; per favore, fallo senza collegarti a un server di produzione. Puoi leggere questo script qui e vedere alcuni degli altri articoli sugli eventi estesi di Jonathan qui.

Se stai attraversando un periodo difficile con l'esperienza utente, non sei solo, ma ci sono alcune risposte:

• Erin Stellato (@erinstellato) è stata a lungo una spettacolare sostenitrice degli eventi estesi e spesso si chiede ad alta voce perché le persone siano riluttanti a lasciar andare Profiler e SQL Trace in generale. Ha qualche intuizione (e ha ispirato molti commenti) nel suo post del 2016, "Perché eviti gli eventi estesi?"; forse c'è qualche indizio sul fatto che le tue ragioni per resistere siano ancora (come) valide nel 2021.
  
• Esiste un XEvent Profiler integrato nelle versioni moderne di SSMS, con un'estensione equivalente per Azure Data Studio. Anche se, in modo confuso, hanno chiamato questa estensione – di tutte le cose che si potrebbero immaginare – SQL Server Profiler . Erin ha anche alcune riflessioni su questa scelta.
  
• Erik Darling (@erikdarlingdata) ha creato sp_HumanEvents per alleviare un po' il dolore del passaggio agli eventi estesi. Una delle mie persone preferite "ferma al punto", Erik descrive sp_HumanEvents come segue:"Se desideri un modo indolore per profilare le metriche delle query, attendere statistiche, bloccare, compilare o ricompilare con gli eventi estesi, questo è il tuo unicorno."