Como configurar una arquitectura de alta disponibilidad con Oracle Standard Edition (SE)

Hace un tiempo un cliente me pidio armar una arquitectura de alta disponibilidad de forma tal de que la base de datos productiva tuviera un "espejo" y que, por ejemplo, ante un fallo de hardware severo del nodo principal pudiera activarse
el nodo de respaldo con la base "espejo" y que esto no dejara mas de unos pocos minutos al sistema corporativo sin base de datos.
El cliente habia comprado un nuevo servidor, similar al equipo que alojaba la base productiva. Ante el pedido, lo primero que se me ocurrio era armarles un esquema con una base stand-by, ahora llamado DATA GUARD. El problema fue que el cliente tenia su base de datos con Oracle 10g Standard Edition. Oracle SE no tiene el feature de DATA GUARD y por lo tanto la mejor opción que encontré fue implementar un esquema stand-by manual, manejado con scripting y cron. Este esquema no provee la robustez de un DATA GUARD pero se acerca bastante. Como voy a explicar mas adelante, con este modelo de no podemos asegurar que no se pierda lo que se persistio los ultimos minutos, pero dado que el negocio podía contemplar esta perdida se decidió implementar la arquitectura que propuse. A continuación voy a explicar paso a paso, llamaré NODO1 al nodo principal y activo y NODO2 al nodo secundario o stand-by que esta en modalidad pasiva.

1. Instalar el motor de base de datos en el NODO 2. Asegurarse que el S.O sea el mismo que el instalado en el NODO 1, debe tener el mismo nivel de parches, misma arquitectura (32 ó 64 bits) y la base debe tener la misma versión y nivel de parches
que la base productiva.

2. La base de producción (NODO1) deberá estar en modo archiving (esto para mi es excluyente para cualquier base productiva asi que lo
tomo como algo obvio). Copiar con RMAN los datafiles de la siguiente manera:

$rman target / no catalog

RMAN>report schema; <-- Para ver los datafiles que necesitamos copiar.

Una vez que tengo el listado de los datafiles de la base de datos se van copiando uno por uno a un directorio de backups,
por ejemplo para copiar el datafile system01.dbf:

RMAN>copy datafile '/u01/oradata/ROP102/system01.dbf' to '/u01/bkp/ROP102/system01.dbf';

3. Crear el control file standby desde la base de datos primaria (NODO1)

SQLPLUS> ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/u01/bkp/ROP102/control_stdy.ctl';

4. Copiar los datafiles respaldados con el comando copy de rman (paso 2), el control file standby creado en el paso 3
y el archivo de parametros de la base productiva al NODO 2, por ejemplo para pasar los datafiles:

