We have a SQL Server 2014 system that is apparently shrinking one or more log files automatically. We are getting a low free disk space alert (triggered at <5% free) at 1:00 AM, but when we check the system in the morning there is about 50% free. We manage about 160 SQL Servers between the various environments and they're all set up with a good degree of standardization. Auto shrink is NOT enabled. I have found what was causing all of the database writes to cause the log files to grow, and that has been addressed, so the cause of the log file growth is not the subject of this question.
I found this SQL Server 7 era post, Transaction log shrinking mysteriously, which states that transaction logs will be shrunk automatically if UserShrinkFile
is set to anything other than -1. This seems so explain what we've noticed, but with a bit of a wrinkle. There is no UserShrinkFile
property in the header, but there is a UserShrinkSize
property, and on three of the databases it is set to a positive integer.
Oddly, I cannot find anything salient about UserShrinkSize
. Anywhere. The only place I've found reference to it is posts that just list it along with everything else in the header. I assume it is the newer version of UserShrinkFile
, and that it works that same way as stated in the linked article above. However, getting some confirmation of these assumptions would be fantastic, and this would be a lovely addition to utilities that check for configuration items that might cause unwanted behavior.
It would be good to know how this property affects the system, as it obviously doesn't just shrink the log files immediately all the time. Right now all three of the databases that have a positive UserShrinkSize
value have log files ranging from 40 – 200 GB with 99% free space, so it's leaving me wondering whether it only shrinks them when it can't grow the log file.
Best Answer
I couldn't add a comment so I will try to comment here:
There are 2 ways how SQL Server clear the t-log:
the only time the t-log will shrink if you issue SHRINKFILE. Maybe you are confused about log shrinking and log clearing?..
Update:
I was able to reproduce the positive value on UserShrinkSize column. The value on UserShrinkSize is the number of (8kb) pages needed to be shrink. -1 means default (none). So when you see a positive value, that means it tries to shrink the log but it can't because there's active transaction going on.
Tested on SQL Server 2016:
Build your table:
open a new query window and execute the insert:
While the insert window is executing, open another window for shrink and execute it at the same time:
Now, you can check the UserShrinkSize:
as you can see below, the value is now positive. 65024 pages needed to be shrink.
you will see the change in value when you issue the SHRINKFILE and the t-log can't be shrink due to active transaction.
you can also check the changes using the fn_dblog function:
There is no magic about the UserShrinkSize, the value have changed because we issued/attempted DBCC SHRINKFILE during active transaction. Before shrinking the log, make sure to check the log_reuse_wait_desc and see what's holding the t-log. Investigate on why the t-log did not clear and why t-log expanded unexpectedly.
We should not worry about the UserShrinkSize value rather we should focus on how to properly manage the t-log. properly size the log, check long running transaction that cause log to grow, etc. If we take care of t-log the value will always be -1. :)
To bring back the value to -1, from my example I need to rollback the inserts. Then issue a SHRINKFILE on t-log (pre-size it to an appropriate size) and the log_reuse_wait_desc is now showing as NOTHING.
HTH