Extended Event To Track Data And Log File Size Changes

One of the things that a DBA tries to avoid/prevent are automatic file growths in data and log files. We generally like to plan for these things and size the data and log files ourselves to prevent SQL Server from having to do it on its own.  But sometimes you can’t help it.  Sometimes tempdb grows unexpectedly overnight, or someone does a large data import into a user database.

This can be frustrating, especially when you don’t know what T-SQL statement caused the file growth, or what user ran the script.  For that reason, I have the following Extended Event running on all of my SQL Servers.

The event itself is pretty light weight, it uses the database_file_size_change event to track size changes of the  data and log files and records what caused those changes, including the user and T-SQL script used.

However, if we take a look at the database_file_size_change event that we are using, we will find that it doesn’t just apply to file growth.  Here is the description of the database_file_size_change event taken from the Extended Event wizard:

Occurs when any of the data or log files for a database changes size. Use this event to monitor changes to the size of database files.

It tracks any changes in size to the data and log files.  This means that the the above Extended Event session will also track any SHRINKFILE operations on a database’s data and log files.  This can come in handy if you have a rouge developer who likes to shrink log files when he things no one is looking. (Yeah, I had someone do that once.)

Even though I don’t use Extended Events as much as I probably should, in cases like this I’m glad they are around and certainly see the benefit in using them.

 

(Visited 4,271 times, 1 visits today)