Share via

SQL Q & A: Come mantenere i dati gestibili

  • Articolo

Questo mese, il nostro autore della rubrica su SQL Server aiuta i lettori ad analizzare diverse tipologie di dati, sviluppare una strategia e gestire i dati con i gruppi di file.

Paul S. Randal

Numeri non mentono

D. Sto tentando di misurare la latenza di I/O di alcuni dei nostri database e sto ottenendo risultati diversi dalle viste a gestione dinamica (DMV) e i contatori di Performance Monitor. Si può spiegare perché questi numeri non sono la stessa cosa?

R. Questi due metodi utilizzano il DM io_virtual_file_stats DMV (vedere il mio blog post per ulteriori informazioni sull'utilizzo che) e i media. Disk sec/Read e AVG. Contatori disco sec/Write dell'oggetto disco fisico in Performance Monitor. È interamente possibile che si potrebbero vedere risultati diversi tra i due meccanismi.

Il DMV misure il cumulativo read e write stallo tempo o latenza. Lo fa per ogni file in ogni database poiché il database è stato portato in linea (solitamente dall'ultimo riavvio dell'istanza del SQL Server ). Dividere quelli totali per il numero di letture e scritture per ottenere la media di lettura e scrittura I/O tempi di latenza. Queste medie sono per tutto il periodo di tempo da quando è interrogato prima del DMV indietro a quando il database in questione è stato portato in linea.

I contatori di Performance Monitor sono una media mobile per un piccolo periodo di tempo. Questi due posti grande blog, "Windows Performance Monitor disco contatori spiegato," e "misura latenza del disco con Windows Performance Monitor (Perfmon)," da Windows Server Core team di spiegare più in dettaglio. Si ottiene ciò che equivale a una visualizzazione istantanea del disco di leggere e scrivere le latenze. Come si può vedere, questi due metodi per misurare la latenza sono abbastanza diversi, che può portare a risultati diversi.

Il DMV misura solo la latenza dei file di database SQL Server . Performance Monitor è misurare tutti gli / o su quel volume. In un ambiente di storage condiviso, questo potrebbe significare un sacco di altri non -SQL Server file che contribuiscono per il / o caricare sul volume. Questo potrebbe fare la media bassa per quanto riguarda le Performance Monitor è interessato da un sacco dei / o di misura attraverso un sacco di file. La media da DMV potrebbe essere maggiore perché sta misurando un minor numero dei / o attraverso un minor numero di file.

Per gli stessi motivi, potrebbe essere scarso rendimento per qualche tempo sul volume, ma non i/o SQL Server nel processo. I contatori di Performance Monitor rifletterebbe le scarse prestazioni. Come il DMV è solo misurando i/o SQL Server , i risultati DMV non sono colpiti da quel periodo di scarse prestazioni.

Ricordo anche il DMV raccoglie dati aggregati. Se c'è un periodo di scarso rendimento con solo il SQL Server SQL\/o che si verificano, i risultati DMV ne risentiranno dei / o scarsamente performanti, anche dopo che la performance migliora ancora. I contatori di Performance Monitor rifletterà latenze elevate durante il periodo di scarse prestazioni, quindi basse latenze quando migliorano le prestazioni.

Come si può vedere, per rendere il senso dei valori diversi, è necessario considerare che cosa stai effettivamente misurare. Purtroppo, non non c'è alcun modo per azzerare i contatori DMV senza momentaneamente disconnettere il database desiderato.

HA per tutti

D. Mi è stato chiesto di lavorare su una nuova strategia di alta disponibilità (HA) per i nostri server SQL. Sto cercando qualche indicazione di che cosa da considerare e dove cominciare. Può offrire qualche consiglio?

**R.**Uno dei problemi è capire che HA la tecnologia da utilizzare quando si progetta la tua strategia. Spesso, una società andrà con la tecnologia incombente solo perché è già in atto. Peggio, l'azienda può fare una scelta arbitraria di tecnologia in assenza di requisiti chiari.

Per progettare la strategia HA corretta, è necessario raccogliere e analizzare le vostre esigenze. Senza questo passaggio fondamentale, non avete alcuna speranza di soddisfare le esigenze di business con la tua strategia. Per ogni porzione di dati a cui si applica la strategia HA, hai bisogno di risposte alle seguenti domande:

  1. Quanto sono importante questo dati rispetto a tutto il resto? Affermando che tutto ciò che è prioritario e deve essere protetta ugualmente funziona con una piccola quantità di dati, ma diventa sempre più impraticabile con più terabyte si sviluppa su più istanze del SQL Server .
  2. Quanti dati business può permettersi di perdere? I proprietari di imprese comprensibilmente piacerebbe vedere zero perdita di dati.
  3. Quanto tempo possono essere non disponibili i dati? Imprenditori piacciono anche vedere zero downtime. Anche se è possibile ottenere vicino, purtroppo non è realizzabile nella realtà.
  4. Elementi no. 1 o n. 2 modificare in vari momenti della giornata o durante il fine settimana? Questo può avere un effetto profondo sulla vostra capacità di soddisfare i requisiti. Zero tempi di inattività e perdita di dati sono molto più realizzabile per un periodo limitato, diciamo, 9 a 17 nei giorni feriali, rispetto al 24 x 365.
  5. È accettabile per compromettere le prestazioni del carico di lavoro per preservare la durata e la disponibilità dei dati? Le tecnologie sola che possono fornire zero perdita di dati necessitano di mirroring sincrono di record del log delle transazioni (mirroring del database o gruppi di disponibilità del SQL Server 2012) o I/O sottosistema scrive (replica di SAN). Entrambi questi possono portare a un ritardo di elaborazione, ma è un compromesso.
  6. La copia secondaria dei dati deve essere leggibile o scrivibile?

Una volta che sei di fronte a questi requisiti, è possibile lavorare attraverso le limitazioni imposte dall'azienda e quindi compromettere. È importante rendersi conto delle limitazioni che stai lavorando all'interno possono significare che non può soddisfare tutti i requisiti. In tal caso, si e i dirigenti dovranno accettare un compromesso. Altrimenti qualsiasi strategia HA che progettazione non ha intenzione di soddisfare le aspettative. È ancora più probabile che la soluzione sarà composta da tecnologie multiple, così conoscendo i limiti di ciascuno, così come essi lavorano insieme, sarà fondamentale per il vostro successo.

Si potrebbe affrontare qualsiasi delle seguenti limitazioni:

  • Preventivo
  • Potenza elettrica disponibile
  • Spazio fisico per nuovi server, rack e impianti d'aria condizionata
  • Personale — non c'è nessuno disponibile a gestire i nuovi sistemi o nessuno attualmente ha le competenze per implementare e gestire le nuove tecnologie necessarie

Ci sono descrizioni approfondite delle tecnologie e strategici negli esempi di queste due white paper:

Sebbene questi white paper sono stati scritti per SQL Server 2008/2008 R2, è tutto ciò che in essi ancora valida. Verificate anche il white paper "AlwaysOn Architecture Guide: Costruzione di una disponibilità elevata e della soluzione di Disaster Recovery da utilizzando AlwaysOn Availability Groups, "per le più recenti tecnologie SQL Server 2012.

Gruppo

D. Mi è stato detto da alcuni dei miei colleghi che devo essere utilizzando filegroup per nuovi database invece di un file di dati singolo. Si può spiegare alcuni dei vantaggi e svantaggi di farlo?

**R.**Non posso pensare ad eventuali svantaggi dell'utilizzo di filegroup, tranne forse andando troppo lontano e utilizzando centinaia di loro. Per quanto riguarda i benefici vanno, più filegroup cominciano a diventare necessari come il vostro database diventati più grandi (più di 50GB - 100GB). Ancora, ci sono tre ragioni principali per averli.

I filegroup consentono per i ripristini veloci e mirati durante un disastro. Immaginate di avere un database di 1TB, con la maggior parte dello spazio preso con una tabella vendita che contiene dati dal 2009 a oggi. Se il database è distrutta in un disastro, Qual è la più piccola quantità che è possibile ripristinare? Se è tutto in un filegroup non ci sono tutte le opzioni, è necessario ripristinare l'intero 1TB, compresi tutti i dati più vecchi.

Un approccio migliore per il disaster recovery è se avete filegroup separati: primaria, 2009, 2010, 2011, 2012 e 2013. In caso di emergenza, si desidera i dati 2013 per essere on-line velocemente come possibile. Che è quello che sostiene il vostro sistema di vendita Online Transaction Processing (OLTP). Finchè avete SQL Server Enterprise edition, è possibile sfruttare la disponibilità parziale del database e iniziare questo processo ripristinando il filegroup primario utilizzando la sintassi con parziale. Quindi è possibile ripristinare altri filegroup che volete subito online. Poi si può finire la sequenza di ripristino.

È possibile ripristinare altri filegroup online e a vostro piacimento. Ora stai sfruttando un'altra funzionalità di Enterprise edition chiamata "ripristino online." Questa è una combinazione di caratteristiche per i database di grandi dimensioni (VLDB). Queste caratteristiche riducono i tempi di inattività e ti danno un sacco di flessibilità quando si tratta di priorità la sequenza di ripristino durante un disastro. Significa anche che è possibile eseguire un ripristino se solo una parte del database è danneggiata per qualche motivo. Questo limita ulteriori requisiti di tempo di inattività in caso di emergenza.

Il secondo motivo per utilizzare filegroup è di supportano il partizionamento e migliore gestibilità. Partizionamento consente facilmente caricare e cancellare i dati da una tabella di grandi dimensioni molto rapidamente, senza generare un sacco di log delle transazioni. Pienamente spiegare i vantaggi di partizionamento è oltre la portata di questa colonna, ma il seguente white paper fare un grande lavoro, utilizzando gli scenari diversi esempio:

Un'altra funzionalità di gestibilità si occupa di frammentazione. Utilizzando lo stesso esempio di tabella sales come prima, se avete gli indici della tabella sales frammentato e la tabella e gli indici non sono partizionati, poi l'ALTER INDEX... RICOSTRUIRE o RIORGANIZZARE i comandi dovrà operare sull'intero indice di essere deframmentato. Questo è vero anche se i dati più vecchi non frammentati. Se si hai diviso il tavolo in più partizioni, ognuna in un filegroup separato, è possibile deframmentare solo le partizioni degli indici che sono frammentati. Questo fa risparmiare un sacco di tempo e risorse.

Ultima, filegroup consentono di isolare i diversi carichi di lavoro all'interno del database su diverse porzioni del sottosistema dei / o. Per esempio, immaginate di avere alcune tabelle leggermente usati e alcuni che sono pesantemente usato e aggiornato. Se tutto è in un filegroup, si possono trovare che le prestazioni operative sui tavoli leggermente usati sono compromessa a causa di operazioni sulle tabelle aggiornate di frequente.

In tal caso, si potrebbero separare le tabelle leggermente usate in un filegroup sulla propria porzione del sottosistema dei / o. Quindi memorizzare ciascuna delle tabelle pesantemente usate e aggiornate in filegroup separati. Hanno ciascuno la propria parte del sottosistema dei / o. Questo separa il carico dei / o, quindi i carichi di lavoro non interferisca con l'altro.

Inoltre potrebbe essere necessario fare questo all'interno di una singola tabella, se c'è un carico di lavoro OLTP su dati più recenti (per esempio, in una tabella vendita, come discusso in precedenza) e un carico di lavoro di magazzino dati sui dati più vecchi. Questo è un caso dove sarà necessario partizionare e diversi carichi di lavoro saranno rinchiusi per separare le partizioni della tabella su filegroup separati — separare nuovamente i carichi di lavoro da altro.

Paul S. Randal

Paul S. Randal è l'amministratore delegato di SQLskills.com, Microsoft regional director e un SQL Server MVP. Ha lavorato su team SQL Server di Storage Engine di Microsoft 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. Blog di lui a SQLskills.com/blogs/paul, e lo si può trovare su Twitter a Twitter.com /PaulRandal..

Contenuti correlati