Impact on DB to shrink a 130GB log file?

Question

Here is my setup:
OS:  Windows Server 2008 R2 Enterprise
6 x Cores
8GB RAM
SQL:  Windows SQL 2008 setup in a 2 node cluster
I noticed that I have been having to add more disk space to one of the DBs that is running on this cluster.  After looking into this further I noticed that there is a 130GB log file for this database.  I have never attempted to shrink a log file
this size and do not know what kind of impact it may have to the running databases.  Can anyone comment on what I might expect?  Do I need to do this during a maintenance window?
Thank you
Rick

Answer 1

Rick,
this is a very comprehensive subject and you should brace yourself for a lot of complex information that is about to be posted here, but I'm going to try put this as simple as possible.
Since you are asking if you can shrink your log file, I'm going to assume you do not have a backup policy that involves them but you probably have your database recovery model set to full. The transaction log is needed to ensure transactional consistency
and may be backed up, under full/bulk-logged database recovery models, enabling you to restore them together with full/differental backups.
Yes you can shrink your log files, and for this to be effective I recommend you set your database to simple recovery model. There are a few main things you should be aware of:
1) The database engine will allocate log file space as needed for it to run transactions. If it runs out of the pre-allocated space, it will autogrow by an ammount previously specified if this option is enabled, but if its disabled or there is no more free
disk space available, transactions will fail. It is recommended that you set the autogrow increment to reasonable values so your log files doesn't get too fragmented (new VLFs are created every time the file grows). There is also a performance impact, generally
overrated by some analysts in my opinion but very real, of growing your file too often.
2) Under simple recovery model, parts of the log known as VLFs that have already been filled and aren't supporting active transactions anymore are reused so your log files will generally remain very small. In full recovery model, these parts are not reused
until you take a log backup, so the log file will keep growing (this is probably your case). You will need to switch your database to simple recovery model or take a log backup in order to successfully shrink the log file.
3) However, if your database is already on simple recovery model and the log grew to 130 GB, it was because the transactions really needed it to work, so I would recommend against shrinking your log file unless you know the transactions were part of an unusual
application process or appeared after an index maintenance operation.
4) Your backup/restore operations will run faster with a smaller log file.
5) You'll need less disk storage to restore your databases on secondary environments if you have smaller log files.
6) If the storage used for the log files are shared across multiple databases, instances, or other files, keeping your log files small ensures they have more free space to grow under abnormal circumstances without manual intervention, preventing service
disruption.
Just because there are clouds in the sky it doesn't mean it isn't blue. But someone will come and argue that in addition to clouds, birds, airplanes, pollution, sunsets, daltonism and nuclear bombs, all adding different colours to the sky, this
is an undocumented behavior and should not be relied upon.