Re: Standby database question

<kal121_at_my-deja.com> wrote in message news:8r0b2p$nah$1_at_nnrp1.deja.com...
> True or false:
>
> With a standby database you have to be willing to tolerate some data
> loss. Since you are only copying over arch files to the standby box, if
> your primary database goes down in a smoking hole, you will lose the
> data in the online redo logs that never got archived, and therefore,
> never made it to the standby.

true. with the Oracle "hot standby" database, only the archived logs are applied, and if the primary database turns into a huge smokeball, and you fail over to the standby database, then you will lose all of the committed transactions in the online redo logs. so first, and foremost, for a high availability solution, you want to identify and eliminate single points of failure of the primary database, like mirrored disks, multiple controllers, redundant paths, high availability cluster, etc.

> What kind of "HA" solution is this???

good enough for some, but not good enough for everyone.

obviously, each solution varies to the degree with which it meets your requirements for high availability. with a "hot standby" database, you can reduce the potential number of comitted transactions that could be lost in the event of a disaster by increasing the frequency at which the redo logs are switched (and archived).

fortunately, there are other vendors that provide alternative solutions. have you taken a look at the offerings from emc or quest or veritas?

other (more complex) alternatives would be to run two separate, but identical, databases, with the application(s) applying transactions to both databases (keeping them in sync could be a real hassle), or designing the application(s) and database so that there is a separate application log that records transactions, and a recovery mechanism that can replay the transactions from the application log.

just some thoughts.

> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
Received on Thu Sep 28 2000 - 22:08:49 CDT