Ci sono molti fattori che influenzano le prestazioni del database. Conoscere le normali fluttuazioni della tua particolare istanza monitorando il tuo server SQL ti aiuta a identificare quando il comportamento sta andando fuori controllo e ad anticipare i problemi prima che si verifichino.
Ti aiuta anche a distinguere tra i problemi di crescita naturali causati dall'aumento del carico di lavoro o dai picchi stagionali che potrebbero richiedere più risorse rispetto a problemi di prestazioni più profondi che richiedono l'ottimizzazione del codice, l'ottimizzazione dell'indice o l'ottimizzazione della configurazione.
Dopo aver stabilito un elenco di server SQL nel tuo ambiente, vorrai porre alcune domande critiche:
- Quanto è sana questa istanza?
- Quando è stato eseguito l'ultimo backup?
- Ha CPU, memoria e spazio di archiviazione sufficienti per soddisfare il suo SLA?
- Che tipo di carichi di lavoro vengono eseguiti su questa istanza?
- Quali applicazioni e utenti utilizzano questa istanza?
- Quando è più intenso il carico di lavoro?
- Esiste una strategia di failover?
- Si tratta di un'istanza mission-critical?
- Deve essere disponibile 24 ore su 24, 7 giorni su 7?
- Che tipo di problemi di prestazioni presenta questa istanza?
Queste possono sembrare domande ovvie, ma se inizi a monitorare i carichi di lavoro del tuo server SQL per la prima volta, rimarrai sorpreso e forse un po' inorridito nel vedere quanti di loro hanno problemi fondamentali.
Imposta obiettivi di prestazioni per il monitoraggio di SQL Server
Pensa a cosa vuoi ottenere con le tue attività di monitoraggio del server SQL e dai la priorità a questi obiettivi. Inquadrando le tue attività in termini di indicatori chiave di prestazione, rendi più facile articolare il valore dell'energia e gli eventuali investimenti necessari. Il seguente elenco ti consentirà di iniziare.
Alta disponibilità
Quali sono le tue statistiche di disponibilità? Ricorda che l'indisponibilità per l'utente è quando non può accedere al servizio. Ciò può essere causato da un'interruzione completa o da un collo di bottiglia delle prestazioni che rende effettivamente il servizio non disponibile. Hai una configurazione sempre attiva? Se sì, ne conosci lo stato?
Tempo di risposta
Dal momento in cui viene segnalato un problema, quanto velocemente puoi isolare la fonte, diagnosticare i sintomi e rispondere a quelli interessati?
Tempo di risoluzione
Quanto velocemente puoi risolvere il sintomo per ripristinare il normale funzionamento? La soluzione del "cerotto appiccicoso" è un inizio importante, ma non dovrebbe rappresentare la fine della questione. Hai esplorato la causa principale del problema? Puoi essere sicuro che non vedrai un ripetersi?
Comprendere il costo di proprietà delle istanze di SQL Server
Il costo di proprietà è un fattore critico quando si decide dove devono risiedere le istanze del server SQL. È importante misurare i costi di investimento iniziali associati all'infrastruttura e alle licenze, i costi di manutenzione continua e tutti i costi basati sul consumo associati a un carico di lavoro basato su cloud.
Se stai cercando di decidere quanto costerà la tua istanza nel cloud, i parametri critici includono l'utilizzo della CPU, l'attività di lettura e scrittura e l'archiviazione. Dovrai misurarli su un lungo periodo per capire i limiti del tuo carico di lavoro per assicurarti di disporre delle risorse per lo spettro di carico di lavoro che ti aspetti per una particolare istanza.
Acquisire familiarità con le caratteristiche particolari dei carichi di lavoro in esecuzione nelle istanze del server SQL ti metterà in una posizione molto migliore per assicurarti che tutto continui a funzionare come dovrebbe e per soddisfare le esigenze attuali e future della tua azienda.
Studiare le prestazioni nel tempo con il monitoraggio di SQL Server
I database sono sistemi fluidi. Pochissimi hanno carichi di lavoro costanti, ripetitivi e prevedibili. È molto più comune vedere ampie variazioni nel tempo che oscillano in base al numero di utenti, lavori automatizzati, numero di transazioni, volume di dati e così via.
Un database di vendita sarà occupato alla fine del mese. Vedrà anche un picco di attività intorno agli eventi stagionali o guidato da promozioni di marketing.
Classificare le prestazioni in base a piccoli snapshot non è una buona politica. Più cronologia puoi raccogliere e analizzare, più informazioni puoi ottenere sulle variazioni e sui limiti di ciascuna delle caratteristiche dei tuoi carichi di lavoro.
Dovrai giudicare quanta storia è pratico conservare e se hai le risorse per elaborarla. Ci sono implicazioni in termini di costi e prestazioni da considerare.
Ottieni il quadro completo per il monitoraggio del tuo database
Ogni database è un sistema complesso con molte parti mobili. Molti criteri di configurazione possono influire sulle sue prestazioni.
Il design e l'architettura del database stesso influenzeranno i risultati. Anche l'efficienza del codice può creare o distruggere le prestazioni. Le opzioni di configurazione determineranno il modo in cui l'istanza del server SQL consuma le risorse a sua disposizione.
Considera lo scenario seguente:un'istanza sta rallentando fino all'arresto e il DBA rileva un picco nell'attesa di CXPACKET o CXCONSUMER. La reazione istintiva è quella di chiudere il parallelismo. Le attese scompaiono e l'attuale collo di bottiglia viene temporaneamente alleviato. Ora l'intera istanza è più lenta, ma il DBA non vuole riattivare il parallelismo. Se fossero state effettuate ulteriori indagini, sarebbe emerso che una query veniva eseguita particolarmente lentamente e la causa era un indice mancante.
Il monitoraggio di molte metriche diverse in parallelo aiuta a identificare con precisione la causa principale ed evitare costose diagnosi errate che possono causare la ripetizione o addirittura l'escalation dello stesso problema.
