Oracle RAC

Oracle RAC ( Oracle Real Application Clusters ) is an additional option of the database management system from Oracle. Oracle RAC enables fault tolerance by accessing multiple nodes of a computer network (English clusters) on the same database and provide for client computer database services. If one of nodes, assume the other its functionality. In addition, Oracle Real Application Clusters can be used as a way of scaling: there is not enough capacity for a database server, it can be supplemented by another computer node. In order to achieve optimal scaling in the Oracle database cluster, but the application design must be adapted to the requirements of parallel cluster accesses. The Oracle Real Application Clusters serves as the basis of the Oracle Grid in the database backend.

Architecture

When using the Oracle Real Application Clusters in normal operation two or more server nodes in a cluster ( computer network ) is activated and access to the same data to. Although each node maintains a separate database instance, but which is interconnected via the cache fusion technology with the database cache of all computers in the cluster. So it makes the user almost no difference which node to be accessed actually arrives.

The advantage: If one host fails, then clients can connect directly and without restart time remaining on a computing node. In addition, loads can be distributed to all cluster nodes. Long -running operations can be parallelized by means of parallel slave processes also over the entire cluster. Thus, in addition to the increased availability is also the subject scaling one of the strengths of the Real Application Clusters. Redundant hardware is used not only in the event of an error, but may - be used in normal operation - unlike failover clusters.

Similar to an Oracle failover cluster also a private network for the cluster heartbeat and one of them -separated public network is needed. However, in Oracle Real Application Clusters is accessed concurrently on the database files of a shared storages. This requires additional communication overhead between the nodes, which is necessary for tuning locks and modified block images. This cluster communication is done via the private network. In Real Application Clusters environments, it is therefore important to use the fastest possible private cluster interconnect. Gigabit Ethernet at least should be used. Better still are special, often proprietary solutions with higher bandwidth. Examples are memory channel (alpha -based HP cluster), Myrinet (Linux systems), Scalable Coherent Interconnect ( SUN), Veritas LLT (various platforms) or HP Hyper- Fabric HMP.

Components

Required components for the use of an Oracle Real Application Clusters are:

  • Shared storage for all participating cluster nodes ( shared access to SCSI, SAN or NAS device from any of the computers in the cluster )
  • Using a cluster file system, ASM or raw devices on shared storage
  • For each cluster node of at least two each, and two private Public Network interface
  • Oracle Cluster Ready Services must always be used in version 10g. In addition, a cluster management software from another manufacturer to be installed.

Pros and Cons

Benefits of Oracle Real Application Clusters

  • Acquisition of functionality in a server without administrative intervention failure
  • Little time needed for restart Client Reconnect ( reconnection recording to the database from another database server in the cluster ) is done for the user or the application for SELECT statements transparently and within a few seconds on the replacement node
  • The entire hardware can - in contrast to the failover cluster - also be used during normal operation.
  • Parallelization on all cluster nodes across feasible
  • Dynamic allocation of services possible
  • Compensation of a data center loss if the RAC and its shared media was distributed accordingly ( " stretched clusters " until about 2000 m )

Disadvantages of Oracle Real Application Clusters

  • Stretching of the cluster is around 2,000 m no longer possible ( latency problems). In case of failure of the data center (eg by fire ) falls out of the entire cluster. This error event can be intercepted in combination with Oracle Real Application Clusters or by metro clustering, if necessary by use of an additional standby database.
  • No or only limited interception of logical corruptions possible (block corruption, operator error ). These errors may be due to a time-delayed standby database (Oracle Data Guard ), data backup and data recovery combined with a roll-forward or even in many cases are intercepted by Oracle Flashback.
  • Every time an instance fails, the entire database is not available, and until such time as the GRD (Global Resource Directory ) has been restarted and SMON has identified all the blocks required for instance recovery and get. Only from this point it is possible to access all the blocks except the necessary for recovery. Only when the instance recovery is completely finished, all data is fully available.
  • If at the same time or in quick succession on multiple instances of the cluster data requested which are in the same database blocks, these are transferred between the buffer cache of the affected instances. In extreme cases, this may mean that the database who only work to push the blocks back and forth.

Tools for managing

Oracle Real Application Cluster is supported by the following administration tools:

  • Database Configuration Assistant (short: DBCA ) to create and basic configuration of cluster databases with Oracle
  • Oracle Enterprise Manager Grid Control: Graphical user interface for managing an Oracle grid including Oracle Real Application Clusters
  • Server Control Utility: command-line -oriented tool for managing databases, services and applications in a Real Application Clusters
Oracle Corporation Client (computing) Cache (computing) Clustered file system Service (economics)
622539
de