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»»

Recovery Expand / Collapse
Author
Message
Posted Sunday, September 28, 2008 10:21 PM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Monday, July 28, 2008 8:36 PM
Points: 11, Visits: 41
Comments posted to this topic are about the item Recovery

Graham Okely B App Sc
Senior Database Administrator
Post #577517
Posted Monday, September 29, 2008 1:23 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Thursday, May 8, 2014 10:08 PM
Points: 358, Visits: 397
Very good use of narrative style storytelling. Fun to read after dry just-the-facts-ma'am articles.

One lesson the author learned that IMO needs a stronger emphasis: before INSERT (or any other operation) on a live table, check the structure, FK's and PK's. Then the Identity column (or other constraints) won't suprise you.

It's also a good idea to use explicit transactions and don't commit them until it looks good when restoring individual rows in this manner to production.
Post #577553
Posted Monday, September 29, 2008 4:27 AM


UDP Broadcaster

UDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP Broadcaster

Group: General Forum Members
Last Login: Monday, July 21, 2014 8:43 AM
Points: 1,434, Visits: 721
I've had to do something similar myself on our intranet database. One of the webteam ran a procedure that completely screwed up our forums, but because the database is also used to store personnel information I couldn't do a blanket restore of the DB. Restoring it spearately then allowed me to just recover those tables that had been corrupted (and a stern talking to the webteam to test their procedures before running them on the production system!)
Post #577611
Posted Monday, September 29, 2008 5:15 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, December 15, 2008 1:48 AM
Points: 3, Visits: 42
I found this article for absolute beginners. Is this really Senior DBA?
Post #577630
Posted Monday, September 29, 2008 5:25 AM


UDP Broadcaster

UDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP Broadcaster

Group: General Forum Members
Last Login: Monday, July 21, 2014 8:43 AM
Points: 1,434, Visits: 721
ABCDEF (9/29/2008)
I found this article for absolute beginners. Is this really Senior DBA?


I'd disagree. It doesn't sound like rocket science granted, but sometimes the most simple of solutions can be overlooked, particularly in the heat of the moment when you know you need to restore lost or corrupt data.

Keeping a level head, examing all the available options, and not making rash decisions are characteristics you would expect from a senior dba.
Post #577631
Posted Monday, September 29, 2008 5:51 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Monday, August 25, 2014 10:41 PM
Points: 480, Visits: 454
This isn't something uncommon, I'd be surprised if you could find a DBA that hasn't had to restore bits of data people have deleted. Possible ways to speed up the process might be more interesting reading for an article.

A few ways we recover data quickly when we need to ...

We run log shipping on our servers so there is usually a 5-15 minute lag between copying data between servers, if one of the DBAs delete some data by accident (rare but has happened before) you can grab it off the log shipping server before the transaction is played there. In theory if someone else in the business deleted data you could do this too but they would have to call pretty quick.

Another way we have of quickly restoring data is that we run a 24 hour old version of the database, each night we backup to various locations and then restore that data to a seperate server which is sometimes used for testing or running certain reports. If something is removed in the last day we can usually recover it from here.

Last option is going back to backups and every DBAs best friend is Litespeed or one of the other compressed backup solutions. Once our databases got past 50gb we found the possible downtime wasn't acceptable to the business (it took about 6 hours to get things back up and running) and now even 100gb databases can be restored in about an hour once you factor in copying it from remote servers etc

Another option is delete triggers, our ERP system uses them for auditing which can be handy from time to time but we haven't tried it on any of the other systems.




Post #577643
Posted Monday, September 29, 2008 6:28 AM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Friday, August 22, 2014 2:06 PM
Points: 198, Visits: 1,129
There are also products that allow for object-level recovery without restoring the database too. We use LiteSpeed and I've tested that functionality and it works fine.
Post #577659
Posted Monday, September 29, 2008 8:26 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 7:21 AM
Points: 2,477, Visits: 1,339
ABCDEF (9/29/2008)
I found this article for absolute beginners. Is this really Senior DBA?


What's wrong with that? This forum should be open to SQL Server DBA's at every level. This is the best way for someone to learn.

I thought that it was a good step by step guide on how to accomplish this common task.
Post #577746
Posted Monday, September 29, 2008 2:45 PM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 10:30 AM
Points: 2,607, Visits: 17,928
You also need to watch foreign keys for other related tables. In this case it sounds like there were no interrelationships. But if data were deleted from a parent table, and then a child table, you would need to track and maintain the primary key on the parent during the "restore" insert so that you could correctly link up the child back to the parent's primary key. In that case, it would be easier to turn the IDENTITY_INSERT ON so that the records would flow smoothly back into the database from the backup copy, maintaining their key values. Another case where IDENTITY_INSERT might be a preferred solution is if the end user knew the primary key values and referenced them (like an account number). In that case, it would also be important to preserve the original key values.

Chad
Post #577999
Posted Monday, September 29, 2008 2:54 PM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Thursday, April 9, 2009 2:25 PM
Points: 22, Visits: 11
Another solution is third party tools. I haven't tested this but we just got Red Gate's SQL Backup Pro (moved away from Litespeed) and SQL Data Compare Pro. SQL Data Compare Pro can use SQL Backup Pro backups as a source for doing comparisons and synchronizations with live databases - then it scripts the changes and you run it against the live database. I'm hoping that'll save me some time in the future when situations like this come up.
Post #578004
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse