Descrizione degli algoritmi di registrazione e archiviazione dei dati che estendono l'affidabilità dei dati in SQL Server

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

Riepilogo

Questo articolo illustra in che modo Microsoft SQL Server la registrazione e gli algoritmi di dati estendono l'affidabilità e l'integrità dei dati.

Per altre informazioni sui concetti sottostanti dei motori e su Algorithm for Recovery and Isolation Exploiting Semantics (ARIES), vedere il documento seguente ACM Transactions on Database Systems (in Volume 17, Numero 1, marzo 1992):

Collegamento esterno: ARIES: metodo di recupero delle transazioni che supporta il blocco Fine-Granularity e il rollback parziale tramite la registrazione Write-Ahead

Il documento illustra le tecniche di SQL Server per estendere l'affidabilità e l'integrità dei dati in base agli errori.

È consigliabile leggere gli articoli seguenti della Microsoft Knowledge Base per altre informazioni sulla memorizzazione nella cache e sulle discussioni sulla modalità di errore alternativa:

• Descrizione della memorizzazione nella cache dei controller del disco in SQL Server

• Informazioni sull'uso delle cache delle unità disco con SQL Server che ogni amministratore di database deve conoscere

Termini usati in questo articolo

Prima di iniziare la discussione approfondita, alcuni dei termini usati in questo articolo sono definiti nella tabella seguente.

Termine	Definizione
Batteria supportata	Funzionalità di backup della batteria separate e localizzate direttamente disponibili e controllate dal meccanismo di memorizzazione nella cache per evitare la perdita di dati. Non si tratta di un alimentatore non ininterruttibile . Un gruppo di continuità non garantisce alcuna attività di scrittura e può essere disconnesso dal dispositivo di memorizzazione nella cache.
Cache	Meccanismo di archiviazione intermedio usato per ottimizzare le operazioni di I/O fisiche e migliorare le prestazioni.
Pagina dirty	Pagina contenente modifiche ai dati che devono ancora essere scaricate nell'archiviazione stabile. Per altre informazioni sui buffer di pagine dirty, vedere Scrittura di pagine nella documentazione online di SQL Server. Il contenuto si applica anche a Microsoft SQL Server 2012 e versioni successive.
Fallimento	Qualsiasi elemento che potrebbe causare un'interruzione imprevista del processo di SQL Server. Gli esempi includono: interruzione dell'alimentazione, reimpostazione del computer, errori di memoria, altri problemi hardware, settori non validi, interruzioni dell'unità, errori di sistema e così via.
Sciacquone	Forzatura di un buffer della cache per l'archiviazione stabile.
Fermo	Oggetto di sincronizzazione usato per proteggere la coerenza fisica di una risorsa.
Archiviazione non volatile	Qualsiasi supporto che rimane disponibile tra gli errori di sistema.
Pagina aggiunta	Pagina che rimane nella cache dei dati e non può essere scaricata in un archivio stabile finché tutti i record di log associati non vengono protetti in un percorso di archiviazione stabile.
Archiviazione stabile	Uguale all'archiviazione non volatile.
Archiviazione volatile	Qualsiasi supporto che non rimarrà intatto tra gli errori.

protocollo WAL (Write-Ahead Logging)

Il termine protocollo è un ottimo modo per descrivere WAL. Si tratta di un set specifico e definito di passaggi di implementazione necessari per assicurarsi che i dati vengano archiviati e scambiati correttamente e possano essere ripristinati in uno stato noto in caso di errore. Così come una rete contiene un protocollo definito per lo scambio di dati in modo coerente e protetto, anche wal descrive il protocollo per proteggere i dati.

Il documento ARIES definisce il wal nel modo seguente:

Il protocollo WAL afferma che i record di log che rappresentano le modifiche apportate ad alcuni dati devono essere già presenti nell'archiviazione stabile prima che i dati modificati possano sostituire la versione precedente dei dati nell'archiviazione non volatile. Ovvero, il sistema non è autorizzato a scrivere una pagina aggiornata nella versione di archiviazione non volatile della pagina fino a quando almeno le parti di annullamento dei record di log, che descrivono gli aggiornamenti della pagina sono stati scritti in un archivio stabile.

Per altre informazioni sulla registrazione write-ahead, vedere l'argomento Write-Ahead Transaction Log all'indirizzo SQL Server Documentazione online.

SQL Server e il WAL

