18210512 alta disponibilidad de datos en ebusiness suite r12

Download 18210512 Alta Disponibilidad de Datos en EBusiness Suite R12

Post on 04-Jul-2015

163 views

Category:

Documents

3 download

Embed Size (px)

TRANSCRIPT

ALTA DISPONIBILIDAD DE DATOS E-BUSINESS SUITE R12

Autor:

Alberto Silva Gallardo

Ubicacin: Santiago de Chile Blog: http://cotosilva.blogspot.com

1

Antecedentes Este documento, describe cmo hacer la configuracin y construccin del esquema de alta disponibilidad de Datos para un Oracle E- Business Suite Relase 12 y Oracle Data Guard 10.2.0.4 Dicha implementacin y plan de pruebas se construir sobre una arquitectura de EBusiness Suite R12 concebido para un ambiente de Pruebas denominado TEST.

2

Arquitectura de E-Business Suite R12 El esquema de alta disponibilidad de datos diseado, est soportado por 2 servidores, cada uno contiene una capa de base de datos, c oncurrentes y aplicaciones, separados geogrficamente, uno ubicado en el SRVEBSDG1 (TEST) y el SRVEBSDG2 (Contingencia). Estos dos sitios estn unidos, a travs, de un enlace dedicado de 100MBits para trfico y replicacin 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 comunicacin definido para la transferencia de datos en el DATAGUARD. Esta separacin ser , a travs, de puertos de comunicaciones y no a travs 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 pro vocarn situaciones de fallas (FAILOVER) afectando el ambiente productivo, esto ser realizado en el n odo en contingencia, conformado por el servidor SRVEBSDG2 y el sitio de Produccin principal servidor SRVEBSDG1. A continuacin, se muestra la grfica con el diseo que va a ser implementado para el ambiente productivo. Y posteriormente, su explicacin para cada una de las capas.

3

4

Diseo de funcionalidad implementada para Alta Disponibilidad. El diseo 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. Diseo y configuracin a nivel de Aplicaciones & Procesamiento de Concurrentes. El mtodo a usar para lograr la habilitacin de contingencia en Aplicaciones y Administradores Concurrentes (CM), es la Clonacin 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 Aplicacin 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)

5

Diseo y configuracin a nivel de Base de datos Oracle. La base de datos Standalone, tiene un mtodo de replicacin 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 mtodo de proteccin a implementar en el Dataguard, es el que Oracle denomina como MAXIMUM performance. Este mtodo, privilegia la independencia del sitio de contingencia, con el sitio primario frente a una catstrofe, 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 mtodo de escritura en el destino del Dataguard, se realiza a travs del proceso background de Oracle LGWR, que paralelamente escribe en el redolog online y traspasa al LNS. Durante la transmisin de redo asncrono, el Network Server Process (LNSn) Transmite redo data fuera de el redo logfile en lnea en la base de datos primaria y no acta 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 lnea y continuar procesando el siguiente Requerimiento sin esperar entre procesos de comunicacin 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 travs, del proceso MRP (media recovery process), que se ejecuta en la standby, se van actualizando en la base las transacciones. La implementacin 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 comunicacin para el dataguard , sern diferentes a los puertos de servicios, de los que escuchan para transaccionales de e- Business Suite, con la finalidad de aislar lgicamente el trfico de replicacin de la informacin, con los servicios de e- Business. El puerto TCP de conexin del trfico a la base es 1521 y el puerto de trfico del dataguard es el 1522. Dado est o, cuando se realice el procedimiento de Failover, no se modificar ningn archivo de configuracin existente, tanto entre el nodo primario y en el sitio de contingencia.

6

Real - Time Apply.

El concepto Real-Time Apply 2 corresponde a u na caracterstica opcional y una mejora en Oracle10g DataGuard. Cuando se habilita esta caracterstica, 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 recuperacin 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, automticamente recupera desde los archive log generados. Este proceso es automtico, ya que en la configuracin est definido el directorio donde estos archivos deben existir. Una vez que el servicio sea restablecido, automticamente comenzar a aplicar los cambios el servicio Log Apply. A continuacin se mencionan los principales beneficios del Real- Time Apply: a. Permite realizar operaciones rpidas de Switchover y Failover. b. Actualiza al instante resultados despus de cambiar una base de datos en modalidad Standby fsica a read- only. c. Presentar reportes actualizados desde una base de datos Standby Lgica. 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)

7

Configuracin de Listeners Ambiente de TEST Listener TEST HA_TEST2 Descripcin Servicio e- Business en TEST Dataguard transporte y resolucin de GAP sitio Primario

Contingencia de TEST Listener TEST HA_TEST2 Descripcin Servicio e- Business en TEST Dataguard transporte y resolucin de GAP sitio Secundario

8

Definicin 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) ) )

9

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) ) )

10

Servicios de Dataguard Se definieron los servicios del Dataguard para transporte y resolucin de GAP. Este mecanismo permite a una base de datos en modalidad Standby, temporalmente desconectada de la base de datos de Test despus de un fallo de red, automticamente sincronizar con la base de datos de produccin sin ninguna intervencin manual. Se define para esta resolucin automtica un canal distinto de comunicacin 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 continuacin 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 configuracin 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)) )

11

Resolucin de GAP La definicin de los servicios del Dataguard de transporte para resolucin de GAP, est dada a travs, de la siguiente definicin del archivo tnsnames.ora 3. Alias en tnsnames.ora definidos para nodo sec undario o Standby. Esta configuracin permite realizar SwitchOver; pero en el caso solo contemplado y c onfigurado para realizar un Failover. HA_TEST2= (DESCRIPTION= (ADDRESS= (PROTOCOL=tcp) (HOST= SRVEBSDG2) (PORT=1522)) (CONNECT