1

ALTA DISPONIBILIDAD DE DATOS E-BUSINESS SUITE R12

Autor: Alberto Silva Gallardo

Ubicación: Santiago de Chile Blog: http://cotosilva.blogspot.com

2

Antecedentes

Este documento, describe cómo hacer la configuración y construcción del esquema de alta disponibilidad de Datos para un Oracle E-Business Suite Reléase 12 y Oracle Data Guard 10.2.0.4

Dicha implementación y plan de pruebas se construirá sobre una arquitectura de E-Business Suite R12 concebido para un ambiente de Pruebas denominado TEST.

3

Arquitectura de E-Business Suite R12

El esquema de alta disponibilidad de datos diseñado, está soportado por 2 servidores, cada uno contiene una capa de base de datos, concurrentes y aplicaciones, separados geográficamente, uno ubicado en el SRVEBSDG1 (TEST) y el SRVEBSDG2 (Contingencia). Estos dos sitios están unidos, a través, de un enlace dedicado de 100MBits para tráfico y replicación de datos.

Los servicios de comunicaciones, debieran estar configurados para el acceso a la base de datos, y se recomienda mantenerlos separados del servicio de comunicación definido para la transferencia de datos en el DATAGUARD. Esta separación será, a través, de puertos de comunicaciones y no a través de IP.

Actualmente, la arquitectura de pruebas de E-Business Suite R12 está definida como single node, en el servidor SRVEBSDG1, el cual contiene la base de datos (standalone llamada TEST), procesos concurrentes y aplicaciones.

La arquitectura definida para pruebas, será sobre la base de la arquitectura actual de TEST, y actualmente en funcionamiento. Se provocarán situaciones de fallas (FAILOVER) afectando el ambiente productivo, esto será realizado en el nodo en contingencia, conformado por el servidor SRVEBSDG2 y el sitio de Producción principal servidor SRVEBSDG1.

A continuación, se muestra la gráfica con el diseño que va a ser implementado para el ambiente productivo. Y posteriormente, su explicación para cada una de las capas.

4

5

Diseño de funcionalidad implementada para Alta Disponibilidad.

El diseño de la arquitectura para el funcionamiento del ambiente de alta disponibilidad, está sobre base de datos 10.2.0.4 en uso por e-Business Suite R12.

Diseño y configuración a nivel de Aplicaciones & Procesamiento de Concurrentes.

El método a usar para lograr la habilitación de contingencia en Aplicaciones y Administradores Concurrentes (CM), es la Clonación de la capa de aplicaciones y administradores concurrentes, procedimiento que se realizará aplicando instructivos, que replican directorios hacia el sitio de contingencia de aplicaciones. Para esto, se utiliza el procedimiento Oracle Cloning R121, usando precloning y postcloning, de esta forma, se mantendrá sincronizada la copia del nodo primario (Testing), con la Aplicación y CM (Administradores Concurrentes) con el contenido en el nodo de contingencia.

1 Referencia Metalink Cloning Oracle Applications Release 12 with Rapid Clone (Note 406982.1)

6

Diseño y configuración a nivel de Base de datos Oracle.

La base de datos Standalone, tiene un método de replicación en forma permanente (Data Guard) hacia el sitio de contingencia, el cual estará registrando las transacciones inmediatamente en una base de datos, que está en modalidad standby. El método de protección a implementar en el Dataguard, es el que Oracle denomina como “MAXIMUM performance”. Este método, privilegia la independencia del sitio de contingencia, con el sitio primario frente a una catástrofe, pero se debe verificar y tener siempre sincronizada la base datos del sitio primario (TEST), con la base de datos que se encuentra en Standby (dataguard).

El método de escritura en el destino del Dataguard, se realiza a través del proceso background de Oracle LGWR, que paralelamente escribe en el redolog online y traspasa al LNS. Durante la transmisión de redo asíncrono, el Network Server Process (LNSn) Transmite redo data fuera de el redo logfile en línea en la base de datos primaria y no actúa directamente con el log writer process. Este cambio de comportamiento permite al log writer process (LGWR) esc ribir redo data al actual redo log file en línea y continuar procesando el siguiente Requerimiento sin esperar entre procesos de comunicación o network I/O para completar. .El proceso remote file Server (RFS) escribe los redo data a los standby redo logs en la base de datos Standby, A través, del proceso MRP (media recovery process), que se ejecuta en la standby, se van actualizando en la base las transacciones.

