RE: Cascading Physical Standbys?
Date: Tue, 18 Nov 2014 13:16:40 -0500
Message-ID: <00c301d0035b$cdccc240$696646c0$_at_rsiz.com>
This could be useful, for example, if standby #1 is local campus active dataguard (or cloned) on a separate machine with a second network so the work of forwarding the archived redologs is up to the (possibly remote) standby machine for all of storage, network consumption, and cpu cycles.
That could give you near real time currency locally and consume less production cpu and network bandwidth on the machine(s) hosting the primary.
I’d say different things can go wrong rather than more things that can break.
I have never measured the cpu and network cost of multiple arch_dest definitions, and of course that would vary according to both your exact load and your exact hardware. Whether or not license cost is an issue will vary by topology and contract, but often it is not cost effective to burn fully licensed cpu when other cpus could be doing the work, and especially if the extra network bandwidth consumed burns production cpu cycles due to spin waits.
Without a detailed knowledge of service level requirement for the primary, reporting for the first standby, and recoverability overall it is impossible to know whether this topology would be good for a given customer.
It sounds as if your data center has many customers. Whether internal or external, there is a non-zero value to having everyone do things the same way. Of course that is subject to still meeting service level requirements, off-loaded reporting requirements, and recoverability requirements.
Good luck!
mwf
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Dba DBA
Sent: Tuesday, November 18, 2014 11:42 AM
To: ORACLE-L
Subject: Cascading Physical Standbys?
I am not sure what the official term is. Its when you have
Primary -> Standby -> Standby
DB Version 11g and up.
I work in a large data center. I was talking to another DBA and one of her customers is doing this. I asked her why we would do this intead of just using 'multiple arch_dest' locations then write the archive logs to separe LUNs that under the surface map to separate RAID Groups. Little more work up front for storage, but when its done its done.
I see a cascading DB as more stuff that can break. The rationale I got is that
Standby #1 is for report and that Standby #2 is for DR. However, if standby #2 is not current, then standby #3 is current.
Anyone ever set this up before? I am just looking for rationals for doing this. I am likely missing something.
-- http://www.freelists.org/webpage/oracle-lReceived on Tue Nov 18 2014 - 19:16:40 CET