Registro delle transazioni e mirroring: cerca la spiegazione più stupida possibile


8

Prima di tutto, devo ammettere che ho problemi con il concetto di Transaction Log. Voglio dire - capisco che è il Registro di tutte le Transazioni che avvengono sul database, ma quando si tratta di metterlo correttamente nel contesto all'interno di un'attività, ovviamente mi manca qualcosa. Quindi, per chiunque risponderà alla domanda, sentiti libero di espandere la teoria dietro il Transaction Log.

La domanda principale è: ho SQL Server 2008 e 2 GB di database di cui ho bisogno per il mirroring (ha un registro delle transazioni da 12 GB). Se non eseguissi il mirroring del database presumo che potrei passare alla modalità Semplice o troncare il registro dopo il backup. Ma in questo caso, cosa devo fare se desidero tenere sotto controllo quel registro delle transazioni? A quanto ho capito, devo conservare l'intero registro delle transazioni se voglio essere in grado di eseguire facilmente il mirroring del database (basta fare il backup completo).

C'è un modo per aggirare questo? Idealmente vorrei che fosse possibile eseguire un backup che mantenga sia MDF che LDF in 1 file ogni volta e dopo che il backup è stato eseguito Il registro delle transazioni (LDF) sul database è ridotto a 0. Il problema con questo scenario sono backup incrementali - se il mio primo backup registro troncato, presumo che il secondo backup debba fare riferimento al primo se voglio fare il mirroring in seguito (cioè sarei bloccato con il mantenimento di un mucchio di file anziché solo uno).

Quindi, qualcuno può illuminarmi su questo argomento? Capisco che sto cercando di riempire un sacco di buchi qui e che le mie "soluzioni" proposte potrebbero non essere le migliori, ma apprezzerei sinceramente se qualcuno mi può spingere nella giusta direzione sui registri delle transazioni, su come influenzano il mirroring e meglio si esercita con quei due.

Risposte:


5

Il registro delle transazioni è un metodo importante per ripristinare il database in un momento specifico. Se si dispone di un database di grandi dimensioni> 500 GB e se è necessario ripristinare il database da un backup completo, questo costerà molto tempo. Inoltre, se esegui il backup completo del database ogni volta, pensa a quanto tempo potrebbe richiedere questo backup.

Un concetto molto semplice per SQL Server può essere: Impostare il modello di recupero del database completo

Creare un piano di manutenzione (1) in SQL Server:

  • Esegui FullBackup ogni settimana, magari in D: \ yourbackup \ FullDBBackup.bak
  • Esegui backup differenziale ogni due giorni in D: \ yourbackup \ DiffBackup.bak
  • Fai ogni 2 ore il backup del tuo log delle transazioni in D: \ Yourbackup \ Tranlogbackup.trn

Creare un piano di manutenzione (2) in SQL Server:

  • Elimina tutti i file precedenti 8 giorni da D: \ yourBackup * .bak
  • Elimina tutti i file precedenti 3 giorni da D: \ yourBackup * .trn

In questo caso, sei in grado di ripristinare il tuo database in un tempo specifico, molto veloce, molto semplice. SQL Server gestirà automaticamente i tuoi file "Backup", i file più vecchi verranno eliminati dopo l'intervallo di tempo specifico.

Vorrei suggerire di leggere il registro delle transazioni di SQL Server qui:

http://www.sqlservercentral.com/articles/Design+and+Theory/63350/

Per utilizzare i piani di manutenzione in SQL Server basta chiedere a BING / google: D

dovresti creare un piccolo db di prova e testarlo prima di andare in produzione


Non ho problemi con i backup completi e il tempo poiché posso arrestare l'intero sistema fino al termine. Una domanda sulla tua risposta: troncare il registro delle transazioni in questo scenario? In caso contrario, capisco che ho solo bisogno dell'ultimo FullDBBackup.bak solo per ripristinare il database? Non mi importa di specifici periodi di tempo: tutto ciò che mi interessa è l'ultima versione di DB che ottengo quando eseguo il backup. Significato: non ho bisogno dei registri delle transazioni; Li sto solo mantenendo per il mirroring. C'è un modo per aggirare questo?
nikib3ro,

2
1. Non è possibile troncare il registro: D 2. Se si esegue un backup del registro di trasferimento, SQL Server lascerà questo spazio libero per il riutilizzo nel file di registro. solo un semplice test dbcc sqlperf ('logpsace') analizza il backup e quindi fa lo stesso dopo il backup. e alla fine, hai bisogno del registro delle transazioni ... prova il mio esempio

Finalmente ho potuto implementare i tuoi suggerimenti nell'ambiente di test e finora mi piace quello che vedo. Per favore fatemi sapere se ho capito bene - se ora dovessi ripristinare il database, utilizzerei prima il backup COMPLETO che ho fatto, e quindi usando la combinazione di backup differenziali e registri delle transazioni, sarei in grado di ripristinare il mio database su certo momento? Ho ragione? E presumo anche che per il mirroring, avrei solo bisogno di arrestare il server e eseguire il backup completo? O avrò bisogno dei registri delle transazioni per configurare il mirroring? Grazie ancora per tutto l'aiuto e le risposte!
nikib3ro,

3

Per sfruttare il mirroring, è necessario disporre del database in modalità di recupero COMPLETO e sarà necessario eseguire i backup del registro delle transazioni per impedire la crescita del file di registro. Se non sono necessari i backup del registro, eliminarli dopo x ore con un piano di manutenzione, ma è necessario eseguirli.

Per ripulire l'ambiente è necessario rimuovere il mirroring, impostare la modalità di ripristino su semplice, ridurre le dimensioni del file di registro tramite il modo Paul Randal consigliato , tornare alla modalità di ripristino completo, impostare backup completi e di registro, quindi inizializzare nuovamente specchio. Puoi provare a ridurre le dimensioni del registro mentre il mirroring è attivo, ma sarà prima molto più semplice rimuoverlo. 1 GB non dovrebbe essere troppo male di un db per reinizializzare.

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.