IT tutorials
 
Database
 

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

2/10/2014 12:48:34 AM
- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019

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.

Note
A simple recovery model also minimally logs bulk-copy operations.

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


Best Practice
You should minimally use a bulk-logged recovery model because you lose the ability to do point-in-time recovery to any point covered by a transaction log backup that contains even a single minimally logged operation. The best practice for production user databases is to use a full recovery model, take a transaction log backup before performing bulk operations, switch to a bulk-logged model, perform the bulk operations, and then immediately switch back to the full recovery model and take a transaction log backup. This allows point-in-time recovery and fully protects the data.

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.


Tip
You can determine the current recovery model for every database from the following query using the sys.databases catalog view:
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.
 
Others
 
 
 
Top 10
 
 
Facebook
 
Technology FAQ
- Microsoft ebs security server configuration
- IIs7 on Windows server 2003
- How to Configure Failover Clusters With Win 2008 Server R2?
- Windows 2008 Network Load Balancing
- Windows Server 2008 - Group Policy Management - Remove Computer Management
- Remove shortcuts possibility in a web page or to put in favorite
- HTA Dynamic Drop Down List
- IIS host header and DNS
- VMware or MS Virtual Server?
- Adobe Acrobat 9 inserting tab pages
programming4us programming4us