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%.
As enterprises rely more on
organized data and databases, an explosion of data accumulation has
occurred in the recent past. This trend will continue as information
and data processing is the key to many business operations and
business decisions. None of the day-to-day business operations can
run without the use of database resources. Dependence on the
database is total. As a result, the stress on scalability and
performance of database system software is greater than ever. The
major benefits of the RAC database system are scalability and high
availability.
Scalability
In a dedicated server
environment, every connected client is associated with a server
process that consumes memory resources and contributes to context
switching overhead in a production environment. However, the TP
monitors and MTS, now called shared server, features of the Oracle
database have been used to reduce the numbers of processes on the
server and better utilize these resources. To solve the resource
crunch, the RAC database provides additional memory resources as
more nodes are added to the clustered database system.
A RAC database system provides
excellent scalability options for the users. As the need arises,
users 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.
Cache fusion technology provides
transparency in the way the data blocks are accessed and the results
are composed to meet the needs of the SQL query.
Horizontal scalability is
generally easy to achieve with the addition of extra nodes at the
operating system and at the physical cluster level. Once the cluster
is physically expanded, it is relatively easy for the Oracle
instance to be created and added into the RAC database system.
Addition of another instance
creates the opportunity to support a large 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.
In the past, the only way to
scale the database server was to scale up by replacing a small
system with a larger system. Oracle9i/10G RAC provides another
option: the addition of more small systems, also known as scale out.
In a typical SMP server, a limit is reached in the number of CPUs
and memory buffers. With the addition of extra nodes and instances,
the total number of processors in the clusters can be enhanced. For
complex database queries, it now becomes possible to achieve higher
parallelism, spanning across the multiple nodes. In other words, a
higher degree of parallelism for queries can be realized.
If a lot of processing is going
on in one of the instances, the applications accessing the database
through that instance can be shifted to another instance. Thus, the
processing or activity can be dispersed.
Scalability is the ability of a system to handle an increased
workload as the number of users increases. When you only have one
server, the only way to raise the server?s capacity is to increase
the resources available in the server. The server can be outfitted
with more CPUs with more cores. Physical memory can be increased.
We say that adding resources to a server is scaling up or vertical
scaling.
One of the biggest problems with vertical
scaling is that hard limits exist in any server. You can only add
a certain number of CPU cores to the server. The server has a
finite number of memory slots that have a physical limit on the
size of the memory chips that can be used. If the workload
increases sufficiently, a server that is outfitted to the maximum
may still be overburdened and not be able to handle the end user
demands.
Another issue with vertical scaling is the cost.
As more and more memory is added to the system, the cost increases
very rapidly. As an analogy, think of constructing a building and
your requirement is to have 10,000 square feet. Such a large
building will cost more if it is built as a ten story structure
with each story sized at 1,000 square feet than if it were built
as a single story building. The taller the building, the more it
costs to create. Similarly, a server outfitted with lots of CPU
cores and very large amounts of physical memory will cost more
than buying lots of smaller servers together provide the same
number of cores and RAM.
Oracle RAC offers the ability to
scale out, or perform horizontal scaling. Horizontal scaling is
normally much cheaper than vertical scaling. Back to the analogy,
in scaling out, we can erect ten 1,000 square foot single story
buildings to achieve our total resource requirement. A ten-story
building is much, much more expensive than ten smaller one-story
buildings even if the end result is the same square footage.
Oracle RAC horizontal scaling is typically accomplished by
implementing low-cost commodity hardware. Today?s data centers are
now filled with inexpensive servers rather than the big iron
systems of the past. We typically scale our Oracle RAC
configurations by adding a new server rather than buying a larger
server. Back to our analogy, if the workload dictates that we need
to grow from 10,000 square feet to 12,000 square feet, we do that
by creating two more 1,000 square foot buildings. Similarly, if
our Oracle RAC cluster needs to scale to meet demands, we simply
add another low-cost server to the cluster.
Oracle RAC
offers the ability to both scale up and scale out. You are not
limited to one or the other. This gives the company great
flexibility is designing their database infrastructure to suit
their specific needs. It is possible to incorporate high-end
servers into a RAC cluster. However, this is rarely done in
practice as the company often saves money by using commodity
hardware, but it is always nice to have options and not be
constrained in a single direction.
Another option is to
have some nodes in the cluster with more resources than other
nodes. In this way, we can mix and match nodes to specific needs
across the cluster. Be very careful in architecting your RAC
systems where nodes may have different resources. If you use any
application failover within the cluster, you may find that
sessions connecting to a different node in the cluster do not have
enough resources to be able to perform adequately. A node in
the cluster should not only have enough resources to handle a
normal workload, it should have enough resources to handle the
additional demands placed on it when the number of sessions
increases due to failure in another node. For this reason, it is
rare to have an Oracle RAC cluster where nodes do not have all the
same resources available to it. While possible to have nodes
with different configurations, doing so would be rare and requires
a proper understanding of the risks involved.
This
first chapter provided an introduction to Oracle RAC performance
tuning. The chapter started with a discussion of using testbeds to
understand the effect of a change on a system, made even easier
with today?s virtualization techniques. The conversation turned to
tuning the application for a single instance. Oracle RAC is not a
silver bullet for an application?s performance woes. A properly
tuned, scalable application can be taken to the next level with
Oracle RAC, but it is possible to have worse performance on Oracle
RAC.
Next, we discussed scale up and scale out. Oracle RAC
is primarily a scale out solution, often leveraging commodity
hardware to scale with reasonable costs. Yet Oracle RAC does not
limit the infrastructure to one scaling direction as the systems
can be configured to scale up as well.
This chapter also
discussed a tuning methodology that works for single-instance as
well as Oracle RAC databases. Tune the application first, the
database second, and the server last. Bottlenecks always exist in
any system and it is impossible to eliminate them all. Response
time is defined as service time plus wait time. Oracle?s wait
events tell us where processes are spending their time.
In the next chapter we will discuss Cache Fusion, the secret sauce
to make Oracle RAC databases perform very well. The Cache Fusion
operations discussed will be important, as those operations will
be illustrated throughout the remainder of the book.