PDF de programación - Implementando Transparent Application Failover sobre Aplicaciones .NET

Implementando Transparent Application Failover sobre Aplicaciones .NET

Por Francisco Riccio



Introducción

Oracle Database ha venido ofreciendo durante versiones anteriores su tecnología Oracle Real
Application Cluster (RAC) como solución de Alta Disponibilidad de Base de Datos, el cual tiene una
arquitectura similar a la que se presenta:

Figura 1



Donde diferentes aplicaciones (cliente/servidor o web) irán conectándose a los diferentes servidores
de base de datos que conforman la solución de Oracle RAC.

Revisar el siguiente link para más información sobre Oracle Real Application Cluster:

http://www.oracle.com/us/products/database/options/real-application-
clusters/overview/index.html



Muchas aplicaciones montadas sobre una arquitectura en Oracle RAC, suelen considerar que una
conexión de base de datos establecida siempre estará disponible; pero en la realidad no siempre



1

Red PúblicaInterconnectStorageNodo-02Nodo-01MiddlewareOracle Real Application Cluster será así; debido a que el servidor de base de datos puede tener un reinicio, congelamiento o
cualquier incidente provocando que sus conexiones de base de datos se desconecten.

Por lo cual, surgen algunas preguntas como: ¿Nuestras aplicaciones están manejando el evento de
pérdidas de conexiones?, ¿En caso de una desconexión, el usuario de la aplicación lo percibirá?, ¿En
caso de una reconexión de base de datos que sucede con la información que estuvo manipulando el
usuario?. Seguramente estas preguntas ya dejaron a más de uno preocupado.

Oracle Database nos ofrece 2 tecnologías disponibles que permiten que nuestras aplicaciones
puedan contar con mecanismos de alta disponibilidad a nivel de sesión:

Estas 2 tecnologías son: Transparent Application Failover (TAF) y Fast Connection Failover (FCF).
Ambos son excluyentes.

Más adelante se explicará en detalle TAF como objetivo de este documento.

Es importante mencionar que estás tecnologías se implementan mediante servicios de base de datos
y no es exclusivo para Oracle RAC, el cual es un error conceptual bastante frecuente. Es decir,
nosotros podemos implementar TAF y FCF en ambientes de base de datos single instance protegidos
mediante Oracle Restart o también mediante Oracle Data Guard o cualquier tecnología de
replicación que permita mantener una copia de la base de datos productiva donde las aplicaciones
se reconectarán.

Recomiendo revisar la Arquitectura de Máxima Disponibilidad de Oracle (MAA) en el siguiente url:

http://www.oracle.com/technetwork/database/features/availability/maa-096107.html

A continuación se presentará un ejemplo didáctico de cómo implementar Aplicaciones .NET con TAF
con la finalidad de contar con un mecanismo de alta disponibilidad no solo a nivel de base de datos
sino también a nivel de conexión.

Se asume que el lector maneja ODP.NET, en caso no lo sea, recomiendo revisar el siguiente url:

http://www.oracle.com/technetwork/es/articles/dotnet/implementar-aplicaciones-net-1924201-
esa.html

La implementación que más adelante se mostrará, se ha realizado sobre un Oracle RAC 12cR1
(12.1.0.1) en configuración Standard Cluster sobre plataforma Oracle Linux 5 Update 9 de 64 bits y
.NET Framework 4.0 con ODP.NET 4. El IDE de desarrollo es sobre Visual Studio 2010 basado en el
lenguaje C#.













2

Implementación - Transparent Application Failover (TAF)

TAF es una característica ofrecida mediante el driver OCI (Oracle Call Interface) y permite
automáticamente reconectar las conexiones fallidas de base de datos, es decir, ejecuta un failover
de sesión de base de datos. Solo está disponible para aplicaciones que utilicen las librerías OCI y está
disponible por defecto. TAF no está disponible para conexiones creadas por RMAN.

Es importante notar que una reconexión recién se iniciará cuando la aplicación intente ejecutar
alguna operación sobre la base de datos usando su conexión fallida y no antes.

La reconexión realizada, generará una nueva conexión idéntica a la original pero con las siguientes
observaciones:

 La reconexión automática utilizará la misma cadena de conexión que mantuvo la conexión

fallida.

 Configuraciones específicas de una sesión tales como: Formato de Fecha, Territorio, Idioma,
etc., no serán establecidas en la nueva conexión. Esto debe ser manejado mediante código
en la aplicación como veremos más adelante.

 Si una desconexión de base de datos ocurre cuando se estuvo realizando una operación de

FETCH mediante un cursor, este podrá ser continuado en la nueva conexión que se
establezca, es decir, el cursor podrá seguir devolviendo las filas faltantes y permitiendo la
continuidad del proceso funcional de la aplicación.

 Cualquier transacción que estuvo pendiente de confirmación se le ejecutará un rollback

automáticamente durante el proceso de failover de sesión.

 Variables establecidas en código anónimo de PL/SQL o en paquetes no serán mantenidas en

la nueva conexión establecida.

