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

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

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

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