Il mantenimento di istanze di SQL Server ad alte prestazioni è una parte enorme delle responsabilità lavorative di un DBA. Il mancato rilevamento e correzione di attività insolite può influire sulle operazioni interne e compromettere i profitti dell'azienda.
Se noti variazioni di attività di picco o anomalie in un'istanza di SQL Server, ecco tre punti da cui iniziare la ricerca delle risposte.
Aspettativa di vita della pagina
L'aspettativa di vita della pagina (PLE) di un'istanza dovrebbe mantenere un intervallo di valori abbastanza coerente. Se quel valore scende e rimane basso, è un segno che il pool di buffer sta subendo un aumento della domanda.
Prima di esaurire e aumentare la memoria, dai un'occhiata all'attività del carico di lavoro. Se il carico di lavoro è aumentato, ciò spiegherebbe la pressione aggiuntiva sul pool di buffer. Ma se il carico di lavoro non è cambiato, dovrai guardare più da vicino per identificare cosa sta usando la memoria extra.
Possibili ragioni per un calo di PLE includono lavori di manutenzione in esecuzione attivamente, ricostruzioni di indici o aggiornamenti delle statistiche, operazioni DBCC e modifiche al piano di query.
Se noti un calo del PLE che non è associato a un aumento del carico di lavoro, ci sono alcune cose che puoi provare per migliorare il PLE di un'istanza:
- Elimina gli indici inutilizzati
- Unisci indici duplicati
- Fai attenzione alle grandi domande
- Deframmenta
- Elimina dati
WRITELOG Tempo di attesa
Quando il tempo di attesa di WRITELOG è una proporzione eccessiva del tempo di attesa totale, è probabile che si verifichi un collo di bottiglia nell'istanza di SQL ServerSQL Server. Il collo di bottiglia è probabilmente causato da un problema sul disco in cui è archiviato il registro delle transazioni o da un commit inefficiente dei dati.
Per determinare il tipo di collo di bottiglia con cui hai a che fare, inizia analizzando il numero di istruzioni SQL in attesa dell'evento WRITELOG. Se ci sono molte istruzioni in attesa, hai un collo di bottiglia del disco. Se ci sono solo poche istruzioni in attesa, è probabile che i dati vengano salvati troppo spesso.
Esistono diversi modi per risolvere i tempi di attesa elevati di WRITELOG una volta stabilito se il collo di bottiglia è correlato al disco o al commit:
- Aggiungi larghezza di banda I/O al disco in cui è archiviato il registro delle transazioni
- Sposta l'I/O del registro non di transazione dal disco
- Sposta il registro delle transazioni su un disco meno occupato
- Riduci la dimensione del registro delle transazioni
- Assicurati che l'istruzione COMMIT sia inserita nel codice in modo che i dati non vengano salvati troppo frequentemente
TempDB
TempDB è un'area di lavoro temporanea in SQL Server che contiene oggetti temporanei. Poiché gli oggetti contenuti in TempDB sono temporanei, un'istanza di SQL Server ricrea TempDB ogni volta che viene riavviata. Ciò rende l'ottimizzazione di TempDB fondamentale per mantenere le prestazioni ed evitare colli di bottiglia operativi.
La contesa di TempDB è uno dei principali colpevoli del degrado delle prestazioni. Il conflitto si verifica quando più risorse devono accedere a TempDB ma è presente un solo file di dati TempDB. Ciò provoca un collo di bottiglia perché i processi non possono accedere a TempDB abbastanza velocemente, con conseguente timeout delle connessioni e deallocazione dei processi.
Fortunatamente, i colli di bottiglia di TempDB possono essere risolti abbastanza facilmente regolando il numero e la dimensione dei file TempDB. Al momento dell'installazione, l'impostazione predefinita di SQL Server è un file di dati TempDB. Se noti che si verificano conflitti, ti consigliamo di aggiungere otto nuovi file di dati e determinare se ciò risolve il problema. Se il problema persiste, prova ad aggiungere file di dati aggiuntivi in multipli di quattro fino al ripristino delle prestazioni.
Sebbene sia utile sapere da dove iniziare a cercare quando si verificano problemi di prestazioni, ciascuno dei problemi precedenti e i colli di bottiglia risultanti possono essere mitigati o evitati del tutto implementando una regola rigida e veloce:il monitoraggio delle metriche delle prestazioni non è facoltativo. Ecco alcuni esempi di metriche chiave da monitorare:
Aspettativa di vita della pagina:tieni traccia di PLE con il monitoraggio continuo e sii proattivo quando scende e rimane al di sotto del valore tipico per una particolare istanza di SQL Server.
WRITELOG tempi di attesa:monitora metriche come la crescita del registro, la riduzione del registro, la percentuale di registro utilizzata e le attese di risciacquo del registro/sec.
Inefficienza di TempDB:monitorare ciò che viene allocato agli oggetti utente, all'archivio versioni o agli oggetti interni. Tieni traccia dell'andamento nel tempo, quindi determina quali sessioni stanno consumando TempDB e quanto.
Sul mercato sono disponibili alcuni eccellenti strumenti di monitoraggio delle prestazioni di SQL Server, ricchi di funzionalità e convenienti, che possono aiutarti a tenere il passo con i problemi di riduzione delle prestazioni. Diventa il DBA MVP dell'azienda ricercando in modo proattivo soluzioni che mantengano sia le operazioni rivolte all'interno che i servizi aziendali rivolti all'esterno al massimo delle prestazioni.
