about Oracle RAC... some thoughts# Database - 数据库
g*g
1 楼
below is posted in google group.
Chinese in North America Oracle User Group (CINAOUG)
============ start the post ==========================================
RAC is like an amplifier, it multiplies both good or bad.
RAC pretty much turns a chunk of application memory requests into network
access requests, so all those access latency will be slower, and the
frontend application will be impacted.
RAC also does nothing to improve IO throughout, it only creates more access
requests to the storage. If your application is IO bound, RAC makes it
worse in theory.
a well tuned application scales well in RAC.
an application with IO, buffer cache contention,in general, behaves badly in
RAC.
Running application in RAC has a much higher performance tuning requirement.
It is ironic that we use RAC to increase capacity, performance and
availability but it is also a performance trap.
Here are couple tuning tip on RAC.( a lot of people would disagree with me
on this, all my tips have cons)
1) enable jumbo frame on the interconnect, this is hardware specific, not
all switches supports this.
2) look into hot blocks, this has greater impact to an app in RAC than a
single instance environment. some technics are "cache a frequently used
sequence number." "Use reverse index to spread out index data block".
DBMS_APPLICATION_INFO is a very useful tool in both single/RAC setting. In a
connection pool client/server setup, it is the best tool to trace an
application. I personally think it is the only meaningful way to trace an
app.
Any inputs on this are welcome.
Chinese in North America Oracle User Group (CINAOUG)
============ start the post ==========================================
RAC is like an amplifier, it multiplies both good or bad.
RAC pretty much turns a chunk of application memory requests into network
access requests, so all those access latency will be slower, and the
frontend application will be impacted.
RAC also does nothing to improve IO throughout, it only creates more access
requests to the storage. If your application is IO bound, RAC makes it
worse in theory.
a well tuned application scales well in RAC.
an application with IO, buffer cache contention,in general, behaves badly in
RAC.
Running application in RAC has a much higher performance tuning requirement.
It is ironic that we use RAC to increase capacity, performance and
availability but it is also a performance trap.
Here are couple tuning tip on RAC.( a lot of people would disagree with me
on this, all my tips have cons)
1) enable jumbo frame on the interconnect, this is hardware specific, not
all switches supports this.
2) look into hot blocks, this has greater impact to an app in RAC than a
single instance environment. some technics are "cache a frequently used
sequence number." "Use reverse index to spread out index data block".
DBMS_APPLICATION_INFO is a very useful tool in both single/RAC setting. In a
connection pool client/server setup, it is the best tool to trace an
application. I personally think it is the only meaningful way to trace an
app.
Any inputs on this are welcome.
