Tecniche di BACKUP SQL SERVER 2000

mercoledì 15 luglio 2009 - 12.27

Elenco Threads

Stanze Forum

Aggiungi ai Preferiti

Cerca nel forum

Aragorn2004 Profilo | Newbie

39 messaggi | Data Invio: mer 15 lug 2009 - 12:27

Ciao, sto implementando una SP per eseguire backup di un db intero e del suo log.
Metodo di recovery è e deve essere full.

Diciamo che questa store dovrebbe essere processata tutte le sere.

Attualmente il file dati è sui 160MB suppongo con un tasso di crescita basso nel breve periodo.
Invece il file di Log nel giro di 10 giorni è salito a circa 1.5 GB. Il DB è usato soprattutto per modificare e cancellare.
I dati nuovi inseriti giornalmente sono relativamente bassi.

Il mio obiettivo è quello di avere sempre disponibile una copia di backup e anche però ridurre periodicamente le dimensioni del file di log.

Eseguo prima i backup interi del db e del log dopodichè tronco il LOG

Nella store eseguo un backup per ogni giorno della settimana in modo tale da avere separati i files relativi a quel determinato giorno.

@NomeDevDB è il nome del device scelto in funzione del giorno della settimana.

BACKUP DATABASE MYDATA TO @NomeDevDB WITH INIT
BACKUP LOG MYDATA TO @NomeDevLOG WITH INIT
BACKUP LOG MYDATA WITH TRUNCATE_ONLY

A questo punto diciamo che vorrei ridurre le dimensione del log

Secondo voi è sensato fare una cosa del genere oppure si può fare meglio.

ALTER DATABASE MYDATA
SET RECOVERY SIMPLE

DBCC SHRINKFILE (MYDATA_LOG, 1)

ALTER DATABASE MYDATA
SET RECOVERY FULL

Grazie ancora

Ciao.

lbenaglia Profilo | Guru

5.625 messaggi | Data Invio: mer 15 lug 2009 - 13:29

>Eseguo prima i backup interi del db e del log dopodichè tronco
>il LOG
Male, perché tronchi il t-log se poi ricresce?
Agendo in questo modo non fai altro che aumentare la frammentazione del file .ldf.

>BACKUP DATABASE MYDATA TO @NomeDevDB WITH INIT
>BACKUP LOG MYDATA TO @NomeDevLOG WITH INIT
>BACKUP LOG MYDATA WITH TRUNCATE_ONLY
>
>A questo punto diciamo che vorrei ridurre le dimensione del log
>
>Secondo voi è sensato fare una cosa del genere oppure si può
>fare meglio.
No, per niente:

1) Non ha senso eseguire un backup del t-log immediatamente dopo un full backup (non copieresti praticamente niente);
2) E' sbagliato troncare il t-log.

>ALTER DATABASE MYDATA
>SET RECOVERY SIMPLE
>
>DBCC SHRINKFILE (MYDATA_LOG, 1)
>
>ALTER DATABASE MYDATA
>SET RECOVERY FULL
No, no, no...
Prima di iniziare l'implementazione di una politica di backup devi avere le idee chiare sull'utilizzo nelle 24 ore del db e quanti dati sei disposto a perdere in qualunque momento a causa di un crash del sistema.

>Grazie ancora
Prego.

Ciao!
--
Lorenzo Benaglia
Microsoft MVP - SQL Server
http://blogs.dotnethell.it/lorenzo/
http://italy.mvps.org

Aragorn2004 Profilo | Newbie

39 messaggi | Data Invio: mer 15 lug 2009 - 14:31

Allora innanzitutto grazie Lorenzo, ora vediamo se riesco a chiarire/rmi le idee.
Diciamo che:
la maggiorparte del lavoro avviene tra le 8.00 e le 20.00
Per cui fermo restando il backup full a fine giornata, non capisco come muovermi se backuppare i log che dico 2/3 volte tra le 8 e le 20.00 oppure e forse dico un'eresia un backup differenziale e qui chiedo magari aiuto a te che sicuramente ne hai da insegnare.

