SQL Server 2K / 2K5 / 2K8 e dischi a stato solido: ottimizzazioni specifiche?

Qualcuno qui esegue SQL Server su unità a stato solido? Hai trovato suggerimenti specifici per l'ottimizzazione? Sono particolarmente interessato ai modi per ridurre la frequenza con cui SQL Server esegue piccole operazioni di scrittura casuali poiché sono nemesi delle prestazioni SSD, in particolare le unità SSD MLC.

Ci sono alcune ovvie ottimizzazioni che si possono fare, ovviamente: i dati pesanti in lettura dovrebbero essere forniti dall'SSD e le cose pesanti in scrittura dovrebbero essere lasciate ai tradizionali dischi rotanti. Ciò include i registri delle transazioni, naturalmente!

Dato un budget sufficiente, ovviamente, si vorrebbe utilizzare i dischi SSD SLC come X25-E o la serie Vertex Ex o varie offerte a livello aziendale. Ma sono anche interessato a suggerimenti che potrebbero giovare alle configurazioni SSD MLC. Penso che sia un'area interessante. Uno dei clienti dei miei clienti ha un budget limitato e un set di dati che è cresciuto immensamente e si trovano ad affrontare una riscrittura completa di quasi un centinaio di query al fine di mantenere un livello decente di prestazioni. Tuttavia, ho il sospetto subdolo che meno di $ 500 di spazio RAM e SSD potrebbero far guadagnare loro un guadagno in termini di prestazioni maggiore di migliaia (forse decine di migliaia) di dollari di tempo per gli sviluppatori.

Non sei sicuro di cosa intendi riducendo la quantità di piccole scritture casuali eseguite da SQL Server. SQL Server scrive le pagine di dati solo durante i checkpoint, quindi l'unico modo per limitare il numero di scritture è modificare l'intervallo del checkpoint o non eseguire così tante operazioni IUD. Intendevi qualcos'altro?

In tutte le implementazioni di SSD che ho visto (una manciata), è un po 'l'opposto di quello che stai suggerendo - il miglior uso degli SSD sembra essere per i log delle transazioni pesanti e tempdb - praticamente dov'è il più grande I / O collo di bottiglia del sottosistema e inserire gli SSD al suo interno - poiché il tempo di ricerca e la latenza sono ridotti a una costante bassa.

Dai un'occhiata a questo documento di ricerca che MS ha prodotto (purtroppo non estremamente dettagliato sulle specifiche di SQL Server): Migrazione dell'archiviazione dei server su SSD: analisi dei compromessi .

Spero che sia di aiuto!

Non è possibile modificare le caratteristiche I / O dei server SQL. La sua unità base di accesso al disco, per i file di dati, è una pagina da 8 KB. Li scriverà principalmente durante un checkpoint, ma li scriverà anche quando sarà possibile.
SQL non attende il completamento delle scritture sul disco dati prima di tornare, è solo le scritture del registro che devono essere completate. Se riesci a mantenere solo un registro del database su un disco, saranno scritture sequenziali e andranno bene sui normali dischi rigidi veloci.
Il successo delle prestazioni dal punto di vista di SQL è quando deve leggere i dischi. Se puoi dargli più memoria, SQL conterrà più pagine di dati in memoria, che è più veloce di qualsiasi tipo di disco, SSD o altro. Ovviamente puoi anche ridurre il numero di letture del disco creando indici appropriati. Mi aspetto che anche un SSD possa aiutare con queste letture perché sono probabilmente casuali e trattenute in attesa che le testine si muovano.
Non so di quale dimensione del database stiamo parlando qui, ma potresti voler dare un'occhiata a HyperOS. Realizzano dischi sata che in realtà sono solo un carico di ram stick DDR2, con un disco SSD o disco da 2,5 pollici come backup. Il modello di accesso del server non importa quindi un jot. Non metterei i registri su nulla di simile, però. I registri sono ciò che mantiene coerenti i tuoi dati, devono andare su un supporto affidabile e nonostante il backup SSD e la batteria e il server probabilmente ha un UPS ecc., Mi sentirei comunque non facile di non avere i miei registri su un vero disco rigido in una sorta di array RAID tollerante ai guasti.

Le piccole operazioni casuali sono la nemesi dei dischi tradizionali, a causa della latenza della ricerca della testa ... Gli SSD sono bravi a risolvere esattamente questo.

Con operazioni sequenziali lunghe, i dischi standard funzionano abbastanza bene, quindi non ci sarebbe alcun motivo nell'uso di SSD (dal punto di vista delle prestazioni, ovviamente).

Non aggiungere ancora un punto qui per aggiungerlo nel thread dei commenti, ma se si imposta la dimensione della pagina del DB / il numero di letture multiple per qualsiasi cosa sugli SSD su un multiplo delle dimensioni della pagina dell'SSD, questo non dovrebbe essere un problema.

Non lavoro su SQL Server da molto tempo, quindi non sono sicuro che queste opzioni siano disponibili lì. Ho fatto Oracle e DB2 negli ultimi anni e questo avrebbe risolto i tuoi problemi in quanto il DB sarebbe stato correttamente adattato alle caratteristiche del disco.

Consiglierei di allineare la partizione in cui sono archiviati i file di database.

Vorrei anche raccomandare di decidere cosa succede su RAID 0 per perf (ldf e TempDB) e posizionare i dati critici su RAID 1 (mdf).

In terzo luogo, è necessario aggiornare davvero il firmware dell'unità nonché i firmware / i driver del controller SATA. In questo modo dai all'azienda hardware e ai suoi sviluppatori la possibilità di ottimizzare perf per te.