Question

I had some databases that would not truncate the transaction log.

These databases are all in SIMPLE recovery mode, and we are ok with one full backup daily.

First thing I checked is if there were some sort or open transactions or something preventing the logs to be re-used.

SELECT name, log_reuse_wait_desc
FROM sys.databases
WHERE log_reuse_wait <> 0

which gave me the following results:

two databases waiting for LOG BACKUP reuse

To get rid of the LOG_BACKUP, I did:

USE [master]
GO
ALTER DATABASE mydb SET RECOVERY BULK_LOGGED WITH NO_WAIT

and back to SIMPLE:

USE [master]
GO
ALTER DATABASE mydb SET RECOVERY SIMPLE WITH NO_WAIT

That sorted the LOG_BACKUP but I still had lack of disk space issues.

So I desperately run the following command:

DBCC SHRINKFILE (N'wslogdb70_27_log', 0, TRUNCATEONLY)

I hope this TRUNCATED the transaction log, instead of SHRINKING it.

  • Am I correct?
  • Is there any article/book that references this?
Was it helpful?

Solution

First, you can't have LOG_BACKUP as a log_reuse_wait if the database is in SIMPLE recovery, because it's not possible to even take the log backup unless recovery mode is either FULL or BULK_LOGGED.

Further, as per the docs:

The TRUNCATEONLY option does not move information in the log, but does remove inactive VLFs from the end of the log file.

To shrink a log file, use

DBCC SHRINKFILE (wslogdb70_27_log, X)

where X is the target size in MB.

Take care not to shrink the log too much, it needs some free space in file to work, otherwise it will just autogrow again.

Regarding autogrowth, try to specify the autogrowth factor in MB, not in percent. How much exactly depends on some factors you didn't mention (size of log and data files, for example).

Actually, monitoring your DB's and adjusting accordingly is your best bet.

OTHER TIPS

DBCC SHRINKFILE (N'wslogdb70_27_log', 0, TRUNCATEONLY)

Seems working well for me with SQL Server 2008 R2

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top