Requisiti del sottosistema I/O di Microsoft SQL Server per il database tempdb

Questo articolo presenta i requisiti del sottosistema I/O per il database tempdb in SQL Server.

Versione originale del prodotto: Microsoft SQL Server
Numero KB originale: 917047

Riepilogo

Microsoft SQL Server richiede che il sottosistema di I/O usato per archiviare i database utente e di sistema rispetta completamente i requisiti di registrazione write-ahead tramite entità di I/O specifiche. Questi requisiti sono necessari per rispettare le proprietà ACID delle transazioni: Atomic, Consistent, Isolated e Durable. I dettagli sui requisiti di conformità del sottosistema I/O sono disponibili nei concetti fondamentali di I/O di SQL Server.

Di seguito è riportato un riepilogo rapido dei requisiti:

  • L'ordinamento di scrittura deve essere mantenuto.
  • È necessario mantenere la coerenza di scrittura dipendente.
  • Le scritture devono essere sempre protette in/su supporti stabili.
  • La prevenzione dell'I/O strappata deve verificarsi.

La manutenzione della durabilità rimane fondamentale per tutti gli altri database, ma potrebbe essere rilassata per il database tempdb. La tabella seguente riepiloga diversi requisiti di I/O critici per i database di SQL Server.

Requisito di I/O Breve descrizione Sistema o utente tempdb
Ordinamento di scrittura

Coerenza di scrittura dipendente		 Possibilità del sottosistema di mantenere l'ordine corretto delle operazioni di scrittura. Ciò può essere particolarmente importante per le soluzioni di mirroring, i requisiti di coerenza dei gruppi e l'uso del protocollo WAL di SQL Server. Richiesto Consigliato
Lettura dopo la scrittura Possibilità del sottosistema di gestire le richieste di lettura con l'immagine dei dati più recente quando viene eseguita la lettura dopo il completamento di qualsiasi scrittura. Richiesto Richiesto
Sopravvivenza in caso di interruzione La possibilità per i dati di rimanere completamente intatta (Durevole) in un'interruzione, ad esempio un riavvio del sistema. Richiesto Non applicabile
Prevenzione I/O strappata Possibilità del sistema di evitare di suddividere singole richieste di I/O. Richiesto Consigliato
Riscrittura del settore Il settore può essere scritto interamente e non può essere riscritto a causa di una richiesta di scrittura su un settore nelle vicinanze. * Scoraggiato, consentito solo se transazionale * Scoraggiato, consentito solo se transazionale
Dati con protezione avanzata Si prevede che quando una richiesta di scrittura o un'operazione FlushFileBuffers venga completata correttamente, i dati sono stati salvati in supporti stabili. Richiesto Non applicabile
Allineamento e dimensioni del settore fisico SQL Server interroga i percorsi di archiviazione dei file di dati e di log. Tutti i dispositivi sono necessari per supportare gli attributi del settore che consentono a SQL Server di eseguire operazioni di scrittura sui limiti fisici allineati al settore e in multipli delle dimensioni del settore. Richiesto Richiesto

Le riscritture del settore transazionale comportano operazioni completamente registrate dal sottosistema consentendo a un settore di essere completamente spostato, sostituito o eseguito il rollback all'immagine originale. Queste riscritture sono in genere sconsigliate a causa del sovraccarico aggiuntivo necessario per eseguire tali azioni. Un esempio è un'utilità defragmentation che sposta i dati del file. Il settore originale nel file non può essere sostituito con la nuova posizione del settore fino a quando non vengono protetti i nuovi settori e i dati. Il mapping del settore deve verificarsi in modo transazionale in modo che qualsiasi guasto, incluso un guasto, causi la ricreazione dei dati originali. Assicurarsi di disporre di meccanismi di blocco disponibili durante questo tipo di processo per impedire l'accesso ai dati non validi, mantenendo così gli altri tenant di I/O di SQL Server.

Sopravvivenza in caso di interruzione

