Donahue, Crash Scene Investigator

Red Gate Support Engineer

Object-level recovery from backup is here!

Published Saturday, August 16, 2008 12:04 PM

Version 7 of the Red Gate SQL Comparison SDK has finally brought the possibility of recovering individual objects from a Microsoft SQL Server backup to a live database. I found this an exciting opportunity to flex the old noggin and design a program that can restore schema and associated data from a backup file to a real database.

The reasons why you would want to do this are vaired. For example, I've heard it would be useful for database normalization, inserting test data, and some obscure disaster recovery situations. Of course, the compelling reason for me is "because I can"!

Simply restoring a table and its' data alone could have unintended consequences. For example, what happens when foreign keys exist between the table you want to restore and other tables? What if the table has dependent objects, such as a default bound to a user-defined function? The SQL Compare Engine can handle all of these things because of its' dependency engine which can create all dependencies in the proper order. The Data Compare Engine can also handle foreign key relationships, triggers, and unique constraints.

 

This means that you could insert a stored procedure from a backup, and the API can add the tables and other objects that the procedure needs, or even adjust the existing schema so that the stored procedure will run without errors!

The example program can do this and more: if the schema object being recovered is a table, all existing data will be altered, superfluous data deleted, and new data inserted so the live database will exactly match the data in the backup. In this example, the table must have a primary key or unique index to match rows of data together. It would be possible to add extra logic to allow the user to pick one or more columns to act as the basis for a comparison key.

The only downside to combining schema and data recovery from backup using the SDK is that, because the SQL Compare Engine is optimized to retrieve schema and the Data Compare Engine is optimized to retrieve data, it is necessary to read the backup twice in order to retrieve schema and data. Hopefully Red Gate can combine the two engines in the future to make the process more efficient!

The example C# project can be downloaded from the Red Gate Labs site: http://labs.red-gate.com/uploads/5/54/SQL_Object-Level_Restore.zip

You will also need to install the assemblies from SQL Compare and SQL Data Compare by downloading the SQL Comparison SDK.

by Brian Donahue
Attachment(s): OLR.PNG

Comments

 

johnc said:

I tried to use the current version to restore a table from a backup...but since the table did not have a PK I could not do it.. Is this version going to be able to do it? A lot of our staging tables don't have any indexes since it's just a place to hold it on the way to somewhere else.
August 19, 2008 10:27 AM
 

Brian Donahue said:

Thanks for having a look at this. I do mention here, and in the release notes, that it should be possible to create "comparison keys" in the SQL Data Compare API by manually mapping together one or more columns that can be used to uniquely identify a row of data. But you would have to plumb in another form to present the user with a list of columns to choose from.

If I have some time this week,  I may look into adding this to the example project.
August 20, 2008 3:54 AM
 

Brian Donahue said:

I take that back... unlike comparing live databases, the BackupReader can only compare tables which have a primary key or other unique index. When I try to create a manual mapping, I get a BackupReaderException indicating that "the table does not have an index".

Sorry for the confusion!
August 20, 2008 10:22 AM
 

RobertChipperfield said:

With respect to the "must have an index" requirement, that stems from the backup reader's SQL Data Compare childhood.

Data Compare needs to be able to order the data on both sides of the comparison in the same way, and so when reading backups, we either had to enforce the use of indexes, or we had to read all of the data out of the table, sort it ourselves (not as easy as it sounds when you start working with SQL Server's collations!), and then do the comparison.

Given that this data might be pretty huge, and the chances of getting the ordering wrong were substantial for strings, we opted to enforce the use of an index when retrieving the data.

The ordering is less important when just dumping the data into an empty table, of course, so it's possible we will support a "just get me all the data already" operation in the future...
August 28, 2008 12:29 PM
 

User links about "from" on iLinkShare said:

October 30, 2008 11:03 AM
You need to sign in to comment on this blog

















<August 2008>
SuMoTuWeThFrSa
272829303112
3456789
10111213141516
17181920212223
24252627282930
31123456
Virtual Exchange Servers
 Microsoft now supports running Exchange Server 2007 in server virtualization environments, not just on... Read more...

Virtualizing Exchange: points for discussion
 With the increasing acceptance of the use of Virtualization as a means of providing server... Read more...

Encouraging .NET Reflector Add-ins
 Jason Haley is well-known for the resources he's provided to developers who wish to extend Reflector's... Read more...

Using .NET Reflector Add-ins
 .NET Reflector by itself is great, but it really comes into its own with the help of some add-ins. Here... Read more...

Unique Experiences!
 You'd have thought that a unique constraint was an easy concept - Not a bit of it; it can cause a lot... Read more...