SQL SERVER – How to Stop Growing Log File Too Big

http://blog.sqlauthority.com/

I was recently engaged in Performance Tuning Engagement in Singapore. The organization had a huge database and had more than a million transactions every hour. During the assignment, I noticed that they were truncating the transactions log. This really alarmed me so I informed them this should not be continued anymore because there’s really no need of truncating or shortening the database log. The reason why they were truncating the database log was that it was growing too big and they wanted to manage its large size. I provided two different solutions for them. Now let’s venture more on these solutions.

If you are jumping over this post to leave a comment, please read first the two options as follows:

1) Convert the Recovery Model to Simple Recovery

If you are truncating the transaction logs, this means you are breaking the T-Log LSN (Log Sequence Numbers). This follows that if disaster comes, you would not be able to restore your T-Logs and there would be no option for you to do point in time recovery. If you are fine with this situation and there is nothing to worry, I suggest that you change your recovery model to Simple Recovery Model. This way, you will not have extra ordinary growth of your log file.

2) Start Taking Transaction Log Backup

If your business does not support loss of data or requires having point in time recovery, you cannot afford anything less than Full Recovery Model. In Full Recovery Model, your transaction log will grow until you take a backup of it. You need to take the T-Log Backup at a regular interval. This way, your log would not grow beyond some limits. If you are taking an hourly T-Log backup, your T-Log would grow until one hour but after this the T-Log backup would truncate all the ‘committed’ transactions once you take it . Doing this would lead the size of the T-Log not to go down much, but it would rather be marked as empty for the next hour’s T-Log to populate.

With this method, you can restore your database at Point of Time if a disaster ever happens at your server.

Let us run an example to demonstrate this. In this case, I have done the following steps:

1. Create Sample Database in FULL RECOVERY Model
2. Take Full Backup (full backup is must for taking subsequent backup)
3. Repeat Following Operation
   1. Take Log Backup
   2. Insert Some rows
   3. Check the size of Log File
4. Clean Up

After a short while, you will notice that the Log file (ldf) will stop increasing but the size of the backup will increase.

If you have an issue with your log file growth, I suggest that you follow either of the above solutions instead of truncating it.

/* FULL Recovery and Log File Growth */
USE [master]
GO
-- Create Database SimpleTran
IF EXISTS ( SELECT name FROM sys.databases WHERE name = N'SimpleTran' )
BEGIN
ALTER DATABASE [SimpleTran] SET SINGLE_USER WITH ROLLBACK IMMEDIATE ;
DROP DATABASE [SimpleTran]
END
GO
CREATE DATABASE [SimpleTran]
GO
-- Set Database backup model to FULL
ALTER DATABASE [SimpleTran] SET RECOVERY FULL
GO
BACKUP DATABASE [SimpleTran] TO  DISK = N'D:/SimpleTran.bak' WITH NOFORMAT , NOINIT , NAME = N'SimpleTran-Full Database Backup' , SKIP , NOREWIND , NOUNLOAD , STATS = 10
GO
-- Check Database Log File Size
SELECT DB_NAME ( database_id ) AS DatabaseName ,
Name AS Logical_Name ,
Physical_Name , ( size * 8 )/ 1024 SizeMB
FROM sys.master_files
WHERE DB_NAME ( database_id ) = 'SimpleTran'
GO
-- Create Table in Database with Transaction
USE SimpleTran
GO
IF EXISTS ( SELECT * FROM sys.objects WHERE OBJECT_ID = OBJECT_ID ( N'[dbo].[RealTempTable]' ) AND TYPE IN ( N'U' ))
DROP TABLE [dbo].[RealTempTable]
GO
CREATE TABLE RealTempTable ( ID INT )
INSERT INTO RealTempTable ( ID )
SELECT TOP 50000 ROW_NUMBER () OVER ( ORDER BY a.name ) RowID
FROM sys.all_objects a
CROSS JOIN sys.all_objects b
GO
-- Check the size of the Database
SELECT DB_NAME ( database_id ) AS DatabaseName ,
Name AS Logical_Name ,
Physical_Name , ( size * 8 )/ 1024 SizeMB
FROM sys.master_files
WHERE DB_NAME ( database_id ) = 'SimpleTran'
GO
-- Take Full Backup
BACKUP LOG [SimpleTran] TO  DISK = N'D:/SimpleTran.bak' WITH NOFORMAT , NOINIT , NAME = N'SimpleTran-Transaction Log  Backup' , SKIP , NOREWIND , NOUNLOAD , STATS = 10
GO
-- Run following transaction multiple times and check the size of T-Log
INSERT INTO RealTempTable ( ID )
SELECT TOP 50000 ROW_NUMBER () OVER ( ORDER BY a.name ) RowID
FROM sys.all_objects a
CROSS JOIN sys.all_objects b
GO
-- Check the size of the Database
SELECT DB_NAME ( database_id ) AS DatabaseName ,
Name AS Logical_Name ,
Physical_Name , ( size * 8 )/ 1024 SizeMB
FROM sys.master_files
WHERE DB_NAME ( database_id ) = 'SimpleTran'
GO
/*
Now run following code multiple times.
You will notice that it will not increase the size of .ldf file but will for sure
increasethe size of the log backup.
*/
-- Second Time
-- START
BACKUP LOG [SimpleTran] TO  DISK = N'D:/SimpleTran.log' WITH NOFORMAT , NOINIT , NAME = N'SimpleTran-Transaction Log  Backup' , SKIP , NOREWIND , NOUNLOAD , STATS = 10
GO
-- Run following transaction and check the size of T-Log
INSERT INTO RealTempTable ( ID )
SELECT TOP 50000 ROW_NUMBER () OVER ( ORDER BY a.name ) RowID
FROM sys.all_objects a
CROSS JOIN sys.all_objects b
GO
-- Check the size of the Database
SELECT DB_NAME ( database_id ) AS DatabaseName ,
Name AS Logical_Name ,
Physical_Name , ( size * 8 )/ 1024 SizeMB
FROM sys.master_files
WHERE DB_NAME ( database_id ) = 'SimpleTran'
GO
-- END
--Clean Up
USE MASTER
GO
IF EXISTS ( SELECT name FROM sys.databases WHERE name = N'SimpleTran' )
BEGIN
ALTER DATABASE [SimpleTran] SET SINGLE_USER WITH ROLLBACK IMMEDIATE ;
DROP DATABASE [SimpleTran]
END


If you run the code that is listed between START and END, you would get the following results almost every time:

This validates our earlier discussion. After seeing this article, the Singapore team implemented Log Backup instead of Log Truncate right away. Let me know what you think about this article.