Duplicate vs Standby -- What To Do Without Data Guard
WHAT WE HAVE
Three 10.2.0.3.0 databases in production on the same Linux x86 server (Red Hat OS). An identical Linux x86 server (with same OS) is available for housing a corresponding backup instance (either duplicate or physical standby).
THE ASSIGNMENT
Develop a plan that, in the event of a loss of our prod server, provides the shortest time before substitute databases are up and running on the backup server. WE CANNOT USE DATA GUARD (due to server licensing issues). It isn't necessarily a high priority to apply archive logs to duplicates or standbys on a regular basis, but I realize the more up-to-date a backup database is, the less recovery time would be needed if and when it's pressed into service. (BTW: We take weekly incremental level 0 and daily incremental level 1 backups of our prod databases with RMAN and keep them for 28 days.)
QUESTIONS
1. Does our 'no Data Guard' rule eliminate using standbys - even if I could use OS processes to transfer archive logs between servers and manually apply redo? (I'm not quite sure what exactly constitutes Data Guard.)
2. If I'm allowed to create standbys, I'll create them using RMAN. Since the scenario being planned for is a loss of the production server, I figure I'm worried about failover and not switchover. Thus, once standbys are created, in addition to manually transferring and applying archives and creating redo files for them, what other action(s) would I need to take before they could be activated, if that's ever needed? Would the redo files I would have to create be of type STANDBY or ONLINE?
3. Can a standby be opened in read/write mode without being activated?
4. If I can only use duplicates and if the production server were to go down one day, could the most recent valid RMAN backup(s) for the prod databases be used in recovering the duplicates?
I'd prefer the backup instances have the SAME SID (db_name) as the corresponding one in prod, if possible.
Thanks.