La implementación del Dataguard, permitirá que se pueda realizar Failover de la base de datos, pasando el rol principal desde el sitio primario, al sitio de contingencia. Se ha implementado la modalidad Failover.

Los puertos de comunicación para el dataguard , serán diferentes a los puertos de servicios, de los que escuchan para transaccionales de e-Business Suite, con la finalidad de aislar lógicamente el tráfico de replicación de la información, con los servicios de e-Business. El puerto TCP de conexión del tráfico a la base es 1521 y el puerto de tráfico del dataguard es el 1522.

Dado esto, cuando se realice el procedimiento de Failover, no se modificará ningún archivo de configuración existente, tanto entre el nodo primario y en el sitio de contingencia.

7

Real - Time Apply.

El concepto Real-Time Apply2 corresponde a una característica opcional y una mejora en Oracle10g DataGuard. Cuando se habilita esta característica, el servicio “Log Apply” aplica los cambios realizados desde los Standby Redo Logs, al mismo tiempo que los archivos de Log comienzan a ser escritos. De lo contrario, la recuperación de los cambios desde el archived redo log file ocurre cuando se genera un evento de Log Switch.

Cuando el servicio de Log Apply no se encuentra disponible, automáticamente recupera desde los archive log generados. Este proceso es automático, ya que en la configuración está definido el directorio donde estos archivos deben existir. Una vez que el servicio sea restablecido, automáticamente comenzará a aplicar los cambios el servicio “Log Apply”.

A continuación se mencionan los principales beneficios del “Real-Time Apply”:

a. Permite realizar operaciones rápidas de Switchover y Failover. b. Actualiza al instante resultados después de cambiar una base de datos en modalidad Standby física a read-only. c. Presentar reportes actualizados desde una base de datos Standby Lógica.

En la actualidad, Real-Time Apply se encuentra configurado y activado para el ambiente de TEST y Contingencia-Standby de EBS R12.

2 Referencia Metalink FAQ : Real Time Apply (Note:247618.1)

8

Configuración de Listeners

Ambiente de TEST

Listener Descripción

TEST Servicio e-Business en TEST

HA_TEST2 Dataguard transporte y resolución de GAP sitio Primario

Contingencia de TEST

Listener Descripción

TEST Servicio e-Business en TEST

HA_TEST2 Dataguard transporte y resolución de GAP sitio Secundario

9

Definición de Listener.

Ambiente de Pruebas

TEST = (ADDRESS_LIST = (ADDRESS= (PROTOCOL= IPC)(KEY= EXTPROCTEST)) (ADDRESS= (PROTOCOL= TCP)(Host=SRVEBSDG1 )(Port= 1521)) ) SID_LIST_TEST = (SID_LIST = (SID_DESC = (ORACLE_HOME=/oracle/product/10.2.0) (SID_NAME = TEST) ) (SID_DESC = (SID_NAME = PLSExtProc) (ORACLE_HOME = /oracle/product/10.2.0) (PROGRAM = extproc) ) ) HA_TEST2 = (ADDRESS_LIST = (ADDRESS= (PROTOCOL= IPC)(KEY= EXTPROCTEST)) (ADDRESS= (PROTOCOL= TCP)(Host= SRVEBSDG2)(Port= 1522)) ) SID_LIST_HA_TEST = (SID_LIST = (SID_DESC = (ORACLE_HOME= /oracle/product/10.2.0) (SID_NAME = TEST) ) (SID_DESC = (SID_NAME = PLSExtProc) (ORACLE_HOME = /u02/apps/orastby/u02/apps/oracle/product/10.2.0) (PROGRAM = extproc) ) )

10

Para los listener definidos en sitio de contingencia.

TEST = (ADDRESS_LIST = (ADDRESS= (PROTOCOL= IPC)(KEY= EXTPROCTEST)) (ADDRESS= (PROTOCOL= TCP)(Host= SRVEBSDG1)(Port= 1521)) ) SID_LIST_TEST = (SID_LIST = (SID_DESC = (ORACLE_HOME= /oracle/product/10.2.0) (SID_NAME = TEST) ) (SID_DESC = (SID_NAME = PLSExtProc) (ORACLE_HOME = /oracle/product/10.2.0) (PROGRAM = extproc) ) ) HA_TEST2 = (ADDRESS_LIST = (ADDRESS= (PROTOCOL= IPC)(KEY= EXTPROCTEST)) (ADDRESS= (PROTOCOL= TCP)(Host= SRVEBSDG2)(Port= 1522)) ) SID_LIST_HA_TEST2 = (SID_LIST = (SID_DESC = (ORACLE_HOME= /oracle/product/10.2.0) (SID_NAME = TEST) ) (SID_DESC = (SID_NAME = PLSExtProc) (ORACLE_HOME = /oracle/product/10.2.0) (PROGRAM = extproc) ) )

11

Servicios de Dataguard

Se definieron los servicios del Dataguard para transporte y resolución de GAP. Este mecanismo permite a una base de datos en modalidad Standby, temporalmente desconectada de la base de datos de Test después de un fallo de red, automáticamente sincronizar con la base de datos de producción sin ninguna intervención manual. Se define para esta resolución automática un canal distinto de comunicación conformado por un nuevo proceso Listener. El nuevo puerto asignado para escuchar es 1522 y su protocolo es TCP. El nuevo Alias generado para nuestro sistema de contingencia se define en el archivo tnsnames.ora que a continuación se describen. Así el cliente se comunica con el servidor.

HA_TEST2= (DESCRIPTION= (ADDRESS= (PROTOCOL=tcp) (HOST= SRVEBSDG2) (PORT=1522)) (CONNECT_DATA=(SERVICE_NAME=TEST)) )

Este servicio (con el alias ‘HA_TEST’) es la configuración de destinto del dataguard en el nodo secundario que está configurado en el nodo primario

HA_TEST= (DESCRIPTION= (ADDRESS= (PROTOCOL=tcp) (HOST= SRVEBSDG1) (PORT=1522)) (CONNECT_DATA=(SERVICE_NAME=TEST)) )

12

Resolución de GAP

La definición de los servicios del Dataguard de transporte para resolución de GAP, está dada a través, de la siguiente definición del archivo tnsnames.ora3.

Alias en tnsnames.ora definidos para nodo secundario o Standby. Esta configuración permite realizar SwitchOver; pero en el caso solo contemplado y configurado para realizar un Failover. HA_TEST2= (DESCRIPTION= (ADDRESS= (PROTOCOL=tcp) (HOST= SRVEBSDG2) (PORT=1522)) (CONNECT_DATA=(SERVICE_NAME=TEST)) )

Alias en tnsnames.ora definidos para nodo primario

HA_TEST= (DESCRIPTION= (ADDRESS= (PROTOCOL=tcp) (HOST= SRVEBSDG1) (PORT=1521)) (CONNECT_DATA=(SERVICE_NAME=TEST))

)

La configuración de los servicios FAL_SERVER y FAL_CLIENT4 está dada por los servicios que están definidos en el tnsnames del nodo primario y secundario como se muestra en los cuadros anteriores.

Así que para el nodo primario

fal_server='HA_TEST2'

fal_client='HA_TEST'

Para el nodo secundario

fal_server='HA_TEST'

fal_client=’HA_TEST2’

3 Referencia Metalink - Business Continuity for Oracle Applications Release 12 on Database Release 10gR2 (Note:452056.1)

4 FAL: Fetch Archive Log System

13

Conectividad entre el e-Business Suite y la base de datos

La conexión hacia la base de datos la hace e-Business Suite R12 utilizando una simple lista de conexiones en el tnsnames.ora, ubicados en forma secuencial, y además usa un archivo de conexión jdbc .

