Backup Isn't Enough

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » SQLServerCentral.com » Editorials » Backup Isn't Enough

Backup Isn't Enough

Rate Topic

Display Mode

Topic Options

Author

Message

Steve Jones - SSC Editor

Posted Saturday, July 17, 2010 11:48 AM

SSC-Dedicated

Group: Administrators
Last Login: Today @ 9:00 AM
Points: 31,410, Visits: 13,728

Comments posted to this topic are about the item Backup Isn't Enough

Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help

Post #954411

george sibbald

Posted Sunday, July 18, 2010 2:52 PM

SSCertifiable

Group: General Forum Members
Last Login: Today @ 7:24 AM
Points: 5,267, Visits: 11,198

good point.

Garbage in, garbage out OR garbage backed up garbage recovered

also the ability to build a delay into log shipping is an oft forgotten advantage of this old workhorse HA method over the fancier and therefore presumed better in all aspects mirroring and clustering

---------------------------------------------------------------------

Post #954546

Cyclone

Posted Monday, July 19, 2010 3:06 AM

SSC Rookie

Group: General Forum Members
Last Login: Friday, May 03, 2013 3:40 AM
Points: 42, Visits: 225

Hi ....

In our datawarehouse environment we have added the fields ExtractDate, LatestEntryIndicator, EntryStartDate, and EntryEndDate to all dimension and fact tables. Using these fields we are able to rollback the data to a specific point in time, removing any suspect data that may have been loaded into the warehouse. We carry out daily differential and monthly full backups of the datawarehouse databases.

The backups are essentially to cater for a server related failure whereas the rollback process is in order to cater for a recovery from suspect data.

This strategy seems like it would be able to recover the database to a reliable state in the event of either type of "catastrophe".

Cheers.

Post #954654

jay-h

Posted Monday, July 19, 2010 7:07 AM

Say Hey Kid

Group: General Forum Members
Last Login: Yesterday @ 8:55 AM
Points: 685, Visits: 1,707

The ability to selectively recover from bad data input should really be part of the initial database design. It's not enough to have 'point in time" because substantial transactions may have occurred in the interim before discovery. You really can't afford to manually review multiple thousands of entries. Transactions need to be fully indentified and preserved (in an append only table, for example). This involves careful planning with the business rules.

It's expensive in development time, but if there is a potential need it is worth it.

...

-- FORTRAN manual for Xerox Computers --

Post #954792

SQLRNNR

Posted Tuesday, July 20, 2010 10:19 AM

SSCoach

Group: General Forum Members
Last Login: Yesterday @ 1:07 PM
Points: 18,733, Visits: 12,332

I hate those "garbage" sources. It is quite difficult to trust any data in the database when the source of the data is known to be suspect.

Jason AKA CirqueDeSQLeil
I have given a name to my pain...
MCM SQL Server 2008

SQL RNNR

Posting Performance Based Questions - Gail Shaw
Posting Data Etiquette - Jeff Moden
Hidden RBAR - Jeff Moden
VLFs and the Tran Log - Kimberly Tripp

Post #955733

« Prev Topic | Next Topic »

Permissions