Jeremiah,
Thanks for the info. It's nice not to be an idiot! ;-)
...and so much easier to copy up-to-date datafiles from the Standby than to
restore from tape backup in the event of a disk failure on the Primary.
We'll use our Standby only in the event of a failure more catastrophic than
a dis
Actually, even something like Hp's ServiceGuard is not so
graceful, depending on the app using the database. I have
had a database fail and know one know and a different
database fail and everyone know. You really have to take into
account with the app that it might lose connection. You need
t
--- Jeremiah Wilton <[EMAIL PROTECTED]> wrote:
>
> If you perform graceful failover, A.K.A. role reversal, you can have
> the former primary pick up as the standby immediately after failover
> without recopying. I cover this topic in my Openworld paper on my
> site.
>
the problem is, you us
There is no problem with using the standby as a source of good files
in the event a file on the primary becomes media corrupt. Once
stopped, you can use a standby just like a good backup of the
database. The primary will not reject the file. This is particularly
useful for single tablespace com
Errr...what's the point in having a standby database then? If you have a
media failure then you fail over to your standby database, and your up.
Once the standby database comes up then you will have to rebuild the old
primary database from the old standby anyway, since you now have all these
new
The first thing that comes to mind is the datafile header.
I'm too lazy too look it up myself ( ;) ), but you might want
to consider header data that would cause the primary
db to reject the file.
Jared
Hi Jack,
I don't think that you really want to use the online redo logs in this
scenario.
The problem is that the SCN at the exact time of failure may be
different on the Standby and therefore the Primary DB's Control File will
not be
"correct" for the given Datafiles being copied over from the