Il database tempdb è un'area scratch per SQL Server e viene ricompilata in ogni avvio di SQL Server. L'inizializzazione sostituisce qualsiasi esigenza di dati per sopravvivere a un riavvio.

Operazioni di riscrittura del settore transazionale

Per garantire l'esito positivo dei processi di ripristino, ad esempio il rollback e il ripristino di arresto anomalo del sistema, i record di log devono essere archiviati correttamente su supporti stabili prima che la pagina dei dati venga archiviata e non possa essere riscritta senza rispettare le proprietà transazionali. Ciò richiede che il sottosistema e SQL Server mantengano attributi specifici, ad esempio l'ordinamento di scrittura, le scritture allineate e ridimensionate del settore e altri attributi di sicurezza di I/O descritti nei documenti indicati in precedenza. Per il database tempdb, il ripristino di arresto anomalo del sistema non è necessario perché il database viene sempre inizializzato durante l'avvio di SQL Server. Tuttavia, il database tempdb richiede comunque funzionalità di rollback. Di conseguenza, alcuni attributi del protocollo WAL possono essere rilassati.

Il percorso di archiviazione per il database tempdb deve agire in modo rigoroso in base ai protocolli di unità disco stabiliti. In tutti i modi, il dispositivo in cui è archiviato il database tempdb deve essere visualizzato e fungere da disco fisico che fornisce funzionalità di lettura dopo la scrittura. Le operazioni di riscrittura del settore delle transazioni possono essere un requisito aggiuntivo di implementazioni specifiche. Ad esempio, SQL Server non supporta le modifiche al database tramite la compressione del file system NTFS perché la compressione NTFS può riscrivere i settori del log che sono già stati scritti e considerati avanzata. Un errore durante questo tipo di riscrittura può causare l'inutilizzabilità del database, danneggiando i dati già considerati sicuri da SQL Server.

Annotazioni

Supporto o compressione estesi di SQL Server per leggere solo database e filegroup. Per informazioni dettagliate, vedere la documentazione online di SQL Server.

Le operazioni di riscrittura del settore transazionale sono pertinenti a tutti i database di SQL Server che includono il database tempdb. Un'ampia gamma di tecnologie di archiviazione estese usa dispositivi e utilità che possono riscrivere i dati che SQL Server considera sicuri. Ad esempio, alcune delle tecnologie emergenti eseguono la memorizzazione nella cache in memoria o la compressione dei dati. Per evitare gravi danni al database, qualsiasi riscrittura del settore deve disporre del supporto transazionale completo in modo che, in caso di errore, i dati vengano ripristinati nelle immagini del settore precedenti. Ciò garantisce che SQL Server non sia mai esposto a un'interruzione imprevista o a una condizione di danno ai dati.

È possibile inserire il database tempdb in sottosistemi speciali, ad esempio dischi RAM, stato solido o altre implementazioni ad alta velocità che non possono essere usate per altri database. Tuttavia, i fattori chiave presentati nella sezione Altre informazioni devono essere considerati quando si valutano queste opzioni.

Annotazioni

I dischi locali negli ambienti cluster di failover sono supportati solo con implementazioni a stato solido o ad alta velocità. Questo perché il disco RAM può essere creato solo su una destinazione iSCSI. Inoltre, le funzionalità di destinazione iSCSI e cluster di failover non possono essere usate nello stesso host.

Ulteriori informazioni

Quando si valuta la posizione di archiviazione del database tempdb, è necessario valutare attentamente diversi fattori. Ad esempio, l'utilizzo del database tempdb implica, ma non è limitato alle decisioni relative al footprint di memoria, al piano di query e alle operazioni di I/O. L'ottimizzazione e l'implementazione appropriate del database tempdb possono migliorare la scalabilità e la velocità di risposta di un sistema. Questa sezione illustra i fattori chiave per determinare le esigenze di archiviazione per il database tempdb.

Sottosistemi ad alta velocità

Sono disponibili diverse implementazioni del sottosistema ad alta velocità sul mercato che forniscono requisiti di protocollo del sottosistema I/O di SQL Server, ma che non forniscono durabilità dei supporti.

