Configurazione ottimale dell'unità per SQL Server 2008R2

19

Ho un server di database piuttosto impegnato che esegue SQL Server 2008 R2 con la seguente configurazione:

SATA RAID 1 (2 Drives) - Sistema operativo / Programmi
SAS RAID 10 (4 unità) - File di database SQL (dati e registri)
SAS RAID 1 (2 unità) - TempDB (dati e registri)

Supponendo che non sia possibile aggiungere ulteriori unità in questo server, ho fatto il miglior uso della configurazione che ho a disposizione? O dovrei prendere in considerazione un altro schema in cui i log sono isolati dai file di dati, ad esempio?

Aggiornare:

Per quelli che hanno richiesto ulteriori dettagli hardware:

Le unità SATA (utilizzate per la partizione del sistema operativo /) sono: WD 7200 RPM 3 Gb / s 3,5 pollici SATA
Le unità SAS utilizzate negli altri array sono: Seagate 15K RPM 6 Gb / s SAS da 3,5 pollici
Il controller RAID utilizzato è: una porta LSI 9260-8i SAS / SATA 6 Gb 8

Aggiornamento 2:

Sulla base del feedback che ho ricevuto, sembra che ho le seguenti opzioni possibili tra cui scegliere: assegnerò la generosità a qualcuno che può dirmi quale è probabilmente il migliore nell'ambiente che ho delineato:

Lascia tutto com'è - probabilmente non farò molto meglio
Sposta le mie 2 unità SAS RAID 1 nel mio array RAID 10 esistente per avere in totale 6 dischi
Sposta i miei file di registro su SAS RAID 1 e / o riposiziona TempDB (dati o registri) su RAID 10

sql-server hardware

— DanP
fonte

Il tuo secondo aggiornamento sta ponendo esattamente le stesse domande della domanda originale, quindi si applica la risposta originale. "... che è probabilmente il migliore nell'ambiente che ho delineato" ... non ci hai mostrato alcuna analisi del carico di lavoro, solo che è "abbastanza occupato", quindi si applica la stessa risposta .

— Mark Storey-Smith,

Con NVMe ad alte prestazioni e altri dischi SSD sul mercato, il RAID non è più molto importante dal punto di vista delle best practice per la configurazione del disco del server SQL . I pool di dischi (spazi di archiviazione) sono la strada da percorrere. Tuttavia, è necessario separare logicamente i volumi per risolvere meglio i problemi di prestazioni relativi al disco.

— Faces Of IT

14

Varianti di questa domanda si presentano semi-regolarmente:

Ci sono anche battaglie occasionali sulla "migliore pratica" di separazione dei dati / log.

Senza un'analisi più dettagliata di ciò che questo server sta facendo, si applicano gli stessi consigli forniti in precedenza.

RAID 1 per sistema operativo
RAID 10 (6 dischi) per dati / registri / tempdb

Raramente c'è un punto in una divisione con così pochi mandrini disponibili. Un singolo array con una capacità IOP maggiore assorbirà in genere i grumi e gli urti del carico di lavoro meglio di 2 array più piccoli.

Una variante che può valere la pena testare è mettere tempdb sull'unità del sistema operativo. Fallo solo se disponi di un carico di lavoro rappresentativo che puoi riprodurre ripetutamente, per garantire un confronto equo della configurazione. Se scegli questo accordo durante la produzione, assicurati che la crescita di tempdb sia limitata in modo da non consumare inavvertitamente tutto lo spazio libero sull'unità del sistema operativo.

Dato che le tue unità OS sono sottobicchieri a 7200 giri / min, sarei sorpreso se il tempdb sull'unità OS configurasse qualche vantaggio.

— Mark Storey-Smith
fonte

7

Tutto dipende dal carico di lavoro, ma con solo 6 unità limita le tue opzioni. Se il tuo carico di lavoro non dipende fortemente da tempdb per cose come ordinamenti, tabelle hash e isolamento di istantanee, allora potresti essere meglio usando le 6 unità SAS insieme in RAID 10. Tuttavia, se conosci o hai le metriche per dimostrare che tempdb è molto utilizzato, quindi dovresti tenerlo separato come hai fatto.

— Patrick Keisler
fonte

Grazie per la risposta, cambiare la configurazione degli intervalli non è (purtroppo) un'opzione poiché questo server è in produzione. Sono curioso di tornare al tempdb su RAID 10 e di mettere tutti i file di registro su RAID 1: è un'opzione intelligente?

— DanP

2

Ricorda che SQL Server deve scrivere fisicamente tutte le transazioni nel registro come parte del commit, in modo da ottenere le prestazioni di scrittura più veloci possibili nella configurazione. RAID 10 offre prestazioni di scrittura migliori rispetto a RAID 1, quindi lascerei i registri sul volume più veloce.

— Patrick Keisler,

2

Dipende molto da cosa intendi per "molto occupato": diversi schemi di carico di lavoro (scrivere pesante o no, operazioni di massa comuni o meno, livello di accesso simultaneo, per citare solo tre delle molte variabili) possono avere un effetto drastico sul prestazioni di ogni disposizione del mandrino.

Per una situazione pesante di scrittura che separa i registri dai dati può fare una differenza significativa poiché ogni scrittura comporta l'aggiornamento sia del registro che dei file di dati, quindi comporta una discreta quantità di testina aggiuntiva se entrambi i set di file si trovano sullo stesso set di mandrini .

Senza ulteriori riferimenti al carico di lavoro (e alle specifiche di tali unità e di qualsiasi controller tra loro e la macchina) sarei propenso a scegliere tre volumi: uno per i programmi OS + e tempdb (dati), uno per il DB principale dati e il terzo per i log (sia tempdb che DB principali).

Ovviamente se i tuoi carichi di lavoro sono molto leggeri nelle operazioni di scrittura, non dovresti spendere troppo tempo a preoccuparti di mantenere separati dati e registri, poiché farebbe poca differenza in termini di prestazioni e dedicare un intero volume per loro sarebbe piuttosto dispendioso spazio.

— David Spillett
fonte

Descriverei sicuramente il nostro ambiente come "pesante" - aggiornerò la mia domanda con specifiche hardware più dettagliate lunedì.

— DanP

Qualche idea sul numero di unità che OP ha? Sto pensando di più al Raid 1 che ha per i file di registro. Non sembra un'ottima opzione per scopi di scrittura e i file di registro AFAIK non sono limitati alla lettura, ma scrivono ..

— Marian

Ho aggiunto ulteriori specifiche sull'hardware della macchina.

— DanP

1

Questo fraintendimento può essere alla radice di molti dei discorsi sulla separazione dei dati / dei registri, quindi mi scuso ma lo chiamerò. "... poiché ogni scrittura implica l'aggiornamento sia del registro che dei file di dati" - no, non è così. Le scritture nelle pagine di dati si verificano sul checkpoint, non su ogni modifica.

— Mark Storey-Smith,

1

@DavidSpillett Vero, ci saranno sempre casi in cui la divisione è vantaggiosa. La chiave è che hai testato e convalidato che la configurazione era utile per quel particolare carico di lavoro.

— Mark Storey-Smith,

2

La risposta effettiva dipende dalle tue esigenze, ma in genere "metti i dati e accedi a matrici diverse" è di importanza maggiore rispetto a "metti tempdb sul suo array".

Dato il numero di unità disponibili, il mio punto di partenza sarebbe:

Due unità, RAID 1 - Sistema operativo, file eseguibili, file di paging.
Quattro unità, RAID 5 - Tutti i file di dati (in alternativa, RAID 1 + 0)
Due unità, RAID 1: tutti i file di registro

Quello che dovrebbe fare è utilizzare SQLIO per testare le prestazioni di diverse configurazioni di unità.

— Greenstone Walker
fonte

Questo rappresenta sicuramente "l'altro lato" del consiglio che ho letto. Vorrei che ci fosse un metodo definitivo per determinare quale delle opzioni sarebbe meglio senza ricorrere a "provarlo" in un ambiente di produzione.

