Re: RAC - mix Intel and AMD in same cluster ?

  • From: John Kanagaraj <john.kanagaraj@xxxxxxxxx>
  • To: "Brandon.Allen" <Brandon.Allen@xxxxxxxxxxx>
  • Date: Thu, 23 Jul 2009 22:37:46 -0700

Hi Brandon,

> I've never run RAC so not speaking from any experience and it's been a long 
> time since I read anything on how RAC manages the multiple caches, but I'd 
> think the locking delays Mark (or Oracle Support) mentioned would only affect 
> DML, so the faster nodes would still be able to process SELECT queries 
> faster, but might just be limited to the speed of the slower nodes for 
> UPDATE/SELECT/DELETEs.  Most of my systems are probably 90% SELECTs so I 
> wouldn't be too concerned about the slower nodes, however in a DML-intensive 
> environment it might be more of a problem.

I would qualify that by saying this: The locking that Mark is talking
about is not DML locking, but locking on Global Cache elements that
will occur regardless of whether DML is in play or not. I might be
mis-stating the exact words (don't have Gopal's book with me right
now) but look at it this way: Node 1 is traversing a set of hot index
blocks repeated (tight NL) and Node -N wants to access those same
blocks. CR copies of those blocks need to be sent over from Node 1 to
Node N, along with all the tiny ~200 byte messages between
Master-Holder-Requestor (gc cr requests + same requests 2-way and
3-way in case you have > 2 nodes). Those blocks will need to be pinned
somewhere along with the GC resource lists. Throw in IMU and possibly
Undo blocks, CR copies, etc. when performing consistent reads (even if
you don't have DML going on at that moment), and you have a ton of
synchronization across the RAC cluster...... Actually, RAC is so much
more complicated than it looks.

John Kanagaraj <>< (Sorry - not an Oracle blog!)
** The opinions and facts contained in this message are entirely mine
and do not reflect those of my employer or customers **

Other related posts: