none
Transaction log DB SQL 2008 RRS feed

  • Domanda

  • Ho un database sql 2008 sul quale viene effettuato un backup full tutti i giorni. Il problema è che non è mai stato fatto il backup del transaction log, che è diventato ormai 18gb!!

    Ho cercato un po’ su google, consigliano di fare sempre il backup del trans. Log perché ne limita automaticamente la dimensione. La dimensione che ha già raggiunto, però, rimane…va fatto lo shrink manualmente.

    Che voi sappiate, quali sono gli svantaggi di tale operazione? Ho trovato questa procedura (vedi sotto), l’ho provata in test e funziona: mi ha ridotto da 4gb a 100mb (da me impostata nel target size). Cosa comporta questa riduzione però? Mi aumenta i tempi di un eventuale restore?

    ALTER DATABASE <database> SET RECOVERY SIMPLE

    DBCC SHRINKFILE ('<log file logical name'>, <target_size_in_mb>)

    Grazie

     

    martedì 31 maggio 2011 10:25

Risposte

  • Ciao OttobreRosso,

    la procedura da te indicata imposta il recovery model del database a SIMPLE. Questo significa che ad ogni checkpoint SQL Server svuoterà il transaction log dopo aver scritto le informazioni nel file dati. In generale non è una procedura scorretta e mantiene il transaction log entro dimensioni accettabili, ma devi essere consapevole di poter perdere TUTTI i dati modificati a partire dall'ultimo backup del database !!!!

    In generale è preferibile mantenere il recovery model a FULL e fare il backup completo del database con cadenza ad esempio giornaliera unitamente al backup del transaction log con cadenza infragiornaliera (ad esempio ogni ora). In questo modo in caso di crash hai tutti i dati dall'ultimo backup completo e, se leggibile, tutte le modifiche intervenute dall'ultimo backup del log al momento del crash all'interno della "coda" del log, che può ancora essere estratta. In questo modo se va tutto liscio puoi ripristinare tutti i dati fino ad un attimo prima del crash.

    Riguardo alla dimensione del log, assicurati che sia sufficientemente ampia da mantenere le transazioni che abitualmente vengono eseguite sul database. La dimensione di 100Mb che indichi tu potrebbe essere troppo piccola e generare frammentazione sul disco dovuta all'auto-crescita del log.

    Ridurre la dimensione del transaction log non comporta l'aumento dei tempi di un restore. Al contrario, visto che il restore ripristina esattamente i files così come sono stati fotografati dal backup, un file di log di dimensioni maggiori ci metterà più tempo ad essere restorato (SQL Server durante il restore prima alloca lo spazio sul disco e poi ci copia le pagine del log, quindi dimensioni maggiori = più tempo).

    Ti segnalo alcuni links dove trovare informazioni specifiche sul transaction log:

    Understanding Logging and Recovery in SQL Server
    Monitoring SQL Server transaction log size
    Shrinking the transaction log
    Recover from a full transaction log
    Paul Randal's SQL Server DBA myths a day
    Paul Randal's Transaction Log posts

    Ciao!
    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.
    martedì 31 maggio 2011 15:20