ALTA DISPONIBILIDAD DE DATOS

E-BUSINESS SUITE R12

Autor: Alberto Silva Gallardo

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

1
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.

2
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, c oncurrentes 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 pro vocará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.

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

5
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 est o, 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.

6
Real - Time Apply.

El concepto Real-Time Apply 2 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)

7
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

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

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

11
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.ora 3.
Alias en tnsnames.ora definidos para nodo sec undario o Standby. Esta
configuración 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_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_CLIENT 4 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

12
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_BALAN
CE\=YES)(FAILOVER\=YES)(ADDRESS\=(PROTOCOL\=tcp)(HOST\=
SRVEBSDG1)(PORT\=1521)))(CONNECT_DATA\=(SERVICE_NAME\=TEST))

13
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 c ada 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.

14
 • 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.

15
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): Est a 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
ant eriormente: 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’;

16
 • 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 sec undario.

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/d
bs/','/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;

17
 • 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;

18
 • 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.

19
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

20
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

21