SQL Q & a: Alla ricerca delle prestazioni

  • Articolo

Riduzione del carico di lavoro e lisciando le funzioni di mirroring è sempre una buona idea, ma la compattazione dei database non è.

Paul S. Randal

Soluzione di carico di lavoro

D. Sto lavorando con un team di sviluppatori che stanno cambiando un'applicazione per utilizzare SQL Server per l'archiviazione dei dati. I dati è stato precedentemente memorizzati localmente sul computer client. Potete darmi un elenco di considerazioni per gli sviluppatori possono raggiungere l'importo minimo possibile del carico di lavoro di SQL Server?

**R.**Sforzandosi di rendere l'applicazione chiamata al livello dati appena possibile, si sta prendendo un ottimo approccio. Concentrandosi sull'applicazione è purtroppo atipico. La cosa principale da tenere a mente è di avere l'applicazione recuperare dati da SQL Server appena possibile. Quando recuperano dati, hanno solo recuperare i dati necessari come efficientemente come possibile.

Qui ci sono alcune cose per gli sviluppatori a considerare circa il modo in cui l'applicazione esegue una query dei dati di SQL Server. Prestando attenzione a questi sarà evitare inutile carico di lavoro e l'impatto negativo sulla CPU, la memoria e i/o:

  • **Elaborazione:**Per i dati che viene tirati da SQL Server, l'applicazione dovrebbe evitare l'elaborazione di una riga di dati alla volta. Questo è comunemente chiamato RBAR, o riga di agonizzante-riga, elaborazione. Qualsiasi momento che SQL Server invia i dati per l'applicazione, ha un thread in attesa per l'applicazione di riconoscere i dati inviati attraverso. Elaborazione RBAR può portare a ASYNC_NETWORK_IO attese in SQL Server. L'applicazione dovrebbe in ingresso dati localmente nella cache e rapidamente risposta a SQL Server che ha i dati.
  • **Filtraggio:**L'applicazione dovrebbe evitare di filtraggio dati localmente prima di usando o la visualizzazione dei dati. È molto più efficace per spingere il predicato del filtro fino a SQL Server e avere la minima quantità di dati restituiti all'applicazione. SQL Server è molto bravo a filtraggio dati, dati i giusti indici non cluster per supportare i predicati di filtro.
  • **One Size Fits All (One):**Ridurre al minimo la quantità di colonne della tabella viene restituito solo a quelle necessarie. Gli sviluppatori dovrebbero anche evitare cercando di costruire un dialogo "one size fits all". Utilizzando un elenco di selezione mirato anziché SELECT * sarà tagliato sulla quantità di dati elaborati e restituiti. Con meno colonne richieste, SQL Server potrebbe avere anche più modi ottimali per ottenere a questa data, che potrebbe migliorare le prestazioni.
  • **Per ordinare:**Se i dati restituiti non ha bisogno di essere ordinati con un ordine da, quindi evitare di specificare ORDER BY come questo può tagliare un'operazione di ordinamento. Le operazioni di ordinamento possono essere spesso costose perché finiscono che richiedono una costosa fuoriuscita di sorta per tempdb.
  • **Solo nel caso:**Rinviare operazioni SELECT fino a quando sono veramente necessari. Se un'applicazione è emettere una selezione nel caso in cui, l'utente fa clic su un pulsante dell'applicazione. Quindi potrebbe essere sprecata di elaborazione. È meglio aspettare fino a quando il pulsante viene premuto in realtà prima di emettere il SELECT, rimuovendo tutte le elaborazioni quando non si preme il pulsante.
  • **Considerare la memorizzazione nella cache:**Se si stanno eseguendo la query dei dati stessi ancora e ancora, nella cache locale e solo emettere un nuovo SELECT quando i dati cambiano. Questo è l'ideale quando i dati non cambiano frequentemente o se non si necessitano di dati aggiornatissimi.

Considerando questi fattori può avere un effetto profondo sulla quantità di lavoro di che SQL Server ha a che fare, soprattutto se un singolo cambiamento nella logica dell'applicazione query viene moltiplicato per centinaia o migliaia di istanze dell'applicazione in esecuzione contemporaneamente.

Chiedete al vostro team di sviluppo di applicazione per esaminare come l'applicazione sta utilizzando SQL Server. Questo potrebbe trarre grande beneficio il vostro carico di lavoro esistente. La causa principale dei problemi di prestazioni è troppo spesso considerato uguale a SQL Server, invece del modo che l'applicazione sta utilizzando SQL Server.

Specchio, specchio

D. Abbiamo usato del mirroring del database per diversi anni. Solo recentemente abbiamo avuto problemi. Abbiamo eseguito il failover e il database mirror ha preso parecchie ore a venire in linea, che era abbastanza inaspettato. Ci sono tutti i contatori delle prestazioni che noi possiamo monitorare per dire se questo si verificherà nuovamente?

**R.**Mirroring del database è diventato estremamente popolare, poiché è stata correttamente introdotta in SQL Server 2005 SP1. Tuttavia, c'è un problema pervasivo sui sistemi client. Ci sembra essere un presupposto che, non appena si implementa il mirroring del database, può tranquillamente dimenticare e si basano su di esso per funzionare perfettamente quando si verifica un errore — porterà sempre il database protetto online sul server mirror senza perdita di dati e tempi di inattività minimi.

Mentre questo potrebbe essere vero in alcuni casi, è un presupposto pericoloso. Per ridurre il potenziale per il disastro, è assolutamente essenziale per monitorare la dimensione della coda REDO sia la trasmissione di una sessione di mirroring:

  • La dimensione della coda di invio viene illustrato quanto log delle transazioni è stato generato sul server principale, ma non è stato ancora inviato al server mirror. Se non è zero, vuol dire che lo stato di mirroring non è sincronizzato e non ci può essere un failover automatico. Inoltre, la dimensione della coda di invio indica la quantità di perdita di dati che si verifica se il database principale subisce un disastro. È necessario monitorare questo per garantire la dimensione della coda di invio non superi la vostra perdita massima ammissibile dati Service Level Agreement (SLA) — o obiettivo punto di recupero (RPO) — per il database in mirroring.
  • La dimensione della coda REDO dimostra quanto log delle transazioni è presente nel database mirror non è ancora stato riprodotto sul database mirror. Ricordate, solo i record del log devono essere indurito — non riprodotti — su unità di registro del database mirror. Che è fatto come un processo in corso sul server mirror. Se si verifica un failover del mirroring, si non può accedere al database mirror fino a quando tutti i record del log delle transazioni in coda REDO sono stati riprodotti sul database mirror. Questo significa essenzialmente che un recupero crash ha di verificarsi. Più grande la coda REDO, il più un failover prenderà. Ricordate che nell'edizione Enterprise, recupero veloce entra in gioco e il database diventa disponibile dopo la fase di rollforward del ripristino è stato completato, ma prima dell'annullamento inizia la fase. È necessario monitorare questo per garantire la dimensione della coda di rollforward non superi il massimo tempo di inattività ammissibile SLA — o obiettivo del tempo di ripristino (RTO) — per il database in mirroring.

La transazione non inviata più antica è un altro modo per monitorare la quantità istantanea di perdita di dati che subirebbe in caso di emergenza database principale. Si applica in tutti i modi di mirroring del database, perché anche se si utilizza il mirroring sincrono, il principale e mirror può diventare scollegati o si potrebbe mettere in pausa il mirroring.

È possibile monitorare le invia e ripristina code utilizzando Monitoraggio Mirroring del Database in SQL Server Management Studio per impostare gli avvisi. È inoltre possibile monitorare direttamente tramite i mirroring del Database oggetto contatori perfmon Log Invia coda KB e KB coda rollforward.

Se trovi la dimensione della coda REDO in crescita, questo implica che il server mirror non può tenere il passo con la quantità di log inviati dal server principale. Potrebbe essere non c'è carico di lavoro aggiuntivo sul server mirror che impedisce il log del database mirror di riproduzione più velocemente possibile. Può anche essere che l'hardware fisico sul server mirror non è capace come che sul server principale.

Ridurla fino

D. Uno dei nostri fornitori di applicazioni è obbligo che corriamo coerenza database regolare controllo delle operazioni di (DBCC) SHRINKDATABASE contro l'applicazione database e tempdb. Il venditore insiste che questo è necessario per mantenere la corretta esecuzione. Potete darmi qualche consiglio?

**R.**Questa questione si presenta piuttosto regolarmente. Un fornitore dell'applicazione possa rifiutare di farvi rimuovere shrink regolari operazioni perché essi sono considerati "necessari per le prestazioni". Compattazione database causa la frammentazione dell'indice, consuma un sacco di risorse di CPU e i/o. Genera anche un sacco di log delle transazioni. Questo può causare problemi per il mirroring del database, AlwaysOn Availability Groups, replica e tutto ciò che ha a spedire i record del log intorno. Ci sono alcune circostanze, tuttavia, dove sono necessarie operazioni una tantum strizzacervelli.

Database non dovrebbero mai essere regolarmente ristretto. Regolarmente compattazione database è una brutta cosa fare perché se il database cresce più volte dopo essere compattato, tutti che si restringono lavoro è sforzo completamente sprecato. È simile ad avere la compattazione automatica abilitata per il database.

Molte squadre di fornitore di applicazioni non sanno che queste cose di restringersi. Questo è spesso perché hai fatto il porting dell'applicazione da un altro sistema di database e sono restio ad ascoltare qualcuno cercando di educarli sul funzionamento di SQL Server.

Occasionalmente potrai ottenere coinvolto con un client e l'applicazione fornitore team. Le giustificazioni dal team di fornitore di applicazione sono di solito lungo le linee delle seguenti (parafrasando):

  • Gli indici nel database sono già frammentati, così il restringimento non rende peggio.
  • Nessuno mai lamentato delle prestazioni prima, così perché sei?
  • Dobbiamo avere un regolare shrink perché le operazioni ci causano il database espandere un sacco e i clienti vogliono il loro spazio su disco indietro.
  • Dobbiamo Riduci tempdb perché le operazioni causano a crescere continuamente.

Nessuno di questi sono validi motivi per la compattazione di database regolarmente. Infatti, è documentato articolo KB 307487 che restringimento tempdb quando c'è l'attività dell'utente può portare alla corruzione del database tempdb. Inoltre, il "lavorando con Tempdb in SQL Server 2005" white paper (applicabile a tutte le versioni) afferma che: "Shrinking file non è una pratica consigliata".

Ogni volta che un venditore afferma restringimento è necessario, viene illustrato come sia un malinteso fondamentale di come si dovrebbe gestire SQL Server o un deficit nel comportamento dell'applicazione coperto attraverso il restringimento regolare. Il modo migliore per coinvolgere con fornitori che mandato regolare restringimento è a punto li all'articolo della KB di Microsoft o carta bianca. Quindi non sostengono che essi stanno aderendo alla procedure consigliate Microsoft.

Purtroppo, non non c'è alcun modo per prevenire le operazioni di compattazione, se essi sono vendor-mandati. Eliminando l'operazione di compattazione sarebbe annullare un contratto di assistenza. La cosa migliore che potreste fare è avere un processo SQL Server Agent che esegue ogni 15 secondi alla ricerca di connessioni che sono compattazione database e poi ucciderli. Uccisione di un'operazione di compattazione non causerà danneggiamento o altri problemi. Questo approccio potrebbe aiutarti a rimanere all'interno dell'accordo di sostegno, evitando anche i problemi di prestazioni sul server di produzione.

Paul S. Randal

Paul S. Randal è l'amministratore delegato di SQLskills.com, un direttore regionale Microsoft e MVP per SQL Server. Ha lavorato il team di Microsoft SQL Server Storage Engine dal 1999 al 2007. Egli ha scritto il comando DBCC CHECKDB/repair per SQL Server 2005 ed era responsabile di Core Storage Engine durante lo sviluppo di SQL Server 2008. Randal è un esperto di disaster recovery, alta disponibilità e manutenzione del database ed è un presentatore regolarmente a conferenze in tutto il mondo. Ha Blog at SQLskills.com/blogs/paul, e lo si può trovare su Twitter a Twitter.com /PaulRandal..

Contenuti correlati