Il modo migliore per eseguire il backup e troncare i registri delle transazioni in base a una pianificazione

Non sono un DBA, ma essendo ciò che sono, devo indossare il cappello DBA e impostare piani di manutenzione sulla mia istanza di SQL Server.

Quindi per un po 'ho avuto il mio processo durante la notte SSIS eseguire un'attività Esegui SQL per eseguire i backup - fondamentalmente in esecuzione master.dbo.xp_create_subdirper garantire l'esistenza delle cartelle di destinazione, e quindi BACKUP DATABASE [DbName] TO DISK = 'G:\Backups\DbName\DbName.bak' WITH INIT.

Ogni volta che l'attività non andava a buon fine, il resto del processo si interrompeva e ricevevo una notifica, e la mattina dopo mi accorgevo che l'unità per i registri delle transazioni era piena di capacità, quindi li troncavo manualmente e proseguivo. .. fino a quando la storia non si è ripetuta e i registri delle transazioni hanno superato di nuovo lo spazio disponibile su disco.

Lo script "troncamento manuale" è simile al seguente:

use Staging;
alter database Staging set recovery simple
alter database Staging set recovery full
dbcc shrinkfile ('Staging_log', 0, truncateonly);
go

Quindi mi sto stancando di questo, e ho deciso di provare a fare le cose correttamente , e seguire i passaggi qui e creare un vero piano di manutenzione :

Il fatto è che non l'ho mai fatto prima, quindi ho alcune domande:

• Il backup dei registri delle transazioni in questo modo li troncerà automaticamente o c'è qualcos'altro che devo fare?
• È possibile eseguire contemporaneamente backup dei dati e dei registri delle transazioni? In caso contrario, qual è il modo corretto di farlo?
• I file di backup vengono raccolti durante la notte da un altro processo che acquisisce tutti i file sul server e li memorizza altrove - sarebbe una buona idea far scadere il set di backup dopo 2 giorni? Devo farli scadere del tutto?
• Le attività di pulizia rimuovono rispettivamente i "vecchi" file .bak e .trn nelle sottocartelle di G:\Backups. Ha senso?
• Sarebbe meglio farlo in SSIS, quindi posso fallire il mio ETL se / quando i backup falliscono? O dovrebbe interessarmi al mio processo ETL?

Scusate se ci sono troppe domande per un post, se necessario modificherò e farò invece più domande - penso che siano tutte strettamente correlate.

Solo SSIS dall'oggi al domani sta scrivendo, il giorno è tutto da leggere - ho solo bisogno del recupero quotidiano.

È necessario scegliere il modello di recupero in base alle esigenze aziendali:

• Quanti dati aziendali possono perdere e allo stesso tempo sopravvivere?

Sulla base della risposta di cui sopra, è necessario scegliere attentamente il modello di recupero del database .

In termini semplici (senza discutere del modello di recupero registrato in blocco) ,

• Un modello di recupero completo consente backup dei log che consentono il ripristino temporizzato.
  • Il troncamento del registro può verificarsi quando si eseguono backup del registro delle transazioni, ad esempio lo spazio del file di registro verrà riutilizzato dopo ogni backup del registro e non si gonfia!
• Un modello di recupero semplice consente solo di eseguire backup COMPLETI. Il recupero temporizzato non è possibile.
  • Il troncamento del registro può verificarsi solo quando si verifica un punto di arresto (manuale o automatico), ad esempio poiché eseguendo backup completi regolari, non è necessario preoccuparsi del registro delle transazioni poiché CHECKPOINT si occuperà di riutilizzare la parte inattiva del file di registro.

Ricordare che il troncamento del registro NON è una riduzione fisica delle dimensioni del file di registro delle transazioni Significa che la parte inattiva del file di registro delle transazioni è contrassegnata come riutilizzabile .

Quindi è necessario preselezionare correttamente il file di registro delle transazioni (e i file di dati). La crescita del file di registro genererà eventi di crescita automatica (se il database è impostato su crescita automatica come ultima risorsa). Controlla la mia risposta - Autogrowth - Percentuale Utilizzo?

Consiglio vivamente di abbandonare i piani di manutenzione e implementare [una soluzione di manutenzione intelligente - che sia facile, flessibile e segua le migliori pratiche] - 5 . - La soluzione di backup di Ola (e anche la soluzione di manutenzione dell'Indice ).

cerchiamo di rispondere alle tue domande:

Il backup dei registri delle transazioni in questo modo li troncerà automaticamente o c'è qualcos'altro che devo fare?

Non aggiungere backup o impostarli per scadere. Creano un gran casino. Utilizzare INITe eseguire backup di log separati con timbro datetime. Facile da mantenere. Utilizzare la soluzione di backup di Ola per questo. La soluzione è flessibile anche per eliminare vecchi backup.

È possibile eseguire contemporaneamente backup dei dati e dei registri delle transazioni? In caso contrario, qual è il modo corretto di farlo?

Un backup completo non ha alcun effetto su un backup T-log. Un backup completo contiene solo il log delle transazioni sufficiente, in modo che, in caso di ripristino, il database possa essere coerente dal punto di vista transazionale con il momento in cui è stata completata la parte di lettura dei dati del backup completo. Verifica: quanto registro delle transazioni include un backup completo?

Inoltre, un backup del registro durante un backup completo non troncherà il registro delle transazioni. Un (paio di) backup del / i log al termine del backup completo tronca il registro.

I file di backup vengono raccolti durante la notte da un altro processo che acquisisce tutti i file sul server e li memorizza altrove - sarebbe una buona idea far scadere il set di backup dopo 2 giorni? Devo farli scadere del tutto?

Le attività di pulizia rimuovono rispettivamente i file "vecchi" .bak e .trn nelle sottocartelle di G: \ Backups. Ha senso? Sarebbe meglio farlo in SSIS, quindi posso fallire il mio ETL se / quando i backup falliscono? O dovrebbe interessarmi al mio processo ETL?

Per entrambi sopra, utilizzare la soluzione di manutenzione di backup di Ola. Si occuperà dell'eliminazione dei vecchi file.