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
Larry Gonick: Geek of the Week
 Cartoonist, mathematician, historian and environmentalist. Larry Gonick proved that learning could be... Read more...

A SysAdmin's Guide to Change Management
 In the first in a series of monthly articles, ‘Confessions of a Sys Admin’, Matt describes the issues... Read more...

Exchange: Recovery Storage Groups
 It can happen at any time: You get a request, as Admin, from your company, to provide the contents of... Read more...

Build Your Own Virtualized Test Lab
 Desmon explains the fundamentals of building a test lab for Windows servers and Enterprise applications... Read more...

Rendering Hierarchical Data with the Treeview
 It sometimes happens that Web Server controls that visualize data don't quite fit with the way that... Read more...