Recovery Model e controllo dimensioni Transaction Log

mercoledì 24 marzo 2010 - 15.53

Elenco Threads

Stanze Forum

Aggiungi ai Preferiti

Cerca nel forum

homozave Profilo | Newbie

3 messaggi | Data Invio: mer 24 mar 2010 - 15:53

Ciao a tutti, sono nuovo del forum e mi complimento per gli articoli e i thread interessanti che ho trovato.
Vorrei sottoporvi un problema, relativo al recovery model utilizzato e alle dimensioni dei T. log in sql server 2005.

Lo scenario è questo:
Sql server 2005 v 9.0.x installato su W2K3 standard.
15 Database gestiti e configurati con recovery model "simple"
Ogni Db ha il suo Transaction Log come file .mdf
Il piano di backup, è un maintenance plan che backuppa tutti i db (compresi i system db) presenti in modalità "full" su tape schedulato ogni notte.
Non ci sono altri piani di manutenzione schedulati (quindi niente shrink, rebuild, etc)

La domanda è questa:
Considerato che i file di log sono spesso sproporzionati come dimensioni rispetto ai DB (es. DB da 2GB, log 14GB)
Considerato che comunque i file di log non vengono backuppati.
Considerato che ogni notte viene fatto il backup dei database.
Come impostare al meglio un piano di backup, che:
1. faccia il backup dei db ogni giorno
2. faccia il backup dei log.
3. elimini o limiti i file di log mantenendo uno storico di circa 1 giorno, limitando quindi lo spazio occupato dagli stessi
4. Ottimizzi periodicamente i DB e lo spazio da essi occupato.

Grazie anticipatamente per le risposte. Cris.

lbenaglia Profilo | Guru

5.625 messaggi | Data Invio: mer 24 mar 2010 - 17:04

>Lo scenario è questo:
>Sql server 2005 v 9.0.x installato su W2K3 standard.
>15 Database gestiti e configurati con recovery model "simple"
>Ogni Db ha il suo Transaction Log come file .mdf
.ldf

>Il piano di backup, è un maintenance plan che backuppa tutti
>i db (compresi i system db) presenti in modalità "full" su tape
>schedulato ogni notte.
>Non ci sono altri piani di manutenzione schedulati (quindi niente
>shrink, rebuild, etc)
>
>La domanda è questa:
>Considerato che i file di log sono spesso sproporzionati come
>dimensioni rispetto ai DB (es. DB da 2GB, log 14GB)
>Considerato che comunque i file di log non vengono backuppati.
>Considerato che ogni notte viene fatto il backup dei database.
>Come impostare al meglio un piano di backup, che:
>1. faccia il backup dei db ogni giorno
>2. faccia il backup dei log.
Se i db sono configurati con il Recovery Model a Simple non puoi eseguire il backup dei t-log.

>3. elimini o limiti i file di log mantenendo uno storico di circa
>1 giorno, limitando quindi lo spazio occupato dagli stessi
Non ti seguo.

>4. Ottimizzi periodicamente i DB e lo spazio da essi occupato.
- Aggiornamento statistiche
- Ricostruzione o deframmentazione indici

Lo shrink dei data file o del t-log sono sempre sconsigliati in quanto all'estensione successiva si viene a generare una frammentazione a livello di file system.

>Grazie anticipatamente per le risposte. Cris.
Prego.

Ciao!
--
Lorenzo Benaglia
Microsoft MVP - SQL Server
http://blogs.dotnethell.it/lorenzo/
http://italy.mvps.org

homozave Profilo | Newbie

3 messaggi | Data Invio: gio 25 mar 2010 - 09:18

>>Lo scenario è questo:
>>Sql server 2005 v 9.0.x installato su W2K3 standard.
>>15 Database gestiti e configurati con recovery model "simple"
>>Ogni Db ha il suo Transaction Log come file .mdf
>.ldf

Si giusto, errore di digitazione o distrazione...

