Al momento sei offline in attesa che la connessione Internet venga ristabilita

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

IMPORTANTE: il presente articolo è stato tradotto tramite un software di traduzione automatica di Microsoft ed eventualmente revisionato dalla community Microsoft tramite la tecnologia CTF (Community Translation Framework) o da un traduttore professionista. Microsoft offre articoli tradotti manualmente e altri tradotti automaticamente e rivisti dalla community con l’obiettivo di consentire all'utente di accedere a tutti gli articoli della Knowledge Base nella propria lingua. Tuttavia, un articolo tradotto automaticamente, anche se rivisto dalla community, non sempre è perfetto. Potrebbe contenere errori di vocabolario, di sintassi o di grammatica. Microsoft declina ogni responsabilità per imprecisioni, errori o danni causati da una traduzione sbagliata o dal relativo utilizzo da parte dei clienti. Microsoft aggiorna frequentemente il software e gli strumenti di traduzione automatica per continuare a migliorare la qualità della traduzione.

230785
Sommario
In questo articolo viene descritto come gli algoritmi di registrazione e dati di Microsoft SQL Server estendono l'integrità e l'affidabilità dei dati.

Per ulteriori informazioni sui concetti di base dei motori e su ARIES (algoritmo per la semantica di sfruttamento di isolamento e ripristino), vedere le seguenti transazioni ACM nel documento di sistemi di Database (in "Volume 17, numero 1, marzo 1992):

L'autore di questo documento è C. Mohan. Il documento affronta le tecniche di SQL Server per estendere l'affidabilità dei dati e l'integrità in relazione a errori.

Si consiglia di leggere i seguenti articoli della Microsoft Knowledge Base per ulteriori informazioni sulla memorizzazione nella cache e discussioni di modalità alternative di errore:
86903 Descrizione della memorizzazione nella cache del controller del disco in SQL Server
234656 Informazioni sull'utilizzo di cache del disco con SQL Server che è necessario conoscere ogni amministratore del database
Informazioni
Prima di iniziare la discussione più approfondita, alcuni dei termini utilizzati nel corso di questo articolo sono definiti nella tabella seguente.
TermineDefinizione
BatteriaBatteria separata e localizzate funzionalità di backup direttamente disponibili e controllato dal meccanismo di memorizzazione nella cache per evitare la perdita di dati.
Nota Non si tratta di un gruppo di continuità (UPS). Un gruppo di continuità non garantisce tutte le attività di scrittura e può essere disconnesso dal dispositivo di memorizzazione nella cache.
CacheMeccanismo di memorizzazione intermedia utilizzato per ottimizzare le operazioni dei / o fisiche e migliorare le prestazioni.
Pagina dirtyPagina contenente le modifiche dei dati che devono ancora essere scaricato di archiviazione stabile. Per ulteriori informazioni sui buffer di pagina dirty, vedere la "Creazione di pagine"argomento relativo alla documentazione in linea di SQL Server.
Nota Il contenuto si applica anche a Microsoft SQL Server 2012 e versioni successive.
ErroreTutto ciò che potrebbe causare un'interruzione imprevista del processo di SQL Server. Alcuni esempi: alimentazione interruzione, ripristino del computer, errori di memoria, altri problemi hardware, settori danneggiati, interruzioni dell'unità, gli errori di sistema e così via.
SvuotamentoImposizione di un buffer di cache per l'archiviazione stabile.
LatchOggetto di sincronizzazione utilizzato per proteggere la consistenza fisica di una risorsa.
Archiviazione non volatileQualsiasi supporto che rimane disponibile in caso di errori di sistema.
Pagina bloccataPagina che rimane nei dati memorizzati nella cache e non possono essere scaricati di archiviazione stabile fino a quando tutti i record di log associato sono protetti in un percorso di archiviazione stabile.
Archiviazione stabileUguale a memoria non volatile.
Memoria volatileQualsiasi supporto che non rimangono invariata in caso di errori.

Protocollo di registrazione Write-Ahead (WAL)

Il protocollo di termine è un modo eccellente per descrivere WAL. È un oggetto specifico e archiviato e scambiati correttamente insieme definito di operazioni di implementazione per assicurarsi che i dati necessari e possono essere recuperate in uno stato noto in caso di errore. Proprio come una rete contiene un protocollo definito per lo scambio di dati in modo coerenza e protetto in modo troppo il WAL descrivere il protocollo per la protezione dei dati.

Il documento ARIES definisce la WAL nel modo seguente:
Il protocollo WAL asserisce che il record del log che rappresentano modifiche ad alcuni dati deve essere già in archiviazione stabile prima che i dati modificati sono consentiti sostituire la versione precedente dei dati nella memoria non volatile. Ovvero, il sistema non è consentito scrivere una pagina aggiornata alla versione di archiviazione non volatile della pagina fino a quando almeno le parti di annullamento dei record di registro che descrivono gli aggiornamenti alla pagina sono stati scritti per archiviazione stabile.
Per ulteriori informazioni sulla registrazione write-ahead, vedere la Log delle transazioni Write-Ahead argomento nella documentazione in linea di SQL Server.

SQL Server e il WAL

SQL Server utilizza il protocollo WAL. Per assicurarsi che una transazione viene eseguito correttamente, è necessario proteggere tutti i record di registro associato alla transazione nell'archiviazione stabile.

Per chiarire questa situazione, considerare il seguente esempio specifico.

Nota In questo esempio si presuppone che non vi sia alcun indice e che la pagina interessata è pagina 150.
BEGIN TRANSACTION   INSERT INTO tblTest VALUES (1)COMMIT TRANSACTION				
A questo punto, suddividere l'attività in passaggi di registrazione semplicistico, come descritto nella seguente tabella.
IstruzioneAzioni eseguite
INIZIO TRANSAZIONEScritto per l'area della cache di registro. Tuttavia, non è necessario svuotare di archiviazione stabile perché il SQL Server non ha effettuato le modifiche fisiche.
INSERT INTO tblTest
  1. Dati pagina 150 viene recuperati nella cache di dati di SQL Server, se non è già disponibile.
  2. La pagina è latch, bloccato, e contrassegnata come dirty, e vengono ottenuti blocchi appropriati.
  3. Un record di Log inserire è creato e aggiunto alla cache di registro.
  4. Una nuova riga viene aggiunto alla pagina di dati.
  5. La serratura viene rilasciata.
  6. I record di log associato alla transazione o la pagina non deve essere scaricato a questo punto, poiché tutte le modifiche rimangono nella memoria volatile.
COMMIT DELLA TRANSAZIONE
  1. Un record di Log Commit viene formato e i record di log associati alla transazione devono essere scritta di archiviazione stabile. La transazione non è considerata impegnato fino a quando i record di log vengono assegnati correttamente all'archiviazione stabile.
  2. Dati pagina 150 rimangono nella cache di dati di SQL Server e non vengano immediatamente scaricati archiviazione stabile. Quando sono protetto correttamente i record del log, ripristino possibile ripetere l'operazione, se necessario.
  3. Transazionali blocchi vengono rilasciati.
Non confondere i termini "blocco" e "registrazione". Sebbene sia importante, blocco e registrazione sono problemi distinti quando si gestiscono con la WAL. Nell'esempio precedente, SQL Server in genere contiene il latch nella pagina 150 per il tempo necessari per eseguire le modifiche di inserimento fisico della pagina, non tutto il tempo della transazione. Il tipo di blocco appropriata viene stabilito per proteggere la riga, intervallo, pagina o tabella in base alle esigenze. Vedere le sezioni di blocco di documentazione in linea di SQL Server per ulteriori informazioni sui tipi di blocco.

Osservando l'esempio in modo più dettagliato, si potrebbe chiedere cosa succede quando esegue i processi LazyWriter o punto di arresto. SQL Server 7 problemi tutte le cancellazioni appropriati per l'archiviazione per i record di registro delle transazioni associate alla pagina dirty e bloccata stabile. Ciò garantisce che la pagina di dati del protocollo WAL non è possibile scrivere mai per archiviazione stabile fino a quando non sono stati scaricati i record del log delle transazioni associati.

Archiviazione di SQL Server e stabile

SQL Server migliora la pagina operazioni di registro e dati includendo la conoscenza delle dimensioni di settore del disco (comunemente 4.096 o 512 byte).

Per mantenere le proprietà di una transazione ACID, necessario considerare punti di errore di SQL Server. In caso di errore diverse unità disco specifiche garantiscono solo una quantità limitata di operazioni di scrittura del settore. La maggior parte delle specifiche di garantire il completamento di un'operazione di scrittura di settore singolo quando si verifica un errore.

SQL Server viene utilizzato pagine di dati di 8 KB e il registro (se scaricato) multipli della dimensione del settore. (La maggior parte delle unità disco utilizzare 512 byte come la dimensione del settore). In questo caso, SQL Server può rappresentare le operazioni di scrittura superiori a un settore mediante l'utilizzo di tecniche di scrittura incompleta e parità di registro.

Rilevazione delle pagine incomplete

Questa opzione consente di SQL Server rilevare le operazioni dei / o incomplete causate da interruzioni di alimentazione o altre interruzioni del sistema. Quando è true, comporta alcuni capovolgimento per ogni settore di 512 byte in una pagina di database di 8 kilobyte (KB) ogni volta che la pagina viene scritta su disco. Se un bit è nello stato adatto quando la pagina viene letta da SQL Server, quindi la pagina è stata scritta in modo errato. una pagina incompleta viene rilevata. Pagine incomplete vengono in genere rilevate durante il ripristino poiché sono probabile che vengano lette tutte le pagine che è stato scritto correttamente.

Anche se le pagine del database di SQL Server sono di 8 KB, dischi consente di eseguire operazioni dei / o utilizzando un settore di 512 byte. Di conseguenza, vengono scritti 16 settori per ogni pagina del database. Una pagina incompleta può verificarsi se il sistema non riesce (ad esempio, a causa di un'interruzione dell'alimentazione) tra il momento in cui il sistema operativo scrive il primo settore di 512 byte su disco e il completamento dell'operazione dei / o di 8 KB. Se il primo settore di una pagina di database vengano scritti correttamente prima dell'errore, la pagina di database su disco sembrerà aggiornata, sebbene non venga completata.

Utilizzando la cache del controller di disco batteria, è possibile assicurarsi che i dati vengano scritti correttamente su disco o non scritti del tutto. In questo caso, non impostare rilevamento pagine incomplete su "true" perché non è necessaria.

Nota Per impostazione predefinita in SQL Server non è attivato il rilevamento di pagine incomplete. Per ulteriori informazioni, vedere il seguente sito Web MSDN:

Registro parità

Registro controllo della parità è molto simile al rilevamento pagine incomplete. Ogni settore di 512 byte contiene bit di parità. Questi bit di parità vengono sempre scritti con il record del log e valutati quando viene recuperato il record del log. Imposizione di scrittura su un limite di 512 byte, SQL Server può essere certi che le operazioni di commit vengono scritte completamente i settori del disco fisico.

Versioni di SQL Server precedenti alla 7.0

Versioni di SQL Server precedenti alla 7.0 non fornivano registro parità o impianti di rilevamento bit incompleta. Infatti, tali versioni possono scrivere la stessa pagina del registro più volte fino a quando i record di log riempire la pagina di log di 2 KB. Ciò consente di esporre le transazioni che hanno eseguito correttamente il commit. Se la pagina di log da riscrivere in caso di errore, un settore con il commit delle transazioni non venga riscritto correttamente.

Impatto sulle prestazioni

Tutte le versioni di SQL Server utilizzando la funzione Win32CreateFile per aprire i file di registro e dati. Il membro dwFlagsAndAttributes include l'opzione FILE_FLAG_WRITE_THROUGHquando vengono aperti da SQL Server.
FILE_FLAG_WRITE_THROUGH
Indica al sistema di scrivere le cache intermedie e accedere direttamente al disco. Il sistema può memorizzare nella cache ancora le operazioni di scrittura, ma in modalità differita non può cancellare.

L'opzione FILE_FLAG_WRITE_THROUGH garantisce che quando un'operazione di scrittura termina con esito positivo, i dati vengono archiviati correttamente nell'archiviazione stabile. Ciò è in linea con il protocollo WAL che garantisce i dati.
Molte unità disco (SCSI e IDE) contengono le cache integrate di 512 KB, 1 MB o superiore. Tuttavia, le cache del disco si basano generalmente su un condensatore e non una soluzione di batteria. Questi meccanismi di caching non garantisce il ciclo di operazioni di scrittura in un risparmio di energia o punto di errore simile. Essi garantiscono soltanto il completamento delle operazioni di scrittura del settore. Si tratta in particolare perché la scrittura incompleta e rilevamento di parità di registro sono stati creati in SQL Server 7.0 e versioni successive. Come le unità continuano a crescere in dimensioni, le cache diventano più grandi e possono esporre grandi quantità di dati in caso di errore.

Molti fornitori di hardware offrono soluzioni controller disco batteria. Queste cache del controller possono gestire i dati nella cache per diversi giorni e può persino consentire la memorizzazione nella cache hardware venga inserito in un secondo computer. Quando l'alimentazione viene ripristinata correttamente, i dati non scritta completamente viene svuotati prima di consentire l'accesso ai dati ulteriore. Molti dei quali consentono una percentuale di lettura e la cache in scrittura da stabilire per prestazioni ottimali. Alcuni contengono aree di archiviazione di grandi quantità di memoria. Infatti, per un segmento specifico del mercato, alcuni fornitori di hardware forniscono high-end disco batteria sistemi controller con 6 GB di cache di memorizzazione nella cache. Questi possono migliorare significativamente le prestazioni del database.

Memorizzazione nella cache implementazioni avanzate handle il FILE_FLAG_WRITE_THROUGH richiesta non è disattivata la cache del controller perché garantiscono true riscriverà funzionalità in caso di riavvio del sistema, interruzione dell'alimentazione o altro punto di errore.

Trasferimenti dei / o senza l'utilizzo di una cache possono essere causa di tempi notevolmente superiori al tempo meccanico che serve per spostare le testine del disco, velocità di rotazione e altri fattori limitanti.

Ordinamento di settore

Una tecnica comune utilizzata per migliorare le prestazioni dei / o è il settore di ordinamento. Per evitare lo spostamento della testina meccanico vengono ordinate le richieste di lettura/scrittura, consentendo un movimento più uniforme della testa per recuperare o memorizzare i dati.

La cache è in grado di contenere più log e le richieste di scrittura dei dati allo stesso tempo. Il protocollo WAL e l'implementazione di SQL Server del protocollo WAL richiedono lo svuotamento del log scrive di archiviazione stabile prima che la scrittura della pagina può essere rilasciata. Tuttavia, utilizzo della cache potrebbe restituire successo da una richiesta di scrittura registro senza dati da scrivere per l'unità effettiva (ovvero, scritto per archiviazione stabile). Ciò può portare all'invio della richiesta di scrittura pagina di dati di SQL Server.

Con la partecipazione di cache di scrittura, i dati sono ancora considerati sia nella memoria volatile. Tuttavia, dalla chiamata Win32 API WriteFile, esattamente come SQL Server rileva l'attività, un codice di esito positivo è stato ottenuto. SQL Server oppure un processo che utilizza la chiamata diWriteFileAPI può determinare onlythat i dati correttamente ha ottenuto archiviazione stabile.

Ai fini della discussione, si supponga che tutti i settori della pagina di dati sono ordinati per scrivere prima i settori dei record di registro corrispondente. Questo viola immediatamente il protocollo WAL. La cache scrive una pagina di dati prima del record del log. A meno che la cache è completamente batteria, un guasto può causare risultati catastrofici.

Quando si valuta i fattori di prestazioni ottimali per un server di database, esistono molti fattori da considerare. È la più importante, "Il sistema consente funzionalità FILE_FLAG_WRITE_THROUGH valido?"

Nota Tutte le cache che sono completamente usingmust supporta una soluzione per la batteria. Tutti gli altri meccanismi di memorizzazione nella cache sono sospette di danneggiamento dei dati e la perdita di dati. SQL Server si impegna a garantire il WAL attivando FILE_FLAG_WRITE_THROUGH.

Test hanno dimostrato che molte configurazioni di unità disco possono contenere la cache in scrittura senza l'appropriato batteria di backup. Unità SCSI, IDE ed EIDE sfruttare appieno le cache di scrittura. Per ulteriori informazioni sull'utilizzo di SSDs con SQL Server, vedere il seguente articolo del Blog di tecnici di CSS SQL Server:


In molte configurazioni, l'unico modo per disattivare correttamente la cache in scrittura di un disco IDE o EIDE è utilizzando un'utilità di un produttore specifico oppure tramite i ponticelli sull'unità stessa. Per assicurarsi che la cache in scrittura è disabilitata per l'unità stessa, contattare il produttore dell'unità.

Unità SCSI dispongono anche di cache di scrittura. Tuttavia, queste cache comunemente possono essere disattivate dal sistema operativo. Se esiste qualsiasi domanda, contattare il produttore dell'unità per utilità appropriato.

Scrittura della Cache di sovrapposizione

Scrittura che cache Stacking è simile all'ordinamento di settore. Direttamente dal sito Web del produttore unità IDE iniziale è stata scattata la seguente definizione:
In genere, questa modalità è attiva. La modalità cache accetta che fino a quando il buffer è pieno o del trasferimento di host, l'host scrittura dati nel buffer di scrittura.

Inizia un'attività di scrittura su disco memorizzare i dati di host su disco. Comandi di scrittura host continuano a essere accettato e trasferire i dati nel buffer fino a quando non lo stack di comando di scrittura è completo o al riempimento del buffer di dati. L'unità può riordinare i comandi di scrittura per ottimizzare la velocità effettiva dell'unità.

Riassegnazione automatica scrittura (AWR)

Un'altra tecnica comune utilizzata per proteggere i dati è di rilevare i settori danneggiati durante la manipolazione dei dati. La spiegazione che segue proviene dal sito Web del produttore unità IDE iniziali:
Questa funzionalità fa parte della cache in scrittura e riduce il rischio di perdita di dati durante le operazioni di scrittura posticipata. Se si verifica un errore di disco durante il processo di scrittura su disco, le interruzioni di attività del disco e il settore sospetto viene riallocato a un pool di settori alternativi che si trovano alla fine dell'unità. Dopo la riassegnazione dell'attività di scrittura su disco continua fino al completamento.
Può trattarsi di una funzionalità molto potente, se la batteria di backup è disponibile per la cache. In questo modo le modifiche appropriate al momento del riavvio. Si consiglia di rilevare gli errori del disco, ma la protezione dei dati del protocollo WAL nuovamente sia richiesta per essere eseguita a tempo reale e non in modalità posticipata. Entro i parametri WAL, la tecnica AWR non può compensare una situazione in cui un'operazione di scrittura registro ha esito negativo a causa di un errore di settore, ma l'unità è piena. Il motore di database deve immediatamente avvertono l'errore in modo che la transazione può essere interrotta correttamente, l'amministratore può ricevere un avviso e correggere le misure adottate per proteggere i dati e risolvere la situazione di errore media.

Sicurezza dei dati

Esistono diverse precauzioni che dovrà essere un amministratore del database per garantire la sicurezza dei dati.
  • È sempre buona norma assicurarsi che la strategia di backup è sufficiente per il ripristino da un errore irreversibile. L'archiviazione fuori sede e altre precauzioni sono appropriate.
  • Test dell'operazione di ripristino di database in un database secondario o del database di test frequentemente.
  • Assicurarsi che le periferiche di memorizzazione nella cache è in grado di gestire tutte le situazioni di errore (interruzione dell'alimentazione, settori danneggiati, dischi danneggiati, interruzione del sistema, blocchi, picco di alimentazione e così via).
  • Assicurarsi che il dispositivo di memorizzazione nella cache:
    • Batteria di backup è stato integrato
    • Possibile nuova edizione scrive sul accendere
    • Può essere completamente disabilitato se è necessario
    • Gestisce la modifica del settore danneggiato in tempo reale
  • Abilita errata rilevazione delle pagine. (Ha un impatto minimo sulle prestazioni).
  • Configurare dischi RAID consentendo di un hot swap di un'unità disco non valida, se possibile.
  • Utilizzare il controller di memorizzazione nella cache più recenti che consentono di aggiungere ulteriore spazio su disco senza riavviare il sistema operativo. Può trattarsi di una soluzione ideale.

Test di unità

Per proteggere completamente i dati, è necessario assicurarsi che tutte le cache di dati viene gestito correttamente. In molte situazioni, è necessario disattivare la cache in scrittura del disco.

Nota Assicurarsi che un'alternativa meccanismo di caching correttamente è in grado di gestire più tipi di errore.

Microsoft ha eseguito test su più unità SCSI e IDE utilizzando l'utilità SQLIOSim . Questa utilità simula l'attività di lettura/scrittura asincrona pesante per una periferica dati simulati e registro. Le statistiche sulle prestazioni test mostrano le operazioni di scrittura media al secondo tra 50 e 70 per un'unità con la cache di scrittura disattivato e un intervallo di giri/min tra 5,200 e 7,200.

Per ulteriori informazioni sull'utilità SQLIOSim exe, vedere il seguente articolo della Microsoft Knowledge Base:
231619 Come utilizzare l'utilità SQLIOSim per simulare l'attività di SQL Server in un sottosistema disco
Molti produttori di computer l'unità dell'ordine facendo in modo che la cache in scrittura disabilitata. Tuttavia, i test mostrano che non sempre è possibile il caso. Pertanto, verificare sempre completamente.

Dispositivi di dati

In situazioni di tutti ma non registrata di SQL Server richiede solo i record di registro da eliminare. Quando si effettuano operazioni non registrate, le pagine di dati devono essere svuotate anche per l'archiviazione stabile. non sono presenti record di registro individuali per rigenerare le azioni in caso di errore.

Le pagine di dati possono rimanere nella cache fino a quando il processo LazyWriter o punto di arresto il salvataggio archiviazione stabile. Utilizzando il protocollo WAL per assicurarsi che i record di log vengono memorizzati correttamente assicura che ripristino possibile ripristinare una pagina di dati in uno stato noto.

Questo non significa che è preferibile inserire i file di dati in un'unità memorizzato nella cache. Quando il SQL Server Cancella le pagine di dati per l'archiviazione stabile, i record di log possono essere troncati dal log delle transazioni. Se le pagine di dati sono memorizzate nella cache volatile, è possibile troncare i record del log che verrebbero utilizzati per recuperare una pagina in caso di errore. Assicurarsi che i dispositivi i dati e il registro deve contenere correttamente archiviazione stabile.

Aumento delle prestazioni

È la prima domanda che si verifica: "ho un'unità IDE che è stata la memorizzazione nella cache. Ma quando è stato disattivato, le prestazioni è diventato notevolmente inferiore al previsto. Perché?"

Molti dei dischi IDE testati da Microsoft vengono eseguiti con un tasso RPM del 5,200 e un RPM di 7,200 alle unità SCSI. Quando si disabilita la scrittura nella cache dell'unità IDE le prestazioni meccaniche possono diventare un fattore.

Esiste un'area molto chiara per risolvere la differenza di prestazioni: "Address" la frequenza delle transazioni.

Esistono molti sistemi online transaction processing (OLTP) che richiedono un'elevata frequenza di transazioni. Per questi sistemi, considerare l'utilizzo di un controller di memorizzazione nella cache che può supportare una cache in scrittura e forniscono l'incremento delle prestazioni assicurando l'integrità dei dati correttamente.

Si verifica in modo significativo le modifiche delle prestazioni con SQL Server in un'unità di memorizzazione nella cache, la frequenza delle transazioni è stata aumentata mediante transazioni di piccole dimensioni.

Test dimostra che alta scrittura attività di buffer è minore di 512 KB o superiore a 2 MB può causare rallentamenti delle prestazioni.
Si consideri l'esempio riportato di seguito:
CREATE TABLE tblTest ( iID int IDENTITY(1,1), strData char(10))GOSET NOCOUNT ONGOINSERT INTO tblTest VALUES ('Test')WHILE @@IDENTITY < 10000   INSERT INTO tblTest VALUES ('Test')				
Risultati dei test campione per SQL Server sono i seguenti:
84 SCSI(7200 rpm) secondi
SCSI(7200 rpm) 15 secondi (controller di memorizzazione nella cache)

IDE(5200 rpm) 14 secondi (unità cache attivata)
IDE(5200 rpm) 160 secondi

Ritorno a capo l'intera serie di operazioni di inserimento in un'unica transazione viene eseguito in circa quattro secondi in tutte le configurazioni.

Il motivo è il numero di cancellazioni di registro necessari. Senza la transazione, ogni inserimento è una transazione di per sé, e ogni volta che il record del log per la transazione devono essere svuotati. Ogni svuotamento è 512 byte in una dimensione che richiede l'intervento dell'unità meccanica significativi.

Quando viene utilizzata una singola transazione, il record del log per la transazione può essere associato e un'operazione di scrittura singola, più grande può essere utilizzato per cancellare i record di log raccolti. L'intervento meccanico risulta notevolmente ridotto.

Avviso Si consiglia di non aumentare l'ambito della transazione. Transazioni a esecuzione prolungata possono condurre a un blocco eccessivo e indesiderati, nonché un maggiore sovraccarico. Utilizzare i contatori delle prestazioni di SQL Server : database di SQL Server per visualizzare i contatori basato su log delle transazioni. In particolare, Registro byte/sec scaricamento può indicare molte transazioni piccole di attività del disco meccanico elevato.

Osservare le istruzioni associate di svuotare il registro e determinare se il numero di cancellazioni del registro può essere ridotte. Nell'esempio precedente è stata implementata una singola transazione. In molti scenari, tuttavia, ciò può causare un comportamento indesiderato blocco. Esaminare la struttura della transazione. Per eseguire il batch per ridurre l'attività di svuotamento del log frequenti e piccole, è possibile utilizzare codice simile al seguente:
BEGIN TRANGOINSERT INTO tblTest VALUES ('Test')WHILE @@IDENTITY < 50BEGIN   INSERT INTO tblTest VALUES ('Test')   if(0 = cast(@@IDENTITY as int) % 10)   BEGIN      PRINT 'Commit tran batch'      COMMIT TRAN      BEGIN TRAN   ENDENDGOCOMMIT TRANGO				
SQL Server che supportano i sistemi "consegna garantita in un supporto stabile," come descritto in richiede la Requisiti di revisione del programma di affidabilità i/o di SQL Server scaricare il documento. Per ulteriori informazioni sui requisiti di input e outpui per il motore di database di SQL Server, fare clic sul numero di articolo riportato di seguito per visualizzare l'articolo della Microsoft Knowledge Base:
967576 Requisiti di Input/Output di Microsoft SQL Server Database Engine

Avviso: questo articolo è stato tradotto automaticamente

Proprietà

ID articolo: 230785 - Ultima revisione: 05/17/2015 07:11:00 - Revisione: 1.0

  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Workgroup Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 7.0 Standard Edition
  • Microsoft SQL Server 2008 Developer
  • Microsoft SQL Server 2008 Enterprise
  • Microsoft SQL Server 2008 Express
  • Microsoft SQL Server 2008 Standard
  • kbhowto kbinfo kbmt KB230785 KbMtit
Feedback