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

> 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.

Regards,

-- 
John Kanagaraj <><
http://www.linkedin.com/in/johnkanagaraj
http://jkanagaraj.wordpress.com (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 **
--
http://www.freelists.org/webpage/oracle-l