RE: 64 node Oracle RAC Cluster (The reality of...)
- From: "Kevin Closson" <kevinc@xxxxxxxxxxxxx>
- To: <mwf@xxxxxxxx>, <Rich.Jesse@xxxxxxxxxxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
- Date: Tue, 21 Jun 2005 10:05:54 -0700
another point is that since it is shared data,
parallel query can do function shipping instead
of data shipping like all the other shared nothing
approaches. IPQO is a naterual for RAC, and even though
it is smart to implement OLTP application partitioning
(Oracle does this in their datacenter implementation
by the way), there are plenty of tasks that benefit
from the shared-disk parallel query implementation
in that same env (ever build a large index ? :-) )
The ironic thing about RAC and its shared-disk
approach is that it is only the database that Oracle
cares to implement with shared-disk. All the maintenance
is done with replication/propagation without a
replication engine (e.g., OUI doing simple rcp of
goodies to the many sundry Oracle Homes)
Kevin Closson
Chief Architect, Database Solutions
PolyServe
www.polyserve.com
>-----Original Message-----
>From: oracle-l-bounce@xxxxxxxxxxxxx
>[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Mark W. Farnham
>Sent: Tuesday, June 21, 2005 9:56 AM
>To: Rich.Jesse@xxxxxxxxxxxxxxxxx; oracle-l@xxxxxxxxxxxxx
>Subject: RE: 64 node Oracle RAC Cluster (The reality of...)
>
>The difference is that any node in the RAC can acquire the
>various blocks you need, and you don't HAVE TO partition functionally.
>
>However, if you route all the clients, say, using the Accounts
>Payables client software to a particular instance, then the
>vast majority of blocks they need will be in the instance they
>are running on.
>
>This will tend to greatly reduce the heat on the internode
>connection fabric, leaving headroom for things that don't
>functionally partition so neatly.
>
>But all instances CAN see all the data and you use one of
>several failover strategies if the preferred node for a
>particular functional partition goes off line.
>
>While I generally favor staying toward the bigger SMP/NUMA
>with fewer nodes side of the trade-off slope versus many-noded
>small box RAC (based on constant dollars and highest
>reliability to serve a given functional requirement), Oracle's
>architecture for RAC/GRID is clearly very good.
>
>Regards,
>
>mwf
>
>-----Original Message-----
>From: oracle-l-bounce@xxxxxxxxxxxxx
>[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Jesse, Rich
>Sent: Tuesday, June 21, 2005 12:45 PM
>To: oracle-l@xxxxxxxxxxxxx
>Subject: RE: 64 node Oracle RAC Cluster (The reality of...)
>
>
>Hey Mladen,
>
>Just for my own clarity, how does functional partitioning
>differ from SQueaLServer's federated layout? I remember an
>Oracle Marketing Schpeel about how that was a bad thing when
>compared to RAC, specifically targeting the high TPC marks
>(which in themselves are irrelevant). The bad part being the
>SPOF of any one box in the federated cluster would take out
>that functionality being solely hosted on that one box.
>
>TIA,
>Rich
>
>-----Original Message-----
>From: oracle-l-bounce@xxxxxxxxxxxxx
>[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Mladen Gogala
>Sent: Tuesday, June 21, 2005 8:20 AM
>To: cmarquez@xxxxxxxxxxxxxxxx
>Cc: rjamya; oracle-l@xxxxxxxxxxxxx
>Subject: Re: 64 node Oracle RAC Cluster (The reality of...)
>
>
>
>On 06/21/2005 08:17:38 AM, Marquez, Chris wrote:
>> >>thought of seeing eye popping
>> >>number of 'global cache cr requests'
>> >>for a 64 node RAC gives me chills.
>>
>> My thoughts exactly!
>>
>> Chris Marquez
>> Oracle DBA
>>
>
>
>There are two unholy words which Oracle sales people usually
>avoid when talking about RAC: functional partitioning.
>Functional partitioning means that each RAC node has a
>separate and specialized function and is mostly dealing with
>one part the database. That is still the best way of
>organizing RAC system. Also, with several cluster nodes, the
>private connection becomes crucial. With 64 nodes, N-cube like
>communication structure must be in place, so that each node is
>reachable through the fixed number of hops.
>
>--
>Mladen Gogala
>Oracle DBA
>
>
>--
>//www.freelists.org/webpage/oracle-l
>--
>//www.freelists.org/webpage/oracle-l
>
>
>--
>//www.freelists.org/webpage/oracle-l
>
--
//www.freelists.org/webpage/oracle-l
Other related posts:
