SQL Server Backup and Restore - Simple Talk

Chapter 5: Log Backups
So, at this stage, we've captured a full backup of our new database, containing three
tables, each with ten rows of data. We're ready to start taking log backups now, but
let's run the DBCC SQLPERF(LOGSPACE) command again, and see what happened to
our log space.
Backup Stage Log Size Space Used
Before full backup 50 MB 0.65 %
After full backup 50 MB 0.73%
Figure 5-3: DBCC SQLPERF (LOGSPACE) output after full backup.
What's actually happened here isn't immediately apparent from these figures, so it needs a
little explanation. We've discussed earlier how, for a FULL recovery model database, only
a log backup can free up log space for reuse. This is true, but the point to remember is
that such a database is actually operating in auto-truncate mode until the first full backup
of that database completes. The log is truncated as a result of this first-ever full backup
and, from that point on, the database is truly in FULL recovery, and a full backup will
never cause log truncation. So, hidden in our figures is the fact that the log was truncated
as a result of our first full backup, and the any space taken up by the rows we added was
made available for reuse. Some space in the log would have been required to record the
fact that a full backup took place, but overall the space used shows very little change.
Later in the chapter, when taking log backups with T-SQL, we'll track what happens to
these log space statistics as we load a large amount of data into our tables, and then take a
subsequent log backup.
160