Condividi tramite

Concetti fondamentali sull'I/O di SQL Server

  • Articolo

Si applica a: SQL Server Istanza gestita di SQL di Azure SQL Server nella VM di Azure

Lo scopo principale di un database di SQL Server è l'archiviazione e il recupero dei dati. L'esecuzione di una quantità elevata di operazioni di input/output (I/O) su disco è pertanto una caratteristica fondamentale del motore di database. Poiché le operazioni di I/O nel disco possono usare molte risorse e richiedere un tempo relativamente lungo per il completamento, in SQL Server viene data grande importanza all'efficienza dell'I/O.

I sottosistemi di archiviazione per SQL Server vengono forniti in più fattori di forma, tra cui unità meccaniche e archiviazione in stato solido. Questo articolo fornisce informazioni dettagliate su come usare i principi di memorizzazione nella cache delle unità per migliorare motore di database I/O.

SQL Server richiede che i sistemi supportino la distribuzione garantita a supporti stabili, come descritto nei requisiti del programma di affidabilità di I/O di SQL Server. Per altre informazioni sui requisiti di input e output per il motore di database di SQL Server, vedere Requisiti di input/output del disco di SQL Server motore di database.

I/O su disco

Gestione buffer esegue solo letture e scritture sul database. Altre operazioni su file e database, ad esempio apertura, chiusura, estensione e compattazione vengono eseguite dai componenti del gestore database e di File Manager.

Le operazioni di I/O su disco eseguite da Gestione buffer hanno le caratteristiche seguenti:

  • L'input/output viene eseguito di norma in modo asincrono. In questo modo, il thread che esegue la chiamata può continuare l'elaborazione mentre l'operazione di I/O viene eseguita in background. In alcune circostanze (ad esempio, le operazioni di I/O del log non allineate), possono verificarsi operazioni di I/O sincrone.

  • Tutti gli I/O vengono eseguiti nei thread che eseguono la chiamata a meno che non sia in uso l'opzione affinity I/O. L'opzione affinity I/O mask associa l'I/O su disco di SQL Server a un subset specificato di CPU. Negli ambienti SQL Server di fascia alta con elaborazione delle transazioni online (OLTP), questa estensione può migliorare le prestazioni dei thread di SQL Server che generano operazioni di I/O.

  • Gli I/O di più pagine vengono eseguiti con un I/O non sequenziale, che consente il trasferimento di dati da e verso aree di memoria non contigue. Questo significa che SQL Server può riempire o scaricare rapidamente la cache buffer evitando più richieste di I/O fisici.

Richieste di I/O lunghi

Gestione buffer segnala qualsiasi richiesta di I/O che rimane in attesa per almeno 15 secondi. In questo modo, l'amministratore di sistema può distinguere tra problemi di SQL Server e problemi del sottosistema I/O. Il messaggio di errore MSSQLSERVER_833 viene restituito e visualizzato nel log degli errori di SQL Server nel modo seguente:

SQL Server has encountered ## occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [##] in database [##] (#). The OS file handle is 0x00000. The offset of the latest long I/O is: 0x00000.

Un I/O lungo può essere un'operazione di lettura o scrittura. Questa indicazione non viene attualmente inclusa nel messaggio. I messaggi relativi a I/O lunghi sono avvisi e non messaggi di errore. Non indicano problemi con SQL Server ma con il sistema di I/O sottostante. ma vengono restituiti per consentire all'amministratore di sistema di individuare in modo più rapido la causa dei tempi di risposta lenti di SQL Server, nonché distinguere i problemi esterni al controllo di SQL Server. I messaggi relativi a I/O lunghi non richiedono quindi alcuna azione. È comunque consigliabile che l'amministratore di sistema verifichi il motivo per il quale per la richiesta di I/O è stato necessario un tempo così prolungato e se esso è giustificato.

Cause delle richieste di I/O lunghi

