Re: Convert 2-node RAC to single instance
From: Tim Gorman <tim_at_evdbt.com>
Date: Sat, 07 Feb 2009 21:14:34 -0700
Message-ID: <498E5C2A.5050700_at_evdbt.com>
Mark, Yong, and Dan,
I ran such tests back in OPS7.3, so I can't say that those results are worth mentioning now. But of course I have already.... :-)
The big issue is global enqueues. When I tested non-OPS against single-node OPS (or with just the 1st node of a 2-node cluster active, node 2 completely passive), the real differentiator was enqueue/lock acquisition and release. At the time, we were told that the difference between OPS and non-OPS was about 20-30%, but I found that the following type of transaction:
So, my lesson then was: it's not the global caching, it's the global enqueues that rob performance in comparing these scenarios. Now, that may no longer be true with RAC. Or maybe it is. It is easy enough to test, and is certainly worth testing.
Hope this helps....
Bobak, Mark wrote:
Date: Sat, 07 Feb 2009 21:14:34 -0700
Message-ID: <498E5C2A.5050700_at_evdbt.com>
I ran such tests back in OPS7.3, so I can't say that those results are worth mentioning now. But of course I have already.... :-)
The big issue is global enqueues. When I tested non-OPS against single-node OPS (or with just the 1st node of a 2-node cluster active, node 2 completely passive), the real differentiator was enqueue/lock acquisition and release. At the time, we were told that the difference between OPS and non-OPS was about 20-30%, but I found that the following type of transaction:
for x in get_rows loop...was indeed about 25-30% worse on OPS than non-OPS. SQL traces pointed directly at whatever wait events represented global enqueues way back then. However, the following type of transaction:
...perform DML...
commit;
end loop;
for x in get_rows loop...was only about 2-3% worse on single-instance OPS (or one node of a 2-node OPS cluster) than non-OPS. Clearly, with only one node active, retrieving cached blocks was not going to be an issue either way.
...perform DML...
end loop;
commit;
So, my lesson then was: it's not the global caching, it's the global enqueues that rob performance in comparing these scenarios. Now, that may no longer be true with RAC. Or maybe it is. It is easy enough to test, and is certainly worth testing.
Hope this helps....
Tim Gorman consultant - Evergreen Database Technologies, Inc. P.O. Box 630791, Highlands Ranch CO 80163-0791 website = http://www.EvDBT.com/ email = Tim_at_EvDBT.com mobile = +1-303-885-4526 fax = +1-303-484-3608 Yahoo IM = tim_evdbt
Bobak, Mark wrote:
-- http://www.freelists.org/webpage/oracle-l Received on Sat Feb 07 2009 - 22:14:34 CSTYong, I don't have any definitive data, but, if I recall correctly, one of the Oakies, maybe Bjorn Engsig(?), did a test, and found that running RAC binaries on a single instance database caused a noticeable performance penalty over the single instance binaries. If I recall correctly, he was quoting around 12-15% performance hit? Sorry, I don't remember details, and this was at least 2 years ago..... I'll ping the Oaktable list see if I can get some follow up information..... -Mark ________________________________________ From: oracle-l-bounce_at_freelists.org [oracle-l-bounce@freelists.org] On Behalf Of Yong Huang [yong321@yahoo.com] Sent: Saturday, February 07, 2009 6:24 PM To: oracle-l_at_freelists.org Cc: dannorris_at_dannorris.com Subject: Re: Convert 2-node RAC to single instance Dan or anybody, Do you think turning RAC option off is only done from a purist's point of view or it has performance or other benefit? I can't think of any benefit other than making the oracle binary smaller. But maybe code path is shorter for some operations when RAC is off. If anybody has performance comparison without and with RAC option on (but cluster_database=false), I'd love to see. Yong Huang5. relink binaries to disable RAC ... Good catch on the relink--I forgot about that step. Danbao jiejie wrote: And ... Do we need relink oracle binary to off the rac option? like make -f ins_rdbms.mk rac on/off ??-- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-l