Database Reference
In-Depth Information
hardware maintenance or to deal with capacity problems on a given host. Almost all visualization solutions try to
automate dealing with failure transparently, which plays nicely toward the requirement to not require a lot of
hands-on management.
Another popular approach is to use an active-passive cluster. Most active/passive clusters are still easy to manage
since the cluster management software takes care of resource management and failover to the passive node. You
achieve higher availability than with a single instance database by means of the cluster framework. A lot of cluster
frameworks exist for Oracle from all the major vendors, operating off the following simple principles:
•
A dedicated active/passive cluster consists of two nodes. More nodes often do not make sense
in active/passive configurations. Quite often, such a setup is dedicated to a specific product
and does not normally host more than a couple of databases.
•
Storage is provided to the active node. There are exceptions when a cluster logical volume
manager, such as Oracle's Automatic Storage Management, or alternative is in place.
•
Important entities are grouped into cluster resources. From an Oracle point-of-view, these
include the OFA and database file systems, the listener process(es) and the database(s),
among others. Resources can be logically grouped.
•
All resources have metadata associated with them. Among the information stored is a check
interval, the command to check for the resource's status, start retries, and a failover process.
•
An agent process monitors resources according to the metadata stored.
•
In case a resource has been detected as “failed,” and it cannot be restarted on the node it was
running on, it will be started on the passive node.
Again, most of this processing is automated internally by the aforementioned agents and the cluster framework.
There will be an outage to the clients, at least for the duration of the instance recovery. If you are unlucky, you might
have to wait for a file system consistency check after the Oracle-related file systems are mounted to the passive node.
Cluster file systems can prevent this problem from happening, but, for most, you need to pay an extra license.
The final option you have at your disposal is to cluster your database in an active/active way. The only way to
do so is to use the Real Application Clusters option to the Oracle database. RAC takes away the strict 1:1 mapping of
the Oracle instance to the database. Remember that the Oracle instance is the transient part of Oracle in memory,
whereas the files on hard disk are referred to as the database. In RAC systems, you have multiple instances running
on multiple hosts accessing the same database, so RAC is a high-availability solution and does not protect you
from disasters or human error. RAC has been designed so the cluster appears as one database to the end user, and
sophisticated programming allows for a single SGA across all the cluster nodes. RAC can be hugely beneficial to
applications, if written with the special demands of RAC in mind. RAC has many advanced workload management
features available to application developers, most of which aim at making instance failure more or less transparent to
the application. In case of a RAC instance failure and supporting programming in the application, there is usually very
little delay in processing. RAC can also be instructed to recreate failed sessions on another cluster node.
Unfortunately, many RAC features are not fully exploited in application code. This becomes even more apparent
when considering an advanced RAC deployment: extended distance clusters. Extended distance clusters split the
RAC setup across two data centers that can be a few miles apart. Each data center uses its own storage array to store
the database, while Oracle Automatic Storage Management (ASM) keeps the arrays in sync.
In the field, it turns out that deploying a RAC system can be time consuming. Any RAC deployment requires
networking, storage, and operating system support teams to work together closer than with the classic single instance
database. Storage needs shared between RAC cluster nodes, and a RAC system needs a few more IP addresses. Finally,
RAC requires a little more preparation on the operating system to work.
To streamline the RAC rollout process, Oracle developed what it calls Engineered Systems. Following the idea of a
pre-packaged and pre-configured deployment, these systems allow for quicker installation and setup.
The Oracle offerings for the relational database include the Oracle Database Appliance (ODA), as well as Exadata.
The Database Appliance has recently been upgraded to the X3-2 model and comprises two dual-socket servers with
10GBit/s Ethernet and 256 GB of DRAM each. Storage in the form of spinning hard disk complemented with SSD is
directly attached in a bay and connected via the Serial Attached SCSI interface.
Search WWH ::
Custom Search