Ridurre dimensione LDF
LsK_Lele
ho un database che occupa parecchio spazio, controllando i files ho
notato che il file db.ldf occupa 11Gb mentre il db.mdf solo 3,8Gb.
Esiste un modo per "comprimere" il file di log del database?
Grazie, a presto!
David Martin
Senza rancore, ma è un argomento trito e ritrito ;-)
Alcuni spunti:
- il sistema naturale per evitare che il t-log cresca a dismisura, è
fare il backup del log con l'istruzione BACKUP LOG (fai riferimento ai
BOL per i dettagli);
- verifica che non ti basti un modello di recupero di tipo semplice, che
provvede a riutilizzare il t-log dopo che le transazioni sono state
scritte nel file dati.
- http://www.dotnethell.it/tips/ShrinkTLOGSql2000.aspx
--
David Martin
Luca Bianchi
> che il file db.ldf occupa 11Gb mentre il db.mdf solo 3,8Gb.
> Esiste un modo per "comprimere" il file di log del database?
Esiste una sana e consapevole politica di backup del t-log...
Fai una ricerca tra i post di questo ng e troverai qualche miliardata di
post al riguardo...
> Grazie, a presto!
Bye
--
Luca Bianchi
Microsoft MVP - SQL Server
http://community.ugiss.org/blogs/lbianchi
LsK_Lele
> Senza rancore, ma è un argomento trito e ritrito ;-)
Nessun rancore, figuriamoci!
Grazie, sia a te che a Luca ;-)
Ciao!
Bitbreaker
news:<47837c79$0$4784$4faf...@reader4.news.tin.it>...
Anche se e' un argomento trito e ritrito, provo a risponderti umilmente,
prendendo spunto
dalla mia esperienza (forzata) da DBA.
Un Database, In SqlServer, ha diversi Recovery Model: Simple, Bulk e Full.
Ognuno di questi ha i suoi vantaggi e svantaggi e la loro scelta dipende da
quanti dati sei disposto a perdere
in caso di crash.
Parliamo del caso piu' "frequente" che forse e' quello in cui ti trovi :
recovery model Full.
In questa modalita', tutte le transazioni che esegui sul DB, vengono
memorizzate sul file di Log ovvero sull'LDF.
Li' si accumulano allo scopo di essere backuppate ed utilizzate, in caso di
crash, per recuperare la situazione piu' recente.
Il tuo caso e' quello, probabilmente, di un DB senza Maintenance Plan
accurato che prevederebbe un backup (piu' o meno)
frequente del Transaction Log (allo scopo di marcare le transazioni
memorizzate come "valide per la sovrascrittura" all'interno del Transaction
Logs stesso)
ed un, eventuale ma non consigliatissimo Shrink del file di Log.
Termino con le istruzioni che dovresti eseguire per il Backup del
Transaction Log:
BACKUP LOG MioDatabase TO DISK = 'N:\BackupLog_200801191604.trn' WITH INIT
Naturalmente, impostando un Maintenance Plan, questo lo puoi schedulare, per
esempio, ogni 2 ore...ogni giorno...insomma, ogni
quanto ritieni utile.
Al fine di "sgonfiare" il Transaction Log, ti conviene (magari solo
all'inizio), eseguire piu' volte l'istruzione sopra (specificando file
diversi) e poi
eseguire un
DBCC SHRINKFILE('NomeFile_Log',2)
Il numero 2 è il numero di pagine non backuppate da lasciare nel Transaction
Log...naturalmente SQLServer ci metterà del suo e non troncherà meno delle
pagine minime richieste dalle transazioni in corso.
Spero di essere stato chiaro e di non essere stato troppo impreciso...
Igor.
>
> Grazie, a presto!
David Martin
> DBCC SHRINKFILE('NomeFile_Log',2)
>
> Il numero 2 è il numero di pagine non backuppate da lasciare nel Transaction
> Log...naturalmente SQLServer ci metterà del suo e non troncherà meno delle
> pagine minime richieste dalle transazioni in corso.
Questa non mi torna proprio... riportano i BOL per l'istruzione DBCC
SHRINKFILE:
--------------------------------------------------------------------
target_size
Dimensioni finali per il file, in megabyte, espresse come valore di tipo
integer. Se target_size viene omesso, le dimensioni del file vengono
ridotte fino alle dimensioni di file predefinite.
--------------------------------------------------------------------
Anche specificando il parametro target_size, non possiamo comunque
essere sicuri che SQL Server lo possa rispettare, perché l'unità di
allocazione del t-log sono i vlf.
Nei BOL è ben spiegato tutto il meccanismo, all'indirizzo:
mk:@MSITStore:C:\Programmi\Microsoft%20SQL%20Server\80\Tools\Books\architec.chm::/8_ar_da2_1uzr.htm
--
David Martin