Un messaggio di I/O lungo indica che un I/O è bloccato definitivamente e non verrà mai completato (I/O perso) o semplicemente che non è stato ancora completato. Non è possibile capire dal messaggio di quale scenario si tratta, sebbene un I/O perso sia spesso causa di un timeout di latch.

Gli I/O lunghi indicano spesso un carico di lavoro di SQL Server troppo intenso per il sottosistema disco. Le situazioni seguenti potrebbero indicare un sottosistema disco non adeguato:

  • Più messaggi di I/O lunghi vengono visualizzati nel log degli errori durante un carico di lavoro elevato di SQL Server.
  • I contatori di Monitor prestazioni indicano latenze prolungate del disco, lunghe code del disco o nessun tempo di inattività del disco.

Gli I/O lunghi possono inoltre essere causati da un componente nel percorso di I/O (ad esempio, un driver, un controller o un firmware) che ritarda continuamente la risposta a una richiesta di I/O precedente privilegiando richieste più recenti. Ciò può verificarsi in ambienti interconnessi, ad esempio reti iSCSI e di canale in fibra (a causa di una configurazione errata o un errore di percorso). Questo può essere difficile da verificare mediante lo strumento Monitor prestazioni in quanto la maggioranza degli I/O vengono gestiti immediatamente. Le richieste di I/O lunghi possono essere ulteriormente complicate da carichi di lavoro che eseguono grandi quantità di I/O sequenziali, ad esempio backup e ripristino, analisi delle tabelle, ordinamento, creazione di indici, caricamenti bulk e azzeramento dei file.

Gli I/O lunghi isolati apparentemente non correlati a una delle condizioni precedenti possono essere causati da un problema hardware o di driver. Il log eventi di sistema potrebbe contenere un evento correlato che consente di individuare il problema.

Problemi di prestazioni di I/O causati da query inefficienti o driver di filtro

Le operazioni di I/O lente possono essere causate da query non scritte in modo efficiente o non ottimizzate correttamente con indici e statistiche. Un altro fattore comune nella latenza di I/O è la presenza di programmi antivirus o di altri programmi di sicurezza che analizzano i file di database. Questo software di analisi può estendersi al livello di rete, che aggiunge la latenza di rete, a sua volta che influisce indirettamente sulla latenza del database. Anche se lo scenario descritto a proposito dei 15 secondi di I/O è più comune con i componenti hardware, una latenza di I/O più breve viene osservata più frequentemente con query non ottimizzate o programmi antivirus non configurati correttamente.

Per informazioni dettagliate su come risolvere questi problemi, vedere Risolvere i problemi di prestazioni lente di SQL Server causati da problemi di I/O.

Per informazioni su come configurare la protezione antivirus in SQL Server, vedere Configurare il software antivirus per l'uso con SQL Server.

Memorizzazione nella cache in scrittura nei controller di archiviazione

I trasferimenti di I/O eseguiti senza l'uso di una cache possono essere significativamente più lunghi nelle unità meccaniche, a causa della velocità di rotazione del disco rigido, del tempo meccanico necessario per spostare le teste di guida e di altri fattori di limitazione. Le installazioni di SQL Server sono destinate a sistemi che forniscono controller di memorizzazione nella cache. Questi controller disabilitano le cache su disco e forniscono cache multimediali stabili per soddisfare i requisiti di I/O di SQL Server. Evitano i problemi di prestazioni correlati alla ricerca di archiviazione e ai tempi di scrittura tramite l'uso delle varie ottimizzazioni del controller di memorizzazione nella cache.

Nota

Alcuni fornitori di archiviazione usano la memoria persistente (PMEM) come risorsa di archiviazione anziché come cache, che può migliorare le prestazioni complessive. Per altre informazioni, vedere Configurare la memoria persistente (PMEM) per SQL Server in Windows e Configurare la memoria persistente (PMEM) per SQL Server in Linux.

