SQL Server Backup and Restore - Simple Talk

Chapter 5: Log Backups
As a log file grows and grows, a related problem is that the log can become "internally
fragmented," if the growth occurs in lots of small increments. This can affect the performance
of any operation that needs to read the transaction log (such as database restores).
Failure to take log backups
Still the most common cause of a rapidly growing log, sadly, is simple mismanagement;
in other words failure to take log backups for a database operating in FULL recovery.
Since log backups are the only operation that truncates the log, if they aren't performed
regularly then your log file may grow rapidly and eat up most or all of the space on your
drive. I rest more peacefully at night in the knowledge that, having read this chapter, this
is a trap that won't catch you out.
If you're asked to troubleshoot a "runaway" transaction log for a FULL recovery model
database, then a useful first step is to interrogate the value of the log_reuse_wait_
desc column in sys.databases, as shown in Listing 5-9.
USE master
GO
SELECT name ,
recovery_model_desc ,
log_reuse_wait_desc
FROM sys.databases
WHERE name = 'MyDatabase'
Listing 5-9: Finding possible causes of log growth.
If the value returned for the log_reuse_wait_desc column is LOG BACKUP, then the
reason for the log growth is the lack of a log backup. If this database requires log backups,
start taking them, at a frequency that will satisfy the terms of the SLA, and control the
growth of the log from here in. If the database doesn't require point-in-time recovery,
switch the database to SIMPLE recovery.
173