RE: Cascading Physical Standbys?
- From: "Mark W. Farnham" <mwf@xxxxxxxx>
- To: <oracledbaquestions@xxxxxxxxx>, "'ORACLE-L'" <oracle-l@xxxxxxxxxxxxx>
- Date: Tue, 18 Nov 2014 13:16:40 -0500
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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] 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.
Other related posts:
