Non ho ben capito se a seguito del backup del t-log (eseguito in recovery mode FULL), la dimensione del file LDF debba diminuire oppure se venga "solo" eseguita una truncate della porzione inattiva dei virtual log inattivi, ma lasciando la dimensione del file inalterata.
Il backup del t-log svuota il contenitore, ma non lo riduce.
Le cause potrebbero essere le seguenti?:
- ci sono ancora delle transazioni aperte e quindi il backup del log delle transazioni non fa la truncate
- la porzione attiva del virtual log è alla fine del t-log e quindi il file non si riduce di dimensioni
La prima è possibile, ma per le dimensioni dei tlog che hai indicato (8 GB e 70 GB) vorrebbe dire che queste transazioni sono rimaste aperte da giorni o da settimane. Più verosimile pensare che sono state fatte in precedenza delle operazioni straordinarie (es: caricamenti massivi) che hanno richiesto simili quantità di tlog o, più probabilmente, che in passato il tlog era lasciato abbandonato (ovvero recovery model diverso da simple e nessun backup del tlog per qualche mese).
Se schedulassi due backup del t-log al giorno riuscirei a tenere l' LDF sotto controllo?
I backup del t-log puoi farli anche ogni 5 minuti, ma l'obiettivo non è tenere il tlog "sotto controllo". La frequenza di backup ti permette di tenere sotto controllo la massima perdita di dati che ti puoi permettere. Nella situazione attuale la perdita di dati che quei database possono sopportare è pari a mezza giornata. Se per te (e soprattutto per l'azienda) va bene così puoi lasciare le cose come sono. In caso contrario introduci altri backup differenziali e/o del tlog per assecondare le esigenze dell'azienda. Ammesso che la perdita di dati ammissibile sia in linea con le esigenze dell'azienda semplificherei la gestione di quei db sostituendo il backup del t-log con un backup differenziale dopo aver impostato il recovery model a simple. Mantieni inalterata la copertura ma semplifichi l'amministrazione dei db.
Per far ritornare gli attuali t-log a dimensioni ragionevoli devo perforza fare uno SHRINK con conseguente frammentazione del virtual log?
Non ci sarà nessuna frammentazione e anche se vi fosse sarebbe il male minore. A causare la frammentazione (a livello di file system e non comunque di virtual log) sono le attività di crescita e non quelle di shrink. Se dopo che hai ricondotto il tuo tlog a dimensioni umane poi ritorna a crescere li può infiltrarsi la frammentazione del file (la nuova porzione potrebbe essere in un settore del disco non adiacente a quella già allocata) e questo significherebbe che quel t-log va gestito in maniera differente a meno che ciò non sia dovuto ad attività straordinarie e come tali da gestire in maniera altrettanto straordinaria.
Bye