RE: Disaster Recovery options

Ellis,
IMHO, Logical Standby isn't very usefull for DR. There are quite some glitches, and it is hard to keep the standby running. I was told by a DBA that he was resuming the standby almost every hour, circumventing unsupported SQL by manually reinstatiating single objects and skipping the illegal transactions.

Furthermore, consider the extra load of supplemental logging, and the lack of scalability. When the RAC is pushed to its limits, the standby cannot keep up.

Logical Standby can be usefull for off-loading reports, but not for DR. If you need both a report server and DR, consider running two standby's, one logical and one physical.

Best regards, Carel-Jan

Best regards,

Carel-Jan Engel

===
If you think education is expensive, try ignorance. (Derek Bok) ===

On Tue, 2005-03-22 at 16:28, Ellis R. Miller wrote:

> Brian,
>
> If you use Oracle Data Guard to set up a logical standby database (10G)
> where SQL from primary node is applied to secondary and the primary is an
> OLTP application then the secondary can/should be used for reporting.
>
> Thus, where the pricing becomes more reasonable is in using the Data Guard
> architecture to ensure HA (failover) AND for a reporting architecture in
> which the primary node isn't getting pounded by long-running reports whilst
> high-concurrency transactional processing is occurring.
>
> Generally, this pricing would be justifiable as from the standpoint of HA it
> is 24x7 high-concurrency, business critical OLTP applications that can
> afford the least amount of downtime, of course, and also require a separate
> reporting server. (I realize that many real-life environments like bringing
> the hardware to its knees by running resource-intensive reports or even
> batch processing even as millions of banking transactions are being
> processed and jeopardized but...)
>
> Data Guard is infinitely improved over the former standby database
> architecture especially with regard to administration via OEM, instantiation
> without downtime, and, again, reporting.
>
> A couple good references:
>
> http://www.oracle.com/technology/deploy/availability/htdocs/DataGuardRedoShi
> pping.htm
>
> http://www.oracle.com/technology/deploy/availability/htdocs/DataGuardOvervie
> w.html
>
> Hope that helps, some, and I am not sure Data Guard would be justified in
> your case or not but the reporting architecture, when considered with the HA
> advantages, does make the cost justification reasonable.
>
> Ellis
>

--
http://www.freelists.org/webpage/oracle-l