In qualità di DBA, affrontare i problemi di prestazioni è spesso un evento reattivo; si verifica un problema, devi rispondere. A volte stai guardando un'istanza di SQL Server che conosci bene, altre volte potrebbe essere il tuo primo incontro con un ambiente. Questo accade anche nel mondo della consulenza. Quando aiuto un cliente a lungo termine, ho già archiviato i dettagli sull'ambiente. Tuttavia, quando riceviamo un'e-mail da qualcuno con cui non abbiamo lavorato prima, ed è una situazione di emergenza in cui vogliono un aiuto immediato, non abbiamo informazioni sull'ambiente e non abbiamo idea di cosa stiamo entrando. Forniamo assistenza senza passare attraverso il vasto processo di raccolta e analisi dei dati che inizia ogni nuovo coinvolgimento del cliente.
Per questo motivo ho un set di cinque elementi che controllo immediatamente quando mi confronto con un nuovo ambiente. Le informazioni che raccolgo preparano il terreno per il modo in cui affronterò la risoluzione dei problemi in futuro e, sebbene raramente individuino LA problema specifico, mi aiuta a escludere cosa è NON il problema, che a volte è altrettanto importante.
Metodi di raccolta dei dati
Riconosco che ognuno ha un approccio diverso quando affronta un nuovo ambiente. Esistono diversi script gratuiti e ampiamente disponibili che puoi scaricare ed eseguire per darti il "lay of the land" per un'istanza di SQL Server (mi vengono in mente gli script DMV di Glenn Berry). L'obiettivo qui non è come raccogli i dati, è cosa dati che raccogli e cosa analizzi prima .
Proprietà del server
La prima cosa che voglio sapere quando guardo un'istanza è la versione e l'edizione di SQL Server. Il modo più veloce per ottenere queste informazioni è eseguire:
SELECT @@VERSION;
Con questo output, posso controllare la build per determinare i service pack, gli aggiornamenti cumulativi e gli hotfix applicati e sapere quale edizione viene utilizzata. Mi piace anche sapere se l'istanza è in cluster, quindi eseguo anche:
SELECT SERVERPROPERTY('IsClustered'); A volte ho queste informazioni dal cliente, ma non fa mai male da verificare, poiché la versione e l'edizione possono influenzare i successivi passaggi e consigli per la risoluzione dei problemi. Ad esempio, un client ci ha contattato di recente in merito a un problema di prestazioni intermittenti riscontrato con SQL Server 2008. Un rapido controllo della versione ha rivelato che stavano eseguendo SQL Server 2008 SP3 e che sono stati rilasciati diversi aggiornamenti cumulativi dopo SP3 che hanno risolto una serie di problemi di prestazione. Anche se ho raccolto ulteriori informazioni prima di consigliare di applicare l'ultima CU, questa è stata un'immediata bandiera rossa su ciò che potrebbe causare il problema.
configurazioni.sys
Questa visualizzazione del catalogo aiuta a costruire sulla base avviata con le proprietà del server e ci aiuta a capire come è configurata l'istanza. Con questa visualizzazione, cerco le impostazioni che sono state modificate rispetto a quelle predefinite, ma non avrebbero dovuto esserlo, e quelle che non stato modificato, ma dovrebbe.
SELECT [name], [value], [value_in_use], [description] FROM [sys].[configurations] ORDER BY [name];
Considera l'impostazione della memoria massima del server (MB), che limita la quantità di memoria disponibile per il pool di buffer. Il valore predefinito è 2147483647, ma deve essere modificato in un valore inferiore alla memoria totale sul server per garantire che vi sia memoria sufficiente per il sistema operativo, altre applicazioni e altre attività di SQL Server che richiedono memoria non prelevata dal pool di buffer . Per indicazioni sull'impostazione del valore appropriato per la memoria massima del server (MB), consiglio il post di Jonathan, Quanta memoria ha effettivamente bisogno il mio SQL Server?
Al contrario, l'impostazione dell'aumento della priorità ha un valore predefinito pari a zero e dovrebbe essere sempre lasciata come tale. In effetti, Microsoft consiglia di non modificarlo e l'opzione verrà rimossa in una versione futura di SQL Server.
sys.database
Dopo aver compreso come è configurata l'istanza, cercherò di vedere cosa esiste a livello di database.
SELECT * FROM [sys].[databases] ORDER BY [database_id];
Quando controllo l'output di questa vista del catalogo, cerco gli anti-pattern, tutto ciò che salta fuori come inaspettato o atipico, nei dati. L'output è favorevole per un'analisi rapida:molte delle impostazioni elencano uno 0 o 1 per il valore (disattivato o attivato) e prendo nota mentalmente di ciò che è diverso. Prevedo che la creazione automatica delle statistiche e l'aggiornamento automatico delle statistiche siano abilitate (impostate su 1). Mi aspetto che la chiusura automatica e la riduzione automatica siano disabilitate (impostate su 0). Cerco di vedere quali sono le regole di confronto per i database utente, in particolare se hanno tutte le stesse regole di confronto e se quelle regole di confronto sono le stesse di tempdb. Noto anche opzioni di sicurezza come il concatenamento tra database e l'opzione is_trustworthy, entrambe disabilitate (0) per impostazione predefinita. Se scopro che una di queste impostazioni devia da ciò che mi aspetto, lo prendo atto e vado avanti. In nessun momento interrompo la mia raccolta o analisi per apportare una modifica, poiché sto semplicemente raccogliendo informazioni il più rapidamente possibile per ottenere una buona comprensione dell'ambiente.
Oltre a controllare le impostazioni per i database, prendo nota anche del numero di database utente. Non esiste un "numero giusto" di database utente per un'istanza:un'istanza può funzionare male con un database e può funzionare meravigliosamente con 100. Ci sono una miriade di fattori in gioco e il numero di database è semplicemente un punto dati degno di nota.
Registri errori
Lo ammetto, trascuravo l'ERRORLOG di SQL Server; è stato come un ripensamento quando ho studiato un problema con SQL Server. Poi mi sono reso conto dell'errore dei miei modi e da allora non l'ho dato per scontato. Tendo a navigare in Management Studio per accedere al registro (all'interno di Management | Registri di SQL Server), anche se puoi utilizzare la stored procedure sp_readerrorlog o sfogliare il file e aprirlo con il tuo editor di testo preferito.
All'interno di ERRORLOG cerco gli errori recenti, ad esempio qualsiasi cosa relativa alla memoria, e cerco anche quali flag di traccia, se presenti, sono in uso. Controllo anche se Blocca pagine in memoria è abilitato, se la cache viene svuotata (di proposito o meno) e se si verificano regolarmente altre attività insolite. A seconda dell'urgenza del problema, guardo anche i registri di Windows (Eventi, Applicazione e Sicurezza), anche in questo caso non cerco solo errori, ma anche schemi di messaggi imprevisti.
Statistiche di attesa
L'ultima area di SQL Server che esamino quando si esamina un problema di prestazioni su un'istanza sconosciuta è la statistica di attesa. Ogni istanza di SQL Server avrà delle attese, non importa quanto sia ottimizzato il codice, non importa quanto hardware ci sia dietro. Come DBA vuoi sapere quali sono le tue attese tipiche per un'istanza e quando guardo un nuovo ambiente, non so immediatamente se le attese che vedo sono tipiche o se sono dovute a problemi di prestazioni. Chiedo al cliente se ha le statistiche di attesa di base e, in caso contrario, chiedo se posso cancellarle e lasciare che inizino ad accumularsi mentre si verifica il problema di prestazioni. Per controllare le statistiche di attesa puoi utilizzare lo script nel post spesso citato di Paul Randal o la versione nelle query DMV di Glenn.
Dopo aver esaminato le statistiche di attesa accumulate, avrai il pezzo finale che fornisce il "quadro generale" dell'istanza di SQL Server e le informazioni necessarie per iniziare la risoluzione dei problemi. Non è raro controllare prima le statistiche di attesa durante la risoluzione dei problemi, ma le attese da sole non sono informazioni sufficienti per determinare cosa è necessario analizzare successivamente, a meno che tu non comprenda anche la configurazione di base di SQL Server.
Passaggi successivi
Come ho accennato in precedenza, in genere non esiste un dato che ti dice dove si trova il problema delle prestazioni, sono più punti dati ottenuti che ti indirizzano nella giusta direzione. Il modo in cui acquisire tali informazioni dipende da te, ma una volta esaminato l'output, dovresti avere una buona conoscenza di come è configurato l'ambiente SQL Server e tale conoscenza, combinata con le statistiche di attesa, può aiutarti a decidere cosa analizzare successivamente. La risoluzione dei problemi funziona meglio con un approccio metodico, quindi inizia con le basi e lavora, e quando pensi di aver determinato la causa principale, scava un po' di più e trova una o due prove aggiuntive che supportano la tua scoperta. Una volta che hai questi dati, puoi dare un consiglio per aiutare a migliorare o risolvere il problema.
