October 15, 2010 at 1:28 pm
Hi,
In the worst-case scenario where a critical bug has crept through QA, are there any software tools that assist in helping you rollback a database to a previous version?
I understand you can do a SQLCompare between workingOLD and brokenNEW to see the schema changes, and that you would lose any data entered in new tables, but if that was acceptable loss does anyone have any pointers?
Could you simply write a script that went through each table and copied the data from brokenNEW to workingOLD for each object in workingOLD?
Has anyone ever done this/have experience of it? Any pitfalls if so?
Thanks,
Richard
October 15, 2010 at 1:35 pm
Do you have the scripts that were used to roll in the schema updates? If so, are they reversible?
When I roll out any major database change, I make sure I have a rollback script available before-hand.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
October 15, 2010 at 1:47 pm
You could use Red Gate's Data Compare as well, but what you're talking about is a custom job. There's no easy way for a tool to make the decisions about how to move data. If you've added or removed columns, what happens to the data?
October 15, 2010 at 1:57 pm
Richard McSharry (10/15/2010)
In the worst-case scenario where a critical bug has crept through QA, are there any software tools that assist in helping you rollback a database to a previous version?
Isn't this the definition of "restore"?
_____________________________________
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at Amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.October 15, 2010 at 2:00 pm
I would have thought so, but if people entered data in a new system, you can't restore without losing that data. So you need to migrate backwards the data.
October 15, 2010 at 2:32 pm
Steve Jones - SSC Editor (10/15/2010)
I would have thought so, but if people entered data in a new system, you can't restore without losing that data. So you need to migrate backwards the data.
I have never seen a good way to do this without customized scripts to merge data sets. Generally speaking most places I have worked commit to go forward in some fashion once an app is deployed and passed for users to work in; I have never seen a rollback at noon on Monday. Better to fix the problem than to go back to an older DB and try and migrate the data to the old restore.
October 15, 2010 at 2:41 pm
I've written lots of rollback scripts as part of deployments to deal with this, but (furious knocking on wood) I've never actually had to use one.
There isn't going to be a magic bullet. You are going to have to identify each schema change and figure out how to map the new data to the old. Hopefully you can just get away with throwing away new columns, but when you get into more complex relationships it can get VERY messy.
Best case, you have a source control of the SQL scripts that were deployed. Otherwise you are going to have to use redgate or equivalent against a backup.
October 15, 2010 at 2:52 pm
Steve Jones - SSC Editor (10/15/2010)
I would have thought so, but if people entered data in a new system, you can't restore without losing that data. So you need to migrate backwards the data.
or... you can perhaps
1- Detach affected database
2- Move affected database datafiles to a different location
3- Attach affected database as bad_db
4- Restore db point-in-time until the moment of the tragic event.
5- Add "good" data from bad_db into restored db
_____________________________________
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at Amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.October 15, 2010 at 4:25 pm
PaulB-TheOneAndOnly (10/15/2010)
Steve Jones - SSC Editor (10/15/2010)
I would have thought so, but if people entered data in a new system, you can't restore without losing that data. So you need to migrate backwards the data.or... you can perhaps
1- Detach affected database
2- Move affected database datafiles to a different location
3- Attach affected database as bad_db
4- Restore db point-in-time until the moment of the tragic event.
5- Add "good" data from bad_db into restored db
Isn't that another way of saying the same thing?
October 15, 2010 at 4:40 pm
jeff.mason (10/15/2010)
PaulB-TheOneAndOnly (10/15/2010)
Steve Jones - SSC Editor (10/15/2010)
I would have thought so, but if people entered data in a new system, you can't restore without losing that data. So you need to migrate backwards the data.or... you can perhaps
1- Detach affected database
2- Move affected database datafiles to a different location
3- Attach affected database as bad_db
4- Restore db point-in-time until the moment of the tragic event.
5- Add "good" data from bad_db into restored db
Isn't that another way of saying the same thing?
Don't think so.
So far I've heard about rolling out bad data while keeping good data until reaching the point where database was kosher.
Proposed approach is to start with a kosher database then add "good" data generated after the "tragic event". 😉
_____________________________________
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at Amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.October 16, 2010 at 7:42 am
From what I've read, the OP needs his old schema back, but needs to move data entered since rollout back to that schema. So moving good data out is what I think we proposed.
October 18, 2010 at 10:30 am
Hi all and thanks for all the replies.
Just to clarify: a simple restore of a backup is not the solution.
It might be that the new schema has been live for some time and users have entered a huge amount of data that you cannot realistically ask them to re-enter.
Any data that is in "new" columns can simply be dropped (or perhaps archived to add back later if you really need to). The problem, as some have pointed out, is inserting the newly added data into the old schema.
So is perhaps the best thing, rather than "rolling back" to simply take the database offline (after backing it up ofc) for long enough to run a script that simpy deletes any new tables and columns you added, and then rollbacks the stored procedures/functions to their previous version?
This would not be too difficult, or am I missing something? :hehe:
Thanks,
Richard
October 18, 2010 at 11:14 am
The complexity will depend on the magnitude of the changes.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
October 19, 2010 at 9:09 am
Red-Gate, ApexSQL and other companies have schema and data comparison tools to help you identify differences between an existing db and a restored backup from a "before bad stuff happened" time.
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
Viewing 14 posts - 1 through 13 (of 13 total)
You must be logged in to reply to this topic. Login to reply