Re: recovery strategies for multi-terabyte database

From: Daniel Morgan <damorgan_at_x.washington.edu>
Date: Fri, 13 Aug 2004 18:38:39 -0700
Message-ID: <1092447562.913049@yasure>

Prem K Mehrotra wrote:

> Daniel Morgan <damorgan_at_x.washington.edu> wrote in message news:<1092406609.341901_at_yasure>...
> 

>>Rob De Langhe wrote:
>>
>>
>>>Hi,
>>>
>>>we are interested to know what DBAs have selected as realistic recovery
>>>(and corresponding backup) strategy for a database with multiple
>>>terabytes of data.
>>>
>>>Internet talks everywhere about backup performances, but nowhere the
>>>actual recovery method is discussed for such a large database. Even when
>>>doing online backups, you still need a way to get this huge dbase back
>>>into a consistent mode, or get a set of data backup in the dbase.
>>>
>>>We are using Solaris-9, Oracle 9.2, SAN storage, Veritas Netbackup, and
>>>LTO tape robot.
>>>
>>>TIA for any suggestions
>>>
>>>Rob
>>
>>Get a duplicate storage array likely NetApp, EMC, Hitachi, or IBM and
>>use the snap-mirror capability to mirror changed blocks to the second
>>array. Be sure the duplicate array is at least 500 miles away from
>>the primary and connect them with a T3.
>>
>>Then don't waste your time backing up anything.

> 
> Dan:
> 
> Pardon my ignorance, what happends if something got corrpted, you
> accidently deleted some data/table or for whatever reaosn you have to
> do point in time recovery. How will one accomplish that using 
> snap-mirror type of backups.

Corruption:
Same thing that happens when you have a tape containing corrupt blocks.

Deletion:
Learn about how snap works ... learn about how table flashback works. Implement the appropriate solution.

Point-in-time:
Archive logs

To be truthful I was being a bit flippant. I do believe in backups. But not like I used to. I haven't had to run for a backup tape in more than 5 years. And I don't believe anyone is backing up today's mutli-terabyte databases to tape anymore.

-- 
Daniel A. Morgan
University of Washington
damorgan_at_x.washington.edu
(replace 'x' with 'u' to respond)

Received on Fri Aug 13 2004 - 20:38:39 CDT