Existen múltiples propiedades que pueden ser configuradas para TAF, las cuales pueden ser
realizadas desde el lado del servidor (configuración en el servicio de base de datos) o desde el lado
de la aplicación (configuración en la cadena de conexión). En caso se realicen en ambos lados
(servidor/cliente) siempre predomina las propiedades establecidas por el lado del servidor.

Recomiendo siempre establecer las propiedades de TAF en el servicio de base de datos porque de
esta manera centralizamos la configuración en un solo lugar, en vez de preocuparnos de realizar la
aplicación en cada estación cliente.

Las propiedades que pueden ser establecidas son:

Parámetro

Descripción

METHOD

BASIC: Crea una conexión de base datos en el momento de solicitar un failover.

PRECONNECT: Se establece una conexión secundaria a la original, utilizando
mínimos recursos para esta segunda conexión y estará preparada en caso de un
failover, de manera que la reconexión sea más rápida. Esta opción solo está



3

disponible cuando trabajamos con servicios de base de datos administrados por el
administrador y debe contar con al menos 1 instancia disponible (AVAILABLE) para
el servicio.

TYPE

NONE (default): Previene de ejecutar un failover de conexión.

SESSION: Permite la reconexión automática sin restablecer las operaciones de
FETCH que los cursores estuvieron realizando antes de la operación de failover.

SELECT: Permite la reconexión automática y reestablece las operaciones de FETCH
que estuvieron ejecutando los cursores antes del failover, es decir continua la
consulta SQL que estuvo en progreso. Adicionalmente utiliza una cantidad de
memoria adicional para mantener información necesaria para el failover, como: el
row fetch último, el SCN utilizado en el momento de obtener los datos y el SQL Plan
Hash.

Nota: Oracle Database ejecuta de nuevo la sentencia que estuvo ejecutándose
antes del incidente en la nueva conexión realizada, utilizando el mismo SCN que fue
utilizado en la sentencia original.

DELAY

Tiempo de espera en segundos para intentar una reconexión.

Número de intentos de reconexión que se realizarán hasta encontrar una conexión
exitosa.

RETRIES



Configuración:

a) Configurar la cadena de conexión hacia la base de datos.

Ejemplo utilizando VIP IP.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key="CONEXION" value="Data Source=(DESCRIPTION = (ADDRESS_LIST = (ADDRESS =
(PROTOCOL = TCP)(HOST = 142.68.1.150)(PORT = 1521))(ADDRESS = (PROTOCOL = TCP)(HOST =
142.68.1.151)(PORT = 1521)))(CONNECT_DATA=(SERVICE_NAME = TAF_APP)(SERVER =
DEDICATED)));User Id=friccio;Password=oracle"/>
</appSettings>
</configuration>


Ejemplo utilizando SCAN IP.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key="CONEXION" value="Data Source=(DESCRIPTION = (ADDRESS_LIST = (ADDRESS =
(PROTOCOL = TCP)(HOST = srvrac-scan)(PORT = 1521)))(CONNECT_DATA=(SERVICE_NAME =
TAF_APP)(SERVER = DEDICATED)));User Id=friccio;Password=oracle "/>
</appSettings>
</configuration>




4

ó

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key="CONEXION" value="Data Source=TAF_APP;User Id=friccio;Password=oracle;"/>
</appSettings>
</configuration>



De ambos ejemplos mostrados, se puede apreciar que la cadena de conexión está utilizando un
servicio de base de datos llamado TAF_APP.



b) Configuración del servicio TAF.

Por un mayor entendimiento, el servicio lo crearé en tres partes.

Paso 1: Definiendo el servicio sin alguna propiedad específica.



Paso 2: Modificando el servicio con TAF con Método BASIC y Tipo de Failover SELECT.





Paso 3: Configurando el número de reintentos a 6 y con una espera en cada reintento de 30
segundos.















5

Validando el Servicio:

Nota 1: A partir de la versión Oracle Database 11gR2, TAF puede trabajar con FAN con la finalidad de
disminuir el tiempo de detección del servicio caído de base de datos y así iniciar el failover de sesión
rápidamente.



Para habilitar FAN, debemos crear el servicio con la opción: -q true.

Más información sobre FAN revisar el siguiente URL:

http://docs.oracle.com/cd/E11882_01/java.112/e16548/apxracfan.htm#JJDBC28935

Nota 2: Cuando una base de datos no se encuentra en Oracle RAC ni tampoco está trabajando con
Oracle Restart, los servicios que deseemos implementar deberán ser creados a través del paquete
DBMS_SERVICE. Para un mayor detalle revisar el siguiente url:

http://docs.oracle.com/cd/E16655_01/appdev.121/e17602/d_serv.htm

Nota 3: Si deseamos crear un servicio con método PRECONNECT debemos crearlo de la siguiente
manera:





6

En este caso se ha creado un servicio con una Instancia Preferida (PRD1) y una Disponible (PRD2).

El servicio no debe ser creado con los parámetros -failovermethod y -failovertype.

Una vez