"Doc, sono preoccupato per le prestazioni di SQL Server."
Non era il genere di cose che senti dalla maggior parte dei pazienti. Ma poi, come professionista retribuito, sono stato addestrato per affrontare tutto, anche i momenti difficili dell'essere un amministratore di database.
"Veramente? Esploriamolo, vero?"
“Certo, dottore. Voglio dire, a volte sembra così opprimente. Pensavo che tutto si sarebbe risolto da solo una volta che mi fossi impegnato. Ma prima che me ne rendessi conto, ho iniziato ad avere problemi di prestazioni in SQL Server 2012, poi 2014, poi 2017. Non voglio nemmeno pensare a SQL Server 2019."
"Vedo. Bene, una buona relazione con SQL Server non si verifica da sola. Devi lavorarci sopra. Dimmi, hai lavorato sulle tecniche di ottimizzazione delle prestazioni di SQL Server?"
«Ehm, no, dottore. Non conosco davvero nessuna di queste tecniche."
"Non preoccuparti. Possiamo lavorare su di loro. Probabilmente il tuo SQL Server si sente trascurato. Devi tenerlo d'occhio per assicurarti di stare al passo con il gioco. Ciò richiede il monitoraggio di SQL Server."
“Monitoraggio? Come lo fai?"
“Devi dimostrare a SQL Server che tieni. Devi prestare attenzione a determinate metriche. Possiamo lavorare anche su quello.”
“Va bene, dottore. Qualunque cosa tu dica. Sono disposto a provare qualsiasi cosa a questo punto. Le cose non potrebbero andare molto peggio di come sono ora."
"Bene allora. Cominciamo."
Metriche delle prestazioni di SQL Server:molte parti mobili
Il paziente aveva ragione:il monitoraggio delle prestazioni di SQL Server può essere schiacciante. Non puoi smettere di prestargli attenzione una volta che è attivo e funzionante. Devi continuare a dimostrargli che ci tieni.
SQL Server ha molte parti mobili che generano costantemente metriche. Sapere quali guardare e poi prendere il tempo della tua giornata impegnativa per monitorarli può essere molto faticoso per un DBA.
Quindi ho esaminato alcune delle aree principali delle metriche delle prestazioni di SQL Server con il paziente.
Indici
Uno dei primi posti da guardare quando si verificano problemi di prestazioni con SQL Server sono gli indici. I tuoi dati sono in continua crescita, quindi anche i tuoi indici sono sempre in crescita. Ma sono soggetti a condizioni come la frammentazione e le divisioni di pagina che possono rallentare la risposta alle query.
Cosa sta succedendo in un database giorno dopo giorno? Gli utenti stanno creando, modificando ed eliminando record. Gli indici tengono il passo con dove si trovano tutti i pezzi dei record, ma nel tempo la frammentazione degli indici ostacola le prestazioni.
Poi c'è il fattore di riempimento dell'indice, un parametro che puoi configurare in SQL Server per controllare il numero di divisioni di pagina e aumentare l'efficienza delle query. Ma l'equilibrio tra un numero maggiore e un minor numero di divisioni di pagina influisce sulle prestazioni in altri modi.
Visualizzazione delle metriche in fattore di riempimento , I/O e frammentazione è un buon modo per tenere le dita sul polso dell'integrità dell'indice di SQL Server.
Cache del buffer
Rendiamolo semplice:disco, lento; cache buffer, veloce. La cache del buffer è una copia in memoria delle pagine del database utilizzate di recente. Se SQL Server non trova ciò che sta cercando lì, deve andare su disco per trovarlo, il che rallenta le prestazioni.
SQL Server consente di specificare la quantità di memoria di sistema da allocare alla cache del buffer, ma si fa a meno della memoria rimasta per altre attività. Il tuo obiettivo è allocare quanto più possibile senza ostacolare le prestazioni di SQL Server in altre aree.
Altrettanto importante è l'aspettativa di vita della pagina, la quantità di tempo che una pagina di informazioni dal database trascorre nel buffer senza essere nuovamente accessibile. SQL Server elimina continuamente le pagine dalla cache del buffer per fare spazio a quelle utilizzate più di recente. Ma meno pagine utili trova lì, più deve leggere dal disco, il che rallenta le prestazioni.
Metriche come aspettativa di vita della pagina e rapporto di hit riusciti nella cache del buffer aiutarti a prendere decisioni sull'eliminazione delle pagine meno frequentemente o sull'aumento delle dimensioni della cache.
T-SQL
SQL Server utilizza un linguaggio di query chiamato T-SQL. Anziché eseguire istruzioni SQL ad hoc, SQL Server tenta di migliorare le prestazioni inviandole in batch, compilandole come piano di esecuzione e memorizzandole nella cache. Cerca inoltre di ridurre al minimo la frequenza di compilazione e di riutilizzare i piani di esecuzione il più spesso possibile. Se non è in grado di riutilizzare il piano di esecuzione, ad esempio perché il database è stato modificato troppo, il piano verrà ricompilato. È meglio mantenere il numero di ricompilazioni di istruzioni SQL il più basso possibile, perché il processo può consumare grandi quantità di CPU e ridurre le prestazioni.
La necessità di compilare e ricompilare è una funzione delle buone pratiche di codifica, come l'utilizzo di procedure memorizzate e la parametrizzazione delle query. DBA che monitorano metriche come la frequenza delle compilazioni SQL e ricompilazioni SQL può modificare i suggerimenti per le query di SQL Server per migliorare le prestazioni.
Blocca, attende e blocca i processi
È frustrante scoprire che qualcun altro sta modificando qualcosa nello stesso momento in cui lo fai tu. Quindi i database bloccano automaticamente cose come righe e tabelle per tenere più cuochi fuori dalla cucina. Il compromesso per tale protezione, ovviamente, è che tutti gli altri utenti devono attendere fino allo sblocco della risorsa. Ed è difficile assicurarsi che il blocco avvenga solo al livello necessario.
Con metriche che mostrano la frequenza e la portata dei blocchi influiscono su altre operazioni, i DBA possono determinare la necessità di più risorse di sistema fisico per elaborare le transazioni più rapidamente. È anche possibile che SQL Server si blocchi a un livello inutilmente basso. La frequenza delle attese di blocco e, più in generale, il numero di processi bloccati può aiutare a individuare i colli di bottiglia.
Elimina i colli di bottiglia con l'ottimizzazione delle prestazioni SQL
“Accidenti, Doc, hai ragione su tutte le parti mobili. Ora vedo come non posso semplicemente installare SQL Server, impostarlo e dimenticarlo. Ho bisogno di nutrire la relazione. Ma tutto questo sembra ancora travolgente. Come farò mai a mantenere così tante cose diverse e stare al passo con il gioco?"
“Questa è la parte migliore. Esistono strumenti che possono aiutare con le prestazioni di SQL Server. Non devi farlo da solo."
“Accidenti! Questo è rassicurante. Non lo sapevo."
"Giusto. Gli strumenti monitorano le prestazioni del tuo server SQL e segnalano tutte queste metriche in modo da poter applicare le tue tecniche di ottimizzazione ed eliminare i colli di bottiglia."
"Davvero?"
"Sicuro. E possiamo lavorare su quelli giusti - oh, mio Dio, siamo fuori tempo per questa settimana. Per favore, fissa un appuntamento con la mia receptionist e verremo a prenderti la prossima settimana."
«Ragazzi, quelle quattro ore sono passate in fretta, dottore! Il tempo vola di sicuro quando stai risolvendo problemi di prestazioni relativi a frammentazione, utilizzo delle risorse e rapporto di hit della cache del buffer , non è vero?"
"Sì, e sono sicuro che una volta che comunicherai apertamente su questi problemi con il tuo SQL Server, tutti i tuoi problemi di prestazioni saranno registrati."
Rincuorato dalla nostra seduta, il paziente se ne andò. La prossima volta, lavoreremo sul monitoraggio dei colli di bottiglia delle prestazioni di SQL Server. Ne parlerò sul blog, quindi tieni gli occhi aperti.
Nel frattempo, fidati di me. Sono un professionista pagato e ti incoraggio a provare queste cose nella tua relazione con il tuo database. Fai sentire il tuo SQL Server desiderato. Presta attenzione alle sue metriche di performance.
Non è mai troppo tardi per provare.
