Re: Lukewarm standby

Matthew.Riggsby_at_novainfo.com (Matt Riggsby) wrote in message news:<397b5de2.0305300607.561601b_at_posting.google.com>...
> What we've got is a database running under 8.1.7 with around 35 to 40
> gigs of data to back up (mostly useful but non-critical historical
> data), adding about 50 mb a day. What we want is a "lukewarm"
> standby, a fairly-but-not-entirely up-to-date copy of the database on
> a different machine which we can bring up to date fairly quickly and
> move into place fairly quickly should the primary server blow up. We
> already have a copy of the primary database on another server which is
> being maintained by a clumsy process of periodically exporting data
> from the main and importing it into the standby, but we're looking for
> something a little more elegant. On consultation with a software
> vendor (the database underlies a third party application), it appears
> that clustering is not an option. We'd like to approach 24x7 but are
> very willing to sacrifice down-time in the event of a disaster for
> ease of administration, so we haven't looked very hard at replication
> (which may not be an option anyway; the vendor hasn't been entirely
> clear on that point).
>
> After a few passes through the backup and recovery manual and the RMAN
> docs, the tenatative plan is this:
>
> Put our primary database into archivelog mode
> Multiplex everything (control files and both archived and online redo
> logs) to a few different physical disks
> Use RMAN to make a full backup of the primary database
> "Restore" the database onto the standby server
> Periodically apply the archived redo logs to the standby server
>
> If the primary server catches fire, we can use the remaining redo logs
> to bring the standby up to speed relatively quickly and slap it into
> service.
>
> So, then, is there anything *profoundly* wrong with this scenario?
> Should we, for example, be doing something with incremental backups
> instead of large numbers of archived redo logs?

The notes on metalink explaining standby db's are very useful.

Note:100698.1 on metalink, about Transportable tablespaces, is very interesting.

Depending on the details, if you can put the historical data into read-only tablespaces, you might speed up backups, too.

jg

--
@home.com is bogus.
http://www.signonsandiego.com/news/business/20030530-9999_1b30peregrin.html