Inoltre ancora non capisco se questo file di Log sia destinato a rimanere sempre enorme in termini di dimensioni.
Vediamo se riesco a spiegarmi: se eseguo un backup totale questo conterrà ance tutto il log delle transazioni chiuse, giusto.
Ecco perchè mi dici che è inutile backuppare il log dopo un backup full.
Ora diciamo che io non tronco il log, che cosa succede al file di log dopo un backup full: SQL inizierà a scrivere sulla parte più vecchia o continuerà ad aumentare le dimensioni del file.

Qual'è il tuo consiglio rispetto a questo file di log ?

Ciao e ancora grazie.

lbenaglia Profilo | Guru

5.625 messaggi | Data Invio: mer 15 lug 2009 - 16:57

>la maggiorparte del lavoro avviene tra le 8.00 e le 20.00
>Per cui fermo restando il backup full a fine giornata, non capisco
>come muovermi se backuppare i log che dico 2/3 volte tra le 8
>e le 20.00 oppure e forse dico un'eresia un backup differenziale
>e qui chiedo magari aiuto a te che sicuramente ne hai da insegnare.

Supponiamo che ti puoi permettere di perdere al più 1 ora di lavoro.
Come prima cosa imposti il recovery model del db a full.
Potresti implementare la seguente politica di backup:

- Un full backup alla mezzanotte;
- Un differenziale a mezzogiorno;
- Un backup del t-log ogni ora tra le 8:00 e le 20:00.

Simulazione di un crash
----------------------------

Es. 1: Alle 10:34 si schianta il server.
Una volta riparato il guasto, tenterai di eseguire un ultimo backup del t-log in modo da recuperare quei 34 minuti scoperti dall'ultimo backup.
A questo punto eseguirai i seguenti restore:

1) Restore del full backup notturno;
2) Restore del backup del t-log delle 9:00;
3) Restore del backup del t-log delle 10:00;
4) Se ci sei riuscito, restore dell'ultimo backup del t-log;
5) Esegui una recovery del db.

A questo punto ti ritroverai tutti i dati committati al momento del crash.

Es. 2: Alle 16:56 schianta il server.
Come prima cercherai di eseguire un ultimo full backup del t-log.
I passi per ripristinare il tutto saranno:

1) Restore del full backup notturno;
2) Restore del backup differenziale delle 12:00;
3) Restore del backup del t-log delle 13:00;
4) Restore del backup del t-log delle 14:00;
5) Restore del backup del t-log delle 15:00;
6) Restore del backup del t-log delle 16:00;
7) Se ci sei riuscito, restore dell'ultimo backup del t-log;
8) Esegui una recovery del db.

Chiaro?

>Inoltre ancora non capisco se questo file di Log sia destinato
>a rimanere sempre enorme in termini di dimensioni.
Questo dipende dall'utilizzo del db e dalla frequenza dei backup del t-log.

>Vediamo se riesco a spiegarmi: se eseguo un backup totale questo
>conterrà ance tutto il log delle transazioni chiuse, giusto.
No, conterrà una minima porzione del t-log necessaria al recovery successivo al restore.

>Ecco perchè mi dici che è inutile backuppare il log dopo un backup
>full.
E' inutile perché le transazioni eseguite tra il full backup ed il backup del t-log saranno una manciata.

>Ora diciamo che io non tronco il log, che cosa succede al file
>di log dopo un backup full: SQL inizierà a scrivere sulla parte
>più vecchia o continuerà ad aumentare le dimensioni del file.
Continuerà ad accodare le nuove transazioni alle vecchie, estendendo il t-log nel caso in cui sia pieno.
La sovrascrittura delle vecchie transazioni la avrai successivamente al backup del t-log.

>Qual'è il tuo consiglio rispetto a questo file di log ?
??

>Ciao e ancora grazie.
Prego.

Ciao!
--
Lorenzo Benaglia
Microsoft MVP - SQL Server
http://blogs.dotnethell.it/lorenzo/
http://italy.mvps.org

Aragorn2004 Profilo | Newbie

39 messaggi | Data Invio: mer 15 lug 2009 - 18:56

Grazie ancora Lorenzo. Mi hai dato una grande mano e soprattutto mi hai spiegato a puntino il processo.

Grazie immensamente ancora.

Ciao.

Torna su

Stanze Forum

Elenco Threads

Partecipa anche tu! Registrati!

Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !