SQL Server

Registrazione di comprensione e ripristino in SQL Server

Paul S. Randal

In un riepilogo delle:

• Funzionamento di registrazione e il ripristino in SQL Server
• Funzionamento del log delle transazioni e ciò che si desidera conoscere sulla gestione
• Modelli di recupero e il loro effetto sulla registrazione

Contenuto

Che cos'è la registrazione?
Che cos'è ripristino?
Il log delle transazioni
Modelli di ripristino
Disposizione dei

Alcune delle parti più misunderstood di SQL Server sono meccanismi di ripristino e la registrazione.Il fatto che il log delle transazioni esiste e può causare problemi se non gestiti correttamente sembra confound molte "involontarie DBA." Perché è possibile che la crescita unbounded del log delle transazioni?Perché talvolta richiede molto tempo per il database possibile portare in linea dopo un arresto anomalo del sistema?Perché non è registrazione essere disattivata completamente?Perché non È recuperare il database correttamente?Semplicemente che cos'è il log delle transazioni e cosa è dovuto?

Si tratta di tutte le domande visualizzati più volte sullo forum di SQL Server e di newsgroup, quindi in questo articolo desidera forniscono una panoramica del sistema di ripristino e registrazione e spiegare il motivo tale parte integrante del motore di archiviazione di SQL Server.È possibile verranno illustrate l'architettura di registro delle transazioni e come i modelli di recupero tre disponibili per un database possono modificare il comportamento del log delle transazioni e il processo di registrazione.Realizzazione del progetto È necessario inoltre fornire alcuni collegamenti a risorse relativo registro transazione gestione procedure ottimali.

Che cos'è la registrazione?

Registrazione e il ripristino non sono concetti che sono univoci per SQL Server, tutti i sistemi di gestione di esterna database relazionali (RDBMSs) devono farli per supportare le varie proprietà ACID delle transazioni.ACID è l'acronimo di atomicità, coerenza, isolamento e durevolezza, ovvero la proprietà fondamentali di un sistema di elaborazione delle transazioni (ad esempio un RDBMS).Puoi leggere ulteriori informazioni, vedere ilACID sezione proprietà della MSDN Library.

Video

Paul Randal viene illustrata l'importanza della gestione del log delle transazioni correttamente nel modello di recupero con registrazione completa e viene è illustrato le tecniche per procedere in SQL Server.

Le operazioni in un RDBMS vengono registrate (o registrate) a fisico e logico livello in termini di ciò che accade in strutture di archiviazione del database.Ogni modifica per le strutture di archiviazione ha il proprio record del log che descrive la struttura in corso di modifica e la modifica era.Questa operazione viene eseguita in modo che le modifiche possono essere riprodotti o invertita, se necessario.I record di log vengono memorizzati in un file speciale denominato del log delle transazioni, verrà descritto in questo in maggiore dettaglio più avanti, ma per ora possono essere considerate di esso un file sequenziale di accesso.

Un insieme di tali modifiche, è possibile (e in effetti, sono sempre) raggruppati in una transazione, che fornisce l'unità di base di apportare modifiche (atomicità) a un database fino come utenti, gli sviluppatori di applicazioni e gli amministratori di database sono riferisce.Una transazione ha esito positivo (commit) o ha esito negativo e viene annullata (rollback).Nel primo caso, le operazioni che formano la transazione sono necessariamente essere applicate al database.Nel secondo caso, le operazioni sono necessariamente non essere applicate al database.

Le transazioni in SQL Server sono esplicita o implicita.Una transazione esplicita è uno in cui l'utente o un'applicazione invia un'istruzione T-SQL BEGIN TRANSACTION, segnala l'avvio di un gruppo di modifiche correlate da tale sessione.Una transazione esplicita ha esito positivo quando viene emessa un'istruzione COMMIT TRANSACTION, segnala il completamento del gruppo di modifiche.Se invece viene generata un'istruzione ROLLBACK TRANSACTION, vengono annullate tutte le modifiche apportate da tale sessione dopo l'istruzione BEGIN TRANSACTION emesso (rollback) e la transazione viene interrotta.Un rollback della transazione può anche essere forzato da un evento esterno, ad esempio il database insufficiente spazio su disco o un arresto anomalo del server, come verrà illustrato più avanti.

Una transazione implicita è uno in cui l'utente o applicazione non in modo esplicito rilascia un'istruzione BEGIN TRANSACTION prima di inviare un'istruzione T-SQL.Tuttavia, dato che tutte le modifiche apportate al database devono essere transazionali, il motore di archiviazione verranno automaticamente avviare una transazione dietro le quinte.Quando viene completata l'istruzione T-SQL, il motore di archiviazione esegue il automaticamente commit della transazione che avviato disposto attorno alla dichiarazione dell'utente.

Si potrebbe pensare che questo non è necessario perché una singola istruzione T-SQL non genera un numero elevato di modifiche apportate alle strutture di archiviazione del database, ma simile a un'istruzione ALTER INDEX RICOSTRUIRE prendere in considerazione.Sebbene questa istruzione non può essere contenuta in una transazione esplicita, è riuscito a generare un numero enorme di modifiche apportate al database.Pertanto, è necessario un meccanismo per garantire che se qualcosa andare errato (l'istruzione viene annullata, ad esempio), tutte le modifiche vengono correttamente stornate.

Come esempio, si considerino le conseguenze una riga di singola tabella viene aggiornata in una transazione implicita.Si immagini di una tabella di heap semplice con un c1 colonna integer e c2 una colonna di tipo char.La tabella include righe 10.000 e un utente invia una query di aggiornamento nel modo seguente:

UPDATE SimpleTable SET c1 = 10 WHERE c2 LIKE '%Paul%';

Eseguire le operazioni seguenti:

• Le pagine di dati da SimpleTable sono leggere dal disco in memoria, il pool di buffer in modo che è possibile cercare informazioni righe corrispondenti. Si scopre che le pagine di dati tre contengono cinque righe che soddisfano il predicato della clausola WHERE.
• Il motore di archiviazione avvia automaticamente una transazione implicita.
• Le pagine di dati tre e righe di dati cinque vengono bloccate per consentire gli aggiornamenti a verificarsi.
• Le modifiche vengono apportate ai record cinque dati nelle tre pagine in memoria.
• Le modifiche vengono registrate anche nei record di log nel registro delle transazioni sul disco.
• Il motore di archiviazione esegue il automaticamente commit della transazione implicita.