L'uso di un controller di archiviazione di memorizzazione nella cache di scrittura (detto anche memorizzazione nella cache writeback) può migliorare le prestazioni di SQL Server. I controller di memorizzazione nella cache di scrittura e i sottosistemi di archiviazione sono sicuri per SQL Server, se sono progettati per l'uso in un ambiente DBMS (sistema di gestione di database) transazionale critico per i dati. Queste funzionalità di progettazione devono mantenere i dati memorizzati nella cache se si verifica un errore di sistema. L'uso di un gruppo di continuità esterno (UPS) per ottenere questo risultato non è in genere sufficiente, perché possono verificarsi modalità di errore non correlate all'alimentazione.

I controller di memorizzazione nella cache e i sottosistemi di archiviazione possono essere sicuri per l'uso da parte di SQL Server. La maggior parte delle nuove piattaforme server create appositamente che incorporano queste piattaforme sono sicure. Tuttavia, è necessario rivolgersi al fornitore dell'hardware per assicurarsi che il sottosistema di archiviazione sia stato testato e approvato per l'uso in un ambiente RDBMS transazionale critico per i dati (sistema di gestione di database relazionali).

Registrazione write-ahead

Le istruzioni di modifica dei dati di SQL Server generano scritture di pagine logiche. Questo flusso di scritture può essere illustrato come un percorso duplice: il log e il database stesso. Per motivi di prestazioni, SQL Server rinvia le operazioni di scrittura nel database tramite il proprio sistema di buffer della cache. Le scritture nel log vengono posticipate solo momentaneamente fino al momento COMMIT. Non vengono memorizzate nella cache allo stesso modo delle scritture di dati. Poiché le scritture dei log per una determinata pagina precedono sempre le scritture dei dati della pagina, il log viene talvolta definito log write-ahead (WAL).

Protocollo di registrazione write-ahead (WAL)

Il termine protocollo è un modo eccellente per descrivere il WAL. Il WAL usato da SQL Server è noto come ARIES (Algorithm for Recovery and Isolation Exploiting Semantics). Per maggiori informazioni, vedere Gestire il ripristino accelerato del database.

Si tratta di un set specifico e definito di passaggi di implementazione necessari per garantire che i dati vengano archiviati e scambiati correttamente e che possano essere ripristinati in uno stato noto in caso di errore. Proprio come una rete contiene un protocollo definito per lo scambio di dati in modo coerente e protetto, allo stesso modo WAL descrive il protocollo per proteggere i dati. Tutte le versioni di SQL Server aprono i file di log e di dati usando la funzione Win32 CreateFile. Il membro dwFlagsAndAttributes include l'opzione FILE_FLAG_WRITE_THROUGH quando viene aperta da SQL Server.

FILE_FLAG_WRITE_THROUGH

SQL Server crea i file di database usando il flag FILE_FLAG_WRITE_THROUGH. Questa opzione indica al sistema di scrivere tramite qualsiasi cache intermedia e passare direttamente all'archiviazione. Il sistema può comunque memorizzare nella cache le operazioni di scrittura, ma non può cancellarle in modo differito. Per ulteriori informazioni, vedere CreateFileA.

L'opzione FILE_FLAG_WRITE_THROUGH garantisce che quando un'operazione di scrittura restituisce il completamento corretto, i dati vengono archiviati correttamente nell'archiviazione stabile. Ciò si allinea alla specifica del protocollo di registrazione write-ahead (WAL) per assicurare i dati. Molti dispositivi di archiviazione (NVMe, PCIe, SATA, ATA, SCSI e basati su IDE) contengono cache di onboarding di 512 KB, 1 MB e superiori. Le cache di archiviazione si basano in genere su un condensatore e non su una soluzione supportata dalla batteria. Questi meccanismi di memorizzazione nella cache non possono garantire scritture in un ciclo di alimentazione o in un punto di errore simile. Garantiscono solo il completamento delle operazioni di scrittura del settore. Man mano che i dispositivi di archiviazione continuano ad aumentare di dimensioni, le cache diventano più grandi e possono esporre grandi quantità di dati durante un errore.

