1. ORACLE RAC
Oracle Real ApplicationClusters (RAC) es una opción software para el SGBD Oracle producida por la
Corporación Oracle.
Introducción
Oracle RAC permite que múltiples computadoras ejecuten el software de SGBD de Oracle simultáneamente
mientras acceden a una base de datos individual. Esto se llama una base de datos en grupo (cluster o
clustered).
En una base de datos de Oracle no-RAC, una base de datos individual es accedida por una instancia individual.
La base de datos se considera la colección de ficheros de datos, ficheros de control, y ficheros redo log
localizados en disco. La instancia se considera la colección de procesos del sistema operativo y memoria
relacionada de Oracle que están ejecutándose en el computador.
En Oracle RAC, dos o más computadoras (cada una con una instancia) acceden concurrentemente a una
base de datos individual. Esto permite que una aplicación o usuario se conecte a alguno de los computadores y
tenga acceso a los mismos datos.
ORACLE RAC
Real Application Clusters o RAC es un software que permite utilizar un cluster de servidores ejecutando múltiples
instancias sobre una misma base de datos. Los archivos de base de datos quedan almacenados en discos, física
o lógicamente conectados a cada nodo, de modo tal que todas las instancias activas pueden leerlos o
escribirlos. El software de RAC maneja el acceso a los datos, de modo tal que los cambios en los datos son
coordinados entre las instancias y cada instancia ve imágenes consistentes de la base. El interconnect del cluster
permite que las instancias se pasen entre ellas información de coordinación e imágenes de los datos. Esta
arquitectura permite que los usuarios y aplicaciones se beneficien de la potencia de procesamiento de múltiples
máquinas. La arquitectura RAC también ofrece redundancia; por ejemplo, en el caso de que un nodo quede
inutilizado, la aplicación continuará accediendo a los datos vía el resto de las instancias disponibles.
Un cluster es un grupo de servidores independientes que cooperan comportándose como si fueran un solo
sistema.
En entornos RAC, la sincronización “internodo” es crítica para mantener una adecuada coordinación entre los
distintos procesos en diferentes nodos. RAC utiliza lo que se conoce como Global Resource Directory (GRD)para
registrar información sobre cómo los recursos son utilizados dentro de una base de datos en cluster. Global
Cache Services (GCS) y Global Enqueue Services (GES) administran la información del GRD.
Acerca de la reconfiguración dinámica, RAC utiliza el Global Resource Directory (GRD) para registrar información
sobre cómo son utilizados los recursos dentro de una base de datos en cluster. Cada instancia mantiene una
porción del GRD en su propia SGA. Cuando una instancia abandona el cluster, es necesario redistribuir la porción
del GRD que administraba entre los nodos sobrevivientes. Algo análogo ocurre cuando una nueva instancia se
suma al cluster, las porciones del GRD de cada instancia necesitan redistribuirse para crear la nueva porción de
GRD correspondiente a la instancia que se suma. En vez de remasterizar todos los recursos a través de todos los
nodos, RAC utiliza un algoritmo denominado lazy remastering que remasteriza una cantidad mínima de recursos
durante una reconfiguración.
La memoria específica para la administración del RAC se aloja mayoritariamente en la Shared pool. Como los
bloques pueden ser cacheados a través de las instancias es necesario contar también con buffer caches más
grandes. Al migrar una base de datos Oracle single instance a RAC, si se pretende que cada nodo mantenga su

2. rendimiento con los mismos niveles de carga que en single instance, habrá que asignar un 10% más de memoria
a la buffer cache y un 15% más a la shared pool. Estos valores son heurísticos, basados en experiencias de RAC a
través del tiempo. Sin embargo, hay que considerar que generalmente los requerimientos por instancia se ven
reducidos cuando la misma cantidad de usuarios y carga de trabajo es distribuido en múltiples nodos.
Una de las nuevas características incluidas en el software de Oracle es la creación de clusters de
base de datos (llamado Real ApplicationCluster – RAC). De acuerdo a Oracle, esta funcionalidad
permite disponibilidad 24/7, desempeño y escalabilidad. Adicionalmente a esto se incluye la
definición de failover transparente (TransparentApplicationFailover – TAF) que utilizan las
aplicaciones para sincronizar sus peticiones con el clúster de Oracle sin que éstas se enteren que
alguno de los nodos del clúster se ha desconectado.
¿Cómo funciona?
Conceptualmente, la arquitectura del Oracle RAC se muestra en la siguiente figura:
Diagrama conceptual del
funcionamiento de un Oracle RAC
(configuración en failover)

3. Las peticiones a la base de datos son generadas por la aplicación (por ejemplo, desde un pool de
conexiones configurado en un Application Server), y el Oracle RAC en su conjunto es el encargado
de direccionar las peticiones al servidor que esté en funcionamiento. Nótese que en esta
configuración no existe un balanceo de cargas, por lo que la configuración mostrada es
exclusivamente en failover (es decir, todas las peticiones llegarán al Nodo 1, y sólo en caso de que
éste deje de funcionar, las peticiones se redireccionarán al Nodo 2).
Ahora bien, es necesario contemplar cómo funciona realmente el Oracle RAC. Esto se puede ver
mejor si utilizamos un diagrama de componentes de software:
Diagrama de componentes Oracle RAC
En realidad, el cliente o servicio de Oracle está configurado para tener como conexión primaria el
Nodo 1; si no es posible ejecutar la petición enviada a dicho servidor, el servicio se encarga de
realizar un redireccionamiento de la misma hacia el servidor de respaldo (en este caso el Nodo 2).
Adicionalmente, es necesario mencionar que lo que está corriendo en los Nodos 1 y 2 es
el listener del motor de base de datos, no la base en sí: la información de la base (los archivos que
componen la DB) se encuentra en un arreglo de discos con configuración en mirror para proveer
redundancia y por lo tanto, alta disponibilidad. En resumen:
Oracle RAC es un componente de software que permite la creación de múltiples instancias del
motor de base de datos de forma independiente, compartiendo un mismo almacenamiento.
Sin embargo, RAC posee dos limitaciones muy importantes que es necesario considerar:
1. No existe un balanceo de carga entre los nodos de base de datos que componen el Oracle
RAC: ésta configuración por default sólo permite el failover de las peticiones realizadas
sobre la base de datos y si el diseño de la arquitectura requiere la optimización de recursos,
prácticamente se está desperdiciando la mitad del poder de procesamiento de la capa
del back-end.
2. Dicho failover no es tan transparente como dice Oracle (ver adelante).
Utilizando TAF
Una vez que un nodo del Oracle RAC se desconecta (ya sea por falla de hardware, red o
sobredemanda de recursos), todas las transacciones deben ser redireccionadas automáticamente
al nodo de respaldo. El punto de dicho esquema consiste en no perder las transacciones que se
encontraban en vuelo en el momento de la desconexión.

