Standby: Managed or Automatic?
ITAPORT06
I did setup a Standby database envirnoment and found out (that for
several reason which I still have to reasearch) that not all archive
loggings where send to the the Standby server.
The Standby server didnot apply the missing loggings which I shipped
over manually. Server was in Managred mode.
I shut down the server and brought the server back in Automatic mode:
RECOVER AUTOMATIC STANDBY DATABASE
All manual shipped loggings were applied succesfully.
Mine question is:
Is it not handier to make use of the Automatic option instead of the
managed?
The loggings wil be shipped by the NET8 configuration and if
something will go wrong then there will be a synchronisation job
running which willl ship the logs that failed to be shipped earlier
by NET8 (This can happen because of a network errors etc etc)
A scheduled job on the standby server will apply the logs by
activating the Recover Automatic standby option every X minutes
The reason why I want to use this method is:
We do not have the resources to check the oracle servers frequently
if all loggings have been shipped to the standby server. If one of the
logs does not have been shipped then we will find this out much later.
I try to prevent this by adding also the synchonisation job and
making use of the Automatic option.
My questions:
1) Is this method ok or do you think it is still beter to go for the "
managed " method. Take as fact that we can not check the server
frequently for missing shipped logs and that we have network problems
now and then.
2) What are the real pro's for making use of the Managed method.
Thanks
bandar
Standby using Oracle 8 is pretty much working with scripts and you
have to check your logs frequently independently of how you configure
it.
I would try an upgrade to Oracle 9i with the Dataguard solution, that
could handle it a little better but you would still need to check your
logs frequently. Dataguard doesn't work with the Standard Edition, you
would need to upgrade to Enterprise ($$) if you are not already on it.
Alternatively think about third party products. I know that a prodcut
called "DBShadow" is handling log shipping very well.
Good Luck.
Joel Garry
You have to check _more_ if you are using your own scripts. You are
basically reinventing the wheel. Granted, the wheel has bugs, but you
have to deal with even more with your reinvention. What do you do
when Oracle starts multiple archivers writing multiple files?
If you are bothering to write a script, why not write one to check
that things are working and notify if not?
> >
> > My questions:
> >
> > 1) Is this method ok or do you think it is still beter to go for the "
> > managed " method. Take as fact that we can not check the server
> > frequently for missing shipped logs and that we have network problems
> > now and then.
Yes, I grant the network problems, but I have real problems with not
checking.
I agree that the 8i method of dealing with network problems is
inherently flawed. One way to deal is to allow lots of log (and
perhaps local arc destinations) to give time to deal with the
problems.
> >
> >
> > 2) What are the real pro's for making use of the Managed method.
> >
> > Thanks
>
>
> Standby using Oracle 8 is pretty much working with scripts and you
> have to check your logs frequently independently of how you configure
> it.
??? He's using 8i.
>
> I would try an upgrade to Oracle 9i with the Dataguard solution, that
> could handle it a little better but you would still need to check your
> logs frequently. Dataguard doesn't work with the Standard Edition, you
> would need to upgrade to Enterprise ($$) if you are not already on it.
Agreed.
>
> Alternatively think about third party products. I know that a prodcut
> called "DBShadow" is handling log shipping very well.
>
> Good Luck.
jg
--
@home.com is bogus.
http://www.b949fm.com/home/index.cfm
Joel Garry
I'm going to disavow my previous post. Since there is no way to
prevent the managed recovery standby from affecting the production
instance in 8i, bottom-line, that is unacceptable. With your own
scripts, you can completely disconnect the standby from the
production.
As it is, the archiver writes 1M chunks to each of the destinations in
a round-robin fashion, and waits for all to be completed before saying
the archiving is finished. There are several circumstances involving
the network or standby hardware that can cause the production archiver
to think it is never done. This can stall the production db, or in
extreme cases, require a resetlogs.
I have personally had two of these circumstances in two months, which
is two too many.
9i is somewhat better, but still not there. There are additional
parameters to deal with these issues, but they don't necessarily work
in earlier versions. Support tells me there is an underscore
parameter in 9.2.0.5 (!) and feature in 10g that allows keeping
archives locally for subsequent shipment to the standby.
Yep, every year. http://www.detnews.com/2001/livingston/0101/07/e05-172555.htm