Importante

Conferma sempre con il fornitore del prodotto per garantire la conformità completa alle esigenze di I/O di SQL Server.

Un disco RAM è un esempio comune di tale implementazione. I dischi RAM installano i driver necessari e consentono a parte del disco RAM principale di apparire come e funzionano come qualsiasi unità disco collegata al sistema. Tutti i sottosistemi di I/O devono garantire la conformità completa ai requisiti di I/O di SQL Server. Tuttavia, è ovvio che un disco RAM non è un supporto durevole. Pertanto, un'implementazione come un disco RAM può essere usata solo come percorso del database tempdb e non può essere usata per altri database.

Chiavi da considerare prima dell'implementazione e della distribuzione

Prima della distribuzione del database tempdb in questo tipo di sottosistema è necessario prendere in considerazione diversi aspetti. Questa sezione usa un disco RAM come base per la discussione, ma si verificano risultati simili in altre implementazioni ad alta velocità.

Sicurezza di I/O

La conformità delle operazioni di lettura dopo operazioni di scrittura e scrittura del settore transazionale è un must. Non distribuire mai SQL Server in qualsiasi sistema che non supporta completamente i requisiti di I/O di SQL Server o si rischia di danneggiare e perdere i dati.

Pagine già memorizzate nella cache (cache DOPPIA RAM)

Le tabelle temporanee sono simili a tutte le altre tabelle di un database. Vengono memorizzati nella cache dal pool di buffer e gestiti da operazioni di scrittura differita. L'archiviazione di pagine di tabelle temporanee su un disco RAM causa la memorizzazione nella cache della RAM doppia, una nel pool di buffer e una sul disco RAM. Ciò elimina direttamente le dimensioni totali del pool di buffer e in genere riduce le prestazioni di SQL Server.

Rinunciare alla RAM

Il disco RAM designa una parte della RAM principale come implica il nome. Sono disponibili diverse implementazioni di dischi RAM e di file basati su RAM. Alcune abilitano anche operazioni di backup di I/O fisiche. L'elemento chiave della cache dei file basata su RAM è che elimina direttamente dalla memoria fisica che può essere usata da SQL Server. L'aggiunta di una cache di file basata su RAM migliora sempre le prestazioni dell'applicazione e non riduce altre prestazioni di query o applicazioni.

Ottimizzare prima

Un'applicazione deve ottimizzare per rimuovere ordinamenti e hash non necessari e indesiderati che potrebbero causare l'uso del database tempdb. Molte volte l'aggiunta di un indice può rimuovere completamente la necessità di ordinare o hash nel piano, causando prestazioni ottimali senza richiedere l'uso del database tempdb.

Possibili punti di vantaggio

I vantaggi dell'inserimento del database tempdb in un sistema ad alta velocità possono essere determinati solo tramite test rigorosi e misurazioni dei carichi di lavoro dell'applicazione. Il carico di lavoro deve essere studiato attentamente per le caratteristiche che il database tempdb può trarre vantaggio e la sicurezza di I/O deve essere confermata prima della distribuzione.

Le operazioni di ordinamento e hash interagiscono con i gestori di memoria di SQL Server per determinare le dimensioni dell'area scratch in memoria per ogni operazione di ordinamento o hash. Non appena i dati di ordinamento o hash superano l'area scratch allocata in memoria, i dati possono essere scritti nel database tempdb. Questo algoritmo è stato espanso in SQL Server, riducendo i requisiti di utilizzo del database tempdb rispetto alle versioni precedenti di SQL Server.

Attenzione

SQL Server è progettato per tenere conto dei livelli di memoria e delle attività di query correnti quando si effettuano decisioni relative al piano di query che implicano l'uso delle operazioni del database tempdb. Di conseguenza, i miglioramenti delle prestazioni variano in modo significativo in base ai carichi di lavoro e alla progettazione delle applicazioni. È consigliabile completare i test con la soluzione preferita per determinare i possibili guadagni e valutare i requisiti di sicurezza di I/O prima di tale distribuzione.