Esta lista generada en TNSNAMES.ora, está dada por la configuración de servidores primario, secundario y de contingencia. Sqlnet rutea secuencialmente los listener que están operativos, hasta que encuentra uno disponible. Allí establece el enlace con la base de datos.

Esta configuración permite que e-Business Suite pueda rutear automáticamente la conexión de la base de datos hacia la instancia secundaria en caso que la instancia primaria presente alguna falla o al sitio de contingencia si es que falla el sitio primario.

El archivo de configuración de conexión a la BD para e-Business es el tnsnames.ora y tiene la siguiente definición:

TEST=

(DESCRIPTION = (ADDRESS=(PROTOCOL=tcp)(HOST= SRVEBSDG1)(PORT=1521)) (ADDRESS=(PROTOCOL=tcp)(HOST= SRVEBSDG2)(PORT=1521)) (CONNECT_DATA = (SERVICE_NAME = TEST) (INSTANCE_NAME = TEST) ) )

El archivo de configuración de Apps tier para conectarse vía JDBC a la BD es el $FND_SECURE/PROD.dbc y debiera tener el siguiente párrafo definido:

APPS_JDBC_URL=jdbc\:oracle\:thin\:@(DESCRIPTION\=(ADDRESS_LIST\=(LOAD_BALANCE\=YES)(FAILOVER\=YES)(ADDRESS\=(PROTOCOL\=tcp)(HOST\= SRVEBSDG1)(PORT\=1521)))(CONNECT_DATA\=(SERVICE_NAME\=TEST))

14

Implementación de la configuración.

IMPORTANTE

Es necesario que el DNS reconozca los nombres, tanto de los servidores de aplicaciones, como los nodos de TEST y contingencia. Esto es, debido a que todos los archivos de configuración son conocidos por los nombres.

Configuración Dataguard

Para implementar el esquema de Data Guard se deberá seguir el siguiente procedimiento:

Referencia Metalink Business Continuity for Oracle Applications Release 12 on Database Release 10gR2 (Note:452056.1)

• Habilitar forced logging: Dado que algunas veces utiliza características de NOLOGGING en la base de datos, se deberá modificar para que la base standby sea consistente con la primaria. Ejecutar el siguiente comando como usuario sysdba sobre el SQL*Plus:

SQL> alter database force logging;

• Habilitar archive logs en producción: En el caso de no estar archivando redo logs, definir un directorio donde alojarlos y agregar estas líneas al archivo init /spfile en cada una de las instancias de E-Business correspondientes.

• Para los procesos de configuración se ocupará Spfile en vez de init.ora , ya que nos permitirá tener más automatización para los procesos de switchover y failover. Para este caso se ha implementado el archivo TEST_ SRVEBSDG1_ifile.ora, el cual tiene la configuración separada del tradicional archivo de parámetros que conforma la instancia. Cualquier modificación realizada al ambiente que signifique modificar parámetros a nivel de Data Guard o modificar destinos de archive logs es necesario modificar este archivo.

15

• Para nodo primario el archivo TEST_ SRVEBSDG1_ifile.ora posee la siguiente configuración:

db_unique_name=HA_TEST log_archive_config='dg_config=(HA_TEST,HA_TEST2)' log_archive_dest_1='LOCATION=/oracle/product/10.2.0/dbs/arch MANDATORY' log_archive_dest_2='service=HA_TEST2 valid_for=(online_logfiles,primary_role) db_unique_name=HA_TEST2 LGWR ASYNC=20480 OPTIONAL REOPEN=15 NET_TIMEOUT=30' log_archive_dest_state_2=enable fal_server='HA_TEST2' fal_client='HA_TEST' standby_archive_dest='LOCATION=/oracle/product/10.2.0/dbs/arch' standby_file_management=AUTO parallel_execution_message_size=8192 db_file_name_convert=('/oracle/oradata/test/','/stby/oradata/test/','/oracle/oradata/test/','/stby/oradata/test/','/oracle/product/10.2.0/dbs/','/stby/oradata/prod/') log_file_name_convert=('/oracle/oradata/test/','/stby/oradata/test')

• Para nodo secundario el archivo TEST_ SRVEBSDG2_ifile.ora posee la siguiente configuración:

db_unique_name=HA_TEST2 log_archive_config='dg_config=(HA_TEST,HA_TEST2)' log_archive_dest_1='LOCATION=/stby/oracle/product/10.2.0/dbs/arch MANDATORY' log_archive_dest_2='service=HA_TEST valid_for=(online_logfiles,primary_role) db_unique_name=HA_TEST LGWR ASYNC=20480 OPTIONAL REOPEN=15 NET_TIMEOUT=30' log_archive_dest_state_1=enable log_archive_dest_state_2=defer fal_server='HA_TEST' fal_client='HA_TEST2' standby_archive_dest='LOCATION=/stby/oracle/product/10.2.0/dbs/arch' standby_file_management=AUTO parallel_execution_message_size=8192 db_file_name_convert=('/oracle/oradata/test/','/stby/oradata/test/','/oracle/oradata/test/','/stby/oradata/test/','/oracle/product/10.2.0/dbs/','/stby/oradata/test/') log_file_name_convert=('/oracle/oradata/test/','/stby/oradata/test') log_archive_format='%t_%s_%r.dbf' remote_login_passwordfile=exclusive

El parámetro REOPEN servirá para regular el tiempo en segundos entre que se encuentra un error de archivado y sé reintenta archivar. Su valor por omisión es de 15 segundos.

16

Se configuran los parámetros db_file_name_convert y log_file_name_convert. El procedimiento de creación de la base de datos en modalidad Standby esta automatizado mediante la herramienta RMAN. La configuración del Servidor SRVEBSDG2 tiene una estructura diferente de directorios; por lo tanto es un requisito configurar estos parámetros al momento de crear la base de datos Standby. De esta manera no se registraran problemas en el proceso automático de creación de la base de datos. En el caso, que exista la misma estructura física de directorios no es necesario configurar dichos parámetros.

Una vez que se han agregado estos parámetros, se deberá bajar y subir la base de datos en c ada una de las instancias para que tengan efecto.

shutdown immediate; startup mount alter database archivelog; alter database open;

Configurar Oracle NET para incluir la entrada de la base de datos de contingencia: En la base de producción, modificar el archivo tnsnames.ora, de forma tal de incluir las siguientes entradas (se puede incluir también una llamada a un archivo externo donde se almacenen los mismos parámetros):

Descripción de esta configuración se encuentra en el capítulo anterior.

• Copiar los archivos de las bases de datos y el $ORACLE_HOME al servidor de contingencia (SRVEBSDG2): Esta copia puede ser vía RMAN, Hot backup o una simple copia en frío.

Referencia Metalink MAA - Creating a RAC Physical Standby for a RAC Primary (Note:380449)

• Generar los controlfiles de standby en la base de datos productiva, copiarlos a la base de datos standby y reemplazarlo por los que fueron copiados anteriormente: Para ello, ejecutar en el servidor principal, desde el prompt de SQL*Plus:

alter database create standby controlfile as <directory>/<controlfile name>';

system switch logfile; select thread#, sequence#-1 from v$log where status = ‘CURRENT’;

17

• Obtener información temporal: Dado que se deberán recrear los archivos temporales en la base de datos de contingencias, se deberá obtener la información correspondiente de la tabla dba_temp_files:

select file_name, bytes from dba_temp_files;

Descripción de esta configuración tanto de listener como de servicios se encuentra en el capítulo anterior

Creación de directorio para los archiveLog que se generaran: se diseño que tanto para efecto de transporte como para generación, el directorio sea /oracle/product/10.2.0/dbs/arch. Este directorio tiene que estar definido en sitio primario y secundario.

Configuración de archivo init en base de datos standby. En archivo nodo secundario

db_unique_name=HA_TEST2 log_archive_config='dg_config=(HA_TEST,HA_TEST2)' log_archive_dest_1='LOCATION=/oracle/product/10.2.0/dbs/arch MANDATORY' log_archive_dest_2='service=HA_TEST valid_for=(online_logfiles,primary_role) db_unique_name=HA_TEST LGWR ASYNC=20480 OPTIONAL REOPEN=15 NET_TIMEOUT=30' log_archive_dest_state_1=enable log_archive_dest_state_2=defer fal_server='HA_TEST' fal_client='HA_TEST2' standby_archive_dest='LOCATION=/oracle/product/10.2.0/dbs/arch' standby_file_management=AUTO parallel_execution_message_size=8192 db_file_name_convert=('/oracle/oradata/test/','/stby/oradata/test/','/oracle/oradata/test','/stby/oradata/test/','/oracle/product/10.2.0/dbs/','/stby/oradata/test/') log_file_name_convert=('/oracle/oradata/test/','/stby/oradata/test') log_archive_format='%t_%s_%r.dbf' remote_login_passwordfile=exclusive

• Montar la base de datos de standby física: Luego que la copia de la base de datos esté completa, crear un spfile del archivo de configuración e ingresar como el usuario oracle en el ambiente de contingencia y conectarse por medio del SQL*Plus y ejecutar:

startup nomount alter database mount standby database;

18

• Habilitar el procesamiento de datos de redos en la base standby: Dentro de la misma base de datos de contingencia, aún con el prompt de SQL*Plus ejecutar:

recover managed standby database using logfile disconnect; exit;

19

• Comenzar a enviar redos del nodo de producción a la base de datos standby: En la base de datos de producción, con el usuario oracle, cambiar el valor que tenía el parámetro log_archive_dest_state_2 a enable en las dos instancia (actualmente debería estar en defer), para habilitar el proceso de pasaje de logs. Para evitar tener que bajar y subir la base de datos nuevamente, se debe ejecutar:

alter system set log_archive_dest_state_2 = ENABLE scope = both;

• Verificar que los redos estén llegando como es debido: Para verificar que los archives se están transmitiendo como es debido, ingresar al servidor de base de datos de producción, realizar un switch de los logfiles, y verificar el estado de los destinos de los archivos de log a través de la ejecución de los siguientes comandos:

alter system switch logfile; select * from v$archive_dest_status where status != ‘INACTIVE’;

Configuración conectividad e-Business Suite hacia nodo primario de base de datos

La configuración de e-Business será a través de un nombre virtual de la instancia llamada TEST. Su arquitectura de configuración está basada en los archivos TNSNAMES.ORA, el que se configura en el Cliente Oracle10g instalados en los servidores de e-Business Suite (App Tier/Cp Tier) y los que requieran conexión hacia la instancia, y en <context>.dbc el cual se configura usando Autoconfig de e-Business Suite (y en versiones antiguas de forma manual).

En el capítulo anterior se detalla estos archivos de configuración.

20

Failover al sitio Standby

- Failover a la base de datos Standby

En la base de datos Standby, ejecutar los siguientes comandos para convertir a una nueva primaria: RECOVER MANAGED STANDBY DATABASE CANCEL; RECOVER MANAGED STANDBY DATABASE FINISH FORCE; ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

- Abrir la base de datos

ALTER DATABASE OPEN;

- Remover topología antigua

Conectarse a la base de datos con el usuario apps y ejecutar lo siguiente:

EXEC FND_CONC_CLONE.SETUP_CLEAN;

Commit;

- Configurar Standby Database Tier

Ejecutar Autoconfig en el nodo de la base de datos Standby para configurar el

Oracle Home para ser utilizado por E-Business Suite.

cd $ORACLE_HOME/appsutil/scripts/<CONTEXT_NAME>

./adautocfg.sh

- Configurar Application Tier

Ejecutar Autoconfig en el nodo de la aplicación Standby.

cd $ADMIN_SCRIPTS_HOME

./adautocfg.sh

21

Referencias

Note 406982.1 - Cloning Oracle Applications Release 12 with Rapid Clone

Note 452056.1 - Business Continuity for Oracle Applications Release 12 on Database Release 10gR2

Note 247618.1 - FAQ: Real Time Apply

Note 380449.1 - MAA - Creating a RAC Physical Standby for a RAC Primary