43 messaggi dal 20 gennaio 2010
Vi è capitato di vedere lievitare il file di log di un DB di SQL-Server fino ad arrivare a 2 tera-byte in poco tempo mentre su Sql Server 2008 lievita normalmente (su un DB i 5 GB di dati)?
1.976 messaggi dal 27 luglio 2005
Contributi
salve,
tera??? no
ti consiglierei di troncare

verifica la tua politica di backup del transaction log, e magari vedi di "ricordare" se hai eseguito attivita' particolari su quel db...
saluti

Andrea Montanari
http://www.hotelsole.com - http://www.hotelsole.com/asql/index.php
43 messaggi dal 20 gennaio 2010
grazie (infinite) per la risposta.
avrei bisogno di qualche indicazione.

con SQL Server 2008, il file dei log arriva a superare la dimensione del file data dopo diverso tempo.
stiamo migrando di server e sia con SQL Server 2012 sia 2014 abbiamo riscontrato che il file arriva a pesare qualche GB in un solo giorno.

io di solito eseguo manualmente il backup dati + 2 backup log e infine eseguo lo Shrink del file log e riesco ad azzerarlo. ma è una operazione fatta manualmente.

cosa mi conviene fare per avere sotto controllo il file di log? esiste una modalità per avere uno shrink automatico? (autoshrink impostato a true pare non funzioni)

grazie ancora
Simone
1.976 messaggi dal 27 luglio 2005
Contributi
salve Simone,
la dimensione del t-log ovviamente dipende dalle attivita' eseguite sulla base dati... avendo (ovviamente) un full recovery mode, tutte le attivita' vengono registrate e restano nel t-log al fine di consentire un corretto ripristino nel caso di corruzione o necessita'... al fine di non avere code di dimensioni esagerate, e' necessario instaurare una corretta politica di backup che preveda, tipecamente nel suo insieme, un backup completo iniziale, quindi successivi t-log backup.. in questa ottica si possono inserire anche dei differential backup per limitare la coda dei t-log backup da dover applicare per ripristinare il tutto...
temporalmente, ad esempio
t0 t1 t2 t3 t4 t5
fullbackup -> tlog-backup -> tlog-backup -> differential-backup -> tlog-backup -> tlog-backup ->goto fullbackup

questo perche', ad esempio, dovesse succedere un problema tra t2 e t3, per tornare "attivi" sara' necessario effettuare il ripristino del fullbackup, quindi aggiungere sequenzialmente i ripristini di tutti i tlog backup (partendo da t1 fino a tN) ed infine la coda finale del tlog... al fine di non avere code lunghissime, di tanto in tanto (t3) si puo' eseguire un differential backup.. nel caso di problemi dopo t5, nell'esempio, si eseguira' il ripristino del fullbackup iniziale + ripristino del differential eseguito al t3 + la coda dei tlog di t4 e t5 ed infine la coda finale del tlog
in questo caso, ovviamente i backup tlog di t1 e t2 non saranno piu' necessari...

una "inquadratura generale" si puo' vedere anche in https://msdn.microsoft.com/it-it/library/ms187048.aspx , ed ovviamente queste sono attivita' che e' consigliabile schedulare utilizzando piani di manutenzione...

come vedi in https://msdn.microsoft.com/it-it/library/ms186865.aspx, Argomenti: LOG: ".. Dopo un tipico backup del log, alcuni record del log delle transazioni diventano inattivi, a meno che non si specifichi WITH NO_TRUNCATE o COPY_ONLY. Il log viene troncato dopo che tutti i record in uno o più file di log virtuali diventano inattivi. ..." cio' non significa che il t-log venga troncato, ma che lo spazio dei virtual log interni oramai inattivi risulti disponibile per altri virtual log, quindi evitando la crescita continua del file stesso...

nel caso di "disastro" come nel tuo caso di 5tera di log, personalmente consiglierei di modificare il recovery mode a simple, cosi' che il t-log venga a tutti gli effetti "invalidato", procedere allo shrink del tlog a dimensioni accettabili, quindi riportare il recovery model a full e fare un bel backup completo :)

saluti

