Intanto ben ritrovati!
Oggi continuamo con la serie che ha riscosso tante visualizzazioni qualche mese fa: La megaditta è bloccata! parlandovi di un recente problema che mi si è presentato.
Sarà l'occasione per tornare a parlare di Wait States ovvero dei tipi di attesa.
"Guardare ai tipi di attesa è un po come leggere le analisi del sangue. Certo non basta ma ci fornisce davvero tante indicazioni"
P.S. Probabilmente seguirà anche l'articolo in inglese per tutti gli amici che mi seguono all'estero!
Buona lettura!
Il vostro "super cliente è bloccato"! Un caso reale!
Driiin…
Arriva la segnalazione! Il vostro "super cliente" titolare della nota "Megaditta" ieri che non riesce più a lavorare!
Sperimenta dei blocchi ed inoltre, parecchie delle funzioni del vostro gestionale, sono diventate estremamente lente!
Prima ancora che la pressione inizi a salire e che l’ambiente inizi a riscaldarsi siete già collegati sul loro server. State guardando faccia a faccia il loro SQL Server e state già eseguendo le vostre stringhe T-SQL magiche.
Tra queste c’è ne è sicuramente una che estrae i tipi di attesa.
La sua esecuzione mostra questo risultato:
Tra i tipi di attesa più che assorbono un tempo maggiore ne troviamo uno che non è tra quelli più conosciuti: è il MSQL_DQ.
Ma cos’è questo tipo di Wait Type?
l' MSQL_DQ - dove "DQ" sta per "Distribuited Query" - è un wait type che misura le attese relative alle query distribuite (ovvero le Query eseguite tra tabelle presenti su server o databases diversi)
In questo caso troviamo associato a questo nostro wait type anche il wait type PREEMPTIVE_COM_QUERYINTERFACE.
Certo il fatto che le query distribuite assorbano tante risorse non vuol dire automaticamente che sia questa la problematica ...
Però! Come ogni esame del sangue di ha dato l’indicazione di dove andare a cercare!
Le “Query distribuite”
Le Query distribuite avvengono solitamente tramite linked server.
Per questo motivo andiamo a vedere quali procedure accedono ai dati in questo modo tramite il comando:
exec sp_linkedservers
Bingo!
Testando quindi la connessione di ogni linked server trovato è emerso che uno di essi non funziona.
Ed ecco cosa succede:
Quando il linked server non è funzionante, le Query che lo utilizzano continuano "a girare" per minuti fino a che non esce un errore di time out (che dice "errore di connessione").
Trattandosi poi nello specifico di un UPDATE che coinvolge sia le tabelle a cui si accede tramite linked Server che le tabelle del nostro dataabse, si finisce per bloccare anche le tabelle proprie del gestionale.
Dopo aver risolto il problema i wait states miusurati all'inizio da li a poco hanno inziato a calare:
Bene, per oggi è tutto!
Spero di avervi appassionato raccontandovi oggi un caso "reale".
In tal caso continuate a seguirmi ...vi aspettano tanti altri articoli già in fase di preparazione!
A presto!
Luca Biondi @ SQLServerPerformance blog!
Next post: https://server.hoit.asia/2019/12/sql-server-problematic-query-with.html
Previous post: SQL Server, Math and Applications