andrea.vermetti ha scritto:
mydb.mdf = 12 Mega
mydb.ldf = 31 Giga
COSA SBAGLIO?????,,, PERCHE' CON COSI' POCHI DATI E CON UN DB COSI' PICCOLO IL FILE .ldf PESA COSI' TANTO?????
...la crescita anomala del t-log indica una inefficiente piano di gestione del t-log. Nel tuo caso ritengo che sia del tutto assente qualunque strategia di backup dello stesso.
Innanzitutto devi immaginare il transaction log (t-log) come un insieme di contenitori (virtual log) che vengono riempiti ciclicamente. A seconda delle necessità (e delle impostazioni delle sue proprietà) il t-log può espandersi e vengono generati altri virtual log che vengono progressivamente riempiti e utilizzati da SQL Server.
Per liberare lo spazio nel t-log devi eliminare la parte di transazioni che e' stata consolidata fisicamente dal meccanismo di CHECKPOINT. Il checkpoint è il processo in cui le pagine modificate da transazioni già concluse vengono scritte materialmente su disco.
Il processo di checkpoint "dichiara inattiva" la porzione di t-log che è stata resa permanente su disco e un successivo backup del t-log (eventualmente specificando l'opzione WITH TRUNCATE_ONLY se non intendi salvare il log delle transazioni) ne svuota il contenuto ma non restituisce tale spazio al sistema operativo ma lo rende nuovamente disponibile per l'utilizzo da parte del t-log.
Quindi l'attività di backup riduce le dimensioni logiche del file di log e non le sue dimensioni fisiche. Per restituire lo spazio "inutilizzato" del t-log (ossia i virtual log inattivi) al sistema operativo è possibile utilizzare le istruzioni DBCC SHRINKDATABASE oppure DBCC SHRINKFILE.
Se l'opzione del database "Truncate log on checkpoint" e' attiva (versione 7.0 di SQL Server) oppure il database è in SIMPLE RECOVERY MODE (versione 2000), il log viene automaticamente svuotato (nelle sue dimensioni logiche) al CHECKPOINT.
Ci sono casi in cui il file di log potrebbe comunque non ridursi oppure ridursi solo in parte.
Questo comportamento apparentemente anomalo trova invece spiegazione in quanto detto precedentemente in merito ai virtual log. Dal momento che il virtual log è utilizzato in maniera ciclica la riduzione delle dimensioni del t-log è vincolato al fatto che la parte inattiva del log delle transazioni si trovi nella parte finale del log stesso.
E' possibile utilizzare il comando
DBCC LOGINFO(nomedb)
(si tratta di una istruzione non documentata di cui non troverai traccia nel Book On Line di SQL Server) per verificare dove si trova la parte attiva del log; la parte attiva e' quella marcata con Status = 2 e qualora, come detto, si trovasse nella parte terminale del file, la compattazione del file di log non sara' quindi eseguita finche' la parte attiva non si sposterà nella parte iniziale.
E' possibile muovere la parte attiva del log in testa al file continuando a generare transazioni, svuotando i virtual log con i comandi di BACKUP LOG ed eseguendo il comando DBCC SHRINKFILE finche' il file non si ridimensiona (tieni comunque presente che il transaction log non puo' comunque avere dimensione inferiore alla dimensione dei singoli virtual log e tale dimensione e' determinata in fase di creazione del log).
Inoltre ti suggerisco di valutare quale recovery model è più adatto alle tue esigenze. SQL Server 2000 ti da la possibilità di scegliere 3 impostazioni di Recovery Model ciascuno con le proprie peculiarità e che, a seconda della strategia di disaster recovery in uso, può rivelarsi più o meno idoneo alla propria esigenza.
Per la vastità degli argomenti trattati e non essendo possibile trasformare questo messaggio in un libro ti suggerisco di far riferimento al Book On Line di SQL Server per eventuali approfondimenti.
Ciao...
