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

In questo articolo vengono illustrati i requisiti del sottosistema di i/O per il database tempdb in SQL Server.

Versione originale del prodotto:   Microsoft SQL Server 2005, SQL Server 2008, SQL Server 2012 SQL Server 2014
Numero KB originale:   917047

Riepilogo

Microsoft SQL Server richiede che il sottosistema di I/O utilizzato per archiviare i database di sistema e degli utenti onori pienamente Write-Ahead i requisiti di registrazione (WAL) mediante entità di I/O specifiche. Questi requisiti sono necessari per onorare le proprietà ACID delle transazioni: atomiche, coerenti, isolate e durevoli. I dettagli relativi ai requisiti di conformità dei sottosistemi di I/O sono forniti nei riferimenti seguenti:

Nozioni di base di I/O di SQL Server 2000 https://technet.microsoft.com/library/cc966500.aspx

Nota

Questo articolo si applica anche a SQL Server 2005 e versioni successive.

Nell'elenco seguente è riportato un riepilogo rapido dei requisiti:

  • L'ordine di scrittura deve essere mantenuto.
  • La coerenza di scrittura dipendente deve essere mantenuta.
  • Le scritture devono essere sempre protette in/su un supporto stabile.
  • La prevenzione delle operazioni di I/O dilaniate deve verificarsi.

La manutenzione della durata rimane critica per tutti gli altri database, ma può essere attenuata per il database tempdb. Nella tabella seguente sono riepilogati alcuni dei requisiti di I/O critici per i database di SQL Server.

Requisiti di I/O Descrizione breve Sistema o utente tempdb
Ordine di scrittura

Coerenza di scrittura dipendente
La capacità del sottosistema di mantenere l'ordine corretto delle operazioni di scrittura. Questo può essere particolarmente importante per le soluzioni di mirroring, i requisiti di coerenza dei gruppi e l'utilizzo del protocollo SQL Server WAL. Obbligatorio Consigliata
Lettura dopo la scrittura La capacità del sottosistema di servire le richieste di lettura con l'immagine di dati più recente quando la lettura viene emessa dopo che qualsiasi scrittura è stata completata correttamente. Obbligatorio Obbligatorio
Sopravvivenza tra le interruzioni La possibilità per i dati di rimanere completamente intatti (durevoli) in un'interruzione, ad esempio un riavvio del sistema. Obbligatorio Non applicabile
Prevenzione delle operazioni di I/O strappata La capacità del sistema di evitare di suddividere singole richieste di I/O. Obbligatorio Consigliata
Riscrittura settoriale Il settore può essere scritto integralmente e non può essere riscritto a causa di una richiesta di scrittura in un settore nelle vicinanze. * Scoraggiato, consentito solo se transazionale * Scoraggiato, consentito solo se transazionale
Dati induriti L'aspettativa che quando una richiesta di scrittura o un'operazione di FlushFileBuffers viene completata correttamente, i dati sono stati salvati in un supporto stabile. Obbligatorio Non applicabile
Allineamento e dimensioni del settore fisico SQL Server interroga i percorsi di archiviazione dei file di dati e di registro. Tutti i dispositivi sono necessari per supportare gli attributi del settore che consentono a SQL Server di eseguire scritture su confini allineati al settore fisico e in multipli delle dimensioni del settore. Obbligatorio Obbligatorio

Le riscritture del settore transazionale implicano operazioni completamente registrate da parte del sottosistema che consente a un settore di essere completamente spostati, sostituiti o ripristinati nell'immagine originale. Tali riscritture vengono in genere scoraggiate a causa del sovraccarico aggiuntivo necessario per eseguire tali azioni. Un esempio di questo defragmentation è un'utilità che consente di spostare i dati del file. Il settore originale nel file non può essere sostituito con la nuova posizione del settore fino a quando non viene protetto il nuovo settore e i nuovi dati. Il rimappaggio del settore deve essere eseguito in modo transazionale, in modo che l'eventuale errore, inclusa un'interruzione dell'alimentazione, provochi il ristabilimento dei dati originali. Assicurarsi di disporre di meccanismi di blocco disponibili durante questo tipo di processo per evitare l'accesso ai dati non validi, mantenendo in tal modo gli altri tenant di I/O di SQL Server.

Sopravvivenza tra le interruzioni

Il database tempdb è un'area di Scratch per SQL Server e viene ricostruito su ogni avvio di SQL Server. L'inizializzazione sostituisce qualsiasi esigenza di dati per la sopravvivenza di un riavvio.

Operazioni di riscrittura del settore transazionale