$scp /u01/bkp/ROP102/*.dbf nodo2:/u01/oradata/ROP102/.

Si tenemos distinta estructura de directorios donde van los datafiles entre el NODO1 y el NODO2 tenemos que editar el archivo
de parametros y agregar el siguiente parametro:

DB_FILE_NAME_CONVERT='/u01/oradata/ROP102','u02/oradata/ROP102'

5. Ahora ya tenemos todos los archivos que necesitamos para levantar la base standy en el NODO2.

Se levanta la base en modo nomount usando el archivo de parametros copiado:

SQLPLUS>startup nomount pfile=/u01/app/oracle/products/10.2.0.1/db_1/dbs/iniROP102.ora

Se monta la base en modalidad standby:

SQLPLUS>alter database mount standby database;

6. Una vez que tenemos la base montada en standby solo resta realizar recover de la base en modo AUTO para poner los
datafiles en modo consistente.

SQLPLUS>recover standby database;
AUTO

7. Para chequear que nuestra base standby esta ok, podemos abrirla en modo read only:

SQLPLUS>alter database open read only;


Scripting necesario para la configuración inicial

En NODO 1 - Base de Datos Primaria

El siguiente script se encarga de transferir al nodo standby (NODO 2) las novedades, es decir los
archivelogs que se hayan generado desde la ultima transferencia.

-- move_stdby.sh
rsync -t -e ssh -Pazv /u01/oradata/ROP102/arch/ oracle@dbprod2:/u01/oradata/ROP102/arch/

Para purgar los archivos que ya no se necesiten usamos:

-- purge_arch_nodo1.sh
find /u01/oradata/ROP102/arch/*.arc -mtime +2 -exec rm {} \;

Una posible programación de los scripts del nodo 1 podria ser:

0,30 * * * * /home/oracle/move_stdby.sh <-- Se mueven del nodo 1 al nodo 2 cada 30'
0 7 * * * /home/oracle/purge_arch.sh <-- Se borran los archives todos los dias a las 7am


En NODO 2 - Base de Datos StandBy

Para aplicar los nuevos archives tranferidos:

-- apply_redo_stdby.sh
export ORACLE_SID=ROP102
export ORACLE_HOME=/u01/app/oracle/product/10.2.0
$ORACLE_HOME/bin/sqlplus -s "/ as sysdba" << EOF
recover standby database;
AUTO
exit
EOF

Para levantar la base en modo standby y preparada para aplicar archives:

-- manual_stdby.sh
sqlplus -s "/ as sysdba" << EOF
shutdown immediate;
startup nomount pfile=/u01/app/oracle/product/10.2.0/dbs/initROP102_stdby.ora
alter database mount standby database;
exit
EOF

Para levantar la base en modo solo lectura

-- readonly_stdby.sh
sqlplus -s "/ as sysdba" << EOF
alter database open read only;
exit
EOF

Para purgar los archives copiados al nodo standby

-- purge_arch_nodo2.sh
find /u01/oradata/ROP102/arch/*.arc -mtime +6 -exec rm {} \;
[oracle@dbprod2 ~]$

Una posible programación de los scripts del nodo 1 podria ser:

0,30 * * * * /home/oracle/apply_redo_stdby.sh <-- Se aplican los cambios a la base standby cada 30'
0 7 * * * /home/oracle/purge_arch.sh <-- Se borran los archives todos los dias a las 7am


La base standby esta continuamente aplicando archives, eso se puede chequear en el alert. Cuando la base standby esta en modo solo lectura no puede aplicar nuevos archives. En ciertas ocasiones resulta util tener la base standby en modo read only para realizar reportes y así evitar sobrecargar la base primaria.


Como hacer el switchover en el caso de que falle la base de datos primaria

Si la base primaria falla y no puede recomponerse (por ejemplo por un problema serio de HW) hay que activar la base standby. Para que pueda cumplir el rol de base primaria tendremos que levantarla en modo read write y hacer los siguiente:

1. Aplicar todos los archives que que aun no se hayan aplicado y que hayan pasado al nodo 2.

2. Hacer backup to trace del control file con la base standby en modo read only.

SQLPLUS> alter database backup controlfile to trace as '/u01/oradata/ROP102/control.txt'

3. Levantar la base standby en modo nomount y crear el control file usando en script del control file creado en el paso 2.

SQLPLUS> startup nomount pfile=/u01/app/oracle/product/10.2.0/dbs/initROP102_stdby.ora

Editar el archivo control.txt y dejar solo la ultima sentencia de creación del controlfile. Comentar todas las otras lineas

SQLPLUS>@/u01/oradata/ROP102/control.txt

4. Montar la base usando el nuevo controlfile

Editar el archivo de parametros y cambiar el nombre del controlfile para que se referencie el controlfile recien creado

SQLPLUS>startup mount pfile=/u01/app/oracle/product/10.2.0/dbs/initROP102_stdby.ora

5. Abrir la base en modo resetlogs

SQLPLUS>alter database open resetlogs;

Una vez realizado el paso 5 tenemos la base standby en modalidad read-write y totalmente operativa. Obviamente esta configuración requiere de scripting y de una tarea manual para levantar la base standby en caso de falla. Lo ideal seria tener DATA GUARD que asegura 0 perdida de información y automatización de los procesos de switchover. De todas formas, la arquitectura descripta es bastante adeacuada si no se pretende gastar mucho dinero en licencias y si la posible perdida de algunos minutos de información no afecta al negocio sensiblemente.