Lukewarm standby

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? Received on Fri May 30 2003 - 09:07:30 CDT