Esiste un gruppo che concorda sul fatto che su un HDD sarebbe utile separarsi, affermano comunque che per le unità SSD questo non è più necessario.
Quindi per loro voglio chiedere "se non c'è nessun problema di contesa, allora perché un RAID 10? Non c'è più bisogno di stripping! Quindi solo il mirrowing sarebbe abbastanza, e ovviamente non c'è bisogno di 8 unità, 2x il database le dimensioni dovrebbero bastare! ".
Tuttavia la realtà è che se qualcosa ha bisogno di un RAID 10 è il file di registro!
Questo non è solo a causa del problema del sequenziale vs casuale (vedi risorse sotto), ma in realtà è molto cruciale una volta capito come funzionano le unità SSD.
Per farla breve (per una descrizione più lunga, consultare
http://arstechnica.com/information-technology/2012/06/inside-the-ssd-revolution-how-solid-state-disks-really-work/ ), un'unità SSD è molto efficace nelle letture e nella scrittura degli zeri, tuttavia per scriverne uno non è così efficiente in quanto deve cancellare l'intera sezione per scriverne anche una sola!
Sebbene questo non sia un problema per le scritture generali, poiché sono comunque bufferate in memoria e scritte nei limiti della pagina, è un grosso problema per il file di registro, poiché il file di registro ignora qualsiasi cache e invece blocca il server SQL fino a quando il i log sono scritti su disco !, il che significa che per ogni scrittura probabilmente ci sarà una cancellazione completa della sezione.
Quindi per ottimizzarlo, suggerirei di dedicare ogni disco aggiuntivo (oltre al doppio della dimensione del database, senza necessità di stripping!) Per il file di registro, in questo modo sarà in grado di elaborarne il maggior numero possibile in un arco di tempo più breve.
RISPOSTA VECCHIA
La risposta è sì, per tre motivi. 1) Casuale vs sequenziale - Mentre è chiaro che SSD ha aumentato drasticamente le prestazioni per le scritture casuali, rimane ancora il problema dei resti casuali vs sequenziali, come si può vedere dai seguenti whitepapaer e collegamenti:
2) Affidabilità - Esiste una forte probabilità che tutte le unità SSD si guastino simultaneamente, nel qual caso RAID non è una protezione, tuttavia poiché un'unità SSD utilizzata esclusivamente per sequenziali ha una durata diversa, questo potrebbe essere il tuo salvagente
3) Contestazione di scrittura: il motivo per cui i log vengono inseriti nel proprio mandrino non è solo a causa di una sequenza casuale o sequenziale, ma anche di una contesa di scrittura, come si può vedere dal fatto che si consiglia anche di avere tempdb su un volume separato che indica che il problema qui riguarda anche la contesa scritta.
E questo dovrebbe valere ancora di più per il file di registro, poiché le scritture sui blocchi di registro bloccano le transazioni da considerarle sottoposte a commit fino a quando non vengono scritte sulla superficie del disco.
In effetti, per i registri è possibile utilizzare le normali unità HDD come white paper di apr Dell all'indirizzo http://www.dell.com/downloads/global/products/pvaul/en/ssd_vs_hdd_price_and_performance_study.pdf
MODIFICARE
Mettere tempdb sul proprio array per girare i dischi è raccomandato da Microsoft, vedi
e numerosi altri ed è l'idea generalmente accettata in SQL Server, mentre nessuno ha espresso problemi con la divisione dell'array.
Inoltre, il team di SQL Server ha creato i concetti di partizionamento filegroup e partioining, con la sola intenzione di spostarli su un array separato.
E in effetti MSDN all'indirizzo http://msdn.microsoft.com/en-us/library/ms187087(v=sql.105) raccomanda che ci potrebbe essere un vantaggio in termini di prestazioni dalla separazione dell'indice non cluster sul proprio array, (sebbene questo non dovrebbe essere preso come un consiglio generale per ogni situazione, solo per carichi di lavoro specifici, vedere maggiori informazioni su http://weblogs.sqlteam.com/dang/archive/2008/08/01/Are-you-a-DBA -Monkey.aspx ).
In quanto tale, è solo un'estensione logica per dire che il motivo della separazione sui dischi rotanti non è solo legato al problema delle letture sequenziali e casuali, ma alla contesa di scrittura generale, qualcosa che si applica anche agli SSD.
Anche se è possibile che alcune persone non siano d'accordo con quel consiglio e considerino che non vi è alcun vantaggio nel mettere tempdb e il suo volume (come Jack Douglas), e potresti persino affermare che non vi è alcun vantaggio nel separare i file di registro (come Mark Storey -Smith), e invece sostengono che la divisione dell'array è molto peggio, ancora non dimenticare che si tratta di un nuovo approccio che va contro l'approccio generale accettato suggerito da Microsoft e dalla community, e finora nessuno ha fornito collegamenti a test benchmark per supportarlo.
Quindi la mia parola a tutti i downvoter è che trovo molto poco etico sottovalutare un post solo perché ha un'opinione diversa dalla tua, specialmente quando 1) la tua opinione va contro la teoria generale accettata 2) ed è contro i venditori (Microsoft ) possiede la documentazione 3) e non hai fornito alcuna prova solo un parere.
Ma in questo caso è ancora più ridicolo, dal momento che il mio post non è altro che l'estensione logica di questa teoria, quindi uno che considera questo post come consiglio di letto deve ovviamente tornare a tutti i post che consigliano questa teoria e li votano .
Supponiamo che qualcuno decida che il RAID è una teoria della vecchia scuola e declassa tutti i post che lo raccomandano, che senso ha?