This is an excerpt from the bestselling book
Oracle Grid & Real Application Clusters. To get immediate
access to the code depot of working RAC scripts, buy it
directly from the publisher and save more than 30%.
While not shown in the diagram,
every component requires a connection to the others. This connection
is usually via a network interface card (NIC) or host bus adapter (HBA)
interface. These NIC or HBA interfaces should be the fastest
possible, especially in the case of the cluster interconnect and
disk connect. Failed NIC interfaces result in the loss of that
component, unless a second NIC card is immediately failed over to. A
failure of the HBA results in loss of connection to the disk array.
At a minimum, a spare NIC and HBA for each and every component must
be available. Wherever possible, use interchangeable NIC and HBA
Provide Redundancy at Each
It is easy to see that
redundancy at the hardware level is vital. At each level of the
hardware layout an alternate access path must be available.
Duplicating all equipment and configuring the automatic failover
capabilities of the hardware reduce the chances of failure to
virtually nil. It is also critical to have spares on hand for
non-redundant equipment such as NIC and HBA cards and interface
By providing the required levels
of redundancy, the system becomes highly available. Once there is an
HA configuration, it is up to the manager to plan any software or
application upgrades to further reduce application downtime. In
Oracle Database 10g using grid control, rolling upgrades are
supported, further increasing reliability. At the SAN level,
appropriate duplication software such as Veritas must be used to
ensure the SAN arrays are kept synchronous. Oracle Database 10g
allows for use of the Oracle Automatic Storage Management or ASM.
ASM allows for automated striping, backup and database flashback
Designing for High
Designing for high performance
means that every tier of the design must eliminate contention for
resources. If there is no contention, each process gets the
resources it needs to perform optimally. Resources fall into
multiple categories: physical, as in disk and network; and internal,
such as CPU speed and memory capacity. Designing for performance
means utilizing these resources properly and not relying on memory
or disk resources to make up for poor application design.
As with normal databases, the
application design will drive performance. The finest equipment will
not make up for a poor application design. In the days of Oracle
Parallel Server (OPS), Oracle recommended partitioning the
application data and the servers to make OPS perform. Now, Oracle
salesmen insist that any application can be run with RAC, with no
need for changes.
To add capacity, the solution is
to just add a server and bingo, more capacity is provided and more
users, no matter what they do with the application, can connect.
This all sounds wonderful until the manual, Oracle9i Real
Application Clusters Deployment and Performance, Release 1 (9.0.1)",
Part No. A96598-01, Chapter 3, Scaling Applications for Real
Application Clusters, and Chapter 4, Scaling Applications for Real
Application Clusters, is consulted. There, Oracle recommends
partitioning both the application data and the users to optimize
performance. This unfortunate fact is omitted from the 9.2 and 10g
versions of the manual which seems to indicate the automated tuning
features of 9.2 and 10g relieve the DBA of this arduous task.
Of course, the difference is
that now partitioning is based on reducing intra-node block pinging
between instances over the cluster interconnects, instead of
reducing disk pinging. At most, a factor of 40 improvements can be
expected for the same application running on a RAC server versus an
OPS-based server. Once the various system latencies are added, the
speed difference between memory operations and disk operations falls
to approximately a factor of 40 between a disk ping and an
intra-node memory ping. The speed is dependent upon the speed of the
interconnect. Still, a factor of 4000% (40) is nothing to sneeze at.
Designing applications for
better performance on RAC involves:
* Assigning transactions with
similar data access characteristics to specific nodes.
* Creating data objects with
parameters that enable more efficient access when globally shared.
* Automating free space
allocation and de-allocation through the use of locally managed
* Automating block management
through local freelist management.
* Using sequences properly by
using sequence ranging triggers for each instance.
* Optimizing all SQL in the
* Understanding the workload on
the system and planning the application to properly utilize
These factors should be
considered for proper application design one-by-one in order to see
how they can be utilized to make RAC applications perform optimally.