March 21, 2008 at 12:26 pm
hi guys! what tool is best if you would like to synchronize the data on the tables in a development server with the data in production.
Is it good just to do a backup of the db in production and then restored it in development?
March 21, 2008 at 12:57 pm
I've used several, but definitely prefer RedGate's SQL Compare. They have a free 14 day evaluation version. If you end up buying it (which you should), ask for Carl from sales when you go to buy and tell 'em I sent ya 🙂
March 21, 2008 at 5:34 pm
Yes, restore is good if you can manage with one day older data or whatever gap you have between backup and restore. Secondly, if your database is not very large and Third you have no issue in transferring data over network.
There are tools but I do not think you really need it if you just want data be transferred onto development box.
[font="Verdana"]--www.sqlvillage.com[/size][/font]
March 24, 2008 at 7:33 am
thank you, for now eventhough the back up and restore seems to be the easiest way to update the data of the tables, we can't do it since in the development server we have stored procedures that the developers have been testing and we haven't migrated them into production server yet, if we do a backup and restore then these would be also updated from production correct? what about just to do a ssis package to drop the tables and then import them from production? since the table is very big (40 millions rows) can we do it by small batches? what about the relationship with other tables? I think it has two related tables, would this lock the production table?
March 25, 2008 at 8:33 am
This is what I'd do:
1) compare Development to production and create an "update" script with the new procs, tables, etc. (redgate tool works great)
2) Ask programmers what reference tables they changed, create update script for reference tables
3) restore production DB to Dev server (the QA database)
4) exec the Update Script in Dev Server (QA database)
5) run tests in Dev server
6) If testing is fubar, check Dev database and QA then modify your update scripts.
This will give you a practice run for when you go to production. Don't give the developers permissions to update objects in the QA database and you'll have a smooth implementation. This will keep them honest.
Good luck
March 25, 2008 at 9:09 am
I agree with Doug. allowing developers to make changes to anything other than development is asking for deployment issues.
March 25, 2008 at 9:10 am
Steve Jones - Editor (3/25/2008)
I agree with Doug. allowing developers to make changes to anything other than development is asking for deployment issues.
I can't wait for the policies feature of 2008 ... man is that going to be great to tackle these types of issues.
March 25, 2008 at 10:18 am
I restore from prod and make it the developers responsiblity to keep scripts to get THEIR changes back on after restores.... Amazingly enough after the first time you over write their changes it never happens again 😉 Do make sure you have management understanding of what you are doing before going this route....
I do give about 12 hours notice when possible. But I have production support databases on my dev server that can (and are) overwritten with less than 30 minutes notice if we need to track down production issues.
March 25, 2008 at 12:48 pm
Thank you guys!! 🙂
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply