Joseph -- Thanks for the question regarding "Oracle RAC - MSFT Whitepaper", version 11g
Submitted on 15-Jul-2009 13:01 Central time zone
Last updated 24-Jul-2009 11:49
You Asked
Tom-
A recent (June 6, 2009) Microsoft white paper titled "
Thinking Oracle RAC? Think again " raises a number of criticisms of Oracle RAC. As an application developer one of the points that jumped out at me was the one below:
<Quote>
"
Myth: Any applications will run in Oracle RAC without modification.
"
</Quote>
Beyond good basic Oracle coding practices like using cached sequences (with an appropriately sized cache), can you comment on the above claim? I suspect the entire white paper is just marketing propaganda but am interested in your impression.
Thank You.
Link to White Paper
http://blogs.technet.com/dataplatforminsider/archive/2009/06/02/thinking-oracle-rac-think-
again.aspx P.S. - Thanks for the great sessions at the NOUG at Boston in June.
and we said...
You are correct about the sequences, with appropriate cache sizes - sequences scale awesome in single instance or clustered instances. There is no serialization.
As for index updates - if you have an index on a sequence, you will have a hot right hand side index. The advice to hash partition, use reverse key indexes and the such is valid -
for single instance oracle as well as RAC. I teach that stuff myself. In an high insert scenario - you will have severe scalability issues with indexes on sequence (or date fields populated by SYSDATE/SYSTIMESTAMP - any monotonically increasing value)
in SINGLE INSTANCE Oracle, in SQLServer, in DB2, in Informix, in whatever
That is a well known and well understood thing. Period.
Now in RAC, you might experience this sooner than in single instance Oracle since the block might need to go back and forth - but the fact is, you would hit it
in single instance Oracle .
If you have something that doesn't scale on a single box (right hand side, HOT indexes), it won't scale on a cluster either.
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:4663078177884 http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:4663078177884#28132795
251868
July 20, 2009 - 4pm Central time zone
Reviewer: Alexander
One of our architects is in charge of building out a new RAC environment said and I quote
"It's also important to note that they mentioned there was about a 20% overhead on each CPU when using Oracle RAC due to LMS processes (This is the Lock Manager Server Process or the LMS process, sometimes also called the GCS (Global Cache Services) process."
Followup July 24, 2009 - 11am Central time zone:
Nope, I think it is more like 3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679%, give or take 0.0001% depending on whether it is raining or not (but only in California, in other states, it has to be raining for at least 1 hour first)
My favourite quote
July 21, 2009 - 9am Central time zone
Reviewer: Luigi D. Sandon
"Oracle RAC also uses many shared components, such as processes (cluster-ready services) and
hardware (voting disk and SAN), that represent a single point of failure"
And later:
"The Windows Server® 2008 R2 operating system includes a new technology, called Cluster Shared
Volume, which enables multiple nodes in the same failover cluster to concurrently access the same
shared logical unit number (LUN). Concurrent access to the same LUN greatly improves fault
tolerance"
Someone could explain me why using LUNs in a SAN with Oracle is a "single point of failure" while
using it with SQL Server "greatly improves fault tolerance"??? LOL!
Anyway, check the carefully crafted "phraseology" to make it appear different to "buyers" with very
little tech background (where could a LUN be??). Mr. Carrabino is the stereotype marketing guy, it
will tell you white is black if you look for black socks and he only has white ones.
And let's not speak about "shared processes"... do they run on the SAN? <g>