SQL Server 2012 : Backup and Recovery Planning - Recovery Models (part 3) - Bulk-Logged Recovery Model, Setting the Recovery Model

Bulk-Logged Recovery Model

The bulk-logged recovery model is similar to the full recovery model except that the following operations are minimally logged:

• Bulk import operations (BCP, BULK INSERT, and INSERT ... SELECT * FROM OPENROWSET (BULK...))
• SELECT INTO operations
• WRITETEXT and UPDATETEXT BLOB operations
• CREATE INDEX (including indexed views)
• ALTER INDEX REBUILD or DBCC DBREINDEX operations
• DROP INDEX

Because this recovery model minimally logs these operations, they run fast. The transaction log marks only that the operations took place and tracks the extents (a group of eight data pages) affected by the bulk-logged operation. When the transaction log is backed up, the extents are copied to the transaction log in place of the bulk-logged marker.

The trade-off for bulk-logged operation performance is that the bulk-logged operation is not treated as a transaction. Although the transaction log itself stays small, copying all affected extents to the transaction-log backup can make the log-backup file large.

Because bulk-logged operations are minimally logged, if a failure should occur after the bulk-logged operation but before the transaction log is backed up, the bulk-logged operation is lost, and the restore must be made from the last transaction log. Therefore, if the database uses the bulk-logged recovery model, every bulk-logged operation should be immediately followed by a transaction-log backup.

This model is useful only when the database sees a large number of bulk-logged operations, and if it's important to increase their performance. If the database performs adequately during bulk-logged operations in the full recovery model, bypass the bulk-logged recovery model.

Using this setting is essentially the same as setting the Select Into/Bulkcopy database option to true.

Setting the Recovery Model

The model system database's recovery model is applied to any newly created database. The full recovery model is the default for the Standard and Enterprise Editions. The Personal and Desktop editions use the simple recovery model as their default, but you can change the default by setting the recovery model for the model system database.

Using Management Studio, you can easily set the recovery model on the Options tab of the Database Properties dialog box. Select the database and right-click to get to the Database Properties dialog.

In code, the recovery model is set with the ALTER DATABASE DDL command:

ALTER DATABASE DatabaseName SET Recovery Option; 

The valid recovery options are FULL, BULK_LOGGED, and SIMPLE. The following code sets the AdventureWorks2012 sample database to the full recovery model:

USE AdventureWorks2012;
ALTER DATABASE AdventureWorks2012 SET Recovery FULL;

You should explicitly set the recovery model in the code that creates the database.

SELECT name, recovery_model_desc
 FROM sys.databases;

Modifying Recovery Models

Although a production user database is typically set to a full recovery model, there's nothing to prevent you from switching between recovery models during an operation to optimize performance and suit the specific needs of the moment.

It's perfectly valid to run during the day with the full recovery model for transaction durability and then to switch to bulk-logged during data imports in the evening.

During recovery it's the full, differential, and transaction-log backups that count. The recovery operation doesn't care how they were made.

Because the simple recovery model does not permanently log the transactions, care must be taken in switching to or from the simple recovery model:

• If you switch to simple, the transaction log should be backed up prior to the switch.
• If you switch from simple, a full database backup should be performed immediately following the switch.
• Schedule regular transaction log backups and update your recovery plans.