SQL Server usa il protocollo WAL. Per assicurarsi che venga eseguito correttamente il commit di una transazione, tutti i record di log associati alla transazione devono essere protetti in un archivio stabile.

Per chiarire questa situazione, prendere in considerazione l'esempio specifico seguente.

Nota

Per questo esempio, si supponga che non sia presente alcun indice e che la pagina interessata sia pagina 150.

BEGIN TRANSACTION
 INSERT INTO tblTest VALUES (1)
COMMIT TRANSACTION

Suddividere quindi l'attività in semplici passaggi di registrazione, come descritto nella tabella seguente.

Istruzione	Azioni eseguite
BEGIN TRANSACTION	Scritto nell'area della cache dei log. Tuttavia, non è necessario scaricare l'archiviazione stabile perché il SQL Server non ha apportato modifiche fisiche.
INSERT INTO tblTest	1. La pagina 150 dei dati viene recuperata nella cache dei dati SQL Server, se non è già disponibile. 2. La pagina viene bloccata, bloccata e contrassegnata come dirty e vengono ottenuti blocchi appropriati. 3. Viene compilato e aggiunto un record di inserimento del log alla cache dei log. 4. Viene aggiunta una nuova riga alla pagina dei dati. 5. Il latch viene rilasciato. 6. I record di log associati alla transazione o alla pagina non devono essere scaricati a questo punto perché tutte le modifiche rimangono nell'archiviazione volatile.
COMMIT TRANSACTION	1. Viene formato un record di log di commit e i record di log associati alla transazione devono essere scritti in un archivio stabile. Il commit della transazione non viene considerato fino a quando i record di log non vengono assegnati correttamente all'archiviazione stabile. 2. La pagina 150 dei dati rimane nella cache dei dati SQL Server e non viene scaricata immediatamente nell'archiviazione stabile. Quando i record di log sono protetti correttamente, il ripristino può ripetere l'operazione, se necessario. 3. I blocchi transazionali vengono rilasciati.

Non confonderti con i termini "blocco" e "registrazione". Anche se importanti, il blocco e la registrazione sono problemi separati quando si gestisce il wal. Nell'esempio precedente, SQL Server in genere contiene il latch a pagina 150 per il tempo necessario per eseguire le modifiche di inserimento fisico nella pagina, non l'intero tempo della transazione. Viene stabilito il tipo di blocco appropriato per proteggere la riga, l'intervallo, la pagina o la tabella in base alle esigenze. Per altre informazioni sui tipi di blocco, vedere le sezioni di blocco della documentazione online di SQL Server.

Esaminando l'esempio in modo più dettagliato, è possibile chiedersi cosa accade quando vengono eseguiti i processi LazyWriter o CheckPoint. SQL Server genera tutti gli scaricamenti appropriati nell'archiviazione stabile per i record di log transazionali associati alla pagina dirty e aggiunta. In questo modo si garantisce che la pagina dei dati del protocollo WAL non possa mai essere scritta in un archivio stabile fino a quando i record di log transazionali associati non sono stati scaricati.

SQL Server e archiviazione stabile

SQL Server migliora le operazioni di log e pagine dati includendo la conoscenza delle dimensioni del settore del disco (in genere 4.096 byte o 512 byte).

Per mantenere le proprietà ACID di una transazione, il SQL Server deve tenere conto dei punti di errore. Durante un errore, molte specifiche dell'unità disco garantiscono solo un numero limitato di operazioni di scrittura del settore. La maggior parte delle specifiche garantisce il completamento di un singolo settore di scrittura quando si verifica un errore.

SQL Server usa pagine di dati da 8 KB e il log (se scaricato) su multipli delle dimensioni del settore. La maggior parte delle unità disco usa 512 byte come dimensione del settore predefinita. In caso di errore, SQL Server può tenere conto delle operazioni di scrittura più grandi di un settore usando la parità di log e tecniche di scrittura strappate.

Rilevamento di pagine strappate

Questa opzione consente SQL Server di rilevare operazioni di I/O incomplete causate da interruzioni dell'alimentazione o altre interruzioni del sistema. Se true, viene capovolto un bit per ogni settore a 512 byte in una pagina di database di 8 kilobyte (KB) ogni volta che la pagina viene scritta su disco. Se uno stato di bit è errato quando la pagina viene letta in seguito da SQL Server, la pagina è stata scritta in modo non corretto. Viene rilevata una pagina strappata. Le pagine strappate vengono rilevate durante il ripristino perché è probabile che qualsiasi pagina scritta in modo non corretto venga letta dal ripristino.

