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