Andrea Montanari
http://www.hotelsole.com - http://www.hotelsole.com/asql/index.php
43 messaggi dal 20 gennaio 2010
grazie. in effetti mi mancava la soluzione in caso di disastro :)

seguirò i tuoi consigli usando la sequenza che indichi, ma immagino debba fare ad un certo punto lo shrink del file dei log...

e una cosa non mi è chiara. come mai mi ritrovo a fare sempre 2 backup dei log prima di risucire a shrinkare il DB log. se non eseguo il secondo backup non si azzera. è dovuto al recovery model?

in ogni caso non ho capito come mai c'è questa differenza di dimensioni dei log tra SQL server 2008 e le versioni 2012 e 2014. secondo te può essere qualche configurazione si MSSQL? il DB di fatto è lo stesso.
1.976 messaggi dal 27 luglio 2005
Contributi
salve,
per poter fisicamente effettuare uno shrink, bisogno vedere come sono posizionati i virtual log attivi al momento dell'operazione...
considera ad esemio, al momento dell'esecuzione, un t-log composto come di seguito: (la rappresentazione e' triviale e solo rappresentativa)
<-- virtual log attivo --><-- virtual log inattivo--><-- virtual log attivo -->
in questo caso, lo shrink non recupera niente visto che il virtual log inattivo e' posizionato tra 2 virtual log attivi
mentre invece
<-- virtual log attivo --><-- virtual log inattivo--><-- virtual log inattivo-->
puo' effettivamente troncare alla fine del virtual log attivo riducendo la dimensione del file...

saluti

Andrea Montanari
http://www.hotelsole.com - http://www.hotelsole.com/asql/index.php
43 messaggi dal 20 gennaio 2010
grazie,

direi che a livello teorico è chiaro.
e che a livello pratico serve un bello script da mettere in job(?) che esegua i vari backup, seguendo (magari) la tua sequenza
fullbackup -> tlog-backup -> tlog-backup -> differential-backup -> tlog-backup -> tlog-backup ->goto fullbackup

hai per caso qualche esempio di script da farmi vedere che vada oltre alle mie ricerche (premetto che sono sviluppatore e non DBA).

Io per il momento mi sono tirato giù i vari script singoli. Si trova qualcosa di integrato?

BACKUP DATABASE [nome_db]
TO DISK = 'path/file.bak'

BACKUP DATABASE [nome_db]
TO DISK = 'path/file.bak'
WITH differential

BACKUP LOG [nome_db]
TO DISK = 'path/file.bak'

DBCC SHRINKFILE ([nome_file_logico_log], 1)

ciao, grazie ancora
Simone
1.976 messaggi dal 27 luglio 2005
Contributi
salve Simone,
tecnicamente puoi fare anche in maniera piu' semplice
con SSMS (il Management Studio), navighi sino al nodo MAnagement->Maintenance Plans e definisci un piano... la prima volta puoi usare anche il wizard cosi' ti sara' piu' semplice... con "Separate schedules for each task",
selezioni i 3 tipi di backup...
- parti dal full backup, generi la schedulazione, ad esempio, weekly, sunday alle 00:00:00, che e' il backup settimanale default...
- poi il differential, daily ore 00:00:00
- poi il t-log, every 3 hours starting 12:00 ending 19:00
in questo modo hai un full settimanale, con il quale partirai per il ripristino iniziale...
ogni giorno hai 1 differential, dal quale partirai per avere il ripristino "a quel momento" saltando i differential e t-log precedenti...
ogni 3 ore a partire dalle 12 hai il t-log..
quindi la giornata inizia alle 9, niente log perche' non hai ancora fatto niente....alle 12 hai il primo t-log... alle 15 hai il secondo e cosi' via...
per ripristinare alle ore 16 di martedi, prima di tutto scarica la coda del log.... poi devi quindi ripristinare il full di domenica, aggiungere il differential di martedi + il log di martedi h 12 + log martedi h 15 + la coda finale che hai scaricato prima di iniziare...

oppure ti fai la tua schedulazione passo passo elemento per elemento...
saluti

Andrea Montanari
http://www.hotelsole.com - http://www.hotelsole.com/asql/index.php

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.