Per altre informazioni sul supporto FUA da parte della distribuzione di Linux e sul relativo effetto su SQL Server, vedere SQL Server On Linux: Forced Unit Access: Forced Unit Access (FUA) Internals (SQL Server in Linux: elementi interni di FUA - Forced Unit Access).

Integrità transazionale e recupero di SQL Server

L'integrità transazionale è uno dei concetti fondamentali di un sistema di database relazionale. Le transazioni sono considerate unità di lavoro atomiche completamente applicate o completamente sottoposte a rollback. Il log delle transazioni write-ahead di SQL Server è un componente fondamentale per l'implementazione dell'integrità transazionale.

Qualsiasi sistema di database relazionale deve anche gestire un concetto strettamente correlato all'integrità transazionale, che è il recupero da un errore di sistema non pianificato. Diversi effetti reali, gravi, non ideali possono causare questo errore. In molti sistemi di gestione del database, l'errore di sistema può comportare un lungo processo di recupero manuale diretto dall'uomo.

Al contrario, il meccanismo di ripristino di SQL Server è automatico e funziona senza intervento umano. Ad esempio, SQL Server potrebbe supportare un'applicazione di produzione cruciale e riscontrare un errore di sistema a causa di una momentanea fluttuazione dell'alimentazione. Al momento della ripresa dell'alimentazione, l'hardware del server viene riavviato, il software di rete viene caricato e inizializzato e SQL Server verrà riavviato. Durante l'inizializzazione di SQL Server, esegue automaticamente il processo di recupero in base ai dati nel log delle transazioni. Questo intero processo si verifica senza intervento umano. Ogni volta che le workstation client vengono riavviate, gli utenti troveranno tutti i dati presenti, fino all'ultima transazione immessa.

L'integrità transazionale e il recupero automatico in SQL Server costituiscono una potente funzionalità di risparmio di tempo e lavoro. Se un controller di memorizzazione nella cache di scrittura non è progettato correttamente per l'uso in un ambiente DBMS transazionale critico per i dati, esso può compromettere la capacità di recupero di SQL Server, danneggiando quindi il database. Ciò può verificarsi se il controller intercetta le scritture del log delle transazioni di SQL Server e le memorizza nel buffer in una cache hardware nella scheda controller, ma non mantiene queste pagine scritte durante un errore di sistema.

Memorizzazione nella cache delle scritture e controller dei dispositivi di archiviazione

La maggior parte dei controller di memorizzazione nella cache dei dispositivi di archiviazione esegue la memorizzazione nella cache di scrittura. La funzione di memorizzazione nella cache di scrittura non può sempre essere disabilitata.

Anche se il server usa un gruppo di continuità, ciò non garantisce la sicurezza delle scritture memorizzate nella cache. Possono verificarsi molti tipi di errori di sistema che un gruppo di continuità non è in grado di affrontare. Ad esempio, un errore di parità di memoria, una trappola del sistema operativo o un effetto glitch dell'hardware che causa una reimpostazione del sistema può produrre un'interruzione del sistema non controllata. Un errore di memoria nella cache di scrittura hardware può comportare anche la perdita di informazioni di log vitali.

Un altro possibile problema correlato a un controller di memorizzazione nella cache di scrittura può verificarsi all'arresto del sistema. Non è insolito spegnere e riaccendere il sistema operativo o riavviare il sistema durante le modifiche alla configurazione. Anche se un operatore attento segue il consiglio del sistema operativo di attendere che tutte le attività di archiviazione terminino prima del riavvio del sistema, le scritture memorizzate nella cache possono ancora essere presenti nel controller. Quando si preme la combinazione di tasti Ctrl+Alt+Del o si preme un pulsante reset dell'hardware, le scritture memorizzate nella cache possono essere rimosse, danneggiando potenzialmente il database.

