La corretta configurazione dei sottosistemi I/O è importante per ottenere prestazioni ottimali e garantire il funzionamento corretto dei sistemi SQL Server. Di seguito vengono descritte alcune delle procedure consigliate più comuni che il team SQL Server consiglia per la configurazione dell'archiviazione per SQL Server.
Informazioni sulle caratteristiche I/O di SQL Server e sui requisiti e sulle caratteristiche I/O specifici dell'applicazione.
Per essere in grado di progettare e distribuire l'archiviazione per l'applicazione SQL Server, è necessario comprendere le caratteristiche I/O dell'applicazione e possedere una conoscenza minima dei modelli I/O di SQL Server. Performance Monitor consente di catturare queste informazioni per un'applicazione esistente. Di seguito sono elencate alcune delle domande da porsi:
Qual è il rapporto tra lettura e scrittura dell'applicazione?
Quali sono le frequenze I/O comuni (I/O al secondo, MB/S & dimensione I/O)? Monitorare i contatori Perfmon:
Media byte letti/sec, media byte scritti/sec
Letture/sec, scritture/sec
Byte letti da disco/sec, byte scritti da disco/sec
Media letture disco/sec, media scritture disco/sec
Lunghezza media coda del disco
In che misura I/O è sequenziale e casuale? Si tratta principalmente di un'applicazione OLTP o di un'applicazione Relational Data Warehouse?
Assi più numerosi e veloci sono utili per le prestazioni
Verificare di disporre di un numero adeguato di assi per supportare i requisiti di I/O con una latenza accettabile.
Utilizzare il filegroup per i requisiti di amministrazione come backup/ripristino, disponibilità parziale di database, e così via.
Utilizzare i file di dati per "delimitare" il database nella configurazione specifica I/O (dischi fisici, LUN, ecc.).
Cercare di non ottimizzare "eccessivamente" la struttura dell'archiviazione; le strutture più semplici offrono generalmente buone prestazioni e maggiore flessibilità.
Se non si capisce a fondo l'applicazione è bene evitare di ottimizzare eccessivamente l'I/O collocando gli oggetti su assi separati.
Assicurarsi di controllare la strategia di crescita. Poiché la dimensione dei dati aumenta, come sarà possibile gestire la crescita dei file di dati / LUN / gruppi RAID? Si consiglia di progettare questo anticipo anziché ribilanciare i file di dati o i LUN successivamente in una distribuzione di produzione.
Convalidare le configurazioni prima della distribuzione
Verificare la velocità effettiva del sottosistema I/O prima di distribuire SQL Server. Assicurarsi che i test siano in grado di ottenere i requisiti I/O con una latenza accettabile. SQLIO è uno degli strumenti da utilizzare a tale scopo. Insieme allo strumento esiste un documento che spiega i principi di base del test di un sottosistema I/O. Scaricare lo strumento SQLIO Disk Subsystem Benchmark Tool.
È necessario capire che il motivo per cui si eseguono i test di SQLIO non è di simulare le caratteristiche esatte dell'I/O di SQL Server ma di verificare la velocità massima ottenibile dal sottoinsieme I/O per i tipi comuni di SQL Server.
È possibile utilizzare IOMETER in alternativa a SQLIO.
Sistemare sempre i file di registro sui dischi RAID 1+0 (o RAID 1). In questo modo è possibile fornire:
migliore protezione in caso di errore hardware e
migliori prestazioni di scrittura.
Nota: In genere, RAID 1+0 fornisce una velocità maggiore per le applicazioni a scrittura intensiva. Le prestazioni ottenute variano in base alle implementazioni RAID del fornitore dell'hardware. L'alternativa più comune a RAID 1+0 è RAID 5. Generalmente, RAID 1+0 fornisce prestazioni di scrittura migliori di qualsiasi altro livello RAID che fornisce la protezione dei dati, compreso RAID 5.
Isolare il registro dai dati a livello del disco fisico
Quando ciò non è possibile (ad esempio, in ambienti SQL consolidati) è necessario considerare le caratteristiche I/O e raggruppare le caratteristiche I/O simili (cioè tutti i registri) sugli assi comuni.
L'unione dei carichi di lavoro eterogenei (carichi di lavoro con caratteristiche I/O e latenza molto diverse) può avere effetti negativi sulle prestazioni globali (ad esempio, collocando i dati Exchange e SQL sugli stessi assi fisici).
Prendere in considerazione la configurazione del database TEMPDB
Spostare TEMPDB in un archivio adeguato e ridimensionarlo dopo l'istallazione di SQL Server.
Le prestazioni possono trarre vantaggio se TEMPDB si trova in RAID 1+0 (secondo l'uso di TEMPDB).
Per il database TEMPDB, creare 1 file di dati per CPU, come descritto nel punto 8 di seguito.
L'allineamento del numero di file di dati con i file della CPU offre vantaggi di scalabilità per l'assegnazione di carichi di lavoro intensi.
È necessario possedere da 25 a 1 file di dati (per filegroup) per ogni CPU sul server ospite.
Questo è vero in particolare per TEMPDB dove l'indicazione è di 1 file di dati per CPU.
Il dual core viene considerato come 2 CPU; al contrario dei processi logici (hyperthreading).
Non sottovalutare alcuni dei fondamentali di SQL Server
I file di dati devono essere di uguale dimensione, SQL Server utilizza un algoritmo proporzionale che favorisce le assegnazioni nei file con più spazio libero.
Ridimensionare i file di dati e di registro.
Non utilizzare AUTOGROW ma gestire la crescita di questi file manualmente. È possibile lasciare AUTOGROW ON per motivi di protezione, ma è necessario gestire in anticipo la crescita dei file di dati.
Non sottovalutare le basi di configurazione di archiviazione
Utilizzare i driver HBA aggiornati consigliati dal fornitore della soluzione di archiviazione
Utilizzare i driver specifici del fornitore della soluzione di archiviazione dal sito Web dei driver HBA
Regolare le impostazioni dei driver HBA richiesti dai volumi I/O. In genere, le impostazioni specifiche del driver devono pervenire dal fornitore della soluzione di archiviazione. Tuttavia abbiamo scoperto che le impostazioni predefinite Profondità coda non sono adeguate per supportare i volumi I/O di SQL Server.
Assicurarsi che il firmware della matrice di archiviazione sia sempre al livello consigliato.
Utilizzare software a percorsi multipli per ottenere il bilanciamento tra i driver HBA e LUN e assicurarsi che questo funzioni correttamente
Semplificare la configurazione & offre vantaggi di disponibilità
Microsoft Multipath I/O (MPIO): I fornitori creano moduli specifici dispositivo DSM su Driver Development Kit, fornito da Microsoft.
.gif "1")
.gif "2")
.gif "3")
.gif "4")
.gif "5")
.gif "6")
.gif "7")
.gif "8")
.gif "9")
.gif "10")