— DanP

2

@DanP Beh, personalmente avrei seguito il consiglio di Mark e avrei scelto un RAID10 con il resto delle unità (tranne il sistema operativo). I file di registro sono ad alta intensità di scrittura e richiedono prestazioni migliori rispetto a ciò che RAID 1 ha da offrire, per quanto ci penso. Ma non sono un esperto di hardware. Solo i miei 2 centesimi.

— Marian

2

Devo dire che la mia opinione proviene solo dall'esperienza di una passata (tipo di) migrazione fallita verso un server migliore, ma con prestazioni peggiori. Non abbiamo mai testato un carico reale su questo nuovo server, non abbiamo mai avuto possibilità, il server non era pronto in tempo. Risulta che il test del server PRIMA di migrare alla produzione dovrebbe essere OBBLIGATORIO. Scusate l'enfasi. Quindi il mio mantra per tutte le migrazioni / aggiornamenti è: TEST, TEST, TEST, ... test di impazzire il più possibile.

— Marian

1

Non sono sicuro se iniziare con RAID 5 o SQLIOSIM ... andiamo avanti con il successivo, poiché il primo parla da solo. SQLIOSIM è uno strumento di correttezza e stress test , non è uno strumento di test delle prestazioni o del carico. Non ha assolutamente spazio nel confrontare le prestazioni di config-X vs config-Y per workload-Z. Tutto ciò che ti dirà è quanto bene config-X si esibisce contro config-Y in una corsa SQLIOSIM. Se si desidera confrontare le prestazioni per workload-Z, provare workload-Z.

— Mark Storey-Smith,

1

@GreenstoneWalker "RAID1 è più veloce per la scrittura di RAID1 + 0" non ha senso. Da dove è venuta questa idea?

— Mark Storey-Smith,

-1

A seconda di cosa stai usando il DB per (OLTP vs warehousing) la tua configurazione sembra una buona configurazione generale. Se avessi più dischi, avresti più opzioni.

È possibile ottenere prestazioni migliori se si passa il disco per TempDB a RAID 0 (stripe). Aumenta il rischio di errori, ma poiché TempDB memorizza solo i dati nel buffer, non è possibile riscontrare la perdita di dati. Quindi la maggior parte delle persone lo considera un ragionevole compromesso. Tieni solo una scorta (o una riserva).

Una cosa che non hai menzionato, ma che potresti provare (se non l'hai già fatto): Microsoft consiglia di suddividere TempDB su più file (uno per CPU). Naturalmente, è meglio se si trovano su dischi separati, ma semplicemente avere file separati aiuta. http://msdn.microsoft.com/en-us/library/ms175527(v=SQL.105).aspx

— TIMG
fonte

4

Tempdb viene utilizzato per molte cose, ma non trattarlo come un database usa e getta e posizionarlo su un RAID 0. Tenere presente che se il volume RAID 0 fallisce, SQL Server non sarà in grado di avviarsi.

— Patrick Keisler,

Ho effettivamente creato un db temporaneo per core come suggerito, ma grazie per aver sollevato anche questo punto :)

— DanP

1

Bene, questi suggerimenti non sono molto buoni e non sono appropriati per ogni ambiente. Il primo è menzionato da @PatrickKeisler in precedenza. Il secondo è un mito che Paul Randal ha sfatato qualche tempo fa. L'articolo è questo: un mito DBA di SQL Server al giorno: (12/30) tempdb dovrebbe sempre avere un file di dati per core del processore . Quindi la documentazione MS può essere sbagliata, non prenderla a memoria.

— Mariano

2

"dal momento che TempDB buffer solo i dati, non si può verificare la perdita di dati" ... e sono sicuro che gli utenti del sistema apprezzeranno il fatto che durante le X ore di inattività subiscono mentre a) le operazioni di scavo nel seminterrato per un disco sostitutivo oppure b) un DBA tenta di spiegare all'helpdesk come spostare tempdb dal suo telefono cellulare.

— Mark Storey-Smith,