SQL Server usa il database tempdb per gestire varie attività che includono ordinamenti, hash, archivio delle versioni delle righe e tabelle temporanee:

  • Le tabelle temporanee vengono gestite dalle routine comuni del pool di buffer per le pagine di dati e in genere non presentano vantaggi in termini di prestazioni dalle implementazioni speciali del sottosistema.
  • Il database tempdb viene usato come area di lavoro per hash e ordinamenti. La riduzione della latenza di I/O per tali operazioni può essere utile. Tuttavia, tenere presente che l'aggiunta di un indice per evitare un hash o un ordinamento può offrire un vantaggio simile.

Eseguire baseline con e senza il database tempdb archiviato nel sottosistema ad alta velocità per confrontare i vantaggi. Parte del test deve includere query sul database utente che non comportano ordinamenti, hash o tabelle temporanee e quindi verificare che queste query non siano interessate negativamente. Quando si valuta il sistema, gli indicatori di prestazioni seguenti possono essere utili.

Indicatore Descrizione/utilizzo
Letture e scritture di pagine Il miglioramento delle prestazioni delle operazioni di I/O del database tempdb può modificare la frequenza di letture e scritture delle pagine per i database utente a causa della latenza ridotta associata all'I/O del database tempdb. Per le pagine del database utente, il numero complessivo non deve variare nello stesso carico di lavoro.
Byte di lettura e scrittura fisici nel database tempdb Se si sposta il database tempdb in un dispositivo, ad esempio un disco RAM, aumenta l'I/O effettivo per il database tempdb, indica che la memoria sottratta dal pool di buffer causa un aumento dell'attività del database tempdb. Questo modello è un indicatore che l'aspettativa di vita della pagina delle pagine del database può anche essere influenzata in modo negativo.
Permanenza presunta delle pagine Un calo dell'aspettativa di vita delle pagine può indicare un aumento dei requisiti di I/O fisici per un database utente. La riduzione della frequenza potrebbe indicare probabilmente che la memoria sottratta dal pool di buffer forza le pagine del database a uscire prematuramente dal pool di buffer. Combinare con gli altri indicatori e testare per comprendere appieno i limiti dei parametri.
Velocità effettiva complessiva
Utilizzo CPU
Scalabilità
Ora di risposta		 L'obiettivo principale di una modifica della configurazione del database tempdb consiste nell'aumentare la velocità effettiva complessiva. I test devono includere una combinazione di carichi di lavoro ripetibili che possono essere ridimensionati per determinare la velocità effettiva interessata.

Un'implementazione del disco RAM basata sulla compressione può funzionare bene con 10 utenti. Tuttavia, con un carico di lavoro aumentato, questo può spingere i livelli di CPU oltre i livelli desiderati e avere effetti negativi sul tempo di risposta quando i carichi di lavoro sono elevati. I test di stress reali e i test di stima del carico futuri sono incoraggiati.
File di lavoro e azioni di creazione di tabelle di lavoro Se si sposta il database tempdb in un dispositivo, ad esempio un disco RAM, il piano di query viene modificato aumentando il numero o le dimensioni dei file di lavoro o delle tabelle di lavoro, indica che la memoria sottratta dal pool di buffer causa un aumento dell'attività del database tempdb. Questo modello indica che anche l'aspettativa di vita delle pagine del database può essere influenzata in modo negativo.

Esempio di riscrittura del settore transazionale

Nell'esempio seguente viene elaborata la sicurezza dei dati richiesta dai database di SQL Server.

Si supponga che un fornitore di dischi RAM usi un'implementazione di compressione in memoria. L'implementazione deve essere incapsulata correttamente fornendo l'aspetto fisico del flusso di file come se il settore fosse allineato e ridimensionato in modo che SQL Server non sia a conoscenza e protetto correttamente dall'implementazione sottostante. Esaminare più in dettaglio l'esempio di compressione.

  • Il settore 1 viene scritto nel dispositivo ed è compresso per risparmiare spazio.
  • Il settore 2 viene scritto nel dispositivo ed è compresso con il settore 1 per risparmiare spazio.

Il dispositivo può eseguire le azioni seguenti per proteggere i dati del settore 1 quando vengono combinati con i dati del settore 2.

  • Blocca tutte le scritture nei settori 1 e 2.
  • Decomprimere il settore 1 in un'area di lavoro, lasciando l'attuale spazio di archiviazione del settore 1 come dati attivi da recuperare.
  • Comprimere i settori 1 e 2 in un nuovo formato di archiviazione.
  • Blocca tutte le letture e le scritture dei settori 1 e 2.
  • Scambiare lo spazio di archiviazione precedente per i settori 1 e 2 con una nuova risorsa di archiviazione. Se il tentativo di scambio non riesce (rollback):
    • Ripristinare lo spazio di archiviazione originale per i settori 1 e 2.
    • Rimuovere i settori 1 e 2 dati combinati dall'area scratch.
    • Non è possibile eseguire l'operazione di scrittura del settore 2.
  • Sblocca letture e scritture per i settori 1 e 2.

La possibilità di fornire meccanismi di blocco per le modifiche del settore e ripristinare le modifiche quando il tentativo di scambio del settore non riesce è considerato conforme in transizione. Per le implementazioni che usano l'archiviazione fisica per il backup esteso, includerebbe gli aspetti appropriati del log delle transazioni per proteggere e ripristinare le modifiche applicate alle strutture su disco per mantenere l'integrità dei file di database di SQL Server.

Qualsiasi dispositivo che consente la riscrittura dei settori deve supportare le riscritture in modo transazionale in modo che SQL Server non sia esposto alla perdita di dati.

Annotazioni

L'istanza di SQL Server viene riavviata quando si verificano errori di I/O online e rollback nel database tempdb.

Prestare attenzione quando si sposta il database tempdb

Prestare attenzione quando si sposta il database tempdb perché se il database tempdb non può essere creato, SQL Server non verrà avviato. Se il database tempdb non può essere creato, avviare SQL Server usando il parametro di avvio (-f) e spostare il database tempdb in un percorso valido.

Per modificare il percorso fisico del database tempdb, seguire questa procedura:

  1. Usare l'istruzione ALTER DATABASE e la MODIFY FILE clausola per modificare i nomi di file fisici di ogni file nel database tempdb per fare riferimento al nuovo percorso fisico, ad esempio il nuovo disco.

    ALTER DATABASE tempdb MODIFY FILE 
(name = tempdev, filename = 'C:\MyPath\tempdb.mdf')

ALTER DATABASE tempdb MODIFY FILE 
(name = templog, filename = 'C:\MyPath\templog.ldf')

  2. Arrestare e quindi riavviare SQL Server.

Le certificazioni dei prodotti partner non sono un'opzione di compatibilità o sicurezza

Un prodotto di terze parti o un determinato fornitore può ricevere una certificazione logo Microsoft. Tuttavia, la certificazione partner o un logo Microsoft specifico non certifica la compatibilità o l'idoneità per uno scopo specifico in SQL Server.

Supporto

Se si usa un sottosistema con SQL Server che supporta le garanzie di I/O per l'uso del database transazionale come descritto in questo articolo, Microsoft fornirà supporto per le applicazioni basate su SQL Server e SQL Server. Tuttavia, i problemi relativi o causati dal sottosistema verranno indicati al produttore.

Per i problemi relativi al database tempdb, supporto tecnico Microsoft Services chiederà di rilocare il database tempdb. Contattare il fornitore del dispositivo per verificare di aver distribuito e configurato correttamente il dispositivo per l'uso del database transazionale.

Microsoft non certifica o convalida che i prodotti di terze parti funzionino correttamente con SQL Server. Inoltre, Microsoft non fornisce alcuna garanzia,ty o dichiarazione di idoneità di qualsiasi prodotto di terze parti per l'uso con SQL Server.

Riferimenti

Per altre informazioni, vedere:

  • Last updated on