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?

Ø 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?

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.)

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.

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.

Ø 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

                                                 ii.      We can then drop

                                                iii.      Transport and

                                               iv.      Rebuild replication.

> 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
> adary_at_mehish.co.il
>
> > -----Original Message-----
> > From: Peter Barnett [SMTP:regdba_at_yahoo.com]
> > 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
> > pnbarne_at_regence.com
> >
> > __________________________________________________
> > 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: regdba_at_yahoo.com
> >
> > 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: ListGuru_at_fatcity.com (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: adary_at_mehish.co.il
>
> 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: ListGuru_at_fatcity.com (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: rvd_oracle_at_hotmail.com

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: ListGuru_at_fatcity.com (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).