Anche se SQL Server pagine di database sono di 8 KB, i dischi eseguono operazioni di I/O usando un settore a 512 byte. Di conseguenza, vengono scritti 16 settori per pagina di database. Una pagina strappata può verificarsi se il sistema ha esito negativo (ad esempio, a causa di un'interruzione dell'alimentazione) tra il momento in cui il sistema operativo scrive il primo settore a 512 byte su disco e il completamento dell'operazione di I/O da 8 KB. Se il primo settore di una pagina di database viene scritto correttamente prima dell'errore, la pagina del database sul disco verrà visualizzata come aggiornata, anche se potrebbe non essere riuscita.

Usando le cache del controller del disco con batteria, è possibile assicurarsi che i dati vengano scritti correttamente su disco o non scritti affatto. In questo caso, non impostare il rilevamento di pagine strappate su "true" perché non è necessario.

Nota

Il rilevamento di pagine strappate non è abilitato per impostazione predefinita in SQL Server. Per altre informazioni, vedere OPZIONI ALTER DATABASE SET (Transact-SQL).

Parità dei log

Il controllo della parità dei log è simile al rilevamento di pagine strappate. Ogni settore a 512 byte contiene bit di parità. Questi bit di parità vengono sempre scritti con il record di log e valutati quando viene recuperato il record di log. Forzando le scritture dei log su un limite di 512 byte, SQL Server può assicurarsi che le operazioni di commit vengano scritte nei settori del disco fisico.

Impatto sulle prestazioni

Tutte le versioni di SQL Server aprire i file di log e di dati usando la funzione CreateFile Win32. Il membro dwFlagsAndAttributes include l'opzione FILE_FLAG_WRITE_THROUGH quando vengono aperti da SQL Server.

FILE_FLAG_WRITE_THROUGH indica al sistema di scrivere tramite qualsiasi cache intermedia e di passare direttamente al disco. Il sistema può comunque memorizzare nella cache le operazioni di scrittura, ma non può scaricarle pigramente.

L'opzione FILE_FLAG_WRITE_THROUGH garantisce che quando un'operazione di scrittura restituisce un completamento corretto, i dati vengono archiviati correttamente nell'archiviazione stabile. Questo è in linea con il protocollo WAL che garantisce i dati.

Molte unità disco (SCSI e IDE) contengono cache di onboarding di 512 KB, 1 MB o superiori. Tuttavia, le cache delle unità in genere si basano su un condensatore e non su una soluzione con 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. Questo è in particolare il motivo per cui il rilevamento della parità di scrittura e log è stato integrato in SQL Server 7.0 e versioni successive. Man mano che le dimensioni delle unità aumentano, le cache diventano più grandi e possono esporre grandi quantità di dati durante un errore.

Molti fornitori di hardware forniscono soluzioni di controller del disco con batteria. Queste cache del controller possono mantenere i dati nella cache per diversi giorni e persino consentire l'inserimento dell'hardware di memorizzazione nella cache in un secondo computer. Quando l'alimentazione viene ripristinata correttamente, i dati non scritti vengono scaricati prima che sia consentito l'ulteriore accesso ai dati. Molti di essi consentono di stabilire una percentuale di cache di lettura e scrittura per ottenere prestazioni ottimali. Alcuni contengono aree di archiviazione di memoria di grandi dimensioni. Infatti, per un segmento specifico del mercato, alcuni fornitori di hardware forniscono sistemi di controller di memorizzazione nella cache del disco con batteria di fascia alta con 6 GB di cache. Queste funzionalità possono migliorare significativamente le prestazioni del database.

Le implementazioni avanzate di memorizzazione nella cache gestiranno la FILE_FLAG_WRITE_THROUGH richiesta non disabilitando la cache del controller perché possono fornire funzionalità di riscrittura reali in caso di reimpostazione del sistema, interruzione dell'alimentazione o altro punto di errore.

I trasferimenti di I/O senza l'uso di una cache possono essere più lunghi a causa del tempo meccanico necessario per spostare le teste di trasmissione, la velocità di rotazione e altri fattori limitanti.

Ordinamento del settore

