views:

34

answers:

2

Let's say I have two database instances:

InstanceA - Production server
InstanceB - Test server  

My workflow is to deploy new schema changes to InstanceB first, test them, and then deploy them to InstanceA.

So, at any one time, the instance schema relationship looks like this:

InstanceA - Schema Version 1.5
InstanceB - Schema Version 1.6 (new version being tested)

An additional part of my workflow is to keep the data in InstanceB as fresh as possible. To fulfill this, I am taking the database backups of InstanceA and applying them (restoring them) to InstanceB.

My question is, how does schema version affect the restoral process?

I know I can do this:

Backup InstanceA - Schema Version 1.5
Restore to InstanceB - Schema Version 1.5

But can I do this?

Backup InstanceA - Schema Version 1.5
Restore to InstanceB - Schema Version 1.6 (new version being tested)

If no, what would the failure look like?

If yes, would the type of schema change matter?

For example, if Schema Version 1.6 differed from Schema Version 1.5 by just having an altered storec proc, I imagine that this type of schema change should't affect the restoral process. On the other hand, if Schema Version 1.6 differed from Schema Version 1.5 by having a different table definition (say, an additional column), I image this would affect the restoral process.

I hope I've made this clear enough.

Thanks in advance for any input!

+7  A: 

No, a restore doesn't look at the schema, it simply restores datafiles as they were, so you'll end up with schema 1.5 after the restore. It will overwrite whatever is already there.

You'd be better to do the data refresh restore first, then apply the 1.6 schema changes.

mrjoltcola
This is one reason why we do everything in scripts (even data entry for test records or logins or lookup values) and save them in source control. It is easy after dev has been restored with prod data (which we do frequently) to then run all the scripts that have not yet been deployed to prod.
HLGEM
Agreed. Also, using a quality tool will help. I use ER/Studio to maintain changes, and it takes care of piping data from old version of tables to new versions.
mrjoltcola
+4  A: 

Unless you're doing restores of just specific filegroups, your restore will include both data and schema. Doing a full restore of the database will include ALL schema and in the database, and would replace the database entirely. If you were to create filegroups and put specific tables in the filegroups, you could restore just those filegroups that you wanted - and that would include just the data and schema for the tables (and anything else you put in the file groups too - like indexes, materialized views, etc.)

What you should really be looking at are Schema- and Data-Compare tools. Things like Redgate, ApexSql Compare, AdeptSQL, or Visual Studio Database Edition all can do a great job with exactly the scenario that you describe. I personally use the VS Database edition because we get it with our Gold Partner licenses, and love it. It does exactly what you are looking for, and does a great job at it. I've used all the others in the past too, and would recommend any of them. Most of them have 30 day trial editions - you should download a couple and give it a test drive in your current scenario.

Scott Ivey
+1 good tools save so much time in the long run.
mrjoltcola
Hi Scott, thanks for the input. When you say the restore includes both data and schema, does the schema also include stored proces, views, users, logins, etc, or does it only include the schema for tables?
Martin Aatmaa
if you're doing a full database restore, it includes all schema including views, sprocs, UDFs, etc. If you were to use separate filegroups, you could restore specific tables - which would include the data and schema for the tables that you put in those filegroups. I'll update my answer to clarify.
Scott Ivey