Per garantire l'esito positivo dei processi di ripristino, ad esempio il ripristino di emergenza e il rollback, è necessario che i record del registro siano archiviati correttamente su un supporto stabile prima che la pagina di dati venga archiviata e non possa essere riscritta senza rispettare le proprietà transazionali. In questo modo, il sottosistema e SQL Server devono mantenere gli attributi specifici, ad esempio l'ordine di scrittura, le Scritture allineate al settore e gli altri attributi di sicurezza di I/O descritti nei documenti menzionati in precedenza. Per il database tempdb, il ripristino dell'arresto anomalo non è necessario perché il database viene sempre inizializzato durante l'avvio di SQL Server. Tuttavia, il database tempdb richiede ancora funzionalità di rollback. Pertanto, alcuni attributi del protocollo WAL possono essere rilassati.

Il percorso di archiviazione per il database tempdb deve agire in conformità rigorosa con i protocolli di unità disco stabiliti. In tutti i modi, il dispositivo su cui è archiviato il database tempdb deve essere visualizzato e funge da disco fisico che fornisce le funzionalità di lettura dopo scrittura. Le operazioni di riscrittura del settore delle transazioni possono essere un ulteriore requisito di implementazioni specifiche. Ad esempio, SQL Server non supporta le modifiche apportate al database utilizzando la compressione del file system NTFS perché la compressione NTFS può riscrivere i settori del registro già scritti e considerati induriti. Un errore durante questo tipo di riscrittura può rendere inutilizzabile il database, danneggiando i dati già considerati sicuri da SQL Server.

Nota

SQL Server 2005 Extended support or compression to read only databases and file groups. Per informazioni complete, vedere la documentazione online di SQL Server 2005.

Le operazioni di riscrittura del settore transazionale sono rilevanti per tutti i database di SQL Server che includono il database tempdb. Un'ampia gamma di tecnologie di archiviazione estese utilizza dispositivi e utilità in grado di riscrivere dati protetti da SQL Server. Ad esempio, alcune delle tecnologie emergenti eseguono la memorizzazione nella cache o la compressione dei dati in memoria. Per evitare danni a database gravi, qualsiasi riscrittura settoriale deve disporre di un supporto transazionale completo in modo che, se si verifica un errore, i dati vengano ripristinati nelle immagini del settore precedente. Questo garantisce che SQL Server non venga mai esposto a un'interruzione imprevista o a una condizione di danneggiamento dei dati.

Potrebbe essere possibile inserire il database tempdb nei sottosistemi di specializzazione, ad esempio i dischi RAM, lo stato solido o altre implementazioni ad alta velocità che non possono essere utilizzate per altri database. Tuttavia, i fattori chiave presentati nella sezione "ulteriori informazioni" devono essere considerati quando si valutano queste opzioni.

Nota

I dischi locali negli ambienti cluster di failover sono supportati solo con le implementazioni a stato solido o ad alta velocità. Ciò è dovuto al fatto che il disco RAM può essere creato solo su una destinazione iSCSI. Inoltre, le caratteristiche del cluster di failover e di destinazione iSCSI non possono essere utilizzate nello stesso host.

Altre informazioni

Alcuni fattori devono essere studiati con attenzione quando si valuta il percorso di archiviazione del database tempdb. Ad esempio, l'utilizzo del database tempdb implica, ma non è limitato a, il footprint di memoria, il piano di query e le decisioni di I/O. L'ottimizzazione e l'implementazione appropriate del database tempdb consentono di migliorare la scalabilità e la reattività di un sistema. In questa sezione vengono illustrati i fattori chiave per determinare le esigenze di archiviazione per il database tempdb.

Sottosistemi ad alta velocità

Esistono diverse implementazioni di sottosistema ad alta velocità disponibili sul mercato che forniscono requisiti di protocollo di I/O di SQL Server, ma che non garantiscono la durabilità dei file multimediali.

Importante

Confermare sempre con il fornitore del prodotto per garantire la piena conformità con le esigenze di I/O di SQL Server.

Un disco RAM è un esempio comune di tale implementazione. I dischi RAM consentono di installare i driver necessari e di abilitare parte del disco RAM principale in modo che funzioni come tutte le unità disco collegate al sistema. Tutti i sottosistemi di I/O devono fornire 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 utilizzata solo come percorso del database tempdb e non può essere utilizzata per qualsiasi altro database.

Chiavi da prendere in considerazione prima dell'implementazione e della distribuzione

Prima di distribuire il database tempdb su questo tipo di sottosistema, è possibile considerare diversi punti. In questa sezione viene utilizzato un disco RAM come base per la discussione, ma si verificano risultati simili in altre implementazioni ad alta velocità.

Sicurezza I/O

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

Pagine già memorizzate nella cache (doppia cache RAM)

Le tabelle temporanee sono come tutte le altre tabelle di un database. Vengono memorizzate nella cache dal pool di buffer e gestite da operazioni di scrittura lazy. L'archiviazione di pagine di tabelle temporanee su un disco RAM causa una doppia memorizzazione nella cache della RAM, una nel pool di buffer e una nel disco RAM. Questo toglie direttamente le dimensioni totali possibili del pool di buffer e generalmente diminuisce le prestazioni di SQL Server.

Rinuncia alla RAM

Il disco RAM designa una parte della RAM principale come implica il nome. Sono disponibili diverse implementazioni di dischi RAM e cache dei file basati su RAM. Alcuni consentono anche operazioni di I/O fisiche. L'elemento chiave della cache dei file basati sulla RAM è che si toglie direttamente dalla memoria fisica che può essere utilizzata da SQL Server. Hanno sempre una forte evidenza che l'aggiunta di una cache dei file basata sulla RAM migliora le prestazioni dell'applicazione e non diminuisce altre prestazioni di query o applicazioni.

Tune First

Un'applicazione deve sintonizzarsi per rimuovere ordinamenti e hash non necessari e indesiderati che potrebbero causare l'utilizzo del database tempdb. Molte volte l'aggiunta di un indice può eliminare completamente la necessità di un ordinamento o di un hash nel piano, determinando prestazioni ottimali senza che sia necessario utilizzare il database tempdb.

Punti di vantaggio possibili

I vantaggi derivanti dall'inserimento di un database tempdb su un sistema ad alta velocità possono essere determinati solo mediante testing rigorosi e misure dei carichi di lavoro dell'applicazione. Il carico di lavoro deve essere studiato con attenzione per le caratteristiche a cui il database tempdb potrebbe trarre vantaggio e la sicurezza di I/O deve essere confermata prima della distribuzione.

Le operazioni di ordinamento e hash interagiscono con i responsabili della memoria di SQL Server per determinare le dimensioni dell'area di Scratch in memoria per ogni ordinamento o operazione hash. Non appena i dati di ordinamento o hash superano l'area di Scratch in memoria allocata, è possibile che i dati vengano scritti nel database tempdb. Questo algoritmo è stato espanso in SQL Server 2005, 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'utilizzo di operazioni di database tempdb. Di conseguenza, i guadagni di prestazioni variano significativamente 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 una distribuzione di questo tipo.

SQL Server utilizza il database tempdb per gestire varie attività che coinvolgono ordinamenti, hash, l'archivio versioni delle righe e le tabelle Temp:

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

Eseguire le linee di base con e senza il database tempdb memorizzato nel sottosistema ad alta velocità per confrontare i vantaggi. Parte del test deve includere query sul database degli utenti che non coinvolgono ordinamenti, hash o tabelle temporanee e quindi verificare che tali query non siano influenzate negativamente. Quando si valuta il sistema, possono essere utili gli indicatori di prestazioni seguenti.

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

Qualcosa di simile all'implementazione di un disco RAM basato sulla compressione potrebbe funzionare bene con 10 utenti. Tuttavia, con un aumento del carico di lavoro, potrebbe essere possibile spingere i livelli di CPU oltre i livelli desiderati e avere effetti negativi sul tempo di risposta quando i carichi di lavoro sono alti. Sono consigliati test di stress veri e test di previsione dei carichi futuri.
File di lavoro e azioni di creazione di tabelle di lavoro Se lo spostamento del database tempdb in un dispositivo, ad esempio un disco RAM, cambia il piano di query aumentando il numero o la dimensione dei file di lavoro o delle tabelle di lavoro, indica che la memoria sottratta al pool di buffer causa l'aumento dell'attività del database tempdb. Questo modello indica che la durata della pagina 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 necessaria per i database di SQL Server.

Si supponga che un fornitore di dischi RAM utilizzi un'implementazione di compressione in memoria. È necessario che l'implementazione sia 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 inconsapevole e venga protetto correttamente dall'implementazione sottostante. Esaminare l'esempio di compressione più vicino.

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

Il dispositivo può eseguire le operazioni seguenti per garantire la protezione dei dati del settore 1 quando viene combinata con i dati di Sector 2.