Una tecnica comune usata per aumentare le prestazioni di I/O è l'ordinamento del settore. Per evitare lo spostamento meccanico della testa, le richieste di lettura/scrittura vengono ordinate, consentendo un movimento più coerente della testa per recuperare o archiviare i dati.

La cache può contenere più richieste di scrittura di log e dati contemporaneamente. Il protocollo WAL e l'implementazione SQL Server del protocollo WAL richiedono lo scaricamento delle scritture di log nell'archiviazione stabile prima che sia possibile eseguire la scrittura della pagina. Tuttavia, l'uso della cache potrebbe restituire l'esito positivo da una richiesta di scrittura del log senza che i dati vengano scritti nell'unità effettiva, ovvero scritti in un archivio stabile. Ciò può comportare SQL Server l'emissione della richiesta di scrittura della pagina dati.

Con il coinvolgimento della cache di scrittura, i dati vengono ancora considerati nell'archiviazione volatile. Tuttavia, dalla chiamata WriteFile dell'API Win32, esattamente come SQL Server vede l'attività, è stato ottenuto un codice restituito riuscito. SQL Server o qualsiasi processo che usa la chiamata API WriteFile può determinare solo che i dati hanno ottenuto correttamente l'archiviazione stabile.

A scopo di discussione, si supponga che tutti i settori della pagina dei dati siano ordinati per la scrittura prima dei settori dei record di log corrispondenti. Ciò viola immediatamente il protocollo WAL. La cache sta scrivendo una pagina di dati prima dei record di log. A meno che la cache non sia completamente supportata dalla batteria, un errore può causare risultati catastrofici.

Quando si valutano i fattori di prestazioni ottimali per un server di database, è necessario considerare molti fattori. Il più importante di questi è: "Il sistema consente funzionalità valide FILE_FLAG_WRITE_THROUGH ?"

Nota

Qualsiasi cache in uso deve supportare completamente una soluzione con batteria. Tutti gli altri meccanismi di memorizzazione nella cache sono soggetti a danneggiamento dei dati e perdita di dati. SQL Server fa tutto il possibile per garantire il wal abilitando FILE_FLAG_WRITE_THROUGH.

I test hanno dimostrato che molte configurazioni di unità disco possono contenere memorizzazione nella cache di scrittura senza il backup appropriato della batteria. Le unità SCSI, IDE ed EIDE sfruttano appieno le cache di scrittura. Per altre informazioni sul funzionamento degli SSD con SQL Server, vedere l'articolo del blog CSS SQL Server Engineers seguente:

SQL Server e SSD - Note sull'apprendimento di RDORR - Parte 1

In molte configurazioni, l'unico modo per disabilitare correttamente la memorizzazione nella cache di scrittura di un'unità IDE o EIDE consiste nell'usare un'utilità del produttore specifica o i jumper presenti nell'unità stessa. Per assicurarsi che la cache di scrittura sia disabilitata per l'unità stessa, contattare il produttore dell'unità.

Le unità SCSI hanno anche cache di scrittura. Tuttavia, queste cache possono in genere essere disabilitate dal sistema operativo. In caso di domande, contattare il produttore dell'unità per le utilità appropriate.

Stacking della cache di scrittura

Lo stacking della cache di scrittura è simile all'ordinamento del settore. La definizione seguente è stata presa direttamente dal sito Web di un produttore di unità IDE leader:

In genere, questa modalità è attiva. La modalità cache di scrittura accetta i dati di scrittura dell'host nel buffer fino a quando il buffer non è pieno o il trasferimento host è completato.

Un'attività di scrittura su disco inizia a archiviare i dati host su disco. I comandi di scrittura dell'host continuano a essere accettati e i dati vengono trasferiti nel buffer fino a quando lo stack di comandi di scrittura non è pieno o il buffer di dati è pieno. L'unità può riordinare i comandi di scrittura per ottimizzare la velocità effettiva dell'unità.

Riallocazione automatica scrittura (AWR)

Un'altra tecnica comune usata per proteggere i dati consiste nel rilevare i settori non validi durante la manipolazione dei dati. La spiegazione seguente proviene da un sito Web leader del produttore di unità IDE:

Questa funzionalità fa parte della cache di scrittura e riduce il rischio di perdita di dati durante le operazioni di scrittura posticipate. Se si verifica un errore del disco durante il processo di scrittura del disco, l'attività disco viene arrestata e il settore sospetto viene riassegnato a un pool di settori alternativi che si trovano alla fine dell'unità. Dopo la ridistribuzione, l'attività di scrittura del disco continua fino al completamento.

Questa può essere una funzionalità potente se viene fornito il backup della batteria per la cache. In questo modo viene apportata una modifica appropriata al riavvio. È preferibile rilevare gli errori del disco, ma la sicurezza dei dati del protocollo WAL richiede di nuovo che questa operazione venga eseguita in tempo reale e non in modo posticipato. All'interno dei parametri WAL, la tecnica AWR non può tenere conto di una situazione in cui la scrittura del log ha esito negativo a causa di un errore di settore, ma l'unità è piena. Il motore di database deve conoscere immediatamente l'errore in modo che la transazione possa essere interrotta correttamente, l'amministratore possa ricevere un avviso e correggere i passaggi eseguiti per proteggere i dati e correggere la situazione di errore multimediale.

Sicurezza dei dati

Esistono diverse precauzioni che un amministratore del database deve adottare per garantire la sicurezza dei dati.

• È sempre consigliabile assicurarsi che la strategia di backup sia sufficiente per il ripristino da un errore irreversibile. L'archiviazione esterna e altre precauzioni sono appropriate.
• Testare frequentemente l'operazione di ripristino del database in un database secondario o di test.
• Assicurarsi che tutti i dispositivi di memorizzazione nella cache possano gestire tutte le situazioni di errore (interruzione dell'alimentazione, settori non validi, unità non riuscite, interruzione del sistema, blocchi, picco di alimentazione e così via).
• Assicurarsi che il dispositivo di memorizzazione nella cache:
  • Ha il backup integrato della batteria
  • Può ripubblicare scritture durante l'accensione
  • Può essere completamente disabilitato se necessario
  • Gestisce la modifica del mapping del settore non valido in tempo reale
• Abilitare il rilevamento di pagine strappate. Questo ha un effetto minimo sulle prestazioni.
• Configurare le unità RAID consentendo uno scambio frequente di un'unità disco non valida, se possibile.
• Usare controller di memorizzazione nella cache più recenti che consentono di aggiungere più spazio su disco senza riavviare il sistema operativo. Questa può essere una soluzione ideale.

Test delle unità

Per proteggere completamente i dati, è necessario assicurarsi che la memorizzazione nella cache di tutti i dati sia gestita correttamente. In molte situazioni, è necessario disabilitare la memorizzazione nella cache di scrittura dell'unità disco.

Nota

Assicurarsi che un 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'intensa attività di lettura/scrittura asincrona in un dispositivo dati simulato e in un dispositivo di log. Le statistiche sulle prestazioni di test mostrano le operazioni di scrittura medie al secondo tra 50 e 70 per un'unità con memorizzazione nella cache di scrittura disabilitata e un intervallo di RPM compreso tra 5.200 e 7.200.

Per altre informazioni sull'utilità SQLIOSim , vedere l'articolo seguente della Microsoft Knowledge Base:

Come usare l'utilità SQLIOSim per simulare l'attività SQL Server in un sottosistema del disco

Molti produttori di computer ordinano le unità con la cache di scrittura disabilitata. Tuttavia, il test mostra che questo potrebbe non essere sempre il caso. Pertanto, testare sempre completamente.

Dispositivi dati

In tutte le situazioni tranne che non registrate, SQL Server richiederanno solo lo scaricamento dei record di log. Quando si eseguono operazioni non registrate, anche le pagine di dati devono essere scaricate in un archivio stabile; Non sono presenti record di log singoli per rigenerare le azioni in caso di errore.

Le pagine di dati possono rimanere nella cache fino a quando il processo LazyWriter o CheckPoint non le scarica nell'archiviazione stabile. L'uso del protocollo WAL per assicurarsi che i record di log siano archiviati correttamente garantisce che il ripristino possa ripristinare una pagina dati in uno stato noto.

Ciò non significa che è consigliabile inserire i file di dati in un'unità memorizzata nella cache. Quando il SQL Server scarica le pagine di dati in un archivio stabile, i record di log possono essere troncati dal log delle transazioni. Se le pagine di dati vengono archiviate nella cache volatile, è possibile troncare i record di log che verranno usati per ripristinare una pagina in caso di errore. Assicurarsi che i dispositivi di dati e di log supportano correttamente lo spazio di archiviazione stabile.

Aumento delle prestazioni

La prima domanda che potrebbe verificarsi è: "Ho un'unità IDE che stava memorizzando nella cache. Ma quando l'ho disabilitato, le mie prestazioni sono diventate meno del previsto. Perché?

Molte delle unità IDE testate da Microsoft vengono eseguite a 5.200 RPM e le unità SCSI a 7.200 RPM. Quando si disabilita la memorizzazione nella cache di scrittura dell'unità IDE, le prestazioni meccaniche possono diventare un fattore.

Per risolvere la differenza di prestazioni, il metodo da seguire è chiaro: "Indirizzare la frequenza delle transazioni".

Molti sistemi OLTP (Online Transaction Processing) richiedono una frequenza di transazioni elevata. Per questi sistemi, prendere in considerazione l'uso di un controller di memorizzazione nella cache in grado di supportare una cache di scrittura e fornire il miglioramento delle prestazioni desiderato garantendo al tempo stesso l'integrità dei dati.

Per osservare modifiche significative delle prestazioni che si verificano in SQL Server in un'unità di memorizzazione nella cache, la frequenza delle transazioni è stata aumentata usando transazioni di piccole dimensioni.

I test mostrano che l'attività di scrittura elevata di buffer inferiori a 512 KB o superiori a 2 MB può causare prestazioni lente.

Si prenda in considerazione l'esempio riportato di seguito.

CREATE TABLE tblTest ( iID int IDENTITY(1,1), strData char(10))
GO

SET NOCOUNT ON
GO

INSERT INTO tblTest VALUES ('Test')
WHILE @@IDENTITY < 10000
INSERT INTO tblTest VALUES ('Test')

Di seguito sono riportati i risultati dei test di esempio per SQL Server:

SCSI(7200 RPM) 84 seconds
SCSI(7200 RPM) 15 seconds (Caching controller)

IDE(5200 RPM) 14 seconds (Drive cache enabled)
IDE(5200 RPM) 160 seconds

Il processo di wrapping dell'intera serie di INSERT operazioni in una singola transazione viene eseguito in circa quattro secondi in tutte le configurazioni. Ciò è dovuto al numero di scaricamenti di log necessari. Se non si crea una singola transazione, ogni INSERT transazione viene elaborata come transazione separata. Pertanto, tutti i record di log per la transazione devono essere scaricati. Ogni scaricamento ha dimensioni pari a 512 byte. Ciò richiede un intervento significativo dell'azionamento meccanico.

Quando si usa una singola transazione, è possibile aggregare i record di log per la transazione e usare una singola scrittura di dimensioni maggiori per scaricare i record di log raccolti. Ciò riduce significativamente l'intervento meccanico.

Avviso

È consigliabile non aumentare l'ambito della transazione. Le transazioni a esecuzione prolungata possono causare un blocco eccessivo e indesiderato e un sovraccarico maggiore. Usare i contatori delle prestazioni SQL Server:D atabases SQL Server per visualizzare i contatori basati sul log delle transazioni. In particolare, i byte di log scaricati/sec possono indicare molte transazioni di piccole dimensioni che possono causare un'elevata attività del disco meccanico.

Esaminare le istruzioni associate allo scaricamento del log per determinare se è possibile ridurre il valore di Log Bytes Flushed/sec. Nell'esempio precedente è stata usata una singola transazione. Tuttavia, in molti scenari ciò può causare un comportamento di blocco indesiderato. Esaminare la progettazione della transazione. È possibile usare codice simile al codice seguente per eseguire batch per ridurre l'attività di scaricamento dei log frequente e ridotta:

BEGIN TRAN
GO

INSERT INTO tblTest VALUES ('Test')
WHILE @@IDENTITY < 50
    BEGIN
        INSERT INTO tblTest VALUES ('Test')
  
        if(0 = cast(@@IDENTITY as int) % 10)
        BEGIN
            PRINT 'Commit tran batch'
            COMMIT TRAN
            BEGIN TRAN
        END
    END
GO

COMMIT TRAN
GO

SQL Server richiede che i sistemi supportano il recapito garantito a supporti stabili, come descritto nel documento di download SQL Server I/O Reliability Program Review Requirements . Per altre informazioni sui requisiti di input e output per il motore di database SQL Server, vedere requisiti di input/output motore di database di Microsoft SQL Server.