Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> Re: RAC Oracle

Re: RAC Oracle

From: Don Granaman <granaman_at_home.com>
Date: Fri, 19 Oct 2001 01:28:09 -0700
Message-ID: <F001.003AF8EA.20011019013518@fatcity.com>

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

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 mm

>>> treegarden_at_yahoo.com 10/17/01 12:10PM >>> Ron, what do you mean by having the redo logs "replicated"?

Thanks,


Paul Baumgartel, Adept Computer Associates, Inc. paul.baumgartel_at_aya.yale.edu

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

--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Ron Rogers
  INET: RROGERS_at_galottery.org

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: Don Granaman
  INET: granaman_at_home.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).
Received on Fri Oct 19 2001 - 03:28:09 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US