Ciao, volevo chiedervi alcune cose:

Se eseguo la copia (tasto dx copia) da windows, dei file DB.MDF e
DB_log.ldf, posso star sicuro a livello di backup? Ci sono altre cose da
salvare?
Le stored procedures sono salvate all'interno del file MDF?

Inoltre ultima cosa che non ho ben capito, ma il file di log che crea il DB
che cosa contiene? Come lo si legge?
Grazie molte!

Marco

> Se eseguo la copia (tasto dx copia) da windows, dei file DB.MDF e
> DB_log.ldf, posso star sicuro a livello di backup?

Certo che no... :-)
A parte il fatto che un "backup" di questo tipo (nota le virgolette) può
dirsi vagamente un backup SOLO ED ESCLUSIVAMENTE se fatto a servizio fermo
(primo problema: limiti la continuità del servizio) faresti il backup di
tutti gli oggetti di database ma resterebbero fuori gli oggetti di sistema
(login, job, alert, ecc).
Ragion per cui ti consiglio di implementare una VERA strategia di backup
(sia dei database utente che di quelli di sistema) che faccia il backup a
livello di SQL Server (ovvero dei database come oggetto logico e non dei
file che lo compongono) ma, soprattutto, fare anche delle simulazioni di
ripristino. Fare il backup non serve a niente se hai difficoltà a procedere
al ripristino dei dati e solo un test di ripristino può darti la certezza
che la strategia di backup scelta sia valida.

> Le stored procedures sono salvate all'interno del file MDF?

No. Le stored procedure, al pari di tutti gli oggetti di database (tabelle,
viste, utenti, ruoli, default, ecc) sono dentro il database visto come
oggetto logico. Evidente che poi questo oggetto logico sia composto da 2 o
più file fisici... ma la cosa è ben diversa...

> Inoltre ultima cosa che non ho ben capito, ma il file di log che crea il
> DB
> che cosa contiene?

Il t-log rappresenta il giornale delle modifiche e serve ad assicurare
l'integrità logica dei dati. Ogni modifica che apporti al db viene scritta
in memoria e nel t-log e solo successivamente nel file dati. In maniera
asincrona un processo scandisce le pagine in memoria e le riversa nei file
dati. Il t-log serve a garantirti, tra le altre cose, che, qualunque cosa
succeda (QUALUNQUE COSA SUCCEDA), alla successiva ripartenza il database sia
integro e che tutte le informazioni modificate (riversate o no sul file
dati) vengano comunque applicate.

> Come lo si legge?

Normalmente non avrai mai necessità di farlo. Ad ogni modo ci sono tools di
terze parti (esempio SQL Log Rescue di Red-Gate e Apex SQL Log di Apexsql)
in grado di curiosare dentro il t-log

> Grazie molte!
>
> Marco

Bye

"Luca Bianchi" wrote:

[..]
> terze parti (esempio SQL Log Rescue di Red-Gate e Apex SQL Log di Apexsql)
> in grado di curiosare dentro il t-log
>> Bye
>
> --
> Luca Bianchi
> Microsoft MVP - SQL Server
> [..]

Ciao Luca, ti volevo ringraziare per la spiegazione e complimenti per la
compentenza. Che dire, sono rimasto abbastanza sorpreso nel sapere che quello
che facevo era un backup alla carlona e soprattuto parziale.
Mi sono armato di un po di volontà a mi son messo a leggere per come poter
fare ad ottenere un backup "decente" (non so se ci sono riuscito in realtà).
Oltre alla copia che ti ho detto (semi-inutile) ho creato uno script che poi
lancio con SQLCMD <istanza> -i <nomeFile>.

Mi permetto di postarlo per una tua (graditissima) verifica.

USE master;
GO
ALTER DATABASE MIODB
SET RECOVERY FULL;
GO
-- Create MIODBData and MIODBLog logical backup devices.
USE master
GO
EXEC sp_addumpdevice 'disk', 'MIODBData',
'C:\SQLServerBackups\MIODBDATA.bak';
GO
EXEC sp_addumpdevice 'disk', 'MIODBLog',
'C:\SQLServerBackups\MIODBLog.bak';
GO

-- Back up the full MIODB database.
BACKUP DATABASE MIODB TO MIODBData;
GO
-- Back up the MIODB log.
BACKUP LOG MIODB
TO MIODBLog;
GO
-- END
============================

Lanciandolo mi crea i 2 file (.bak) di dimensioni un pochino infeririori
rispetto al file .mdf

Cosa ne pensi? ho migliorato un po ? devo cambiare qualcosa? devo salvare
qualcos'altro?

So che sono noioso (ed hai ragione) ma mi è successo una cosa terribile al
pc nel quale gira sql che "miracolosamente" sono riuscito a sistemare, e
adesso, mi rendo conto di quanto possa essere importante tenere un backup!

Grazie mille e spero un giorno di poter ricambiare.
Marco

>> Come lo si legge?
>
> Normalmente non avrai mai necessità di farlo. Ad ogni modo ci sono tools
> di terze parti (esempio SQL Log Rescue di Red-Gate e Apex SQL Log di
> Apexsql) in grado di curiosare dentro il t-log

In realtà il T-SQL fornisce gli strumenti di base per leggere il t-log ma,
come puoi vedere da questo post pubblicato giusto oggi la cosa non è affatto
agevole e richiede una elevata competenza

http://www.sqlskills.com/BLOGS/PAUL/...ction-log.aspx

Bye

"Luca Bianchi" wrote:

>
> In realtà il T-SQL fornisce gli strumenti di base per leggere il t-log ma,
> come puoi vedere da questo post pubblicato giusto oggi la cosa non è affatto
> agevole e richiede una elevata competenza
>
> [..]
>
> Bye
>
> --
> Luca Bianchi
> Microsoft MVP - SQL Server
> [..]

Grazie Luca anche di questo :)
In effetti dopo quello che mi hai detto, non trovo esigenza di andarlo ad
aprire, era solo per avere idea di cosa fosse quel log :P

La mia grande preoccupazione è ora il backup fatto a modo! :)

> Lanciandolo mi crea i 2 file (.bak) di dimensioni un pochino infeririori
> rispetto al file .mdf

Si, è giusto... il database ha uno spazio allocato (ovvero utilizzato dagli
oggetti del database) e una riserva di spazio libero. Solo se lo spazio
libero fosse pari a zero le dimensioni del backup coinciderebbero con lo
spazio del database (più o meno). Le dimensioni del backup del t-log,
invece, dipendono da quante informazioni ci sono dentro al t-log stesso e,
di conseguenza, da quanto tempo non fai il backup del t-log.

> Cosa ne pensi? ho migliorato un po ? devo cambiare qualcosa? devo salvare
> qualcos'altro?

L'esecuzione del backup deve fare solo il backup.
L'impostazione del recovery model una volta scelta rimane tale fino a mutate
esigenze e non ha senso impostare il recovery model ad ogni esecuzione del
backup.
Idem la definizione dei device... una volta impostati quelli sono e quelli
rimangono fino a che non decidi di modificare il percorso o il nome del
device (e ti ricordo che definire il device non è strettamente necessario).
Un backup fatto sullo stesso server dei dati ti serve a poco. Cosa faresti
se si ferma il server? Il backup DEVE essere fatto su una risorsa di rete ed
anche se esegui la copia del file di backup subito dopo averne fatto il
backup ti esponi comunque ad un rischio proporzionale al tempo che passa tra
la fine del backup e la fine della copia che invece elimineresti facendo un
backup su una risorsa esterna al database server.
Infine fare un backup del t-log subito dopo un backup completo serve anche
questo a poco (solo ad un restore-point-in-time) e tanto vale, allora,
schedularlo lontano dal backup completo per ridurre la quantità di dati
persi a seguito di un danno

> So che sono noioso (ed hai ragione) ma mi è successo una cosa terribile al
> pc nel quale gira sql che "miracolosamente" sono riuscito a sistemare, e
> adesso, mi rendo conto di quanto possa essere importante tenere un backup!

L'importante è pensarci prima... c'è chi se ne rende conto troppo tardi...
:-)

http://community.ugiss.org/blogs/lbi...ray-raid1.aspx
http://community.ugiss.org/blogs/lbi...very-plan.aspx

> Grazie mille e spero un giorno di poter ricambiare.
> Marco

Bye

Luca,
ho letto con attenzione quanto mi hai scritto. Mi permetto di ricapitolare
per fissare bene le idee. La procedura che ho scritto (vedi scopiazzato) è
fatta bene ma SOLO per la prima volta che la si esegue in quanto cosi
facendo, introduco dei parametri che il DB si tiene in memoria nel tempo.

Per tanto, è sufficiente modificare il mio script in:
------------------------------------
USE master;
GO
ALTER DATABASE MIODB
BACKUP DATABASE CEG TO MIODBdata;
GO
------------------------------------

(non sono sicuro di quell'alter perchè a logica, non voglio alterare niente
hehe, ma solo backupparre :):) )

