Se il t-log è arrivato a quelle dimensioni significa che ci sono gravi carenze amministrative, ovvero che

1) Il recovery model del database è diverso da SIMPLE
2) Il backup del t-log non viene fatto da parecchio tempo (verosimilmente da mesi/anni o non è mai stato fatto)

Attenzione che ENTRAMBE le condizioni di cui sopra sono vere perchè una soltanto non sarebbe in grado di produrre quanto indichi.
Per porre rimedio a questa situazione devi seguire una delle 2 indicazioni di cui sopra, ovvero impostare il recovery model a simple OPPURE definire una strategia di backup del transaction log.
Viste le dimensioni del t-log se esegui un backup del t-log, lo stesso andrà avanti per ore e allora ti suggerisco, nell'immediato, di switchare il recovery model a SIMPLE e poi eseguire il comando DBCC SHRINKFILE (di cui trovi ampia documentazione sul BOL) per riportare il t-log a dimensioni ragionevoli (viste le dimensioni del db poche decine di MB sono sufficienti).
Potrebbe verificarsi il caso in cui il DBCC SHRINKFILE non riduce immediatamente il t-log alle dimensioni indicate, ma lo fa solo parzialmente (questo si verifica quando la porzione attiva non è all'inizio del file). In questo caso dovrai rieseguirlo a distanza di qualche ora fino a che non arrivi alle dimensioni volute.
Una volta fatto il tutto puoi decidere se mantenere il recovery model a simple OPPURE impostarlo a FULL o BULK-LOGGED e definire una politica di backup del t-log.
Per rispondere alla tua ultima domanda (alle altre credo di aver risposto)... un backup di tipo differenziale non ti aiuta in nessun modo.

Bye

---

Modificato da l.bianchi il 26 aprile 2010 16.01 -

carmine81 ha scritto:

DBCC SHRINKFILE (NomeFile_Log, 1);
GO

va bene specificare 1 MB??? può creare problemi??? meglio non specificarlo eseguendo solo DBCC SHRINKFILE (NomeFile_Log) ???

Farei almeno 10-20 MB

poi quando so per certo che nessun utente farà accesso al database, farò il backup del t-log con questo comando:

I backup di SQL Server puoi farli quando ti pare. I backup full sono abbastanza invasivi (ma non per database di poche centinaia di MB) ed è preferibile schedularli nei momenti di minor traffico. I backup del t-log si introducono per ridurre la finestra di potenziale perdita di dati in caso di problemi minimizzando, al tempo stesso, l'invasività nei confronti delle attività utente e in taluni ambienti il backup del t-log viene fatto anche con frequenze di 5 minuti

è ok specificare "NO_LOG" oppure meglio "TRUNCATE_ONLY"...o altro...???

Hanno 2 scopi differenti. Il primo non esiste più in SQL Server 2008; il secondo è un "non backup". Se vuoi utilizzare l'opzione TRUNCATE_ONLY significa che non ti interessa avere la protezione offerta dai backup del t-log e allora tanto vale impostare il recovery model a SIMPLE, dimenticarsi della gestione del t-log e basare la tua strategia di disaster recovery esclusivamente sui backup full viste anche le dimensioni del db (con database di 100 MB il backup full dura una manciata di secondi). Se il db fosse più grande potresti pensare di introdurre 1 o 2 differenziali tra 2 backup completi, ma viste le dimensioni attuali...

questo comando, se mi confermi che va bene, lo vorrei schedulare per farlo eseguire una volta ogni settimana, che ne pensi ???

Al di la del fatto che non va bene così come l'hai pensato, il t-log in genere viene schedulato con frequenze più elevate rispetto ai full e ai differenziali.

il recovery model lo imposto a simple solo per lo DBCC SHRINKFILE oppure lo lascio sempre così anche con il backup del t-log impostato ???

Recovery model SIMPLE e backup del t-log sono incompatibili tra loro.

ciao e grazie ancora.

Bye