4. El problema radica en que de acuerdo al mismo Oracle, para hacer uso la funcionalidad de TAF es
necesario utilizar el API del Oracle Call Interface – OCI. En pocas palabras, es necesario instalar un
cliente de Oracle en el servidor de aplicaciones, y el simple uso de un driver de conexión a la base
de datos (por ejemplo, el ThinClient de Java) no es suficiente.
Adicionalmente, cuando menos para la versión 10g de Oracle, TAF sólo realiza failover transparente
para queries de tipo SELECT. Todos los demás tipos de operaciones marcarán un error
automáticamente:
Queries transaccionales o de manipulación de datos: INSERT, UPDATE y DELETE.
Operaciones de manejo de sesión: ALTER SESSION y SQL*Plus.
Objetos temporales (aquellos que utilizan el espacio de trabajo TEMP).
Estados obtenidos durante la ejecución de StoredProcedures (PL/SQL).
Así entonces, llegamos a la siguiente conclusión:
Oracle RAC no garantiza por sí mismo un failover transparente (sólo garantiza disponibilidad de la
base de datos). El failover es implementado por el OCI en el cliente de Oracle, con ciertas
restricciones.
Esto limita la viabilidad de Oracle RAC considerando el costo-beneficio pues éste se cotiza de forma
separada al motor de la base de datos.
Mejorando Oracle RAC
Sin embargo, no todo está perdido. Ambos problemas (balanceo de cargas y failover transparente)
pueden ser resueltos mediante un clúster con balanceo de carga por hardware o software. La
escalabilidad de dicha solución depende más bien del presupuesto con el que se cuenta, pero
soporta la decisión de implementar un Oracle RAC para alta disponibilidad de la base de datos.
El esquema conceptual se muestra en la siguiente figura:
Oracle RAC con balanceo de cargas
El encargado de realizar la distribución de carga es el balanceador. Éste puede ser un componente
de software (por ejemplo, un Web Server con balanceo round-robin como Apache) o uno de
hardware (como un Switch F5) de tal forma que:

5. No exista dependencia hacia un Oracle Client instalado en el servidor de aplicaciones. Esto
es especialmente importante cuando no se puede instalar este componente o es necesario
incrementar la portabilidad de la plataforma.
Se optimizan los recursos al distribuir la carga entre los dos o más servidores que componen
la solución.
El componente de balanceo es el encargado de detectar las caídas de los nodos de la
capa de back-end. El cómo se detectan dichas caídas depende del componente utilizado
(por ejemplo, mediante pings alheartbeat de los nodos) y puede configurarse de la
siguiente manera:
o Redireccionamiento al primer error. Cuando ocurre un error de desconexión, el
componente redirecciona las demás peticiones que lleguen hacia los demás nodos
de la plataforma, hasta que vuelva a recuperar el heartbeat del nodo afectado. El
detalle es que las peticiones en vuelo regresan un error. Esto se tendría que resolver
con un mecanismo de reintento ya sea en la aplicación misma o en el contenedor
(en caso de que el Servidor de Aplicaciones y el driver de base de datos soporten
dicha funcionalidad). Para este caso particular, puede utilizarse el Oracle Cache
Fusion, que básicamente es un componente que permite sincronizar bloques de
datos entre los nodos del clúster, pero con esta solución perdemos el balanceo de
cargas.
o Redireccionamiento sin pérdida. Este se logra utilizando una combinación del
cliente OCI, el balanceador de carga y una configuración especial del TAF donde
se especifica que las peticiones deben lanzarse a ambos nodos de la plataforma y
el que llega primero es resuelto (descartando el segundo). Esto en efecto permite
un failover completamente transparente sin necesidad de modificaciones en la
aplicación, pero tiene un inconveniente: duplica el tráfico transaccional entre las
capas de middle y back end.
o La opción con SunCluster. De acuerdo a Sun Microsystems, el SunCluster permite
realizar un redireccionamiento sin pérdida y sin necesidad de configuraciones
adicionales a la plataforma: el SunCluster y los agentes instalados en cada uno de
los nodos se dedican a sincronizar las peticiones evitando la pérdida de
transacciones en caso de un error. Esto es el equivalente al failover de una
aplicación web donde las sesiones de usuario se migran entre los nodos activos del
clúster en caso de que uno falle.
Conclusiones
Oracle RAC es un componente que nos permite agregar alta disponibilidad a nuestro back-end al
ofrecer múltiples instancias de una base de datos (con una sola unidad de almacenamiento),
permitiendo con la ayuda de un componente de balanceo, alta escalabilidad y disponibilidad de
los servicios ofrecidos por la base de datos.