Come sa fin troppo bene chiunque gestisca i database, l'ottimizzazione delle prestazioni di SQL Server è una funzione fondamentale per garantire prestazioni ottimali. Poiché le prestazioni dipendono da vari fattori come memoria, configurazione, progettazione delle query e utilizzo delle risorse, isolare la causa principale del degrado delle prestazioni non è un'impresa da poco.
Anziché attendere che si verifichino problemi di prestazioni, l'ottimizzazione proattiva di SQL Server garantirà l'esecuzione delle istruzioni SQL nel modo più efficiente possibile, aiutando SQL a trovare il percorso più veloce in entrata e in uscita per fornire i risultati della query.
Se stai lottando con prestazioni lente o non sei uno che aspetta solo che sorgano problemi, ecco tre aree chiave su cui concentrare l'ottimizzazione delle prestazioni di SQL Server per ottenere prestazioni ottimali e sistemi più sani.
Suggerimento n. 1:ottimizza il tuo TempDB
TempDB configurato in modo errato è un colpevole comune quando si osserva il degrado delle prestazioni. Se riempi spesso il tuo TempDB, è tempo di dare un'occhiata a cosa deve cambiare.
Innanzitutto, controlla le dimensioni di TempDB. Non esiste una regola rigida su quanto dovrebbe essere grande, ma una buona regola pratica è mantenere TempDB al 25% del database più grande o alla stessa dimensione dell'indice più grande. Ciò evita di dover aumentare TempDB durante le ricostruzioni.
Con TempDB, più veloce è l'unità, meglio è. Quando TempDB viene posizionato su un'unità lenta o sulla stessa unità del sistema operativo, vedrai sicuramente problemi di prestazioni del database. Se possibile, mantieni TempDB su un SSD locale dedicato. Se ciò non è possibile, la tua prossima opzione migliore è mantenerlo sul proprio volume dedicato con spazio su disco preallocato sufficiente.
È anche importante mantenere separati i dati e i file di registro e impostare un valore fisso elevato per la crescita automatica di TempDB. Altrimenti, verrai colpito da un sovraccarico non necessario ogni volta che TempDB si riempie.
Il controllo del numero di file di dati TempDB contribuisce all'ottimizzazione di TempDB. Ma la grande domanda è:quanti file di dati TempDB sono necessari? Idealmente, avrai un file di dati TempDB per ogni CPU logica, ma non più di otto in totale (con alcune eccezioni). Ad esempio, se si dispone di quattro CPU logiche, sono necessari quattro file di dati TempDB. Se hai 12 CPU logiche, puoi avere otto file di dati TempDB.
Suggerimento n. 2:evita i colli di bottiglia delle prestazioni
Esistono tre tipi principali di colli di bottiglia delle prestazioni di SQL Server che contribuiscono a scarse prestazioni:CPU, memoria e I/O. Le cause, i sintomi e la diagnostica differiscono in base al tipo di collo di bottiglia, quindi ecco una guida rapida a cosa prestare attenzione:
Colli di bottiglia della CPU
Causa: Risorse hardware insufficienti
Sintomi: Utilizzo del processore costantemente elevato
Metriche da monitorare: % tempo processore, richieste batch/sec, compilazioni SQL/sec e ricompilazioni SQL/sec
Colli di bottiglia della memoria
Causa: Limitazioni nella memoria disponibile e pressione di memoria causate da SQL Server, sistema o altre attività dell'applicazione
Sintomi: Reattività lenta delle applicazioni, rallentamento generale del sistema e arresti anomali delle applicazioni
Metriche da monitorare: Memoria disponibile (KB), memoria totale del server (KB), memoria del server di destinazione (KB), pagine al secondo, pagine checkpoint al secondo, scritture pigre al secondo e rapporto hit cache buffer
Colli di bottiglia I/O
Causa: Lettura e scrittura eccessive di pagine di database da e su disco
Sintomi: Lunghi tempi di risposta, rallentamenti delle applicazioni e timeout delle attività
Metriche da monitorare: Lunghezza media della coda del disco, sec/lettura media del disco, sec/scrittura media del disco, % di tempo del disco, letture medie del disco/sec e scritture medie del disco/sec
Suggerimento n. 3:assicurati che gli indici siano progettati correttamente
Gli indici sono un ottimo modo per velocizzare alcune operazioni di SQL Server, ma solo se sono ben progettati. Gli indici mal progettati hanno l'effetto opposto e sono un modo sicuro per ridurre le prestazioni di SQL Server.
La corretta configurazione di queste quattro aree può aiutare a garantire che gli indici siano progettati correttamente e aiutare piuttosto che compromettere le prestazioni di SQL Server.
Dimensioni del tavolo
Non tutte le tabelle sono un buon candidato per l'indicizzazione. In effetti, se una tabella è troppo piccola, è molto più efficiente per SQL Server eseguire ricerche nell'intera tabella anziché dover eseguire ricerche negli indici. Ovviamente, vale il contrario per le tabelle di grandi dimensioni, quindi è necessario valutare il potenziale sovraccarico quando si decide quali tabelle trarrebbero vantaggio dagli indici.
Tipi di indice
Tecnicamente, ogni tabella di database può avere un indice cluster e un numero infinito di indici non cluster, ma sai cosa si dice di "Solo perché puoi fare qualcosa"...
Troppi indici non cluster possono rallentare notevolmente le operazioni di inserimento e aggiornamento, quindi attenersi a un indice cluster e al numero minimo di indici non cluster assolutamente essenziali è una scelta di progettazione di gran lunga migliore.
Archiviazione dell'indice
Durante la fase di progettazione, la selezione dei criteri di archiviazione appropriati per gli indici è fondamentale per le prestazioni di I/O. Gli indici cluster partizionati e gli indici non cluster possono essere archiviati nello stesso filegroup della tabella principale oppure possono essere archiviati in un filegroup diverso. L'archiviazione di un indice non cluster in un filegroup situato su un'unità disco diversa può migliorare le prestazioni delle query che lo utilizzano, poiché non è influenzato dalla lettura simultanea dei dati e delle pagine dell'indice SQL che si verificano su unità disco diverse.
FILFACTOR
FILLFACTOR specifica la percentuale di spazio che verrà riempita su ciascuna pagina di dati durante la creazione di un indice. I valori di FILLFACTOR possono variare da 0 percento (nessuna pagina di dati è riempita) a 100 percento (la pagina di dati è completamente riempita). Durante la progettazione dell'indice, seleziona un valore FILLFACTOR che ottimizzerà l'utilizzo della pagina riducendo al minimo il rischio di un'eccessiva frammentazione dell'indice.
Rendere l'ottimizzazione delle prestazioni di SQL Server una parte della routine standard è un modo eccellente per garantire che i database funzionino al massimo delle prestazioni. L'integrazione di questi tre semplici passaggi nei normali piani di manutenzione di SQL Server migliorerà notevolmente la velocità e le prestazioni dei tuoi utenti.
