Followup: Cascaded standby vs non-cascaded standby configuration:
This is just a followup to let the list know that we chose a Cascaded
configuration and implemented it in Production Saturday evening.
So far, all is well. Ran into one bug that seems to be specific
to
10.1.0.3 -- if the Standby Redo Logs in the physical standby have
more than one log member, the alert log will report ORA-00322 and
ORA-00312. The solution was simply to re-create the Standby Redo
Logs with a single member. It will be some weeks before reporting
users get migrated over so, at the moment, our new logical standby
database is just running along happily hoovering in the archived
logs. 10g Data Guard is a wonderful thing.
Regards,
Mark Strickland
Next Online Technologies
Seattle, WA
On 6/2/06, Mark Strickland <strickland.mark@gmail.com> wrote:
Thank you for the responses: Yes, we've considered the impact if
the physical standby is out of commission for an extended time.
The end-users can live without their reporting database for a
day. Mission-critical reporting is going to stay on the
primary. I'm looking for a best practice if there is one and, if
anyone has actually implemented a cascaded configuration, have there
been any gotchas.
Mark
well yes that's what I implied, ab it useless for reporting purposes if you dont have all the data to report on.
On 02/06/06, Ghassan Salem <salem.ghassan@gmail.com
> wrote:
David,
the log stdby will still be available, but not updated, until the physical one resumes sending it's redologs.