È possibile progettare una cache di scrittura hardware, che tiene conto di tutte le possibili cause di eliminazione dei dati della cache modificati ma non salvati, che sarebbero quindi sicuri per l'uso da parte di un server database. Alcune di queste funzionalità di progettazione includono l'intercettazione del segnale del bus RST per evitare la reimpostazione non controllata del controller di memorizzazione nella cache, il backup della batteria su scheda e il controllo degli errori o il controllo degli errori e la correzione della memoria (ECC). Rivolgersi al fornitore dell'hardware per assicurarsi che la cache di scrittura includa queste e tutte le altre funzionalità necessarie per evitare la perdita di dati.

Usare le cache di archiviazione con SQL Server

Un sistema di database è prima di tutto responsabile dell'archiviazione e del recupero accurato dei dati, anche in caso di errori di sistema inaspettati.

Il sistema deve garantire l'atomicità e la durabilità delle transazioni, considerando al contempo l'esecuzione corrente, molteplici transazioni e di vari punti di errore. Questo fenomeno viene spesso definito come proprietà ACID (Atomicità, Coerenza, Isolamento e Durabilità).

Questa sezione illustra le implicazioni delle cache di archiviazione. È consigliabile leggere gli articoli seguenti nella Microsoft Knowledge Base per ulteriori chiarimenti sulla memorizzazione nella cache e sulle discussioni sulla modalità di errore alternativa:

Sono consigliati anche i documenti seguenti:

Questi due documenti si applicano a tutte le versioni attualmente supportate di SQL Server.

Soluzioni di memorizzazione nella cache supportate dalla batteria

I sistemi di controller di memorizzazione nella cache avanzata disabilitano la cache su disco e offrono una soluzione funzionale di memorizzazione nella cache supportata dalla batteria. Queste cache possono mantenere i dati nella cache per diversi giorni e anche consentire il collocamento della scheda di memorizzazione nella cache in un secondo computer. Quando l'alimentazione viene ripristinata correttamente, i dati non scritti vengono cancellati completamente prima che venga consentito un ulteriore accesso ai dati. Molti di essi consentono di stabilire una percentuale di letture e cache di scrittura adatta a ottenere prestazioni ottimali. Alcuni contengono aree di archiviazione di memoria di grandi dimensioni. Alcuni fornitori di hardware forniscono sistemi di memorizzazione nella cache di unità supportate da batteria di fascia alta con più gigabyte di cache. Questi possono migliorare significativamente le prestazioni del database. L'uso di soluzioni di memorizzazione nella cache supportate da batteria offre durabilità e coerenza dei dati previsti da SQL Server.

Implementazioni del sottosistema di archiviazione

Vi sono molti tipi di implementazioni del sottosistema. RAID (Redundant Array of Independent Disks) e SAN (rete di archiviazione) sono due esempi di questi tipi di implementazioni del sottosistema. Questi sistemi vengono in genere costruiti con unità basate su SCSI. Le ragioni sono molteplici. La sezione seguente descrive in modo generico le considerazioni generali sull'archiviazione.

SCSI, SAS e NVMe

Dispositivi di archiviazione SCSI, SAS e NVMe:

  • Vengono in genere prodotti per lavori pesanti.
  • Vengono in genere destinati a implementazioni multiutente basate su server.
  • In genere, hanno un tempo medio in merito alle percentuali di errore migliore di altre implementazioni.
  • Contengono euristica sofisticata per facilitare la stima degli errori imminenti.

Non-SCSI

Altre implementazioni di unità, ad esempio IDE, ATA e SATA:

  • Vengono in genere prodotte per lavori leggeri e medi.
  • Vengono in genere destinati a singole applicazioni basate sull'utente.

I controller non SCSI basati su desktop richiedono una maggiore larghezza di banda del processore principale (CPU) e sono spesso limitati da un singolo comando attivo. Ad esempio, quando un'unità non SCSI modifica un blocco non valido, l'unità richiede l'attesa dei comandi host. Il bus ATA presenta un altro esempio: il bus ATA supporta due dispositivi, ma solo un singolo comando può essere attivo. In questo modo si lascia inattiva un'unità mentre l'altra esegue il comando in sospeso. I sistemi RAID basati su tecnologie desktop possono tutti manifestare questi sintomi ed essere notevolmente influenzati dal risponditore più lento. A meno che questi sistemi non usino progettazioni avanzate, le prestazioni non sono efficienti quanto le prestazioni dei sistemi basati su SCSI.

Considerazioni sulle risorse di archiviazione

Vi sono situazioni in cui un'unità o una matrice basata su desktop è una soluzione appropriata a basso costo. Ad esempio, se si configura un database di sola lettura per la creazione di report, non è consigliabile riscontrare molti dei fattori di prestazioni di un database OLTP quando la memorizzazione nella cache delle unità è disabilitata.

Le dimensioni dei dispositivi di archiviazione continuano ad aumentare. Le unità ad alta capacità a basso costo possono essere interessanti. Tuttavia, quando si configura l'unità per SQL Server e le esigenze relative al tempo di risposta aziendale, è consigliabile considerare attentamente i seguenti aspetti:

  • Progettazione del percorso di accesso
  • Requisito di disabilitare la cache su disco

Dischi rigidi meccanici

I dischi meccanici utilizzano piatti magnetici rotanti per l'archiviazione dei dati. Sono disponibili in diverse capacità e fattori di forma, ad esempio IDE, SATA, SCSI e Serial Attached SCSI (SAS). Alcuni dischi SATA includono costrutti di previsione degli errori. I dischi SCSI sono progettati per cicli di lavoro più pesanti e percentuali di errore ridotte.

La memorizzazione nella cache delle unità deve essere disabilitata per usare l'unità con SQL Server. Per impostazione predefinita, la cache dell'unità è abilitata. In Windows Server usare la scheda Proprietà disco>Hardware per accedere alla scheda Proprietà>Criteri per controllare l'impostazione della cache delle unità.

Nota

Alcune unità non rispettano questa impostazione. Queste unità richiedono un'utilità produttore specifica per disabilitare la cache.

I sistemi basati su IDE e ATA possono posticipare i comandi host quando eseguono attività come la rettifica dei blocchi danneggiati. Ciò potrebbe portare a periodi di attività bloccate di I/O.

I vantaggi di SAS includono l'accodamento avanzato fino a 256 livelli e l'aggiunta all'inizio della coda e non in ordine. Il backplane SAS è progettato in modo tale da consentire l'uso di unità SAS e SATA all'interno dello stesso sistema.

L'installazione di SQL Server dipende dalla capacità del controller di disabilitare la cache su disco e di fornire una cache di I/O stabile. La scrittura di dati non in ordine in varie unità non è un ostacolo a SQL Server, purché il controller fornisca le funzionalità di memorizzazione nella cache corrette dei supporti stabili. La complessità della progettazione del controller aumenta con le tecniche di sicurezza dei dati avanzata, come il mirroring.

Archiviazione in stato solido.

L’archiviazione in stato solido presenta vantaggi rispetto ai dischi rigidi meccanici (rotanti), ma è soggetta a molti degli stessi modelli di errore dei supporti rotanti. L'archiviazione a stato solido è connessa al server usando varie interfacce, tra cui NVM Express (NVMe), PCI Express (PCIe) e SATA. Considerare i supporti a stato solido come supporti rotanti, e assicurarsi che siano presenti misure di sicurezza appropriate per gli errori di alimentazione, ad esempio un controller di memorizzazione nella cache supportato dalla batteria.

