SQL Server (2005/2008): il backup completo tronca il registro in modalità di ripristino completo


41

Ho appena letto un sacco di documentazione su MSDN e penso di aver capito i diversi modelli di recupero e il concetto di una catena di backup. Ho ancora una domanda:

Un backup completo del database tronca il registro delle transazioni (utilizzando la modalità di ripristino completo)?

  • Se sì: dove viene menzionato nel MSDN? Tutto quello che ho trovato è stato che solo BACKUP LOG tronca il registro.

  • Se no: perché? Poiché un backup completo del database avvia una nuova catena di backup, qual è il punto nel mantenere attive le transazioni finite prima del backup completo nel registro?

Risposte:


43

No, sicuramente no. L' unica cosa che consente al registro di cancellare / troncare nei modelli di recupero FULL o BULK_LOGGED è un backup del registro, senza eccezioni. Ho avuto questo argomento un po 'di tempo fa e ho pubblicato un post sul blog lungo e dettagliato con una spiegazione e uno script che puoi usare per dimostrarlo a te stesso in Misconceptions intorno al backup del log e del log: come convincerti .

Sentiti libero di dare seguito a ulteriori domande. A proposito, vedi anche il lungo articolo che ho scritto per la rivista TechNet sulla comprensione della registrazione e del recupero in SQL Server .

Grazie


Grazie mille signore per la tua SUPER RISPOSTA e l'articolo che ha risposto a un milione di domande nella mia mente.
M. Ali

13

Un backup completo NON tronca il registro, è necessario eseguire un'operazione del registro di backup. Un backup completo NON reimposta la catena di log, il che rovinerebbe totalmente la replica / il log shipping, ecc.

Dovresti esaminare da vicino come SQL Server esegue i backup, ma sappi che le transazioni in volo / di lunga durata non sono incluse nel backup (altrimenti il ​​backup potrebbe non essere mai completo), quindi non è del tutto esatto affermare che un backup completo di un il database online è garantito per rendere obsoleto il backup del registro successivo.

http://msdn.microsoft.com/en-us/library/ms175477.aspx


8

Da quanto ho capito, l'unica cosa che tronca il registro delle transazioni è un backup del registro .

Un backup completo copia solo una parte sufficiente del registro in modo che sia coerente dal punto di vista delle transazioni, poiché il completamento dell'operazione di backup richiede un po 'di tempo e, in quel momento, le pagine copiate potrebbero essere cambiate.

Sono ancora necessari i backup del registro per il ripristino temporizzato.

Non ho MSDN a cui collegarmi, ma posso collegarti al blog di Paul Randal , che era uno sviluppatore del team di SQL Server, ha scritto DBCC CHECKDB e parti della documentazione online.

Risponde anche alle domande su questo forum, quindi sarebbe un'autorità ancora migliore delle informazioni di seconda / terza mano da me :)


5

Le persone spesso hanno un'idea sbagliata del backup completo e dei backup dei log. Affinché il backup funzioni nel FULLmodello di recupero backup, è necessario utilizzare i t-log, poiché durante i backup potrebbero esserci ancora transazioni in corso nel database (a meno che non si esegua un cosiddetto COLDbackup quando si arresta il database). Oracle utilizza lo stesso concetto quando si dispone di un database in ARCHIVELOGmodalità. La sequenza di un backup si riduce a questo:

  1. Avvia backup: sospendi tutte le azioni in file reali e scrivi su t-log.
  2. Esegui backup: tutte le transazioni continuano, ma non sono scritte in file reali, ma sono scritte in t-log
  3. Termina backup: riprende la scrittura delle transazioni del database in file reali.
  4. Se necessario, svuota i file T-log nei file reali.

Questo è il motivo per cui i log di t non vengono troncati / ridotti per impostazione predefinita, poiché sono una parte vitale della continuazione della transazione durante la fase di backup.


1

Non confondere troncando il registro con la riduzione del registro.

  • TRUNCATE è rimuovere le transazioni nel registro che si trovano prima dell'ultimo checkpoint, (il checkpoint è quando le transazioni vengono scaricate nel database stesso). Questo viene fatto usando il comando BACKUP.

  • Per SHRINK il registro deve ridurre la dimensione effettiva del file di registro. Questo viene fatto usando i comandi DBCC.


1

Fondamentalmente non è necessario ridurre automaticamente il registro delle transazioni ogni volta perché i registri delle transazioni hanno bisogno di spazio per funzionare e se si troncano automaticamente rimarranno quasi della stessa dimensione.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.