Posizionamento ottimale di file tempdb, mdf e ldf in SQL Server 2012 su SSD?


9

Mi rendo conto che questa è probabilmente una domanda a risposta aperta e le risposte potrebbero variare, ma qual è il posizionamento ottimale per i file tempdb, mdf e ldf in SQL Server 2012 quando si parla di SSD?

Pre-nuovo acquisto, avevo un SSD esistente con i file core e tempdb di SQL Server 2012 installati e avevo sia il mdf / ldf su un HDD a 7200rpm. Ho quindi acquistato 2 SSD con l'intenzione originale di mettere mdf su uno e ldf sull'altro.

Ma, leggendolo di più, i dischi fisici separati per i file mdf e ldf non si applicano veramente quando si tratta di SSD. Corretta?

Quindi, stavo pensando a quanto segue:

SSD 1 - SQL Server 2012 Core Files e Windows
SSD 2 - tempdb
SSD 3 - mdf e ldf

Se fa la differenza, questo sarà dedicato a un solo database, quindi non ci sarà contesa tra più database.

La mia configurazione "pensante" è buona o semplicemente uno spreco (cioè nessun motivo per separare tempdb) in cui ora ho un SSD extra da utilizzare altrove?


2
La tolleranza agli errori è un'opzione per la configurazione? Se il database è importante, le unità mdf e ldf devono essere archiviate su unità separate con tolleranza agli errori (ad es. Mirroring).
datagod

3
Un potenziale problema che vedo nella tua configurazione è che non hai tenuto conto di un singolo guasto dell'unità. Se hai solo tre SSD con cui lavorare, consiglierei di prendere in considerazione un array RAID5 e di posizionare tutti i file relativi a SQL Server su quell'array.
Matt M

2
Si tratta di un server di livello di produzione o ti interessa se si guasta in caso di guasto di un'unità?
Jon Seigel,

1
Ho dimenticato di menzionare quel pezzo: la tolleranza agli errori non è un problema poiché il backup dei dati è completo, di notte, ma sono per lo più dati statici che posso facilmente sostituire anche se i backup non erano un'opzione. Gli unici dati dinamici sono principalmente la registrazione / il controllo che non ha dipendenze. Qualsiasi piccola interruzione del servizio che avrei dovuto tagliare manualmente su un backup è tollerabile.
Kevin,

Apprezzo le risposte, tutto. Ho una domanda di follow-up su "è meglio formattare i blocchi da ssd a 64k?", Ma non ho familiarità con il formato qui. Devo postarlo come una nuova domanda o va bene qui?
Kevin,

Risposte:


5

Ma, leggendolo di più, i dischi fisici separati per i file mdf e ldf non si applicano veramente quando si tratta di SSD. Corretta?

Il motivo originale per suddividere i file di log e di dati su dischi separati era di 2 volte - latenza e larghezza di banda sulle unità.

Gli SSD non rimuovono queste restrizioni, ma riducono / aumentano i limiti in modo abbastanza significativo (7,9 ms per una lettura con un singolo HDD vs 0,1 ms per una lettura in un singolo SSD, approssimativamente).

Quindi alla fine sì e no - non si applica MOLTO come con gli HDD, ma quei limiti sono ancora lì e possono ancora essere raggiunti. Tutto dipende dal carico di lavoro.

La mia configurazione "pensante" è buona o semplicemente uno spreco (cioè nessun motivo per separare tempdb) in cui ora ho un SSD extra da utilizzare altrove?

Supponendo che

  • Hai 3 SSD fisici
  • Hai 1 HDD fisico
  • È necessario che i dati siano ridondanti, ma non necessariamente il sistema stesso

L'impostazione proposta avrebbe alcuni problemi (come menzionato in precedenza) e una singola unità guasta è quella principale.

Potresti scegliere qualcosa del genere.

Unità singola da 7200 rpm -
Array RAID 5 del sistema operativo Windows (3 SSD) - Suddivisa in 4 unità (D per dati, L per registri, S per scambio e T per temp)

O

Unità singola 7200rpm -
Sistema operativo Windows SSD singolo -
Array RAID 1 Temp e Swap (2 SSD) - Dati e registri

È una mia preferenza personale scaricare Windows su un'unità non SSD quando hai solo un numero limitato, ma questo dipende interamente da cosa sta facendo il server e da quanto rischio sei disposto a correre.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.