SQL SERVER – Error 9002: The Transaction Log for Database ‘SQLAuthority’ is Full Due to ‘REPLICATION’

Recently one of my clients contacted me to provide them assistance in finding and fixing the cause of a huge transaction log file. There are many caused to get error 9002 in SQL Server ERRORLOG. In this blog, I would explain the cause and fix of error: The transaction tog for database ‘SQLAuthority’ is full due to ‘REPLICATION’.

SQL SERVER - Error 9002: The Transaction Log for Database 'SQLAuthority' is Full Due to 'REPLICATION' full-due-to-replication-800x247

I joined a call with them and ran a few queries to know the state of the database. I always start with the below query.

SELECT name, log_reuse_wait_desc
FROM sys.databases
where name = 'Database_Name'

Here is the complete list as of today from books online. Here are the various values which can be seen in log_reuse_wait_desc in sys.databases catalog view.


In my client’s case, I was seeing “REPLICATION”.

When I queried sys.databases to know about replication using the following query:

SELECT [is_published]
FROM sys.databases
WHERE name = 'Database_Name' 

I saw this

SQL SERVER - Error 9002: The Transaction Log for Database 'SQLAuthority' is Full Due to 'REPLICATION' log-reuse-repl-01

That was weird! Based on my discussion with them at some point they did try to do a replication. They created a publication but no subscription. When I checked, I found that the log reader job was not running. That explains the cause of the full transaction log.

Fundamentally, SQL Server would keep the data in the transaction log and won’t allow truncation until data is replicated or picked by Log Reader Agent.  You may run into the same issue as there are errors encountered by the log reader agent job.

WORKAROUND/SOLUTION – Full Due to Replication

Since there was no subscriber configured, they were confident enough that we should remove it and it won’t break anything. We attempted to use SQL Server Management Studio to drop the publication, but it was taking a long time. Finally, it got removed but we were still seeing REPLICATION wait. I also used sp_removedbreplication to clean it up. After that, I took transaction log backup and checked log_reuse_wait_desc and it was NOTHING.

After that, I was able to shrink the log file. Here is one of my earlier posts which has a script to shrink the log file of all databases.

SET @ScriptToExecute = '';
@ScriptToExecute = @ScriptToExecute +
'USE ['+ d.name +']; CHECKPOINT; DBCC SHRINKFILE ('+f.name+');'
FROM sys.master_files f
INNER JOIN sys.databases d ON d.database_id = f.database_id
WHERE f.type = 1 AND d.database_id > 4
-- AND d.name = 'NameofDB'
SELECT @ScriptToExecute ScriptToExecute
EXEC (@ScriptToExecute)

Well, this is how we fixed the Error 9002: The Transaction Log for Database ‘SQLAuthority’ is Full Due to ‘REPLICATION’.

Have you seen such an unexplained situation with SQL Server? Please comment and let me know.

Reference: Pinal Dave (https://blog.sqlauthority.com)

SQL Error Messages, SQL Log, SQL Replication, SQL Scripts, SQL Server, Transaction Log
Previous Post
SQL SERVER – Why Server Authentication is Disabled? What Mode is SQL Server Using Currently?
Next Post
Work from Home Contest – Download Spotlight And Win USD 100

Related Posts

3 Comments. Leave new

  • HI Panel,
    good article on replication. I have a database which log has exceeded over 100 GB. I tried using to shrink but the size did not decrease, i also take transaction log back and tried again to shrink database through DBCC command. i have replication that is not working since two months. Please guide me how to resolve the issue, secondly we do not need replication further.

  • Saurabh Krishnan
    October 6, 2020 4:29 pm

    Even while executing above command at my end gives the same error and so problem remains same.

  • I have a similar situation — a server with no replication configured, and a database with a nearly full transaction log with a REPLICATION wait_state. I believe the DB may have been created from a backup of a replicated DB, but the published/subscribed, cdc values are all 0. Unsurprisingly, sp_removedbreplication has no effect, since replication has never been set up here. The log file for the DB is the largest thing on the disk, and it’s become an issue.


Leave a Reply