>>Il piano di backup, è un maintenance plan che backuppa tutti
>>i db (compresi i system db) presenti in modalità "full" su tape
>>schedulato ogni notte.
>>Non ci sono altri piani di manutenzione schedulati (quindi niente
>>shrink, rebuild, etc)
>>
>>La domanda è questa:
>>Considerato che i file di log sono spesso sproporzionati come
>>dimensioni rispetto ai DB (es. DB da 2GB, log 14GB)
>>Considerato che comunque i file di log non vengono backuppati.
>>Considerato che ogni notte viene fatto il backup dei database.
>>Come impostare al meglio un piano di backup, che:
>>1. faccia il backup dei db ogni giorno
>>2. faccia il backup dei log.
>Se i db sono configurati con il Recovery Model a Simple non puoi
>eseguire il backup dei t-log.
>
>>3. elimini o limiti i file di log mantenendo uno storico di circa
>>1 giorno, limitando quindi lo spazio occupato dagli stessi
>Non ti seguo.

I T.Log registrano le transazioni prima di scriverle nel db giusto? (spero)
Considerando che utilizzo il recovery model semplice, non me ne faccio comunque niente in caso di crash
Pertanto vorrei limitarne lo spazio occupato. Potrei configurarne la dimensione massima nella Scheda "Files" invece di farlo crescere a dismisura? creerebbe problemi?

>>4. Ottimizzi periodicamente i DB e lo spazio da essi occupato.
>- Aggiornamento statistiche
>- Ricostruzione o deframmentazione indici
Ok.Cosa è meglio? un rebuild o il reorganize? queste operazioni mi permettono di ridurre i Log? dovrei impostare una percentuale di "free space" o meglio lasciare che riporti le dimensioni a default?

>Lo shrink dei data file o del t-log sono sempre sconsigliati
>in quanto all'estensione successiva si viene a generare una frammentazione
>a livello di file system.
Ok
>>Grazie anticipatamente per le risposte. Cris.
>Prego.
Ri-Grazie.
>Ciao!
>--
>Lorenzo Benaglia
>Microsoft MVP - SQL Server
>http://blogs.dotnethell.it/lorenzo/
>http://italy.mvps.org

lbenaglia Profilo | Guru

5.625 messaggi | Data Invio: gio 25 mar 2010 - 11:55

>I T.Log registrano le transazioni prima di scriverle nel db giusto?
>(spero)
>Considerando che utilizzo il recovery model semplice, non me
>ne faccio comunque niente in caso di crash
>Pertanto vorrei limitarne lo spazio occupato. Potrei configurarne
>la dimensione massima nella Scheda "Files" invece di farlo crescere
>a dismisura? creerebbe problemi?
Inizia a leggere con attenzione questo paragrafo dei Books Online:
http://msdn.microsoft.com/en-us/library/ms345583.aspx

>Ok.Cosa è meglio? un rebuild o il reorganize?
Dipende dallo stato in cui si trova l'indice.
la rebuild è una operazione più onerosa in quanto comporta l'intera ricostruzione, mentre la reorganize si limita a riorganizzare il leaf level:
http://technet.microsoft.com/en-us/library/ms189858.aspx

>queste operazioni mi permettono di ridurre i Log?
No, anzi, la manutenzione degli indici è una operazione loggata quindi occupa spazio nel t-log.

>dovrei impostare una percentuale di "free space" o meglio lasciare che riporti le dimensioni a
>default?
Se un file (data o t-log) occupa x spazio, significa che ha bisogno di quello spazio, quindi ha poco senso rimpicciolirlo se dopo mezz'ora si ingrandisce nuovamente (generando frammentazione fisica).
In caso di operazioni straordinarie che comportano una crescita anomala del t-log, ha senso riportarlo alla dimensione x dato che difficilmente verrà esteso nuovamente.

Ciao!
--
Lorenzo Benaglia
Microsoft MVP - SQL Server
http://blogs.dotnethell.it/lorenzo/
http://italy.mvps.org

homozave Profilo | Newbie

3 messaggi | Data Invio: gio 25 mar 2010 - 15:18

Grazie per le risposte molto esaurienti.
Dopo aver letto la documentazione ho eseguito un ridimensionamento manuale dei log, in quanto non era mai stato fatto e i DB arrivano da importazioni in access. Ora i log sono sensibilmente ridotti in dimensione (che era 10 volte il db), monitorerò la situazione per capire se "ricrescono" in modo sproporzionato o meno.
Grazie.

Torna su

Stanze Forum

Elenco Threads

Partecipa anche tu! Registrati!

Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !