Re: Standby database issue

hi,

if i have the enterprise edition of oracle, i would't use a standby database.
i would use multimaster replication.
(synchron or asynchron, this depends on the needs) the problem of a standby-db is, once used you cannot put back the db to a standby-db.

so long
frank

btw: the license-costs of the enterprise edition are much more higher then the "normal" server edition. That's why we developed an own replication mechanism (synchronous, without blocking the main db if the standby-db is unavailable).

"Sybrand Bakker" <postbus_at_sybrandb.demon.nl> schrieb im Newsbeitrag news:tev4hjeqblnc1b_at_beta-news.demon.nl...
>
> "ff" <cfs3526_at_ureach.com> wrote in message
> news:WhKH6.7841$Aj1.3878670_at_typhoon2.ba-dsg.net...
> > We have a standby databse, and we use a in house developed perl script
 to
> > copy the redologs from the remote production database.
> > The way we do is we use 'ls -l' to detect the redolog file, as soon as
 we
> > see it, wait for 30 seconds, and then we copy it over. Most of time it
> > worked, but sometimes, the copy begins before the production finish
 writing
> > to the redo, and we got corrupted file.
> > Is there any way we can monitor the finish of the redologs and begin to
 copy
> > only after the writing of redologs have finished?
> >
> > Thanks for your help.
> >
> > PS: Could some body show me your script for manually copy your redo
 logfile
> > to remote standby database?
> >
> > Thanks.
> >
> >
> >
> >
> Is the standard edition or the enterprise edition of Oracle.
> If it is the latter, please use the hot standby database feature of
 Oracle,
> and don't develop your own procedures, which are bound to fail.
> Copying of redolog files in an Oracle standby database is *fully*
 automatic,
> and you don't have to bother about it.
> I have seen one implementation of a manual standby database as you have,
 and
> the verdict of a colleague consultant and myself was it was too shaky and
> risky. It has been replaced by a true standby database since.
>
> Hth,
>
> Sybrand Bakker, Oracle DBA
>
>
>
Received on Wed May 02 2001 - 17:08:00 CDT