SQL Server Log File - Why it increases in size when the database is not in use?

Question

We have an ERP application that uses a SQL server database. Although the application is not in use currently, its log file increases constantly and is currently at 28GB. I took a full backup couple of weeks back to truncate the log file when it was 85GB and now it is back to 28GB. I've setup the log file size to be 20GB with 100MB increment and unrestricted growth.

Why the log file size is increasing when the application is not in use, how can I see the transactions that are causing it to increase and how can I manage it better? Does setting up a server trace is useful in this case?

Answer 1

Check the output of sys.dm_exec_requests and sys.dm_exec_sessions to find out what queries are running and what/who's connected to your database.

If that doesn't help you, then you could certainly set up a server trace or an extended events session - if you really think no one is connecting and querying, you could verify that using something like this:

IF EXISTS (SELECT * FROM sys.server_event_sessions WHERE name = 'EE_Queries')
DROP EVENT SESSION EE_Queries ON SERVER;
GO

CREATE EVENT SESSION EE_Queries ON SERVER
ADD EVENT sqlserver.sql_statement_completed
(ACTION (sqlserver.sql_text,sqlserver.client_app_name,sqlserver.client_hostname,sqlserver.nt_username, sqlserver.username)
WHERE sqlserver.database_id = /* fill in your DB_ID() here */)
ADD TARGET package0.asynchronous_file_target
(SET FILENAME = N'C:\logs\EE_Queries.xel', METADATAFILE = N'C:\logs\EE_Queries.xem')
WITH (max_dispatch_latency = 1 seconds);
GO


ALTER EVENT SESSION EE_Queries ON SERVER STATE = START;

which would log all queries going on against your database - just replace the comment portion with the DB_ID() of the database you want to track. That will start an extended events session that tracks all queries, including the text of the query, the app name, the host name, and the username (NT and/or SQL user name) of the user that's running the query. That should clue you in pretty quickly. Just be careful with that events session in a production environment on a busy database - it will likely degrade performance and may fill up the disk quickly if you have lots of queries . Output of that extended event locally: