La cosa che ho notato è che SQL mette di default il valore 2.097.152 MB per
il log. è davvero necessario così alto? o c'è un modo per settare a tutti i
DB una dimensione più "umana" per questo file di log?
grazie a tutti!
Se il t-log è arrivato a queste dimensioni significa che ci sono delle
enormi carenze amministrative. In particolare che
1) il recovery model è diverso da SIMPLE
2) Non è MAI stato eseguito un backup del transaction log
Entrambe queste condizioni sono sicuramente vere per i tuoi database e,
quindi, la prima cosa che ti suggerisco di fare è di mettere il recovery
model a SIMPLE per ridurre le dimensioni logiche del t-log (ma non quelle
fisiche). Una volta impostato il recovery model a SIMPLE puoi ridimensionare
il t-log nelle sue dimensioni fisiche ad un valore più consono tramite il
comando
DBCC SHRINKFILE (nomedb, size)
Di questo comando troverai ampia documentazione sul BOL (la guida di SQL
Server).
Fatto questo per non trovarti fra una settimana, un mese o comunque fra un
po di tempo nella stessa situazione, puoi lasciare il recovery model a
SIMPLE (rinunciando quindi a tutte le peculiarità del t-log), oppure puoi
impostare il recovery model a BULK LOGGED o a FULL e pianificare una
adeguata strategia di backup del t-log per ciascun database.
Fai riferimento al BOL per ulteriori approfondimenti; anche in questo ng si
è parlato più volte dell'argomento...
> La cosa che ho notato è che SQL mette di default il valore 2.097.152 MB
> per
> il log. è davvero necessario così alto?
Attenzione che quello è il "max size"; ovviamente il max size reale sarà
quello inferiore tra questo valore e lo spazio disco effettivamente
presente...
> o c'è un modo per settare a tutti i
> DB una dimensione più "umana" per questo file di log?
L'impostazione sia del recovery model che della frequenza di backup del
t-log (se decidi per avere un recovery model diverso da SIMPLE) devi farla
per ciascun database. PErò se utilizzi SQL Server 2008 puoi farla in maniera
semplice e generalizzata utilizzando le policy e, nel caso, un configuration
server se la policy devi applicarla non solo a tutti i database di una
istanza ma anche a differenti database server...
> grazie a tutti!
Bye
--
Luca Bianchi
Microsoft MVP - SQL Server
http://community.ugiss.org/blogs/lbianchi
"Luca Bianchi" wrote:
Grazie infinite per le dritte perchè sono state utilissime ed ho risolto.
Ora ti faccio un'altra domanda: l'impostazione del backup va fatta da sql
oppure, con l'ntbackup, posso backuppare la cartella dove risiedono MDF e
t-log? Se uso l'ntbackup settando di salvare la cartella dei db ci possono
essere problemi di inconsistenza del db (dato che SQL è attivo)?
grazie!
NTBackup non è in grado di fare backup con file in uso.
Quando si parla di backup, in SQL Server si intende SOLO il backup fatto
(con i comandi T-SQL) del database come oggetto logico. Il backup a livello
di file system NON è un backup del database; idem il backup del file con
estensione ldf NON è il backup del t-log.
> grazie!
Usa sempre il backup dell' SQL
> grazie!
Prego
--
___________
Ruggiero Lauria
MCSA-MCSE-MS SQL DBA
Cavoli è vero, oggi è lunedì!!!!
Se non ci fosse un log ogni w.e. a scoppiare il lunedì mi passerebbe molto
più indifferentemente :)