none
FILE LDF di dimensioni allucinanti. Come ridurlo? RRS feed

 > 

  • Domanda

  • Question
    Registrati per votare
    0
    Registrati per votare

    Ciao a tutti.

    Dopo circa 1 anno dall'installazione del sql 2008r2 mi accorgo che il database è cresciuto in dimensioni molto.

    Purtroppo causa mia dimenticanza ho lasciato il recovey mode a full e non a simple

    risutato:

    Databae 190 gb

    ldf:  140 gb

    Ora, chiaramente lo spazio su disco sta scarseggiando, quindi vi chiedo:

    Come faccio a ridurre il file LDF?

    COnsiderate che:

    -Il database e in "simple" in recovey model

    -lo scrink sul database non da buoni risulti

    -ho installato in mangment studio

    Stavo pensando di muovermi cos':

    -backup database

    -unmount database

    -delete unmount database e relativo ldf

    -restore database dal fil .bak

    Cosa ne pensate?  Idee più semplici? meno "rischiose"

    COme sempre grazie a tutti per l'help

    mercoledì 30 maggio 2012 06:39
    |

Risposte

  • Question
    Registrati per votare
    0
    Registrati per votare

    Ciao

    qui dovresti trovare tutte le info per procedere allo shrink del T-Log.

    Ciao

    Luca

    Luca Ferrari http://tipsandtrickssqlserver.blogspot.com/

    mercoledì 30 maggio 2012 07:48
    |
  • Question
    Registrati per votare
    0
    Registrati per votare

    In aggiunta a quanto indicato da Luca, permettimi un paio di considerazioni:

    1) il restore fisicamente rialloca lo stesso spazio dei files presenti al momento del backup (che legge dal file .BAK) e copia il contenuto del file di backup "sopra" i nuovi files, per cui non ti cambierebbe assolutamente nulla rispetto alla situazione attuale! Avresti comunque il transaction log a 140GB...

    2) tu dici che "purtroppo" hai dimenticato il recovery model a full... Beh, dipende dalla tua strategia di backup e dal tempo massimo che la tua azienda può o vuole perdere in caso di disastro: con il recovery model SIMPLE puoi solamente fare backup di tipo full o differenziale (immagino che ora li facciate almeno una volta al giorno...) e quindi rischi di perdere tutti i dati dall'ultimo backup, mentre con il recovery model FULL puoi aggiungere al normale backup giornaliero anche una serie di backup del log più "fitti" e in caso di crash riuscire a ripristinare tutto o quasi il lavoro fatto! Nel tuo caso l'importante è che poi venga schedulato anche il backup del log, che è il responsabile anche della riduzione delle dimensioni del file di log.

    HTH

    Danilo Dominici MCP MCDBA MCITP MCSE MCAD Questo post è fornito "così com'è". Non conferisce garanzie o diritti di alcun tipo. Ricorda di usare la funzione "segna come risposta" per i post che ti hanno aiutato a risolvere il problema e "deseleziona come risposta" quando le risposte segnate non sono effettivamente utili. Questo è particolarmente utile per altri utenti che leggono il thread, alla ricerca di soluzioni a problemi similari. ENG: This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer" if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    mercoledì 30 maggio 2012 08:09
    |

Tutte le risposte

  • Question
    Registrati per votare
    0
    Registrati per votare

    Ciao

    qui dovresti trovare tutte le info per procedere allo shrink del T-Log.

    Ciao

    Luca

    Luca Ferrari http://tipsandtrickssqlserver.blogspot.com/

    mercoledì 30 maggio 2012 07:48
    |
  • Question
    Registrati per votare
    0
    Registrati per votare

    In aggiunta a quanto indicato da Luca, permettimi un paio di considerazioni:

    1) il restore fisicamente rialloca lo stesso spazio dei files presenti al momento del backup (che legge dal file .BAK) e copia il contenuto del file di backup "sopra" i nuovi files, per cui non ti cambierebbe assolutamente nulla rispetto alla situazione attuale! Avresti comunque il transaction log a 140GB...

    2) tu dici che "purtroppo" hai dimenticato il recovery model a full... Beh, dipende dalla tua strategia di backup e dal tempo massimo che la tua azienda può o vuole perdere in caso di disastro: con il recovery model SIMPLE puoi solamente fare backup di tipo full o differenziale (immagino che ora li facciate almeno una volta al giorno...) e quindi rischi di perdere tutti i dati dall'ultimo backup, mentre con il recovery model FULL puoi aggiungere al normale backup giornaliero anche una serie di backup del log più "fitti" e in caso di crash riuscire a ripristinare tutto o quasi il lavoro fatto! Nel tuo caso l'importante è che poi venga schedulato anche il backup del log, che è il responsabile anche della riduzione delle dimensioni del file di log.

    HTH

    Danilo Dominici MCP MCDBA MCITP MCSE MCAD Questo post è fornito "così com'è". Non conferisce garanzie o diritti di alcun tipo. Ricorda di usare la funzione "segna come risposta" per i post che ti hanno aiutato a risolvere il problema e "deseleziona come risposta" quando le risposte segnate non sono effettivamente utili. Questo è particolarmente utile per altri utenti che leggono il thread, alla ricerca di soluzioni a problemi similari. ENG: This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer" if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    mercoledì 30 maggio 2012 08:09
    |
  • Question
    Registrati per votare
    0
    Registrati per votare

    Grazie a tutti

    Ho settato true in auto shrink.

    Potete scrivermi un esempio di comando per eseguire lo shrink dei log?

    Grazie ancora

    mercoledì 30 maggio 2012 08:37
    |
  • Question
    Registrati per votare
    0
    Registrati per votare

    Hai messo a true la proprietà autoshrink del DB ?

    Questa proprietà consente a SQL Server di rilasciare al SO lo spazio libero in coda ai file dati, ma se il file dati è cresciuto un motivo ci sarà.Tieni presente inoltre che in questo modo, potenzialmente, costringi SQL Server ad effettuare un numero maggiore di operazioni di grow sui file dati, con ripercussioni molto pesanti in termini di performance e di risorse e causando pesantissima frammentazione di data pages e del file stesso.

    In altre parole ti sconsiglio di abilitare l'autoshrink.

    Per quanto riguarda il t-log

    Use AdventureWorks2012
    Go
    Dbcc shrinkfile(AdventureWorks2012_Log,Dimensione da raggiungere in MB) 
    GO 

    Prima di implementare lo shrink del t-log ti consiglio la lettura di questo post che spiega come il grow del t-Log va ad impattare sulle performance del DB.

    Ciao

    Luca Ferrari http://tipsandtrickssqlserver.blogspot.com/



    mercoledì 30 maggio 2012 09:19
    |
  • Question
    Registrati per votare
    0
    Registrati per votare

    Ciao

    Use AdventureWorks2012
    Go
    Dbcc shrinkfile(AdventureWorks2012_Log,Dimensione da raggiungere in MB) 
    GO

    Questo comando immagino posso eseguirlo anche con il managment studio

    mi posiziono sul db seleziono shrink del file.Quanto posso mettere in dimensione da raggiungere? 10GB?

    Grazie ancora

    mercoledì 30 maggio 2012 12:45
    |
  • Question
    Registrati per votare
    0
    Registrati per votare

    Si, lo puoi eseguire da Management Studio, sostituisci ad AdventureWorks2012 il nome del tuo database e a AdventureWorks2012_Log il nome logico del tuo file T-Log.

    Per la dimensione dipende da quante transazione sono applicate e da quanto grandi sono. Dovresti ipotizzare una dimensione in grado di contenere le transazioni senza costringere SQL ad effettuare Grow sul file.

    Ciao

    Luca 

    Luca Ferrari http://tipsandtrickssqlserver.blogspot.com/

    mercoledì 30 maggio 2012 12:57
    |