Re: Oracle RAC
Date: Wed, 2 Sep 2009 22:04:20 +0000 (UTC)
Message-ID: <h7mq54$4v3$1_at_solani.org>
On Wed, 02 Sep 2009 13:24:22 +0000, Jim Watts wrote:
> We are going to be implementing a new Student Information System which
> will be using Oracle 11G for the database. We are looking at RAC and
> are interested what some of the gotachs. What are some of the things
> that can not be done if using RAC versus not RAC (as in software updates
> and such). I have read through some of the documentation but over the
> years have learned to it does not always tell you everything. I have
> gone through a few forums and news groups but it is all running together
> at this point.
>
> Any information and insight is greatly appreciated.
>
> Regards,
>
> Jim Watts
> Kutztown University
RAC is, first and foremost, a high availability option. If a node goes down, there are other nodes that survive and thus your database continues to be available. If you need something that's up for 99% of the time, RAC is for you. For 99.9% you need to strenghen it even more. With all due respect, I don't see that in a student information system. So, business case for RAC is on very shaky ground in your case. RAC is an ideal DW technology, it scales almost linearly for queries, especially large reports doing lots of full table scans. 11G has made some great strides to help it even further, by enabling direct I/O for full table scans of the large tables. That makes I/O even cheaper as there is less of buffer handling, latching, global cache locks etc. On the other side, one needs to be very careful when doing OLTP on RAC. The expensive operation on RAC is locking across nodes. That happens when when the two transactions on two different nodes access the same block and attempt to change it. Every block in the database can have many read consistent versions but only one current version in the entire database. When two transaction want to update one block, each node has to get an exclusive lock on that block. That is done over the private interconnect and is very fast but not nearly as fast as a memory access on the same node. It's still much better than OPS which used to flush the affected block to the disk and the owning node would have to re-read it. So, the obvious answer is not to do modify the same objects at the same time from different nodes. To rephrase it, a table should only be modified from one node at any given time. That is called "functional partitioning" (you are partitioning your application is such a way that related functions are located on the same node as they access the same set of tables) and is a major design constraint. If you are careful in doing that, you can have a fault tolerant OLTP application that will perform very well. The caveat is that you must have somebody who knows what is doing, and not in the Sledge Hammer sense of the phrase.
-- http://mgogala.freehostia.comReceived on Wed Sep 02 2009 - 17:04:20 CDT