I problemi comuni causati da un errore di alimentazione includono:

  • Danneggiamento dei bit: i record presentano errori di bit casuali.
  • Scritture volanti: i record ben formati finiscono nel posto sbagliato.
  • Scritture livellate: le operazioni vengono eseguite parzialmente a un livello inferiore alle dimensioni previste del settore.
  • Danneggiamento dei metadati: i metadati in FTL sono danneggiati.
  • Dispositivo non responsivo: il dispositivo non funziona affatto o per lo più non funziona.
  • Impossibilità di serializzazione: lo stato finale dell'archiviazione non deriva da un ordine di operazione serializzabile.

512e

La maggior parte delle risorse di archiviazione a stato solido riporta dimensioni di settore di 512 byte, ma usa pagine da 4 KB all'interno dei blocchi di cancellazione di 1 MB. L'uso di settori allineati a 512 byte per il dispositivo di log di SQL Server può generare altre attività di lettura/modifica/scrittura (RMW), che possono contribuire a prestazioni e usura più lente.

Raccomandazione: assicurarsi che il controller di memorizzazione nella cache conosca le dimensioni corrette della pagina del dispositivo di archiviazione e sia in grado di allineare correttamente le scritture fisiche all'infrastruttura di archiviazione a stato solido.

0xFFFFFFFF

Un'unità appena formattata contiene in genere tutti zeri. Un blocco cancellato di un dispositivo a stato solido è tutto 1, rendendo una lettura non elaborata di un blocco cancellato tutto 0xFF. Tuttavia, è insolito per un utente leggere un blocco cancellato durante le normali operazioni di I/O.

Uso di stamp per i modelli

Una tecnica usata in passato prevede la scrittura di un modello noto nell'intera unità. Quindi, mentre si esegue l'attività del database su quella stessa unità, è possibile rilevare un comportamento non corretto (lettura non aggiornata/lettura persa/lettura di scarto non corretto/ecc.) quando viene visualizzato in modo imprevisto il modello.

Questa tecnica non funziona bene nell'archiviazione a stato solido. Le attività di cancellazione e RMW per le scritture eliminano definitivamente il modello. L'attività di garbage collection (GC) dell'archiviazione a stato solido, il livellamento dell'usura, i blocchi di elenco proporzionali/impostati e altre ottimizzazioni tendono a causare l'acquisizione di scritture in posizioni fisiche diverse, al contrario del riutilizzo del settore dei supporti rotanti.

Firmware

Il firmware usato nell'archiviazione a stato solido è solitamente complesso in confronto con le controparti dei supporti rotanti. Molte unità usano più core di elaborazione per gestire le richieste in ingresso e le attività di garbage collection. Assicurarsi di mantenere aggiornato il firmware del dispositivo a stato solido per evitare problemi noti.

Danni ai dati in lettura e livellamento dell'usura

Un approccio comune di garbage collection (GC) per l'archiviazione a stato solido aiuta a evitare danni ripetuti ai dati di lettura. Quando si legge ripetutamente la stessa cella, è possibile che l'attività degli elettroni possa fuoriuscire e causare danni alle cellule vicine. L'archiviazione a stato solido protegge i dati con vari livelli di codice di correzione di errore (ECC) e altri meccanismi.

Uno di questi meccanismi riguarda il livellamento dell'usura. L'archiviazione a stato solido tiene traccia dell'attività di lettura e scrittura sul dispositivo di archiviazione. La garbage collection può determinare aree sensibili o posizioni che si usurano più velocemente rispetto ad altre posizioni. Ad esempio, la GC determina che un blocco si è trovato in uno stato di sola lettura per un periodo di tempo e deve spostarsi. Questo spostamento è in genere a un blocco con più usura, quindi il blocco originale può essere utilizzato per le scritture. Ciò consente di bilanciare l'usura sull'unità, ma sposta i dati di sola lettura in una posizione che ha più usura e aumenta matematicamente le probabilità di errore, anche se di poco.

Un altro effetto collaterale del livellamento dell'usura può verificarsi con SQL Server. Supponiamo di eseguire DBCC CHECKDB e che restituisca un errore. Se viene eseguito una seconda volta, c’è una piccola possibilità che DBCC CHECKDB restituisca un modello diverso o aggiuntivo di errori, perché l'attività di GC di archiviazione a stato solido potrebbe apportare modifiche tra le esecuzioni di DBCC CHECKDB.

