RAC or Not ? A comprehensive to guide
Choosing whether to implement Oracle Real Application
Clusters (RAC) is a critical architectural decision that can significantly
impact the performance, availability, complexity, and cost of your database environment.
Oracle RAC enables multiple instances to access a single database, providing
high availability, scalability, and fault tolerance. However, it also
introduces additional infrastructure requirements and operational
considerations.
This guide aims to help IT decision-makers, DBAs, and
architects evaluate the pros and cons of using Oracle RAC versus a non-RAC
(single-instance) deployment. I’ll explore key factors such as workload
characteristics, high availability requirements, application design, licensing
costs, and manageability to help determine whether Oracle RAC aligns with your
business and technical objectives.
By the end of this document, you should have a clearer
understanding of when RAC is the right solution — and equally important, when
it is not and when present a lighter alternative as a RAC One Node.
When IT organizations need to decide whether to deploy an
Oracle RAC as their database architecture, IT architects and DBAs need to make
decisions based on many factors.
In this topic I represented some of key notes for this
decision:
1. The High availability SLA: How much database downtime is
acceptable for both unplanned and planned downtime?
Without RAC, planned downtime for hardware and software
maintenance may vary from a few minutes to as much as a few hours. And the
unplanned time for hardware and software problems can also vary from minutes to
hours.
If a database server is completely lost, it will take a
longer time to rebuild it, although some downtimes, like the complete loss of
the server, may occur only rarely,
Are these potential downtimes acceptable to the business
according to the SLA? If not, can downtime prevention justify the cost of the
RAC deployment?
And furthermore, a loss of the entire database system including
the storage may take hours or days to recover from the backup.
Does this justify a Disaster Recovery (DR) solution which
consists of a completely duplicated system in another data center?
Some mission-critical databases may be equipped with the
combination of RAC and Data Guard DR solution to protect the database from
server failure as well as storage and site failure.
However, the cost and technical complexity need to be
justified by business needs.
2.
Scalability Requirement:
What kind of workloads are there and where is the performance bottleneck: CPU
intensive and/or storage I/O intensive?
If there is no need
to scale out CPU/memory resources or if we can scale up by adding additional
CPUs or memory, Oracle RAC One Node (instead of multiple RAC RAC) may be a good
way of providing HA without the need to pay for an RAC license.
RAC One Node provides higher availability by eliminating the
database server as a single point of failure.
Similar to Oracle Real Application Clusters (RAC), Oracle
RAC One Node uses a shared disk system to provide best in class high
availability for Oracle Databases.
Unlike Oracle RAC, which runs multiple instances
concurrently, Oracle RAC One Node provides an Oracle Database failover solution
for that facilitates the clustered infrastructure.
It requires no application changes, can support any Oracle
Database workloads, and is easily upgraded to a full multi-instance Oracle Real
Application Clusters configuration.
The Oracle Database with the Oracle Real Application
Clusters (RAC) One Node option benefits from the same infrastructure used for
Oracle RAC. Unlike Oracle RAC, Oracle RAC One Node normally runs only one
instance against a shared set of data files, also known as the database. This
database is fully Oracle RAC-enabled, but does not span multiple hardware
systems at the same time. Instead, the Oracle RAC One Node database instance
will failover to another server in the cluster should a server, instance or a
related and monitored component on this server fail. For cases of planned
downtime such as OS or database patching, Oracle RAC One Node provides a unique
feature, Online Database Relocation, which allows relocating a database from
one server to another without interrupting the database service. Addressing
planned as well as unplanned downtime makes Oracle RAC One Node the best
in-class Oracle Database failover solution. The ability to Online Upgrade to a
multi-node Oracle RAC database complements its functionality and makes it an
ideal infrastructure for database cloud deployments.
The Oracle Database with the Oracle Real Application
Clusters (RAC) One Node option benefits from the same infrastructure used for
Oracle RAC. Unlike Oracle RAC, Oracle RAC One Node normally runs only one
instance against a shared set of data files, also known as the database. This
database is fully Oracle RAC-enabled, but does not span multiple hardware
systems at the same time. Instead, the Oracle RAC One Node database instance
will failover to another server in the cluster should a server, instance or a related
and monitored component on this server fail. For cases of planned downtime such
as OS or database patching, Oracle RAC One Node provides a unique feature,
Online Database Relocation, which allows relocating a database from one server
to another without interrupting the database service. Addressing planned as
well as unplanned downtime makes Oracle RAC One Node the best in-class Oracle
Database failover solution. The ability to Online Upgrade to a multi-node
Oracle RAC database complements its functionality and makes it an ideal
infrastructure for database cloud deployments.
3. Database Consolidation Requirements: If the
organization has a business requirement to consolidate many database services together,
a multi-node RAC can offer significant advantages in terms of cost of ownership
while providing HA and scalability to all the databases.
4. If the organization decides to deploy the RAC solution,
it should fulfil the hardware requirements and follow configuration and
management best practices to ensure that the RAC provides all the potential
advantages.
5. Many companies have carried out successful migration of
their mission-critical databases from big SMP Unix machines to multi-node
Oracle RAC clusters based on lower-cost industry-standard commodity X86-64
servers running Linux.
In the last decade, these servers have advanced
significantly in terms of reliability as well as processing power.
Practical experience has shown that the new architecture can
provide a highly available and scalable infrastructure for enterprise-level
applications.
Best In-Class Oracle Database Availability For failure
cases, Oracle RAC One Node ensures the lowest possible failover times.
In addition, Oracle
RAC One Node can make use of Oracle’s latest Business Continuity feature
“Application Continuity”, which is included in the Oracle RAC, Oracle Active
Data Guard and Oracle RAC One Node option. Utilizing Application Continuity as
part of the failover strategy minimizes the downtime experienced by an
application running on an Oracle RAC One Node Database, but also helps to
optimize planned downtime as it reduces the need to free up work on the database
instance to be patched for example. Online Database Relocation completes the
Oracle RAC One Node functionality making Oracle RAC One Node the best in-class
Oracle Database failover solution.
Example: Using Online Database Relocation to perform Zero
Downtime Patching Online Database Relocation allows maintenance operations such
as server firmware, OS or database patching to be performed without downtime of
the database service (online).
While Online Database Relocation is a standard Oracle RAC
One Node feature, using it for zero downtime maintenance requires some
preparation.
In figure 4, a three-node cluster hosts various Oracle RAC
One Node Databases:
» Node 1 hosts Oracle RAC One Node Database A
» Node 2 hosts Oracle RAC One Node Database B and D
» Node 3 hosts Oracle RAC One Node Database C and E
The Oracle Database home for each Oracle RAC One Node
database is installed on a per-server-basis (as opposed to using a shared
Oracle Database home). Using an individual database home per database allows
for online patching of individual databases on a server, as described below.
For simplicity reasons, the following example will only focus on Oracle RAC One
Node database A. In a real world example, other databases that might be running
on the same server would have to be accounted for. Given these assumptions,
online maintenance using Online Database Relocation can be performed in four
simple steps (which can be further optimized to three steps depending on the
scenario):
1. Initiate Online Database Relocation from source to target
2. Patch the Oracle
Database home on the source server
3. Rewind (relocate back to source server) to activate the
patch usage
4. Patch remaining Oracle Database home(s)
Step one in the above list makes Oracle RAC One Node
superior to any other database cluster failover solution on the market today.
Based on the fact that Oracle RAC One Node is an Oracle RAC
enabled database, Online Database Relocation can start a second instance for
the Oracle RAC One Node database for the purpose of the relocation.
This is the only time during which an Oracle RAC One Node
database should have two database instances running at the same time.
As part of the Online Database Relocation the following
steps are performed:
» The database service(s) are stopped on the source database
instance (the instance that you want to stop) and then started on the target
database instance (the new instance).
• Note that Oracle RAC One Node for this reason requires at
least one dynamic database service to be created as part of the DBCA-based
database creation. o Further database services can be created as a
post-installation step.
» The database service started on the target database
instance will cause new connections requesting access to the Oracle RAC One
Node database go to the new target server.
» Connections that were established at the moment of
initiating an Online Database Relocation on the source server will remain on
the source instance, while a shutdown transactional will be issued against the
source database instance.
» As a shutdown transactional will wait for sessions to
finish the transaction and to disconnect, the Online Database Relocation
feature allows for setting a timeout describing the time that it should wait
before forcefully stopping the source database instance using shutdown abort.
• The default wait
time (timeout) is 30 minutes.
• The wait time can be increased up to 24 hours.
» After either the timeout has expired or the last session
on the source database instance is closed (whichever comes first), the source
database instance will be shut down and the new (target) database instance
remains as the only available instance.
As the source database instance is now stopped and assuming
no other database is operated from the respective database home, the database
home on the source server can now be patched (see step 3), implicitly making
use of the Rolling Upgrade functionality that is inherent to Oracle RAC
databases.
Step 4 foresees to rewind the operation, which means to
relocate Oracle RAC One Node Database A back to the original home in order to
activate the patch, as so far this database instance has only been running out
of an unpatched database home. Starting the Oracle RAC One Node Database A
instance on Node 1 will activate the patch for this instance and allow for
patching the remaining home(s).
Optimized Online Patching in Consolidated Environments The
procedure outlined above called “Zero Downtime Patching using Online Database
Relocation”, assumes that a particular database instance is relocated twice as
part of the workflow, which leads to four steps to be executed. In consolidated
environments and assuming that there is no specific server, on which a database
instance needs to be hosted, the above procedure can be shortened to 3 steps:
Better Oracle Database Consolidation:
Consolidation has become a hot topic in the IT industry.
Oracle RAC One Node enables better server consolidation, enhanced protection
from failures, greater flexibility, easier workload management as well as
better online maintenance than virtualized environments. Oracle RAC One Node
provides superior consolidation by leveraging the benefits of a shared
operating system (OS) image. This means, there is only one OS to install,
configure, secure, patch, upgrade, backup, manage vs. multiple operating systems
in a Virtual Machine (VM) environment.
Consolidation
schemes used today
Oracle RAC One Node’s OS consolidation model presents the
system administrator with a single OS (per-server) to manage. In contrast, in a
VM environment it is not unusual to have a dozen of operating systems installed
on a single physical server, presenting the system administrator with a dozen
operating systems to install, configure, patch, secure, upgrade, back up and
manage. Using a single OS image to host multiple Oracle Databases presents the
problem of isolation of resources, of which CPU utilization next to memory
utilization is the most critical. Instance Caging5 is a feature introduced with
Oracle Database 11g Release 2 that provides the required resource isolation
across databases. This feature helps delivering consistent service levels,
without the overhead and inefficiencies of more cumbersome approaches. Instance
Caging allows the administrator to limit the CPU used by an instance,
preventing runaway processes in one instance from impacting others sharing that
server. The administrator can dynamically change the CPU allocation without
taking the database offline, should requirements or demand change on the
system.
Oracle RAC
One Node - Isolation through Instance Caging
Oracle RAC One Node Support for Oracle Multitenant
Oracle Multitenant is a new option to the Oracle Database
12c Enterprise Edition that helps customers reduce IT costs by simplifying
consolidation, provisioning, upgrades and more. It is based on a new
architecture that allows a multitenant container database to hold many
pluggable databases (PDBs). The idea is that an existing database can be simply
adopted, with no changes in the application tier, as a pluggable database. In
this architecture, Oracle RAC One Node provides local failover based high availability
that is required when consolidating various business critical applications on
one system. Figure 7:
When using PDBs with Oracle RAC One Node, the multitenant
container database (CDB) is based on Oracle RAC One Node. Each pluggable
database is made available on the Oracle RAC One Node CDB instance. Access to
and management of the PDBs are regulated using Dynamic Database Services, which
will also be used by applications to connect to the respective PDB – as they
would in a Single Instance Oracle Database using Oracle Net Services for
connectivity.
When to
Use Oracle RAC One Node
Oracle RAC One Node is ideal for customers who
require high availability (HA) and planned failover capability,
but do not need full multi-instance scalability of traditional Oracle
RAC.
It provides a single-instance active database with the
ability to move or fail over to another server in the cluster,
minimizing downtime.
You should consider RAC One Node in the following
situations:
- Need
High Availability Without Full RAC Complexity
When your system needs continuous availability but doesn’t require active-active database instances, RAC One Node offers a simpler HA option than full RAC. - Planned
Maintenance With Zero Downtime
RAC One Node allows online database relocation to another server for hardware, OS, or patch maintenance — providing near-zero downtime for planned operations. - Consolidation
in Private Cloud Environments
Ideal for environments running Database as a Service (DBaaS) where multiple RAC One Node databases can be consolidated across nodes, with flexibility and high availability. - Future
Upgrade Path to Full RAC
If you want to start small but keep the option to scale to full RAC later, RAC One Node provides a migration path without needing to re-architect your solution. - Cost-Sensitive
High Availability
When full RAC licensing is not justified or affordable, RAC One Node offers a more budget-friendly alternative with key HA features. - Single-Instance
Workload With Downtime Sensitivity
If your workload fits a single-instance model but your business cannot tolerate outages, RAC One Node adds automatic failover and relocation capabilities to reduce risk.
When You
Don’t Need Oracle RAC
Oracle RAC is a powerful solution, but it is not always the
right fit for every environment. In many cases, simpler and more cost-effective
architectures can meet business requirements without the added complexity of
RAC.
Consider avoiding Oracle RAC in the following scenarios:
- No
High Availability (HA) Requirement
If your application or business can tolerate short periods of downtime (e.g., for maintenance or failover), a single-instance Oracle setup — possibly with Data Guard for standby — is often sufficient. - Low
to Moderate Workload
Environments with low to moderate CPU, memory, and I/O demands typically do not benefit from RAC’s horizontal scalability. A well-tuned single-instance database can handle such workloads efficiently.
Specially, I have a good experience
about handling over 10k TPS on Single-Node on Virtualization infrastructure!
- Application
Not Designed for RAC
Applications with high contention, non-scalable session logic, or lack of RAC-aware features may perform worse in a RAC environment due to interconnect overhead and global cache coordination. - Limited
Budget or Infrastructure
RAC requires shared storage, clusterware, and more complex hardware and networking setups. If budget constraints or infrastructure limitations exist, RAC might not be justifiable. - Licensing
and Operational Overhead
RAC adds to both licensing costs and administrative effort. If operational simplicity and cost minimization are priorities, a non-RAC solution with standby, backup, and monitoring may be more appropriate. - Geographically
Distributed Architecture
RAC is not suited for active-active configurations across data centers (and if possible, its implementations have a special network device with very high speed such so which will cost your organization more). If disaster recovery or multi-region availability is required, Data Guard or other replication technologies are better choices.
Summary
Recommendations:
- Use
Oracle RAC when you need maximum availability + active-active
scalability and have the budget and infrastructure to support it.
- Use
RAC One Node when you want high availability with minimal
complexity and don’t need multiple active database instances.
- Use
Single Instance + Data Guard when you need HA or DR protection
at lower cost, and can tolerate a few minutes of failover time.
No comments:
Post a Comment