SQL SERVER 2005 Enterprise e ripristino DB cancellato

lunedì 18 maggio 2009 - 14.26

the_driver Profilo | Senior Member

Ciao a tutti, ho in azienda un sql server 2005 enterprise edition e vorrei sapere: è possibile ripristinare un database ad un particolare momento o ricreare un db cancellato volontariamente o per sbaglio?

Che politica utilizza per eventuali disaster recovery?

grazie mille.

lbenaglia Profilo | Guru

>Ciao a tutti, ho in azienda un sql server 2005 enterprise edition
>e vorrei sapere: è possibile ripristinare un database ad un particolare
>momento o ricreare un db cancellato volontariamente o per sbaglio?

Disponendo di un full backup seguito da eventuali backup differenziali e del transaction log è possibile eseguire un recovery point-in-time ad una certa data e ora (il recovery model del db deve essere impostato a full).
Se hai eliminato per sbaglio un db (DROP DATABASE) e non disponi di alcun backup non esiste alcun modo di "ripescare" i dati

>Che politica utilizza per eventuali disaster recovery?
Quella che stabilisci tu in base alle tue esigenze

>grazie mille.
Prego.

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

the_driver Profilo | Senior Member

Come faccio, attraverso il log a ripristinare il db?

lbenaglia Profilo | Guru

>Come faccio, attraverso il log a ripristinare il db?
Quale log?
L'unico modo di ripristinare un db consiste nell'eseguire un restore di un full backup, seguito dal restore di eventuali backup differenziali o del transaction log.

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

the_driver Profilo | Senior Member

Ok,quello che mi sfugge è questo:

per esempio
cancello per sbaglio un campo di una tabella, ma il mio backup risale al giorno prima, quindi non ò più i valori inseriti dall'ultimo backup all'operazione di drop.

C'è modo di recuperare tali dati o li ho persi comunque?

scusa l'ignoranza

lbenaglia Profilo | Guru

>cancello per sbaglio un campo di una tabella, ma il mio backup
>risale al giorno prima, quindi non ò più i valori inseriti dall'ultimo
>backup all'operazione di drop.
Che significa quanto scritto sopra?

>C'è modo di recuperare tali dati o li ho persi comunque?
Ripristinando il backup del giorno precedente riotterrai il db in uno stato consistente che risale alla data e ora relativa alla fine del backup.
Ovviamente questo significa che perderai tutte le modifiche successive a tale data e ora.

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

the_driver Profilo | Senior Member

Ok, stavo pensando di creare un agent che facesse il backup ogni ora (incrementale) del DB.

Purtroppo ho un altro dubbio: lato sql server, c'è la possibilità di impostare(anche in un altro agent) un job che mi esporti da un DB delle VIEW in un file access?

Si può fare con SQL AGENT o devo impostare un JOB con SSIS?

grazie mille

lbenaglia Profilo | Guru

>Ok, stavo pensando di creare un agent che facesse il backup ogni
>ora (incrementale) del DB.
Iniziamo con l'utilizzare la terminologia corretta, altrimenti rischiamo di non capirci:

SQL Server Agent: scheduler di SQL Server
Job: Processo pianificato ad orari prefissati ed eseguito automaticamente dal SQL Server Agent.

Ora SQL Server NON permette di eseguire backup incrementali.
Le tipoligie di backup disponibili sono:

Full: backup completo di tutto il db;
Differenziale: vengono backuppate le data pages modificate a partire dall'ultimo full backup;
Transaction Log: esegue il backup del solo transaction log a partire dall'ultimo backup log.

Puoi approfondire questi aspetti sui Books online

>Purtroppo ho un altro dubbio: lato sql server, c'è la possibilità
>di impostare(anche in un altro agent) un job che mi esporti da
>un DB delle VIEW in un file access?
Per eseguire questa attività puoi creare un package DTS o SSIS (in base alla versione di SQL Server che utilizzi) e schedularne l'esecuzione tramite job.

>grazie mille
Prego.

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

the_driver Profilo | Senior Member

Full: backup completo di tutto il db;
Differenziale: vengono backuppate le data pages modificate a partire dall'ultimo full backup;
Transaction Log: esegue il backup del solo transaction log a partire dall'ultimo backup log.

Il FULL BACKUP effettua un append ad un file bak già presente? Se si, allora mi va bene. Questo dovrebbe garantirmi il restore di un db per un qualsiasi intervallo di tempo , giusto?

(esempio: restore del database DATABASE al giorno X all'ora Y )

Ti ringrazio! appena trovo qualche soluzione ti faccio sapere!

lbenaglia Profilo | Guru

>Il FULL BACKUP effettua un append ad un file bak già presente?
>Se si, allora mi va bene. Questo dovrebbe garantirmi il restore
>di un db per un qualsiasi intervallo di tempo , giusto?

Volendo puoi "appendere" i singoli backup set ad un unico media set in modo da avere un unico file con n backup set (anche di tipologia differente). Tieni presente, però, che se "appendi" n full backup ogni volta verranno accodati TUTTI i dati (compresi quelli precedentemente backuppati).

>(esempio: restore del database DATABASE al giorno X all'ora Y)
Questa funzionalità l'avrai eseguendo almeno un full backup seguito da almeno un backup del transaction log (il che implica che il recovery model del db deve essere impostato a full).

>Ti ringrazio! appena trovo qualche soluzione ti faccio sapere!
Le soluzioni le troverai leggendo BENE questi argomenti sui Books Online.

Ciao!

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

the_driver Profilo | Senior Member

Allora, ho creato il seguente script:
Il codice sorgente non è stato renderizzato qui
perchè non c'è sufficiente spazio.
Clicca qui per visualizzarlo in una nuova finestra

Tale backup effettua:
un shrink , un backup del file di log + test e un backup del database + test.

Ho letto sulle specifiche del comando BACKUP che vi è anche l'opzione DIFFERENTIAL.

Tale script verrà inserito in un job di SQL SERVER e partirà ogni ora. Mi chiedevo: inserendo la proprieta DIFFERENTIAL, mi ritroverò un FULL backup (iniziale) + le differenze ... quindi potrei risolvere il mio problema del RESTORE ad una certa ora?

grazie

lbenaglia Profilo | Guru

>Allora, ho creato il seguente script:
>use master
>/*compressione del database*/
>DBCC SHRINKDATABASE(N'Pippo', 10, TRUNCATEONLY)
>GO
>/*salvataggio file di log*/
>BACKUP LOG [Pippo]
>TO DISK = N'C:\BACKUPFTP\Pippo_backup.trn'
>WITH NOFORMAT, NOINIT, NAME = N'Pippo_backup', SKIP, REWIND,
>NOUNLOAD, STATS = 10

...
>/*salvataggio db*/
>BACKUP DATABASE [Pippo]
>TO DISK = N'C:\backupftp\Pippo_backup.bak'
>WITH NOFORMAT, NOINIT, NAME = N'Pippo_backup',
>SKIP,
>REWIND,
>NOUNLOAD,
>RESTART,
>STATS = 10
>GO

>Tale script verrà inserito in un job di SQL SERVER e partirà
>ogni ora.
1) Che senso ha eseguire lo shrink del db ogni ora? Teoricamente lo shink è una operazione che non andrebbe mai eseguita!
2) Che senso ha eseguire il backup del t-log seguito da un full backup?


>Mi chiedevo: inserendo la proprieta DIFFERENTIAL, mi
>ritroverò un FULL backup (iniziale) + le differenze
Si, ma solo dall'ultimo full backup.

>... quindi
>potrei risolvere il mio problema del RESTORE ad una certa ora?
Quello di sicuro, sempre se rispetti quanto scritto in precedenza.

>grazie
Prego.

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

the_driver Profilo | Senior Member

Ciao che problemi potrebbe dare effettuare lo shrink ?

Teoricamente con NOINIT dovrebbe aggiungere il nuovo backup al file bak già presente,giusto?

In che modo potrei risistemare questo script? Cosa consigli?

grazie

lbenaglia Profilo | Guru

>Ciao che problemi potrebbe dare effettuare lo shrink ?
Se effettui lo shrink ogni ora significa che il db tende ad aumentare di dimensioni, poi a seguito a cancellazioni lo vai nuovamente a rimpicciolire.
Questo continuo "tira e molla" non fa altro che frammentare i data files ed il t-log, comportando un riposizionamento continuo delle testine sulle tracce del disco, con conseguente decadimento di I/O.
Dimensiona opportunamente fin dall'inizio i files che costituiscono il tuo db in modo da non rendere necessarie eventuali estestensioni future.

>Teoricamente con NOINIT dovrebbe aggiungere il nuovo backup al
>file bak già presente,giusto?
Esatto, accodi il backup set al media set.

>In che modo potrei risistemare questo script? Cosa consigli?
Non conosco a sufficienza l'utilizzo del db, le sue caratteristiche e quanti dati sei disposto a perdere in caso di crash dello storage per poterti essere d'aiuto.

>grazie
Prego.

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

the_driver Profilo | Senior Member

effettivamente hai ragione, lo shrink potrebbe rallentare l' I/O del server. Forse è meglio se l' operazione viene fatta una sola volta al giorno o al più alla settimana (week end), con uno script dedicato.

Lo script che ho sviluppatto è un "template" che verrà utilizzato da un applicazione web e sarà utilizzato(e customizzato) per N sotto sistemi generati da questa applicazione.

Mediamente vengono effettuati un centinaio di insert al giorno su ogni DB.I dati sono molto importanti.Nel db non è possibile effettuare DELETE.


ps. Sono alla ricerca di corsi microsoft / certificazioni per SQL SERVER 2005, precisamente, vorrei specializzarmi sia nel mantenimento e amministrazione di un server sql ma anche nella gestione dei dati con SSIS , strumento che ho già utilizzato e che a noi serve parecchio. Cosa mi consiglieresti? Che percorso formativo mi consiglieresti?

Grazie mille!

lbenaglia Profilo | Guru

>effettivamente hai ragione, lo shrink potrebbe rallentare l'
>I/O del server. Forse è meglio se l' operazione viene fatta una
>sola volta al giorno o al più alla settimana (week end), con
>uno script dedicato.
Ancora meglio non eseguirla mai dato che è una operazione del tutto inutile
Se il db si ingrandisce significa che DEVE ingrandirsi, quindi non ha senso continuare a rimpicciolirlo.

>Mediamente vengono effettuati un centinaio di insert al giorno
>su ogni DB.I dati sono molto importanti.Nel db non è possibile
>effettuare DELETE.
Quindi non ha senso eseguire alcuno shirnk.

>ps. Sono alla ricerca di corsi microsoft / certificazioni per
>SQL SERVER 2005, precisamente, vorrei specializzarmi sia nel
>mantenimento e amministrazione di un server sql ma anche nella
>gestione dei dati con SSIS , strumento che ho già utilizzato
>e che a noi serve parecchio. Cosa mi consiglieresti? Che percorso
>formativo mi consiglieresti?
Giusto ieri ho risposto al medesimo quesito:
http://www.dotnethell.it/forum/messages.aspx?ThreadID=31358

>Grazie mille!
Prego.

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

the_driver Profilo | Senior Member

Ok ,allora provvedo a togliere lo shrink dallo script.

Per quanto riguarda il backup, faccio prima il backup del db e poi quello del log o viceversa?

A questo punto pensavo: faccio un backup completo la prima volta e ogni ora esegui il backup del file di log,aggiungendo le modifiche.

Giusto?

cosi facendo potrò sempre ripristinare il db ad un preciso stato (mese o anno passato)?

lbenaglia Profilo | Guru

>Per quanto riguarda il backup, faccio prima il backup del db
>e poi quello del log o viceversa?
Eseguire un backup log immediatamente dopo un full backup non ha alcun senso, dato che nel caso peggiore andrai a salvare una manciata di transazioni.
Studiati bene sui Books Online la differenza tra full, log e differential backup.

>A questo punto pensavo: faccio un backup completo la prima volta
>e ogni ora esegui il backup del file di log,aggiungendo le modifiche.
>
>Giusto?
Per esserlo lo è, ma nel tuo contesto ha senso?
E' quello che vuoi?
Se la risposta è affermativa, allora va bene

>cosi facendo potrò sempre ripristinare il db ad un preciso stato
>(mese o anno passato)?
Se tieni da parte tutta la catena di backup allora la risposta è affermativa. Preparati un ambiente di test e simula i ripristini point-in-time per capire come funzionano.

Ciao!

--
Lorenzo Benaglia
Microsoft MVP - SQL Server
http://blogs.dotnethell.it/lorenzo/
http://italy.mvps.org
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 !
Copyright © dotNetHell.it 2002-2024
Running on Windows Server 2008 R2 Standard, SQL Server 2012 & ASP.NET 3.5