Actually, the redo logs were not "mirrored" to the other server - they
were on shared disk. The distinction is of sharing a file rather than
copying (or "network mirroring") it. Shared online redo logs are
essential for any version of OPS/RAC - on any platform. Otherwise,
how could you do instance recovery on node A after an instance crash
on NODE B? In an OPS/RAC environment, if instance B crashes, then
instance A automatically detects it and performs an instance recovery
on instance B's behalf. From the beginning, all redo logs, control
files, and datafiles have had to be on shared storage for OPS.
Archive logs do not "have to" be on shared storage, but it is a good
idea. The preferred method is to place even archive logs on shared
disk subsystems rather than local storage. Then even if a node dies
permanently, one can mount it's archive dest(s) on a survivor and do
complete DB recovery. If the archive dest is on local disk on the
crashed node, then you have to start moving hardware around first. It
is common to NFS mount each node's archive log dest to other nodes -
for several reasons. One is that backups of everything, including all
archived redo threads, can be done from a single node. Another is
that in case of a restore & recover you will need access to all
threads' archive logs anyway.
The standby analogy you give doesn't actually quite work - at least
not 100%. With a standby, even with copying online redo log files
after every log switch, you will still lose anything in the currently
active redo log group - it hasn't yet been copied. It is also
possible that the copy of a recent log file will not finish before a
node crash - and those transactions will be lost also. To maintain a
"no loss" standby, synchronous mirroring of the redo to the standby is
required (via EMC's SRDF, or 9i's DataGuard mechanisms, for example).
You are correct that the principle is the same for OPS/RAC. The
difference is that with OPS/RAC every write to every log group for
every instance is available instantaneously to all other instances
since it is the SAME shared file, not a copy.
I suspect that this somewhat mistaken concept was conveyed by the
folks doing the presentation. I attended one of these also. The
presenters were not really very technical on the Oracle OPS/RAC side
and made a number of such mistakes.
-Don Granaman
{OraSaurus - Honk if you remember OPS ;-)
----- Original Message -----
To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
Sent: Thursday, October 18, 2001 7:55 AM
In the demonstration arena Oracle and Compac had the redo's "mirrored"
across the network to the second server. Not that the second server
would do anything with them, they were there in case of a failure and
you did not want to loose any transactions when you switched to the
second server.
At my previous employer during a controlled switch from the hot
server to the standby server we would copy and apply archivelogs all
of the time. At switch time we would copy the redo's also and bring
the "new" server up with no loss of transactions that had completed
and not yet archived. Same principle but automated for RAC.
ROR m���m
>>> [EMAIL PROTECTED] 10/17/01 12:10PM >>>
Ron, what do you mean by having the redo logs "replicated"?
Thanks,
--- Ron Rogers <[EMAIL PROTECTED]> wrote:
> The Dog and Pony show that I attended was a joint effort by Oracle
> and Compaq. For a complete RAC Oracle system they were fiber
> connecting everything for speed and they even had the redo's
> replicated to assist in the prevention of lost transactions in the
> event of a failure.
> Very impressive and expen$ive.
> ROR m���m
=====
Paul Baumgartel, Adept Computer Associates, Inc.
[EMAIL PROTECTED]
__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Paul Baumgartel
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: Ron Rogers
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: Don Granaman
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).
