I will write my comments in your response. Scroll down.

One point I would like to stress:
We are planing to drop replication and work with the live DB in case one DB
goes down.
In this case we will work for some days without replication until we rebuild
the dba machine
and then do an export/import from the live DB to the new one and rebuild the
replication again.
See my comments bellow.



Yechiel Adar, Mehish Computer Services
[EMAIL PROTECTED]

> -----Original Message-----
> From: Rahul Dandekar [SMTP:[EMAIL PROTECTED]]
> Sent: Mon, February 18, 2002 7:03 PM
> To:   Multiple recipients of list ORACLE-L
> Subject:      Re: Oracle Advanced Replication
> 
> Adar,
> 
> How do you take care of backups?
> I mean, what kind of backups do you take? How are you addressing the
> scenario of incomplete recovery?
> Following are some of my doubts.....
> 
> 1.      What kind of Backup should be taken? Online or Offline? Does
> replication would generate substantially higher redo?
        [ADAR]  >  We do online backups using Veritas backupexec + some
exports at key points. 

> Ø      Lets analyze the possibility of Online Backups :
> 
> q       Redo Generation
> Apparently, a database in replicated environment would generate
> significantly more redo if the same database was not in replicated
> environment. Is there sufficient bandwidth (diskspace, tapes) for the
> additional redo?
> 
        [ADAR]   We are doing synchronous replication (2 phase commit). In
this case oracle use
                      a trigger to update the backup DB without writing
anything to the redo log.
                      The redo log will inflate in case of asynchronous
replication because of the updates
                      to the replication tables.

> q       Need for Complete Recovery
> If we need to recover one of the databases then it should be complete
> recovery. Incomplete recovery will not be permissible since the databases
> are in replicated environment. (Lets not consider 'All' the databases
> restored from their backups till a certain SCN.)
> 
        [ADAR]  We are doing full backup just in case of both system
failure. If one system fails
                      we continue to work with the other and synchronize
later.

> q       Quick Recovery
> Also, the recovery must be done quickly. This is because as one of the
> databases in replicated environment is down, the DEFTRAN queues in other
> master sites would start getting larger and larger and it might reach to a
> stage where we would also need to do the 'Offline Instantiation' for
> replicated objects.
        [ADAR]  We are not planing it this way. For NOW we plan on dropping
the replication
                     and building the bad DB from scratch, using export from
the live DB and building 
                     the replication again.
                     Our system is dealing room and we have each Sunday
available as the dealers
                     around the world have a day off.
                     So if one computer is down we will not have replication
until next Sunday. This also
                     gives us time to fix the computer and build a new DB
without pressure.

> q       When complete ercovery is not possible....
> In case complete recovery is not possible then we need to recover the
> databases and then perform 'Offline Instantiation' for replicated objects.
        [ADAR]  That's the beauty of our plan. You do not need recovery at
all. Just use the live DB
                      as a source to recreate the bad DB again.

> Ø      What if we take Offline Backups :
> 
> q       For a simple recovery, entire database needs to be restored from
> the
> cold backup.
> 
> q       'Offline Instantiation' needs to be performed each time media
> recovery is performed. This is because media recovery would always bring
> the
> database till the time of cold backup and other master sites would be
> ahead
> in time.
>
> q       In case datafiles affecting 'only' those tablespaces which have
> objects which are replicated are needing recovery then recovery can be
> done
> by using transportable tablespaces feature.
> 
>                                                    i.      First, we would
> need to drop those tablespaces from the database.
> 
>                                                  ii.      We can then drop
> replication for this master group.
> 
>                                                 iii.      Transport and
> Plug-in the tablespace's datafile from other master site.
> 
>                                                iv.      Rebuild
> replication.
> 
> TIA,
> 
> +Rahul
> 
> 
> ----- Original Message -----
> To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
> Sent: Sunday, February 17, 2002 11:18 AM
> 
> 
> > Hello Peter
> >
> > We implemented Advance Replication as part of dealing room.
> > We defined master to master real-time replication.
> > Synchronous, 2 phase commit, from the primary to the backup DB as each
> deal
> > is a
> > lot of money and standby database will not reflect updates since the
> last
> > log file was archived.
> > Since we need master to master we defined the replication from the
> backup
> DB
> > to the primary as asynchronous even though no body is using the backup
> DB.
> >
> > I think that the cases are similar.
> >
> > Points to take care off:
> >
> > 1) Prepare a script to drop the replication on each machine if the other
> > machine fails.
> >     Lets say that you got a CPU fault on the primary and you switch to
> the
> > backup.
> >     In this case you might get off with the asynchronous replication as
> > updates will
> >     accumulate in the backup machine until the CPU is replaced. When the
> > primary
> >     will come up the replication will update the primary DB with all the
> > changes.
> >     Now, if the disk drive fails on the primary you will probably have
> to
> > rebuild the
> >     DB from scratch (or from export from the backup). In this case there
> is
> > no point
> >     to accumulate updates in the backup machine.
> >    Also, if the backup machine fails you do not want the updates to the
> > primary to
> >     fail. In this case you drop replication and go on working.
> >
> > 2) Ensure that the log files, rollback segments, datafiles (size) and
> all
> > init ora are the
> >     same on both machines. You do not want to swap to the backup only to
> > find that
> >     the parameters are ok for one connection (replication) but fails
> when
> > working as
> >     a primary DB.
> >
> > 3) Hey, what happens if the air condition stopped working and ALL the
> > machines heats
> >     up and stopped working. Both machine will fail.
> >    Worse if that room gets on fire you are out of luck.
> >    Move the backup machine at least a couple of rooms away.
> >
> > 4) Use stand by database in another building so in case of a serious
> problem
> > (11 seqptember)
> >     you will not lose all your data, only the data since the last
> archive.
> >
> > 5) Test, Test, Test again all failure scenarios, and test again each
> month,
> > quarter or whatever.
> >
> >
> > Yechiel Adar, Mehish Computer Services
> > [EMAIL PROTECTED]
> >
> > > -----Original Message-----
> > > From: Peter Barnett [SMTP:[EMAIL PROTECTED]]
> > > Sent: Fri, February 15, 2002 1:04 AM
> > > To: Multiple recipients of list ORACLE-L
> > > Subject: Oracle Advanced Replication
> > >
> > > We are looking at Advanced Replication as a fail over
> > > option for a web site.  Straight forward installation,
> > > both boxes on the same subnet on their own dmz. The
> > > servers will be located on the same rack in the
> > > computer room. Very few tables storing data from an
> > > application that is tracking click through data.
> > >
> > > Does anyone see any flaws with the basic plan?  Any
> > > hidden 'features' that we may run into?
> > >
> > > Thanks
> > >
> > >
> > >
> > > =====
> > > Pete Barnett
> > > Lead Database Administrator
> > > The Regence Group
> > > [EMAIL PROTECTED]
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Send FREE Valentine eCards with Yahoo! Greetings!
> > > http://greetings.yahoo.com
> > > --
> > > Please see the official ORACLE-L FAQ: http://www.orafaq.com
> > > --
> > > Author: Peter Barnett
> > >   INET: [EMAIL PROTECTED]
> > >
> > > Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
> > > San Diego, California        -- Public Internet access / Mailing Lists
> > > --------------------------------------------------------------------
> > > To REMOVE yourself from this mailing list, send an E-Mail message
> > > to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
> > > the message BODY, include a line containing: UNSUB ORACLE-L
> > > (or the name of mailing list you want to be removed from).  You may
> > > also send the HELP command for other information (like subscribing).
> > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> > >  This e-mail was scanned by the eSafe Mail Gateway
> > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> >
> > --
> > Please see the official ORACLE-L FAQ: http://www.orafaq.com
> > --
> > Author: =?iso-8859-8?Q?=E0=E3=F8_=E9=E7=E9=E0=EC?=
> >   INET: [EMAIL PROTECTED]
> >
> > Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
> > San Diego, California        -- Public Internet access / Mailing Lists
> > --------------------------------------------------------------------
> > To REMOVE yourself from this mailing list, send an E-Mail message
> > to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
> > the message BODY, include a line containing: UNSUB ORACLE-L
> > (or the name of mailing list you want to be removed from).  You may
> > also send the HELP command for other information (like subscribing).
> >
> -- 
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> -- 
> Author: Rahul Dandekar
>   INET: [EMAIL PROTECTED]
> 
> Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
> San Diego, California        -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from).  You may
> also send the HELP command for other information (like subscribing).
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>  This e-mail was scanned by the eSafe Mail Gateway 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: =?iso-8859-8?Q?&alef;&dalet;&resh;_&yod;&het;&yod;&alef;&lamed;?  INET: [EMAIL PROTECTED]

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

Reply via email to