Scalability
There are two ways to scale hardware: vertically
and horizontally.
Vertical scaling means to build up.
Add CPUs, RAM, and such until the system
is full.
To visualize scaling vertically, think of
Manhattan.
There is no more room on the horizontal
plane.
There is no room to build new buildings.
However, adding new stories to existing
buildings is possible.
This is scaling up.
Scaling horizontally is the practice of adding
new systems to the cluster.
In an area with ample open land, when new
developments are needed, building taller
buildings is unnecessary.
Building out is more practical, scaling
upon the horizontal plane.
Oracle, vendors, and consultants may mention
that RAC is good because of the price.
At first glance, it seems expensive
because of the added cost per CPU on top of what
is already being paid for Oracle.
However, it can actually decrease costs
by decreasing hardware requirements.
RAC allows the use of multiple low cost machines
together in order to provide the same capability
of a single large system with the added benefit
of high availability.
For instance, four 16-CPU systems instead
of a single 64-CPU server could be used.
Now new servers can be added as needed.
In addition, a single system may have
underutilized resources.
If the system is waiting on a RAM
resource, but the CPUs are at only 50% capacity,
half of the CPUs are wasted.
In a RAC environment, every server can be
utilized to the max.
The concurrent processes will be balanced
across all the nodes of the cluster, and will
therefore have a better chance to use otherwise
unclaimed resources.
The addition of an instance creates the
opportunity to support a larger number of
concurrent users. Any instance introduced into
the RAC system opens up new memory buffers and
permits more user connections without affecting
the performance of the other instances.
A RAC database system provides excellent
scalability options for the users. As the need
arises, DBAs can expand or add the number of
nodes in the cluster. This enhances the total
database engine computing power when the need
for high performance arises. With the additional
nodes and instances in the database cluster, the
system is able to accommodate demands. Consider
the following statements:
-
If the application will scale by adding RAM
and CPUs, it should scale on RAC.
-
If the application will not scale by adding
RAM and CPUs, it typically will not scale on
RAC.
-
RAC can expose application design issues
that were not exposed on a single instance
non-RAC system.
-
A poorly designed application could work
fine on a non-RAC single instance but might
not work very well on RAC.
When one thinks about database scalability on
RAC, one needs to visualize the data blocks.
Constantly having to ship a large number
of the same data blocks back and forth via cache
fusion may not be scalable.
Bert Scalzo, Ph.D has a great document online
called “RAC Be Nimble RAC Be Quick.”
The image below originates from his
document.
Remember, the application should be built
so that an instance can run full throttle
without worrying what the other instances are
doing.
Oracle RAC can provide near linear
scalability.
Figure 7.2:
Multi-node Capability of RAC (Source:
Bert Scalzo
