SQL Server Backup and Restore - Simple Talk

Chapter 6: Log Restores
If we do need to perform maintenance operations that can be minimally logged and
we wish to switch to BULK_LOGGED model, the recommended practice is to take a log
backup immediately before switching to BULK_LOGGED, and immediately after switching
the database back to FULL recovery, as demonstrated in Listing 6-1. This will, as far as
possible, isolate the minimally logged transactions in a single log backup file.
Performing Log Restores
Being prepared to restore your database and log backups is one of the DBAs most
important jobs. All DBAs are likely, eventually, to find themselves in a situation where
a crash recovery is required, and it can be a scary situation. However, the well-prepared
DBA will know exactly where the required backup files are stored, will have been
performing backup verification and some random test restores, and can exude a calm
assurance that this database will be back online as quickly as possible.
As we did for log backups, we're going to discuss how to perform log restores the "GUI
way," in SSMS, and then by using native T-SQL Backup commands. We're going to be
restoring to various states the DatabaseForLogBackups database from Chapter 5, so
before we start, let's review, pictorially, our backup scheme for that database, and what
data is contained within each backup file.
With our first example, using the GUI, we'll restore the DatabaseForLogBackups
database to the state in which it existed at the point after the first log backup was taken;
in other words, we'll restore right to the end of the transaction log DatabaseForLog-
Backups_Native_Log_1.trn, at which point we should have 20 rows in each of our
three message tables.
187