Recovery Model for Bulk Operations

Posted on 2011-10-28
Medium Priority
Last Modified: 2012-05-12
We have a few stored procedures that do some heavy select into (millions of records at a time).

It has been recommend that we alter the database to a Bulk-logged recovery model during the window in which we perform the bulk operations.

We currently have the database in a Simple recovery model. Based on SQL documentation, both Bulk-Logged and Simple recovery models support high-performance bulk copy operations.

Is there any performance benefit to switch the database from Simple recovery model to Bulk-logged recovery model while we perform the 'select into'?

Question by:dthansen
LVL 28

Accepted Solution

Ryan McCauley earned 1000 total points
ID: 37047560
The BULK-LOGGED recovery model actually appears to be much closer to the FULL model than SIMPLE, as you're currently using. Given that, I'd recommend that you continue to use SIMPLE.

Bulk Logged is really designed as an alternative to FULL recovery, to be used during large bulk load operations. If you're already using Simple, then you'd actually generate more logging by switching to Bulk.
LVL 70

Assisted Solution

by:Scott Pletcher
Scott Pletcher earned 500 total points
ID: 37047834
I agree.

You should do other tuning as needed to handle the large INSERTs, rather than just the recovery model.

1) Do you have IFI (Instant FIle Init.) enabled?

2) Have you preallocated enough data space and, *even more so*, log space to handle the INSERT statement *before* the INSERT starts?

3) Is the autogrow set to a *fixed* (*not* %) amount that is fairly large, so that you are not constantly having to autogrow? (Just in case; should avoid autogrow if you can)

4) Are the physical files highly fragmented?  That can hurt performance of the db overall.

Author Comment

ID: 37048346
So if the recovery model is already Simple, you don't see any benefit to doing the following...

1. alter database SOMEDB set recovery BULK_LOGGED

2. select  column1, column2 into sometable from sometable2  (nolock)

3. alter database SOMEDB set recovery Simple



LVL 28

Assisted Solution

by:Ryan McCauley
Ryan McCauley earned 1000 total points
ID: 37048350
None at all - the SIMPLE recovery model already takes all the logging shortcuts that BULK_LOGGED does, plus some more. Changing to BULK_LOGGED sounds like it would actually increase the amount of logging that's done, not decrease it or speed things up.
LVL 25

Assisted Solution

jogos earned 500 total points
ID: 37052469
Altering the transaction-model during a process is something that must be carefully done and very good documented.  It's quickly done but if you change the transaction model of the db your code won't be correct anymore.... and maybe your backup-cycle won't be corret either.

Featured Post

Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Ever wondered why sometimes your SQL Server is slow or unresponsive with connections spiking up but by the time you go in, all is well? The following article will show you how to install and configure a SQL job that will send you email alerts includ…
In this article we will learn how to fix  “Cannot install SQL Server 2014 Service Pack 2: Unable to install windows installer msi file” error ?
This videos aims to give the viewer a basic demonstration of how a user can query current session information by using the SYS_CONTEXT function
Viewers will learn how to use the INSERT statement to insert data into their tables. It will also introduce the NULL statement, to show them what happens when no value is giving for any given column.
Suggested Courses

809 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question