Per quanto rigarda lo spazio dove salvo, sarà un server di rete ben
backuppato e non il C:\.

Il log Backup non ha senso farlo assieme, meglio farlo posticipato o
comunque differenziato. Ok! creerò un secondo file.sql per il log e lo
schedulerò distante nel tempo (1 o 2 ore).

Se quanto scritto su andasse bene, ho solo un dubbio, tutte le volte il
backup avviene con lo stesso nome.. ma cosi facendo lo sovrascrivo... Mi
servirebbe avere il backup storico (diciamo di almeno una o due settimane)..
Esiste un modo per passare una variabile con il nome del file .bak e la data
attuale? tipo BackupMIODB17062009.bak?

> fatta bene ma SOLO per la prima volta che la si esegue in quanto cosi
> facendo, introduco dei parametri che il DB si tiene in memoria nel tempo.

Esatto... sia il recovery model che i device vengono definiti una tantum...
fino a che non hai necessità di modificarli puoi scordarti di questi
comandi...

> (non sono sicuro di quell'alter perchè a logica, non voglio alterare
> niente
> hehe, ma solo backupparre :):) )

Infatti il comando ALTER DATABASE non centra proprio niente... :-)

> Per quanto rigarda lo spazio dove salvo, sarà un server di rete ben
> backuppato e non il C:\.

Bene...

> Il log Backup non ha senso farlo assieme, meglio farlo posticipato o
> comunque differenziato. Ok! creerò un secondo file.sql per il log e lo
> schedulerò distante nel tempo (1 o 2 ore).

Tieni presente che un backup del t-log dura veramente pochissimo. In taluni
ambienti lo eseguo ogni 10 minuti. Per iniziare va bene schedularlo ogni 2-3
ore salvo poi customizzare questo intervallo per aumentare o ridurre la
finestra...

> Se quanto scritto su andasse bene, ho solo un dubbio, tutte le volte il
> backup avviene con lo stesso nome.. ma cosi facendo lo sovrascrivo...

No, non lo sovrascrivi... vai in append... per sovrascriverlo devi
aggiungere, in coda al comando di backup, l'opzione INIT (sta per
INITialize).

> Mi
> servirebbe avere il backup storico (diciamo di almeno una o due
> settimane)..
> Esiste un modo per passare una variabile con il nome del file .bak e la
> data
> attuale? tipo BackupMIODB17062009.bak?

Si, ma per tutta una serie di motivi ti suggerirei di implementare una
strategia simile a quella descritta in questo post

http://groups.google.it/group/micros...b1233e76c76125

Inoltre avere SEMPRE lo stesso nome del file mi permette di creare uno
script di ripristino, archiviarlo, e lasciarlo li fino al momento del
bisogno. Se dovesse servire chiunque sarà in grado di lanciare lo script di
RESTORE senza doverlo customizzare e, come ben sai, in situazioni di
emergenza e preferibile avere più certezze possibile.
Forse puoi trovare utile anche questo script

http://community.ugiss.org/blogs/lbi...ipristino.aspx

che se mantieni backup full e t-log (ed eventualmente anche differenziali)
ti ricostruisce la giusta sequenza di ripristino


Bye

"Luca Bianchi" wrote:

[..]
> [..]
>
> che se mantieni backup full e t-log (ed eventualmente anche differenziali)
> ti ricostruisce la giusta sequenza di ripristino
>> Bye
>
> --
> Luca Bianchi

Luca, mio eroe!
============
USE master;
GO
BACKUP DATABASE MIODB TO MIODBdata;
GO
============
Il tutto si riduce a questo.

Non so come ringraziarti. Stasera pianifico il backup programmato.
Adesso farò sogni piu tranquilli.

Buona serata, Marco

> Luca, mio eroe!

:-))

> Il tutto si riduce a questo.

Ridurre per ridurre... anche il comando USE master non è poi necessario...
Inoltre tieni presente che se il recovery model è FULL (o BULK-LOGGED) e non
implementi una strategia di backup basata ANCHE sul backup del log delle
transazioni il t-log di quel database è destinato a crescere fino a saturare
il disco su cui è posizionato. O modifichi il recovery model oppure DEVI
implementare una strategia di backup che preveda, anche solo 2o 3 volte al
giorno, il backup del t-log...

> Non so come ringraziarti. Stasera pianifico il backup programmato.
> Adesso farò sogni piu tranquilli.

Saranno ancora più tranquilli quando avrai fatto anche dei test di
ripristino... :-)

> Buona serata, Marco

Bye