Azione
Blocca tutte le scritture nei settori 1 e 2.
Decomprimere Sector 1 in un'area di Scratch, lasciando l'archiviazione del settore 1 corrente 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.
Archiviazione obsoleta di Exchange per i settori 1 e 2 con nuovo spazio di archiviazione.
Se il tentativo di Exchange ha esito negativo (rollback):
Ripristinare lo spazio di archiviazione originale per i settori 1 e 2.
Rimuovere i dati combinati dei settori 1 e 2 dall'area scratch.
Esito negativo dell'operazione di scrittura del settore 2.
Sblocca la lettura e la scrittura per i settori 1 e 2.

La possibilità di fornire meccanismi di blocco per le modifiche al settore e ripristinare le modifiche apportate quando il tentativo del settore Exchange ha esito negativo viene considerato conforme a una transizione. Per le implementazioni che utilizzano l'archiviazione fisica per il backup esteso, includere gli aspetti del registro delle transazioni appropriato per garantire la protezione e il rollback delle modifiche applicate alle strutture sul 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 venga esposto alla perdita di dati.

Nota

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

Fare attenzione quando si sposta il database tempdb

Prestare particolare attenzione quando si sposta il database tempdb perché, se non è possibile creare il database tempdb, SQL Server non verrà avviato. Se non è possibile creare il database tempdb, avviare SQL Server utilizzando il parametro di avvio (-f) e spostare il database tempdb in un percorso valido.

Per modificare il percorso fisico del database tempdb, eseguire la procedura seguente:

  1. Utilizzare l' ALTER DATABASE istruzione e la clausola MODIFY file per modificare i nomi di file fisici di ogni file nel database tempdb in modo che facciano riferimento alla nuova posizione fisica, 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 una garanzia di compatibilità o sicurezza

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

Supporto

Se si utilizza un sottosistema con SQL Server che supporta le garanzie di I/O per l'utilizzo di database transazionali come descritto in questo articolo, Microsoft fornirà supporto per SQL Server e per le applicazioni basate su SQL Server. Tuttavia, i problemi con, o causati da, il sottosistema verrà riferito al produttore.

Per i problemi relativi al database tempdb, i servizi di supporto Microsoft vi chiederanno di rilocare il database tempdb. Contattare il fornitore del dispositivo per verificare di aver distribuito e configurato correttamente il dispositivo per l'utilizzo del database transazionale.

Microsoft non certifica o verifica che i prodotti di terze parti funzionino correttamente con SQL Server. Inoltre, Microsoft non fornisce alcuna garanzia, fideiussione o dichiarazione di idoneità del prodotto di terze parti per l'utilizzo con SQL Server.

Riferimenti

Per ulteriori informazioni, fare clic sui numeri dell'articolo seguenti per visualizzare gli articoli della Microsoft Knowledge Base:

Le informazioni contenute in questo documento rappresentano la visualizzazione corrente di Microsoft Corporation sui problemi discussi alla data di pubblicazione. Poiché Microsoft deve rispondere alle mutevoli condizioni di mercato, non deve essere interpretato come un impegno da parte di Microsoft e Microsoft non è in grado di garantire l'accuratezza delle informazioni presentate dopo la data di pubblicazione.

Questo white paper è solo a scopo informativo. MICROSOFT NON FORNISCE ALCUNA GARANZIA, ESPRESSA, IMPLICITA O STATUTARIA, IN MERITO ALLE INFORMAZIONI CONTENUTE IN QUESTO DOCUMENTO.

Il rispetto di tutte le applicabili leggi in materia di copyright è esclusivamente a carico dell'utente. Fermi restando tutti i diritti coperti da copyright, nessuna parte di questo documento potrà comunque essere riprodotta o inserita in un sistema di riproduzione o trasmessa in qualsiasi forma e con qualsiasi mezzo (in formato elettronico, meccanico, su fotocopia, come registrazione o altro) per qualsiasi scopo, senza il permesso scritto di Microsoft Corporation.

Microsoft può essere titolare di brevetti, domande di brevetto, marchi, copyright o altri diritti di proprietà intellettuale relativi all'oggetto del presente documento. Salvo quanto espressamente previsto in un contratto scritto di licenza Microsoft, la consegna del presente documento non implica la concessione di alcuna licenza su tali brevetti, marchi, copyright o altra proprietà intellettuale.

© 2006 Microsoft Corporation. Tutti i diritti riservati.

Microsoft, Windows, Windows Server e SQL Server sono marchi o marchi registrati di Microsoft Corporation negli Stati Uniti e/o negli altri paesi.

SQL Server richiede sistemi per il supporto del ' recapito garantito al supporto stabile ' come indicato nei requisiti di programma di affidabilità i/O di SQL Server. Per ulteriori informazioni sui requisiti di input e output per il motore di database di SQL Server, vedere requisiti di input/output del modulo di gestione di database di Microsoft SQL Server.