SQL Server: Ottimizzazione delle Query efficaci
Per ottimizzare realmente le prestazioni di SQL Server e gestirne i carichi di lavoro in modo efficiente, è necessario concentrarsi sull'ottimizzazione delle query.
Tratte da "SQL Server DMV Starter Pack," pubblicato da documentazione di Red Gate (2010).
Bacche di Giovanni, Louis Davidson e Tim Ford
Ottimizzazione delle query è il cuore e l'anima di ottimizzazione delle prestazioni di SQL Server. Se il carico di lavoro tipico è costituito da query inefficienti o non valido-progettato, è sarà che si verifichino problemi di prestazioni e scalabilità. Se le query sono più lunghe, più numerosi e più complessa di necessità, si utilizzerà più risorse della CPU durante l'esecuzione.
Di conseguenza, essi anche richiederà più tempi per l'esecuzione. Query non valido-progettato, insieme a un tentativo di fare buon uso degli indici, portare a SQL Server la lettura dei dati di più quello necessario. Causando un ritardo evidente nelle prestazioni e tempi di esecuzione.
Se SQL Server legge i dati dalla cache del buffer, viene definito i/O logico. Può trattarsi di un'operazione dispendiosa dal punto di vista delle prestazioni. Se i dati non sono in memoria e deve essere lette da disco (o se sono necessario scrivere i dati), si tratta dei / O fisico ed è ancora più costoso.
Questioni di dimensione
Se si dispone di numerose query che restituiscono grandi quantità di dati, potrebbe provocare pressione della memoria nella cache del buffer. Ciò comporta i dati di consuntivazione di SQL Server di cache, che a sua volta influirà sulle prestazioni di altre query.
La regola"golden" delle query SQL ben progettata è restituire che alcuna quantità di dati superiore è realmente non necessario. È opportuno SQL Server a passare attraverso i dati come alcune volte possibile e utilizzare logica basata su set per manipolare tali dati nel set di risultati che è necessario.
L'analisi e ottimizzazione delle istruzioni di SQL non è un'operazione di "alta concurrency" ". SQL Server archivia i piani di query eseguite in precedenza in un'area di memoria condivisa denominata cache dei piani. Ogni volta che si invia una query per l'esecuzione, SQL Server controlla la cache dei piani per vedere se è possibile utilizzare un piano esistente per eseguire la query. Ogni volta che esso non viene trovata una corrispondenza, quindi analizza, consente di ottimizzare e genera un piano per la query inviata. Si tratta di un processo intensivo della CPU.
Inoltre, ogni volta che questa operazione viene eseguita, SQL Server acquisisce latch sulla cache dei piani per proteggere l'area pertinente della memoria da altri aggiornamenti. Le query di SQL Server più ad hoc, con parametri non intendono più piani di utilizzo singolo nella cache. Ciò si traduce per l'aumento del consumo di risorse della CPU e serrature incorporante durante l'analisi. Il risultato finale possibile in un sistema non ridimensionabile. Le query SQL ben promuoverà il riutilizzo del piano ("analizzare una sola volta, utilizzare più volte") nella misura del possibile.
Progettazione con il tempo presente
In definitiva, se il carico di lavoro è costituito da query progettazione inadeguata, si verificheranno inutili operazioni dei / O. Il sovraccarico della CPU e memoria verrà mostrerà scarse prestazioni e tempi di esecuzione risulterà lente. La situazione otterrà peggio man mano che aumenta il numero di utenti. Le richieste saranno costretti a attendono l'accesso alle risorse condivise che monopolizzano le query progettate in modo non corretto.
Al contrario, se è possibile ridurre al minimo il numero di singole istruzioni SQL che sono necessari per eseguire un determinato processo, quindi è anche possibile ridurre il lavoro svolto da ciascuna di queste singole istruzioni SQL. Si è molto più probabile che dispone di un sistema di SQL Server veloce e reattivo, scalerà normalmente come il numero di utenti e aumenta il carico di lavoro globale.
Un approccio utilizzato spesso per l'ottimizzazione delle prestazioni consiste nel recuperare un elenco di "Top 10" delle query più lente che costituisce parte del carico di lavoro normale, ogni giorno sull'istanza di SQL Server e quindi ottimizzare, uno alla volta. Traccia verso il basso le sessioni, le richieste e le query all'interno dell'infrastruttura di SQL Server che sono il più intensivo delle risorse e i tempi di esecuzione.
Un approccio più scientifico potrebbe avviare ai livelli inferiori, alla ricerca di aree specifiche in cui SQL Server sta riscontrando intensivo delle risorse. Controllo per determinare dove sono in attesa processi insolitamente lunghi tempi per un'altra operazione da completare prima di procedere. In questo modo, è possibile scoprire se il componente principale del tempo di esecuzione lento è tempo di CPU (se il sistema è legato alla CPU) o tempo esaurito in attesa dei / O (se il sistema è associate ai / O) e così via.
È possibile lavorare nuovamente da tale posizione per le richieste che causano il conflitto di risorse. Avente isolato le query del problema, è possibile trovare quindi un modo per ridurre la quantità di lavoro in corso. Questa operazione richiede la regolazione del istruzioni SQL e le query o l'aggiunta di indici. Se nessuna di queste soluzioni non riesce, è possibile aumentare la capacità dal potere di ulteriori dischi/memoria/CPU.
.png)
.png)
.png)
Glenn bacchefunziona come un architetto di database a tecnologie NewsGator in Denver, Colo. Egli è un MVP di SQL Server e si dispone di un intero insieme delle certificazioni Microsoft, tra cui MCITP, MCDBA, MCSE, MCSD, MCAD e MCTS, che dimostra che assegnandogli sostenere test.
**Louis Davidson**è stato nel settore IT per 16 anni come database aziendale, sviluppatore e architetto. Egli è stato un MVP di SQL Server per sei anni e ha scritto quattro libri sulla progettazione di database. Egli è attualmente architetto di dati e a volte DBA per cognome la trasmissione di rete, gli uffici di supporto in Virginia Beach responsabile e Nashville, Tenn.
**Timothy Ford**è un MVP di SQL Server e ha lavorato con SQL Server per più di 10 anni. È l'amministratore del database primario ed esperto per la piattaforma di SQL Server per la salute di spettro. Egli è stato scrittura sulla tecnologia dal 2007 per una vasta gamma di siti Web e si mantiene il proprio blog al thesqlagentman.com, che coprono SQL come argomenti di sviluppo ben come telecommuting e professionale.
Per ulteriori informazioni su "SQL Server DMV Starter Pack" nel red-gate.com/our-company/about/book-store.