SQL Server Backup and Restore - Simple Talk

Chapter 5: Log Backups
There are several other issues that can be revealed through the log_reuse_wait_
desc column, mainly relating to various processes, such as replication, which require
log records to remain in the log until they have been processed. We haven't got room
to cover them here, but Gail Shaw offers a detailed description of these issues in her
article, Why is my transaction log full? at www.sqlservercentral.com/articles/
Transaction+Log/72488/.
Excessive logging activity
If no problems are revealed by the log_reuse_wait_desc column then the log growth
may simply be caused by a very high rate of logging activity. For a database using the
FULL recovery model, all operations are fully logged, including bulk data imports, index
rebuilds, and so on, all of which will write heavily to the log file, causing it to grow rapidly
in size.
It is out of scope for this book to delve into the full details of bulk operations but, essentially,
you need to find a way to either minimize the logging activity or, if that's not
possible, then simply plan for it accordingly, by choosing appropriate initial size and
growth settings for the log, as well as an appropriate log backup strategy.
As noted in Chapter 1, certain bulk operations can be minimally logged, by temporarily
switching the database from FULL to BULK_LOGGED recovery, in order to perform the
operation, and then back again. Assuming your SLA will permit this, it is worth considering,
given that any bulk logged operation will immediately prevent point-in-time
recovery to a point within any log file that contains records relating to the minimally
logged operations. We'll cover this option in a little more detail in Chapter 6.
175