Essentially we have to identify the BOTTLENECK which is filling the log file.

As a quick resolution check all possible solutions as below:

• Resolve if there are any errors in the log reader agent/distribution agent
• Fix if there are any CONNECTIVITY issues either between publisher-DISTRIBUTOR or distributor
• Fix if there are any issues with I/O at any level
• Check if there is any huge number of transactions pending from publisher
• Check if there are any large number of VLFs (USE DBCC Loginfo)which slows the log reader agent work.
• Check all DATABASE statistics are up-to-date at the distributor. Usually, we do switch off this “Auto Update Stats” by default.
• To find and resolve these issues we can use “Replication Monitor”, “DBCC Commands”, “SQL Profiler”, “System Tables / SP / Function”.

If in case we can’t resolve just by providing a simple solution we have to shrink the transaction log file. Below are two methods.

To shrink the transaction log file:

1. Backup the log — So transactions in vlf’s are marked as inactive
2. Shrink the log file using DBCC SHRINKFILE – Inactive VLF’s would be removed
3. If you find no difference in size repeat the above steps 1 and 2

To truncate the transaction log file:

In any case, we are not able to provide the solution against the increasing logfile the final solution is to DISABLE the replication, truncate the log and reinitialize the subscribers.

1. Disable replication jobs
2. Execute the SP_ReplDone procedure. It disables the replication and mark as “Replicate done” for all pending transactions at the publisher.
3. Backup the transaction log “WITH TRUNCATE” option.
4. Shrink the log file using “DBCC SHRINKFILE”
5. Flues the article cache using “sp_replflush”.
6. Go to distributor database and truncate the table MSRepl_Commands
7. Connect to replication monitor and reinitialize all subscriptions by generating a new snapshot.
8. Enable all replication-related jobs.