Oracle Database 11g: "Client Failover" en "Standby Databases" ( Part I )

Oracle Database 11g: "Client Failover" en "Standby Databases" ( Part I )

Por Joel Pérez  & Mahir M. Quluzade
Publicado en Septiembre 2015

Reciban estimados tecnólogos Oracle un cordial saludo. A través del presente artículo, tendremos la oportunidad de tratar un tema de gran importancia como lo es el concepto de “Client Failover” en ambientes de bases de datos “Standby”
Introducción
En repetidas ocasiones cuando analizamos infraestructuras e implantaciones de clientes, una de las primeras actividades que realizamos es el chequeo de cómo las buenas practicas están implementadas o si realmente lo están.
Al momento de realizarlo en materia de “Standby Databases”. Siempre hacemos una pregunta típica: ¿Cual es procedimiento o método que aplican/usan para manejar las conexiones de aplicaciones al momento en que se ha llevado a cabo un “Switchover” o “Failover”?
Las respuestas son diversas, la más típica en muchos casos es:
“...como casi nunca realizamos “Switchover” y mucho menos “Failover” es poco común que tengamos que re-direccionar las conexiones de nuestras aplicaciones.. por lo tanto dado el momento en que tengamos que realizar dicha operación, nos dirigimos al servidor de aplicaciones, allí editamos de forma manual el “Tnsentry” que direcciona a nuestra base de datos de producción, y lo cambiaremos para que direccione posteriormente al servidor “Standby”... en el cual estará operando la base de datos con rol primario”
En líneas generales muchos clientes aplican métodos manuales para re-direccionar sus aplicaciones hacia servidores con bases de datos “Standby”, una vez efectuada una operación de tipo “Switchover” o “Failover”.
Antes de ir mas allá en este tema hay una pregunta que deberían hacerse todos los DBAs que implantan soluciones de “Standby Databases”/”Data Guard”. Los productos Oracle gozan de un nivel elevado en tecnicismo y mas aun cuando estos poseen diversas versiones de desarrollo tal como el tema relacionado con “Standby Databases”/”Data Guard”. La pregunta seria la siguiente: Si las soluciones mencionadas poseen alto tecnicismo para realizar operaciones de “Switchover”/”Failover” y mas, ¿“Oracle Corp.” dejaría de lado el desarrollo o disponibilidad de un modo para que las aplicaciones puedan estar en alta escalabilidad con lo mencionado anteriormente?
La respuesta para el caso es: Si, “Oracle Corp” posee solución y modo para ello, lo mismo es denominado “Client Failover” para conexiones de aplicaciones. El concepto referido a “Client Failover” no está basado solo para el contexto de “Data Guard”.
Para mayor información al respecto les dejamos acá unos enlaces en cual podrán abarcar en forma profunda toda la información al respecto:
Client Failover Best Practices for Highly Available Oracle Databases: Oracle Database 11g Release 2
http://www.oracle.com/technetwork/database/features/availability/maa-wp-11gr2-client-failover-173305.pdf
Client Failover Best Practices for Highly Available Oracle Databases Oracle Database 12c
http://www.oracle.com/technetwork/database/availability/client-failover-2280805.pdf
How To Configure Client Failover For Dataguard Connections Using Database Services
El objetivo de este artículo es exponer de forma breve y efectiva una de las principales técnicas para conseguir implementar “Client Failover” en solución “Data Guard”. A través de los enlaces proporcionados, usted podrá abarcar el tema en un contexto general.
Iniciemos…
En la siguiente figura se expone una configuración típica de una solución “Data Guard”

Los primeros cambios a ser aplicados serán para los archivos “tnsnames.ora” & “sqlnet.ora” de servidores y clientes. En la figura podemos visualizar un servidor con IP: 192.168.56.146 el cual funge conceptualmente como servidor primario y el segundo con dirección IP: 192.168.56.136 como servidor “Standby”. En la descripción del “Tnsentry” encontrara la inclusión de ambos servidores. En el archivo “sqlnet.ora” la inclusión del parámetro “SQLNET.INBOUND_CONNECT_TIMEOUT”

Para mayor información del uso del parámetro “SQLNET.INBOUND_CONNECT_TIMEOUT”, colocamos acá la referencia textual de su descripción proveniente de la documentación oficial Oracle.
http://docs.oracle.com/cd/B28359_01/network.111/b28317/sqlnet.htm#CIHCCCHD

El objetivo principal del articulo y de la técnica que estamos exponiendo es presentar una configuración en la que sea posible que el cliente pueda conectarse indistintamente a la base de datos primaria independientemente de que esta se encuentre en cualquiera de los servidores sin modificar los archivos del cliente para cuando ocurra alguna transición ocasionada por un “Switchover” o “Failover”.
En la figura tenemos como ejemplo la ejecución de una operación de “Failover”. Internamente en la base de datos de producción y por consiguiente de forma replicada en la base de datos “Standby”, tendremos un servicio que para el presente caso lleva por nombre “ADMAPP”. El mismo estará iniciado “started” solo en la base de datos primaria, en la base de datos “Standby” el mismo estará detenido. El control para lo mencionado lo establecernos a través de un disparador en evento “Startup on Database”. Tal como podrán visualizar el código es bastante sencillo, si el rol que ejecuta dicha base de datos en ese momento es de tipo “Primary” entonces se procederá a su inicio en caso contrario permanecerá detenido como es su condición por defecto al momento del inicio de la base de datos.


Ubiquémonos en el escenario en el cual ya se ha llevado a cabo una operación de “Swithover” o “Failover”. Como resultado de la misma la base de datos primaria transformo su rol a “Standby Database” y viceversa para la original “Standby Database”, la cual para el momento desempeñaría rol como base de datos primaria.
Para el caso descrito, los clientes podrán establecer conexión sin problema alguno bajo esta nueva configuración debido a que el servicio “ADMAPP” se encuentra iniciado en la base de datos primaria que se encuentra trabajando en el servidor ( 192.168.56.136 ). Analizando la configuración “tnsentry” descrita, observara que la misma soporta la conexión descrita.

Entonces de esta sencilla manera podemos establecer “Client Failover” para bases de datos “Standby”. Lo mostrado acá es solo el concepto principal. Hay información adicional que conocer con respecto a que pasaría con el funcionamiento del “Observer” en caso de estar configurado, como aplicar TAF y sus efectos.. etc .. todo ello lo abarcaremos en la próxima entrega.
Para concluir el presente artículo mostremos un ejemplo de “tnsentry” para soportar el modelo descrito para ambiente RAC. Tal como puede apreciarse, poseemos una entrada para una configuración RAC, para dicho caso seria la solución típica que conforma el primario ( Base de datos de producción en RAC ) y el lado “Standby” configurado para el presente caso con un servidor con base de datos “Single Instance”. Descripción de la figura:
*  “LOAD_BALANCE” & “FAILOVER” para los 2 elementos de la lista ( Configuración RAC & “Single Instance” )
* Como es de forma natural y habitual, “LOAD_BALANCE” para la configuración interna de la solución RAC.

Estimados lectores hemos llegado al final de esta entrega, esperando que el presente artículo sea de utilidad. Nos despedimos hasta la próxima entrega.
Saludos!