Errore del sistema operativo 665 e deframmentazione

I supporti rotanti devono mantenere i blocchi vicini tra loro per ridurre lo spostamento della testa dell'unità e aumentare le prestazioni. L'archiviazione a stato solido non ha la testa fisica, eliminando il tempo di posizionamento. Molti dispositivi a stato solido sono progettati per consentire operazioni parallele su blocchi diversi in parallelo. Ciò significa che la deframmentazione dei supporti a stato solido non è necessaria. Le attività seriali sono i migliori modelli di I/O per massimizzare la produttività di I/O nei dispositivi di archiviazione a stato solido.

Nota

Lo spazio di archiviazione a stato solido trae vantaggio dalla funzionalità di taglio, un comando a livello di sistema operativo (OS) che cancella i blocchi considerati non più in uso. In Windows, usare lo strumento Ottimizza unità per impostare una pianificazione settimanale per l'ottimizzazione delle unità.

Raccomandazioni:

  • Usare un controller appropriato supportato da batteria progettato per ottimizzare le attività di scrittura. Ciò può migliorare le prestazioni, ridurre l'usura delle unità e i livelli di frammentazione fisica.

  • Considerare l'utilizzo del file system ReFS per evitare le limitazioni degli attributi NTFS.

  • Assicurarsi che le dimensioni di crescita dei file siano appropriate.

Per maggiori informazioni sulla risoluzione dei problemi per l'errore di sistema operativo 665 in relazione alla frammentazione, vedere Gli errori di sistema operativo 665 e 1450 sono riportati per i file di SQL Server.

Compressione

Finché l'unità mantiene lo scopo dei supporti stabili, la compressione può aumentare la durata dell'unità e potrebbe influire positivamente sulle prestazioni. Tuttavia, alcuni firmware potrebbero già comprimere i dati in modo invisibile. Ricordarsi di testare nuovi scenari di archiviazione prima di distribuirli nell'ambiente di produzione.

Riepilogo

  • Gestire procedure e processi di backup e ripristino di emergenza appropriati.
  • Mantenere aggiornato il firmware.
  • Ascoltare attentamente le linee guida per la produzione di hardware.

Considerazioni sulla cache e SQLIOSim

Per proteggere completamente i dati, è necessario assicurarsi che la memorizzazione nella cache dei dati sia gestita correttamente. In molte situazioni, ciò significa dover disattivare la memorizzazione nella cache di scrittura dell'unità.

Nota

Assicurarsi che qualsiasi meccanismo di memorizzazione nella cache alternativo possa gestire correttamente più tipi di errore.

Microsoft ha eseguito test su diverse unità SCSI e IDE usando l'utilità SQLIOSim . Questa utilità simula un'attività in lettura/scrittura asincrona pesante in un dispositivo dati simulato e in un dispositivo di log. Per altre informazioni e dettagli su SQLIOSim, vedere Usare l'utilità SQLIOSim per simulare l'attività di SQL Server in un sottosistema del disco.

Molti produttori di PC ordinano le unità con la cache di scrittura disabilitata. Tuttavia, i test mostrano che non sempre potrebbe essere così, quindi è consigliabile eseguire test completi. Per eventuali domande sullo stato di memorizzazione nella cache del dispositivo di archiviazione, contattare il produttore e ottenere le impostazioni appropriate delle utilità o dei ponticelli per disattivare le operazioni di memorizzazione nella cache di scrittura.

SQL Server richiede che i sistemi supportino la distribuzione garantita a supporti stabili, come descritto nei requisiti del programma di affidabilità di I/O di SQL Server. Per altre informazioni sui requisiti di input e output per il motore di database di SQL Server, vedere Requisiti di input/output del disco di SQL Server motore di database.

Contenuto correlato