Recovery

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » Article Discussions » Article Discussions by Author » Discuss content posted by Graham Okely » Recovery

16 posts, Page 1 of 2

1 2 »»

Recovery

Rate Topic

Display Mode

Topic Options

Author

Message

GrahamO-735217

Posted Sunday, September 28, 2008 10:21 PM

Grasshopper

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

magarity kerns

Posted Monday, September 29, 2008 1:23 AM

Old Hand

Group: General Forum Members
Last Login: Monday, May 13, 2013 10:22 PM
Points: 358, Visits: 393

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

SQLPhil

Posted Monday, September 29, 2008 4:27 AM

Ten Centuries

Group: General Forum Members
Last Login: Thursday, May 16, 2013 12:28 AM
Points: 1,413, Visits: 659

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

ABCDEF-848380

Posted Monday, September 29, 2008 5:15 AM

Forum 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

SQLPhil

Posted Monday, September 29, 2008 5:25 AM

Ten Centuries

Group: General Forum Members
Last Login: Thursday, May 16, 2013 12:28 AM
Points: 1,413, Visits: 659

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

dougjjj

Posted Monday, September 29, 2008 5:51 AM

SSC-Addicted

Group: General Forum Members
Last Login: 2 days ago @ 7:51 PM
Points: 446, Visits: 353

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

Chuck Hottle

Posted Monday, September 29, 2008 6:28 AM

SSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, May 07, 2013 2:39 PM
Points: 197, Visits: 1,065

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

William Vach

Posted Monday, September 29, 2008 8:26 AM

SSCrazy

Group: General Forum Members
Last Login: Today @ 6:49 AM
Points: 2,111, Visits: 1,070

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

Chad Crawford

Posted Monday, September 29, 2008 2:45 PM

SSCrazy

Group: General Forum Members
Last Login: Today @ 4:17 PM
Points: 2,548, Visits: 17,356

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

Andy Ognenoff

Posted Monday, September 29, 2008 2:54 PM

Grasshopper

Group: General Forum Members
Last Login: Thursday, April 09, 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 »

16 posts, Page 1 of 2

1 2 »»

Permissions