database replication and standby database

[Chassidy Rentz]

Can a replicated database residing on another server be used as a backup if the primary production database fails? If so, what is the difference between this and using another option such as Oracle Standby database?

[Rita C Workman]

Depends....

If your production failed because somebody 'hosed' something and this condition is mirrored over...then you got a problem.
If your Oracle Standby database is not keeping up with the Primary, then you could have the problem of your control file being out of sync. You might be able to backup, via Oracle, but again that's a 'might be able'. So depends...

I prefer to ensure my data is available by using mirror/split disk technology.
That way I can make a point in time copy and mount that read/only for querrying or use to do my backups from (BCV disks). And then with other disks I can also ensure that my Oracle logs are kept in sync with production, with the rest of Oracle going in adaptive copy, so every couple hours these get updated and split off again to protect them. So if a failure occurs, I can then apply my Oracle logs (that are kept in sync) and bring my database back up. Up to date for production on another server.
And if something had gone terribly wrong, I could restore from my point in time copy disks (those BCV) and go back to then.

Takes a good bit of disks and alot of planning, no matter what you do.

Rgrds,
Rita

[Chassidy Rentz]

Well, I need to come up with a strategy to have a synchronized backup database in place and have all transactions re-routed to it in the event of a planned takedown or an unplanned primary failure. I need the best way to maintain continuous availability. I am wondering if having a replicated database residing on another server can serve as a secondary production database and a utility such as Oracle DataGuard can be used to open the backup database to connections and send transactions on? Is that even feasible?

[Rita C Workman]

Well Chassidy, let's hope some Oracle guru's jump on here to answer those options...cause I'm no Oracle expert.

But for our DR...

.. for failover of our Oracle environment, we went with data replication using SRDF to a remote site. Our DBA's like it and I'm reasonably pleased with it. We keep the production within our Clustered environment (we run Continental Cluster) at our primary site and our BCV copy mounted for large report querries and doing our backups with outside the Cluster at the remote site. That way in a fail over event at our primary, we 'could' bring production up at the remote site (to the failover node within our CC Cluster) and still have our BCV copy running in read only.

EMC and HP both provide great products if you choose to go with this kind of DR method.

Rgrds,
Rita

[Yogeeraj_1]

hi,

Think RAC (Real Application Clusters)

RAC allows you to use more then one computer in a cluster to make sure the failure of a single computer (n-1 computers actually) doesn't bring down the database. By running more then one instance of oracle on different computers -- all accessing the SAME database -- we can increase (greatly) the availability of the system

see also:
http://download-west.oracle.com/docs/cd/B10501_01/rac.920/a96597/toc.htm

hope this helps too!
regards
Yogeeraj

[R. Allan Hicks · Accepted solution]

Yogi is right on that RAC is the best solution, but have your checkbook ready because it ain't cheap.

I was excited about 10g and the transparent way that it is supposed to allow you to cluster servers so that if one fails, the users won't experience any disruption. I talked to the sales guy about upgrading and the RAC was going to cost me around $80K. My boss like to had a stroke over that one.

I've done replication under 8i and it works pretty good. My plan was to use connection manager so that if a machine died, the connection manager would re-route the requests to the surviving machine. The scheme is obviously not automatic but cheap. I became disillusioned with it because it was a pain to keep the databases sync'ed without having some down time to bring the other back on after a failure and there were some issues with keeping the data dictionay sync'ed on all the nodes.

At a meeting in Atlanta that introduced 9i, I asked Tom Kyte himself (If there is an guru to the guru's it's Tom try asktom.oracle.com is an excellent site) and he told me that replication wasn't really designed for a backup scheme.

The silver bullet of the day was Dataguard. Dataguard is a set of tools and some other software that supports the standby database. The basic concept is that one database is always in recovery mode so that as the archive logs become available, they are shipped to the standby database and should the on-line database suffer an unfortunate accident.... The standby database is manually stared as the new on-line or you can simply switch database on a whim. You still need to use LDAP, Name server or change all the tnsnames.ora files to make the clients connect to the new machine. The plus side is that it is cheap (i.e. free with your license).

Another plus to dataguard is that you can delay application of the logs. Why would you want to do that you may ask? Well if you delay the application by say 30 minutes and someone drops a table, you have 30 minutes to stop dataguard. Break the systems back up the dropped table, carry the tape back to the on-line machine and recover the table and be a hero.

So the grid is best. Replication and dataguard are definately cheaper, but harder to manage. I don't see a technical reason that you can run a standby database off of a replicated node.

-Good Luck