HowardW (11/13/2012)
Assuming that the growth to 36GB was an unusual activity or was caused when it was in FULL Recovery Model and TLog backups weren't being run, then yes, a one off shrink is probably prudent.
Your second guess is right.
The database has been in FULL recovery model with no T-Log backups ever taken. I've changed to SIMPLE (no need for Point In Time disaster recovery) but then I realised that the backups of all databases on this SQL Server instance take a very long time so I thought I check the transaction log size to see if that's affecting backup size. That's when I noticed the 36GB log file.
I know how to shrink the log via SSMS but I'm not sure how to specify the size of the LDF file.
Also, can I just confirm that by shrinking the log file from 26GB to 1GB for example, my backup will also reduce by the same size?
---------------------------------------------------------
It takes a minimal capacity for rational thought to see that the corporate 'free press' is a structurally irrational and biased, and extremely violent, system of elite propaganda.
David Edwards - Media lens[/url]
Society has varying and conflicting interests; what is called objectivity is the disguise of one of these interests - that of neutrality. But neutrality is a fiction in an unneutral world. There are victims, there are executioners, and there are bystanders... and the 'objectivity' of the bystander calls for inaction while other heads fall.
Howard Zinn