Question: I have a database that has a 28gig transaction log file. Recovery mode is simple. I just took a full backup of the database, and then ran both:

`backup log dbmcms with truncate_only`

DBCC SHRINKFILE ('Wxlog0', TRUNCATEONLY)

The name of the db is db\_mcms and the name of the transaction log file is Wxlog0. 

Neither has helped. I'm not sure what to do next.

Answer: 
'sp\_removedbreplication' didn't solve the issue for me as SQL just returned saying that the Database wasn't part of a replication...

I found my answer here:

* <http://www.sql-server-performance.com/forum/threads/log-file-fails-to-truncate.25410/>
* <http://blogs.msdn.com/b/sqlserverfaq/archive/2009/06/01/size-of-the-transaction-log-increasing-and-cannot-be-truncated-or-shrinked-due-to-snapshot-replication.aspx>

Basically I had to create a replication, reset all of the replication pointers to Zero; then delete the replication I had just made.
i.e.

```
Execute SP_ReplicationDbOption {DBName},Publish,true,1
GO
Execute sp_repldone @xactid = NULL, @xact_segno = NULL, @numtrans = 0, @time = 0, @reset = 1
GO
DBCC ShrinkFile({LogFileName},0)
GO
Execute SP_ReplicationDbOption {DBName},Publish,false,1
GO

```
I know this is a few years old, but wanted to add some info.

I found on very large logs, specifically when the DB was not set to backup transaction logs (logs were very big), the first backup of the logs would not set log\_reuse\_wait\_desc to nothing but leave the status as still backing up. This would block the shrink. Running the backup a second time properly reset the log\_reuse\_wait\_desc to NOTHING, allowing the shrink to process.