What realistic issues can occur from shrinking the log files on my database (either through the SSMS UI or issuing a DBCC ShrinkFile command)?

Question

I've heard talk of potential corruption or data loss occurring from shrinking the database data or log files. I'm curious in particular about only shrinking just the log files, what are some real examples of issues that can pop up as a result of doing so?

Looks like the Tags are even against me on this one:

Answer 1

As far as the SQL Server product is concerned, the SHRINKFILE operation is safe. It is designed to respect locks, recovery models, transaction log usage, etc. In the absence of a bug in the SQL Server code, shrinking a database file won't cause corruption of data loss.

All code has bugs, so there is a chance that a routine operation like shrinking a data or log file could cause corruption. But this is true of anything. There was a bug in SQL Server 2012 and 2014 that caused corruption when rebuilding certain indexes. This mean doesn't that index rebuilds are unsafe.

All of the issues you'd run into when shrinking a data or log file are related to performance and maintainability (causing index fragmentation, having to wait on autogrowth events as the data size increases the file size again, etc).

Answer 2

If you're making regular backups of the log file or are running in SIMPLE recovery mode, the log file should mostly consist of free space; shrinking it will just truncate the free space from the log file. This is usually safe to do, but you need to realize that the log file will likely just grow back to the previous size....when this happens the log will auto-grow, which can cause a performance hit every time it happens.

The only real reason for shrinking it is if you're low on disk space, if the log is filling up the drive you should consider adding additional disk space as a long term solution.