| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: RAC Oracle
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 mª¿ªm
>>> treegarden_at_yahoo.com 10/17/01 12:10PM >>> Ron, what do you mean by having the redo logs "replicated"?
Thanks,
-- 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
 |
 |