Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

How to Rollback an entire database? Expand / Collapse
Author
Message
Posted Friday, October 15, 2010 1:28 PM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Monday, September 19, 2011 11:54 PM
Points: 53, Visits: 134
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
Post #1005532
Posted Friday, October 15, 2010 1:35 PM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Friday, June 27, 2014 12:43 PM
Points: 13,872, Visits: 9,596
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
Post #1005536
Posted Friday, October 15, 2010 1:47 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 12:34 PM
Points: 31,181, Visits: 15,626
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?






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1005541
Posted Friday, October 15, 2010 1:57 PM


Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Tuesday, January 28, 2014 8:15 AM
Points: 3,065, Visits: 4,639
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.
Post #1005558
Posted Friday, October 15, 2010 2:00 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 12:34 PM
Points: 31,181, Visits: 15,626
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.






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1005563
Posted Friday, October 15, 2010 2:32 PM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Yesterday @ 11:18 AM
Points: 985, Visits: 1,829
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.
Post #1005589
Posted Friday, October 15, 2010 2:41 PM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Yesterday @ 5:12 PM
Points: 860, Visits: 1,116
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.

Post #1005594
Posted Friday, October 15, 2010 2:52 PM


Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Tuesday, January 28, 2014 8:15 AM
Points: 3,065, Visits: 4,639
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.
Post #1005596
Posted Friday, October 15, 2010 4:25 PM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Yesterday @ 11:18 AM
Points: 985, Visits: 1,829
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?
Post #1005625
Posted Friday, October 15, 2010 4:40 PM


Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Tuesday, January 28, 2014 8:15 AM
Points: 3,065, Visits: 4,639
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.
Post #1005631
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse