Database Reference
In-Depth Information
Shared vs. Non-Shared Oracle Homes
In a typical cluster deployment, small, medium, or large sized, each node must at least consist of a Grid Infrastructure (GI)
and RDBMS home, where the Oracle Clusterware, Automatic Storage Management (ASM), and RDBMS software
binaries will be installed. Though the storage requirement for an individual home is between 8 GB and 4 GB, it is
best advised to have at minimum a 100-GB file system under which the homes will be deployed to sustain future
requirements, such as upgrades and patching, and also to maintain an adequate free space for various cluster and
database logs.
When you have a complex cluster environment with a large number of nodes, let's say 20 or more nodes, and
if the Oracle Homes on each node are configured locally on a local file system, you not only require a large amount
of space to house them—say 2 TB for 20 nodes—managing the environment becomes not only complex but also
expensive from a storage cost factor perspective.
The administrative complexity and cost can be cut down by sharing the Oracle Homes across nodes in a cluster.
Oracle gives the flexibility to have the software installed once in a shared cluster file system, so that it is shared among
all other nodes in a RAC cluster. The key advantage of this approach is not only to reduce the overall installation
duration of remote copy operation, but also to drastically reduces the storage requirements for other nodes. You can
use any Oracle-certified or -supported shared storage to install the Oracle Homes.
During a fresh cluster installation, when a shared storage location is specified to install the software, OUI
automatically detects and adjusts to the environment and bypasses the remote node software copy option, speeding
up the installation. In addition, this kind of setup requires less storage for the software installation and potentially
reduces the duration when you plan to deploy a patch on the existing environment or plann to upgrade the
environment. Adding additional nodes also becomes faster when shared Oracle Homes are in place.
The out-of-place upgrade option introduced recently in 11gR2 (11.2.0.2) won't really hamper the current Oracle
Homes much, as it doesn't require a prolonged downtime during the course of the upgrade. Whereas, the patch
deployment in a shared home requires a complete cluster-wide downtime in contrast to non-shared Oracle Homes.
Regardless of shared or non-shared Oracle Homes, both settings have their share of strengths and weaknesses.
The following highlights some pros and cons of shared Oracle Homes:
Pros:
•
Less storage requirement
•
Oracle Homes backup becomes faster and takes less storage, as it is just a single copy
•
Add node (cloning homes) process takes considerably less time
•
Patching, upgrade process will become quicker
•
All cluster and database logs across nodes can be put under one roof
•
Patch consistency will be guaranteed across nodes
Cons:
•
Cluster-wide downtime for patching and upgrade
•
Rolling upgrades and patching is not possible
•
High-level risk of single point of failure
•
If the nodes' OS are incompatible, will result in cluster instability