Si noti che È non elencare un passaggio in cui vengono scritti nuovamente le pagine di dati aggiornati tre insufficiente su disco. Si tratta poiché non sono ancora necessario essere, a condizione che descrivono i record di log le modifiche sono su disco nel registro delle transazioni, quindi le modifiche sono protetti. Se le pagine necessario successivamente essere letto o modificato di nuovo, quindi la copia più aggiornata della pagina è già in memoria, ma non su disco (ancora. Le pagine di dati verranno scritte uscita su disco quando si verifica la successiva operazione checkpoint o se la memoria che utilizzano il pool di buffer è necessaria per un'altra immagine pagina.

I punti di arresto esiste per due motivi, per il batch dei scrittura I/o per migliorare le prestazioni e ridurre il tempo necessario per il ripristino di arresto anomalo del sistema. In termini di prestazioni, se una pagina di dati erano costretti in uscita su disco a ogni aggiornamento è stato, il numero di operazioni di I/o che si verificano in un sistema di disponibilità può facilmente scrittura annegare il sottosistema di I/O. È preferibile periodicamente scrivere pagine dirty (pagine che sono state modificate dopo letto dal disco) di per scrivere pagine immediatamente sono state modificate. In seguito verrà illustrato l'aspetto di ripristino di punti di arresto.

Una comune pregiudizio su punti di arresto indica che sono solo scrittura pagine con le modifiche apportate da transazioni di cui è stato eseguito il commit. Non è vero, ovvero un checkpoint sempre scrive tutte le pagine dirty, indipendentemente se la transazione che modifica una pagina è impegnata o non.

Registrazione write-ahead è il meccanismo di cui i record del log che descrive una modifica vengono scritte su disco prima vengono scritte modifiche stesse. Fornisce la parte di durata della proprietà ACID. Fino a quando i record di log che descrive le modifiche su disco, in caso di un arresto anomalo, i record di log (e quindi le modifiche stesse) possono essere recuperati e gli effetti della transazione non vengono persi.

Che cos'è ripristino?

Stai cercando suggerimenti per SQL Server?

Per suggerimenti su SQL Server, visitare il Suggerimenti di TechNet Magazine SQL Server pagina.

Per ulteriori suggerimenti su altri prodotti, visitare il Indice TechNet Magazine suggerimenti.

Registrazione esiste per supportare un'ampia gamma di operazioni in SQL Server. Assicura che se si verifica un arresto anomalo del sistema, una transazione di cui è stato eseguito il commit verrà essere correttamente riflesse nel database dopo l'arresto anomalo del sistema. Garantisce che una transazione di cui non è stato eseguito il commit verrà essere correttamente rollback e non applicata al database dopo un arresto anomalo. Garantisce che è possibile annullare una transazione in corso e hanno tutte le operazioni rollback. Consente di una copia di backup da eseguire in modo che un database può essere ripristinato il log delle transazioni e backup log delle transazioni riprodurre per portare il database a un punto specifico in tempo con coerenza transazionale. E supporta funzionalità che dipendono di leggere il registro delle transazioni, ad esempio replica, il mirroring del database e modifica dati acquisizione.

La maggior parte di questi utilizzi della registrazione comportano un meccanismo di ripristino. Ripristino è il processo di con le modifiche descritte in record del registro riprodurre o ripristinare nel database. Riproduzione dei record del registro è denominato ripristino (o rollforward) fase di ripristino. Ripristino registro è denominato record ANNULLARE (o rollback) fase di ripristino. In altre parole, ripristino verrà assicurati che una transazione e tutti i record relativo del log costitutivi sono sia ripetere o annullare.

Form di ripristino semplice è quando viene annullata una singola transazione, in tal caso è annullata e non è Nessun effetto netto sul database. La maschera più complessa è ripristino di arresto anomalo del sistema, ovvero quando SQL Server si blocca per qualsiasi motivo) e il log delle transazioni deve essere recuperato per portare il database a un punto di coerenza a livello di transazioni. Ciò significa che tutte le transazioni che erano eseguito il commit al momento dell'arresto anomalo devono essere rollforward per garantire che i relativi effetti vengono mantenuti nel database. E tutte le transazioni di corso non ha eseguito il commit al momento dell'arresto anomalo devono essere rollback per garantire che i relativi effetti non vengono mantenuti nel database.

Ciò avviene perché non è nessuna funzionalità per una transazione in SQL Server per continuare dopo un arresto anomalo. Pertanto, se gli effetti di una transazione completata parzialmente non sono stati ripristinati, il database potrebbe restare in uno stato incoerente (possibilmente anche strutturalmente danneggiato, a seconda di ciò che la transazione all'interno di tale).

Come è ripristino sapere che cosa fare? Tutti i processi di ripristino variano in base al fatto che ogni record del log è contrassegnato con un numero di sequenza log (LSN). Un numero di sequenza del registro è un numero sempre crescente, tre parti che definisce in modo univoco la posizione di un record di log all'interno del log delle transazioni. Ogni record di registro in una transazione è memorizzato in ordine sequenziale all'interno del log delle transazioni e contiene l'ID di transazione e il numero LSN del record di log precedente per la transazione. In altre parole, ciascuna operazione viene registrata come parte della transazione ha un "collegamento" nuovamente all'operazione che immediatamente preceduta.

Per il semplice caso di una singola transazione in corso l'esecuzione del rollback, il meccanismo di ripristino può facilmente rapidamente seguire la catena di operazioni registrate dall'ultima operazione nuovamente per la prima operazione e Annulla gli effetti delle operazioni nell'ordine opposto da cui durante. Le pagine di database interessate dalla transazione sono ancora nel pool di buffer o sul disco. In entrambi i casi, l'immagine della pagina che è disponibile sia necessariamente una in cui l'effetto della transazione riflesse nella pagina e deve essere annullata.

Durante il ripristino di arresto anomalo del sistema, il meccanismo è più complesso. Il fatto che le pagine del database non vengono scritte su disco quando si esegue il commit di una transazione significa che è garantito che l'insieme di pagine del database sul disco riflette accuratamente l'insieme di modifiche descritte in del log delle transazioni, per cui non è stato eseguito il commit o il commit transazioni. Tuttavia, è disponibile una parte finale del puzzle che non sono state detto ancora, tutte le pagine del database disponibile un campo in loro intestazione di pagina (una parte di 96 byte della pagina a 8192 byte contenente i metadati sulla pagina che contiene il numero LSN dell'ultimo record registro interessati la pagina. Ciò consente al sistema ripristino decidere che cosa fare su un record di log specifico è necessario recuperare:

• Per un record di registro da una transazione commit in cui la pagina di database contiene un uguale LSN a o maggiore di LSN del record del log, non è necessario eseguire alcun valore. L'effetto di record del log è stata già resa persistente nella pagina dal disco.
• Per un record di registro da una transazione commit in cui la pagina di database ha un numero LSN minore numero LSN del record del log, il record del log deve essere ripetere per garantire che gli effetti delle transazioni vengono mantenuti.
• Per un record di registro da una transazione di cui non è stato eseguito il commit in cui la pagina di database contiene un uguale LSN a o maggiore di LSN del record del log, il record del log deve essere annullato per garantire che gli effetti delle transazioni non vengono mantenuti.
• Per un record di registro da una transazione di cui non è stato eseguito il commit in cui la pagina di database ha un numero LSN minore numero LSN del record del log, non è necessario eseguire alcun valore. L'effetto del record del log non è stato mantenuto nella pagina dal disco e pertanto non è necessario essere annullata.

Arresto anomalo del sistema ripristino letti del log delle transazioni e garantisce che tutti gli effetti di commit di tutte le transazioni vengono mantenuti nel database e tutti gli effetti di tutte le transazioni cui non è stato eseguito il commit non vengono mantenuti nel database, il ripristino e ANNULLARE fasi, rispettivamente. Al termine del ripristino di arresto anomalo del sistema il database è coerente e disponibili per l'utilizzo a livello di transazioni.

Detto in precedenza che uno degli utilizzi di un'operazione checkpoint è per ridurre la quantità di tempo di arresto ripristino richiede. Per la consuntivazione periodicamente da tutte le pagine dirty su disco, viene ridotto il numero di pagine che sono state modificate a causa delle transazioni salvate, ma con immagini non sul disco. A sua volta, riduce il numero di pagine che è necessario disporre di ripristino di ROLLFORWARD applicato durante l'arresto anomalo del sistema ripristino.

Il log delle transazioni

Ripristino di arresto anomalo del sistema è possibile solo se il log delle transazioni è intatto. Infatti, il log delle transazioni è la parte più importante del database, è la posizione sola in cui tutte le modifiche apportate al database invece sono necessariamente essere descritto in caso di un arresto anomalo del sistema.

Se il log delle transazioni è mancante o danneggiato dopo un arresto anomalo del sistema, quindi arresto anomalo del sistema ripristino Impossibile completare, causando un database sospetto. In questo caso, il database deve essere ripristinato da backup o recuperati usando le opzioni meno utile, ad esempio ripristino della modalità di emergenza. Queste procedure sono descritte in questo articolo ma verranno trattate in dettaglio negli articoli più avanti nell'anno.

Il log delle transazioni è un file speciale che ogni database deve presentare per funzionare correttamente. Contiene i record del log che vengono prodotte dalla registrazione ed sono utilizzati per leggerle durante ripristino (o qualsiasi altri utilizzi della registrazione che HO già accennato). Nonché lo spazio occupato dai record del log stessi, una transazione verrà inoltre riservare spazio nel registro delle transazioni per qualsiasi record di registro potenziali necessario se la transazione deve essere annullata e necessari per ripristinare. Questo account per il comportamento si può osservare dove, ad esempio, una transazione che aggiorna 50MB di dati del database potrebbe essere necessario effettivamente 100MB dello spazio del log delle transazioni delle.

Quando viene creato un nuovo database, il registro delle transazioni è essenzialmente vuoto. Quando si verificano le transazioni, i record di registro vengono scritti in modo sequenziale del log delle transazioni, ovvero esiste alcun aumento delle prestazioni dalla creazione di file di registro delle transazioni più, ovvero un pregiudizio molto comune. Il log delle transazioni utilizzerà ogni file di registro a sua volta.

I record di registro per transazioni simultanee possono essere frammisti nel registro delle transazioni. Tenere presente che i record di registro per una singola transazione sono collegati da loro LSNs, pertanto è necessario per tutti i record di registro per una transazione per essere raggruppati nel registro. LSNs può essere considerato quasi come timestamp.

L'architettura fisica del log delle transazioni è illustrata nella Figura 1 . Si è suddiviso internamente in blocchi più piccoli, denominati file di registro virtuali o VLFs. Questi sono semplicemente un facilitare la semplice gestione interna del log delle transazioni. Quando un VLF risulta pieno, registrazione automaticamente procede da utilizzare VLF successiva nel registro delle transazioni. Si potrebbe pensare che alla fine del log delle transazioni sarà esaurito lo spazio, ma è in cui il log delle transazioni in modo diverso dal file di dati.

Figura 1 accesso Architettura fisica di transazione

Il log delle transazioni è effettivamente un file di circolare, purché i record del log all'inizio del log delle transazioni sono stati troncati (o deselezionati). Quindi quando registrazione raggiunge la fine del log delle transazioni, ritorna al inizio nuovamente e inizia a sovrascrivere è ciò che era prima.

Come si i record del log ottenere troncati in modo che lo spazio occupati che può essere riutilizzato? Un record del log non è più necessario nel registro delle transazioni se tutte le operazioni seguenti sono true:

• Ha eseguito il commit della transazione di cui fa parte.
• Le pagine di database che è modificata tutti scritti su disco da un checkpoint.
• Il record del log non è necessaria per il backup (completo, differenziale o registro).
• Il record del log non è necessaria per le funzionalità che legge il Registro (ad esempio il mirroring del database o la replica).

Un record di registro che è comunque necessario viene chiamato attivo e un VLF include almeno un record di registro attivo viene anche chiamato attivo. Tanto così spesso, il log delle transazioni viene controllato per verificare se tutti i record log un VLF completo sono attivi, se sono tutti inattivi, il VLF viene contrassegnato come troncati (ovvero che il VLF possono essere sovrascritte quando esegue il wrapping del log delle transazioni). Quando un VLF viene troncato, non viene sovrascritto o azzerato in alcun modo, viene solo contrassegnato come troncato e quindi può essere riutilizzato.

Questo processo è denominato Troncamento log, non per essere confuso con effettivamente ridurre le dimensioni del registro delle transazioni. Troncamento log non cambia mai la dimensione fisica del log delle transazioni, solo quali parti del log delle transazioni sono attivi. Figura 2 Mostra il log delle transazioni da figura 1 dopo il verificarsi di errori di troncamento in seguito.

Nella figura 2 registrare la transazione dopo il troncamento del log

Attiva VLFs compongono il registro logico, ovvero la parte del log delle transazioni che contiene tutti i record di registro attivo. Il database stesso conosce dove ripristino di arresto anomalo del sistema deve iniziare la lettura di record del registro all'interno della parte attiva del log, ovvero l'inizio della transazione attiva meno recente nel registro di MinLSN (questo è memorizzato nella pagina di avvio del database).

Ripristino di arresto anomalo del sistema non conosce la posizione in cui interrompere la lettura i record di registro, in modo che continua finché non viene raggiunta una sezione azzerata del log delle transazioni (se il log delle transazioni non è ancora incapsulato) o un record di registro con bit di parità non rientrano la sequenza del record di registro precedente.

VLFs diventano troncato e nuovi diventano attivi, il registro logico viene spostato all'interno del file log transazione fisica e infine deve circondare all'inizio, come illustrato nella Nella figura 3 .

Nella figura 3 la natura circolare del log delle transazioni

Il controllo se Troncamento log può essere eseguita in uno dei seguenti casi:

• Si quando un checkpoint verifica nel modello di recupero con registrazione minima o in altri modelli di recupero quando non è stato eseguito un backup completo. Questo implica che un database rimarrà in un modello di recupero pseudo-SIMPLE dopo passata di SIMPLE finché non si verifica un backup completo del database.
• Termine un backup del log.

Tenere presente che Troncamento log potrebbe non essere possibile a causa dei molti motivi che un record del log deve rimanere attivo. Quando Troncamento log non può verificarsi, il VLFs non può essere troncato e alla fine del log delle transazioni è aumento delle dimensioni (o da aggiungere un altro file di registro delle transazioni). Crescita registro transazione eccessivo può causare problemi di prestazioni mediante un fenomeno detto VLF frammentazione. Rimozione VLF frammentazione può talvolta causare un notevole miglioramento delle prestazioni delle attività correlata ai log.

Per ulteriori informazioni su questo, vedere il blog di Kimberly Tripp registrare" I passaggi 8 per migliore velocità effettiva del log delle transazioni." Kimberly vengono illustrati le procedure ottimali relative a transazioni registro capacità pianificazione, gestione, le prestazioni miglioramenti e, vale la pena anche durante la lettura.

Esistono due problemi comuni che possono impedire il troncamento log:

• Una transazione attiva a esecuzione prolungata. Il log di intera transazione poiché il primo record del log dalla transazione attiva meno recente non può essere troncato fino a tale transazione esegue il commit o si interrompe.
• Il passaggio al modello di ripristino FULL, eseguire un backup completo e quindi mai calcolando i backup del log. Il log delle transazioni intero rimarrà attivo, in attesa di eseguire il backup da un backup del log.

Per un elenco completo di fattori e istruzioni su come determinare la causa Troncamento log, vedere l'argomento nella documentazione in linea" Fattori che è possono posticipare il troncamento del log." HO anche creato una dimostrazione di video viene illustrato l'effetto di crescita del registro delle transazioni non controllato e su come rimuovere VLF frammentazione, controllare questa screencast video e il precedente screencasts su argomenti SQL in technetmagazine.com/videos.

Se il log delle transazioni raggiungere capacità e non può aumentare le ulteriori, quindi verrà segnalato l'errore 9002 e sarà necessario eseguire operazioni per fornire più spazio, ad esempio aumentando il file di registro, l'aggiunta di un altro file di registro o rimozione di qualsiasi impediment nel log troncati.

In nessun caso devono è eliminare il log delle transazioni, provare a ricostruire utilizzando i comandi non documentati o semplicemente troncare utilizzando le opzioni NO_LOG o TRUNCATE_ONLY di BACKUP LOG (che sono stati rimossi in SQL Server 2008). Queste opzioni verranno transazionale incoerenza e danneggiamento più probabile o rimuovere la possibilità di poter recuperare correttamente il database.

Per ulteriori informazioni su come risolvere un registro delle transazioni completo, vedere out l'argomento nella documentazione in linea" Risoluzione dei problemi un intero log delle transazioni (errore 9002)."

Modelli di ripristino

Come può notare, il comportamento del log delle transazioni dipende in parte il database utilizza il modello di recupero. Sono disponibili tre modelli di recupero e tutti hanno effetto sul comportamento del log delle transazioni come operazioni vengono registrate o entrambi.

Il modello di ripristino FULL significa che viene registrato ogni ambito di ogni operazione, che viene chiamato completamente registrate. Una volta nel modello di ripristino FULL è stato eseguito un backup completo del database, il log delle transazioni non verrà automaticamente troncati finché non viene eseguita una copia di backup di log. Se non si desidera rendere Utilizzo di backup del log e la possibilità di ripristinare un database a un punto specifico nel tempo, non utilizzare il modello di ripristino FULL. Tuttavia, se si desidera utilizzare il mirroring del database, sarà non possibile scelta, come supporta solo il modello di ripristino FULL.

Il modello di recupero BULK_LOGGED semantica la stessa transazione registro troncamento come il modello di ripristino FULL ma consente alcune operazioni di essere parzialmente registrato, che viene chiamato minime registrati. Esempi sono ricostruzione di un indice e alcune operazioni di caricamento di massa, nel modello di ripristino FULL viene registrato l'intera operazione.

Ma nel modello di ripristino BULK_LOGGED solo l'allocazione le modifiche vengono registrate, che consente di ridurre drasticamente il numero di record di log generati e, a sua volta, consente di ridurre il rischio di crescita del log delle transazioni. Per ulteriori informazioni sulle operazioni minime registrate, vedere la sezione della documentazione in linea" Le operazioni che possono essere registrate minime."

Infine, il modello di recupero con registrazione minima è effettivamente lo stesso comportamento registrazione il ripristino BULK_LOGGED, ma la semantica di troncamento del log delle transazioni è molto diversa. Backup del log non sono possibili nel modello di recupero con registrazione minima, ovvero troncare il log (a condizione che non c'è altro è contenente i record del log attiva) quando si verifica un checkpoint. Esistono pro e contro a ognuno di questi modelli di recupero in termini di quali i backup sono possibili (o necessario) e la possibilità di ripristinare in diversi punti nel tempo (viene descritta questa in un altro articolo alla fine dell'anno).

Disposizione dei

In questo articolo è stato effettivamente una spiegazione più accademico del funzionamento di una parte importante di SQL Server. Spero che È stato gestito cancellare le eventuali malintesi alla creazione è possibile che sono stati. Se questo è il primo Introduzione alla registrazione e ripristino, questi sono i punti chiave che vorrei per eseguire da questo articolo:

• Non creare più file di registro, come non verrà causare un aumento delle prestazioni.
• Conoscere il database utilizza il modello di recupero e l'effetto ha del log delle transazioni, soprattutto intorno se può automaticamente troncati o non si quando un checkpoint verifica.
• Tenere in considerazione la possibilità di crescita del log delle transazioni, eseguire i fattori che possono causare e come ottenere incluso nel controllo.
• Sapere dove cercare della Guida in linea per risolvere il problema un registro delle transazioni completo.

Nel mio blog, È necessario molte più informazioni sui log delle transazioni e fattori che influenzano, vedere la categoria post di blog " Log delle transazioni"per ulteriori informazioni. I diversi argomenti documentazione in linea riguardanti il log delle transazioni inoltre sono ottimo, a partire da Gestione di registro delle transazioni.

Come sempre, se disponi di eventuali commenti e suggerimenti o domande, eliminare più una riga Paul@SQLskills.com.

Grazie a Kimberly l. Tripp per fornire una revisione tecnica di questo articolo.

S Paul Randal è il responsabile gestione SQLskills.come un MVP di SQL Server. Ha lavorato nel team motore di archiviazione di SQL Server in Microsoft da 1999 a 2007. Paul scritto DBCC CHECKDB e ripristino per SQL Server 2005 ed era responsabile per il motore di archiviazione principale durante lo sviluppo di SQL Server 2008. Paul è un esperto di ripristino di emergenza, disponibilità elevata e manutenzione dei database ed è in un normale relatore a conferenze di tutto il mondo. Blog ha in SQLskills.com/blogs/paul.