Transaction Log File (Full) Issues

While troubleshooting the replication issue I came across the very common error

–Msg 9002, Level 17, State 4, Line 1

–The transaction log for database ” is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases

I did the same as suggested by the error, checking the sys.database for the reason why the error log is full.

select log_reuse_wait ,log_reuse_wait_desc  from sys.databases where name =’Databases Name’

As a first step of troubleshooting I checked the logfile configuration to see if log file size is ristricted ,Auto Growth is enabled (is auto growth in percent or MB) and the initial size of the log file.

The Log file initial size is set to 3 MB (Default) and as we can see the log file is enabled for autogrowth with Ristricted file growth of 10 MB.

So, the maximum log file can grow upto 10 MB.

The question come’s in one’s mind is “How can we check the used percentage of the log file?”

To check the Log file used Percentage

DBCC SQLPERF(logspace)

Database Name Log Size (MB) Log Space Used (%) Status
Xzcvxz 9.929688 99.76396 0


As u can see the logfile has been used till the last extend and there is no more space to grow.

Now the question is how to determine SQL Server database transaction log usage?

To determine the Log Usage there is an undocumented command

(DBCC LOGINFO(‘Database name’)

This will give you information about your virtual logs inside your transaction log.  The primary thing to look at here is the Status column.  Since this file is written sequentially and then looped back to the beginning, you want to take a look at where the value of “2” is in the output.  This will tell you what portions of the log are in use (2) and which are not in use Status = 0.  Another thing to keep an eye on is the FSeqNo column. This is the virtual log sequence number and the latest is the last log.  If you keep running this command as you are issuing transactions you will see these numbers keep changing.

FileId FileSize StartOffset FSeqNo Status Parity CreateLSN
2 253952 8192 2275 2 128 0
2 253952 262144 2276 2 128 0
2 253952 516096 2273 2 64 0
2 278528 770048 2274 2 64 0
2 262144 1048576 2277 2 64 1571000000037600000
2 262144 1310720 2278 2 64 1572000000050200000
2 262144 1572864 2279 2 64 1573000000040000000
2 262144 1835008 2280 2 64 1574000000050200000
2 262144 2097152 2281 2 64 1575000000050000000

Now as we know the issue however the confusion is how to resolve the same.

But wait

(1)What if there are transaction still running against the database.

To check the same run

DBCC Opentran() against the database.

Transaction information for database ‘xzcvxz’.

Oldest active transaction:

    SPID (server process ID): 57

    UID (user ID) : -1

    Name          : SELECT INTO

    LSN           : (3395:100:1)

    Start time    : Aug 29 2010  2:35:32:837AM

    SID           : 0x01

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

If there are still open transaction againt the database or if the database is setup for replication or CDC and the transaction are still not marked as replicated in the transaction log, the logfile can’t be shrinked.


To resolve the same I go around multiliple ways will explain few workaround here.

1.If database is not setup for Logshipping,Replication,Mirroring and CDC.

1.  set the database into simple recovery mode

2.  Set the database back to full recovery mode.

3.  Run the shrinkfile command.





DBCC SHRINKFILE (2,truncate_only)

(Mirosoft do not recommend to use truncate statement in production)


2.In case the database is setup for Replication (any topology) and transaction log file is growing tremendously and soon will be full. Transaction Log file can’t be shrinked as there are transaction which are not marked as replicated in the transaction log file.


If transaction log is full and transaction written on the log file are not marked as replicated the logreader agent will keep trying to scan the log and mark the transaction as replicated but it will not succeed as there is no space to write transaction in the transaction (Mark the transaction as replicated).As the transaction are not marked as replicated DBA’s cant shrink the Log file.

To resolve the issue we can execute the below steps.

1.  Lets say the trasaction log file is on drive D: of size 200 GB.

2.  The transaction log file has grown by size 200 GB.

3.  Create a new log file to some other drive.Let’s say on drive F: at the publisher database.

USE [master]


ALTER DATABASE [xzcvxz] ADD LOG FILE ( NAME = N’xyz_log’, FILENAME = N’F:xyz_01.ldf’ , SIZE = 1024KB , FILEGROWTH = 10%)


4.  As new log file is added to the database, SQL Server will start using it.the new transaction will be written to the newly added transaction log files.The Log reader agent will start scaning the old log file and will mark the transaction as distributed once sp_repcmd will replicate the commands or transaction to the distributor database.

5.  Alter the Database in simple recovery mode.


 6.  Alter the Database again in full recovery mode. 


7.  Now Shrink the Log file.

USE [xzcvxz]



 Will write about how to shrink log file in Mirroring and Log shipping in my next article.

Leave a Reply

Your email address will not be published.