En esta entrega mostraré los pasos para implementar una réplica standby de Base de Datos sobre Windows. He de mencionar que esto lo hice en base a la documentación de Oracle para implementar replicas sin dataguard para la versión 9i, que estaba guardado en mi empresa.
Este tipo de réplica aún es utilizado en muchos lugares, ya que la implementación no es muy compleja y en cuestiones de licenciamiento, no tiene costo mas que el de la BD que se está creando.
Actualmente lo tengo aplicado con la versión 11g, y una de las ventajas es que se puede utilizar la modalidad snapshot database, útil para pruebas de tipo UAT (User Aceptance Test) sin necesidad de que entren a los entornos productivos o hacer carga de información a un entorno de desarrollo.
Las condiciones para implementar la réplica son las siguientes:
- Las version de la BD primaria y la réplica deben ser la misma
- La versión sistema operativo donde se encuentra la BD primaria debe ser del mismo tipo que la réplica (no se pueden mezclar linux en la primaria con un windows en la réplica, por ejemplo)
Ahora si, vamos a colocar los pasos (recuerden que la implementación que describo es para un ambiente con SO Windows Server 2003, en caso de utilizar otro hay que revisar en la documentación de oracle particularidades para su SO.
En el servidor de Producción
1.- Realizar un respaldo en Frío de la Base de Datos (Datafiles, Controlfiles, Redologs, PWDFile y SPFILE)
2.- Crear un PFILE a partir del SPFILE y colocarlo en la carpeta del respaldo en Frío
SQL> create pfile = 'ruta\SIDPfile.ora' from spfile;
3.- Crear un STANDBY CONTROLFILE y colocarlo en la carpeta del respaldo en Frío
SQL>alter database create standby controlfile as 'ruta\standby.ctl';
4.- Copiar la carpeta del respaldo en Frío en el servidor para la réplica.
En el servidor de Réplica
5.- Instalar software de Base de Datos Oracle con la misma versión que en el de Producción
6.-Crear una instancia con DBCA la cual deberá tener el mismo SID que la de Producción
7.- Modificar el PFILE de la carpeta del respaldo en frío
- Modificar rutas y nombres de los controlfiles por los de standby control files en el parametro *.control_files
- Modificar ruta de destino de archives (si aplica)
- Si los datafiles no van a quedar en la misma ruta que en el servidor de producción, utilizar el parametro *.db_file_name_convert para hacer las "traducciones de rutas"
- Si los redolog no estarán en la misma ruta que en el servidor de producción utilizar el parametro *.log_file_name_convert (Se pueden utilizar "patrones" de rutas, por ejemplo si yo seteo en la ruta "C:\DIR\FILES\" se traduciran todos las carpetas que estén en la raíz de esa ruta [FILES] y lo que esté dentro de ella)
SQL>create spfile from pfile='ruta\SIDpfile.ora';
NOTA: En este paso asegurese que sus variables de entorno están configuradas para el SID de la base de datos que creó con DBCA
9.- Detener la instancia e iniciarla en modo mount
SQL>shutdown immediate;
SQL>startup mount;
NOTA: Si al momento de montar la base no reporta ningún datafile faltante, quiere decir que vamos bien... pero pase lo que pase NO ABRIR LA BASE DE DATOS!
10.- Pasar la Base de Datos a modo Physical Standby, con ello al abrir la BD automáticamente se abre en modo SOLO LECTURA. Esta operación desmonta la base de datos.
SQL>alter database convert to physical standby
Para revisar si la configuración aplicó realice la siguiente consulta:
select database_role from v$database;
11.- Reiniciar la Base de Datos en modo MOUNT
SQL>startup mount;
12.- Iniciar el proceso de recuperación
SQL>recover stanby database;
Con ello dará inicio el proceso de recuperación, el cual solicitará los archives que sean necesarios para completar los datafiles con las operaciones realizadas en la BD de Producción.
Este proceso se puede realizar por medio de archivos de procesamiento por lotes.
Activación de la Base de Datos Standby
Para activar la Base de Datos en modo Lectura/Escritura en caso de perdida del servidor productivo, se realiza lo siguiente:
1.- Detener el proceso de sincronización
2.- Detener instancia de Base de Datos
3.- Iniciar la instancia en modo MOUNT
4.- Pasar la Base de Datos de Physical Standby a Primary
SQL>alter database activate physical standby database;
5.- Verificar el rol de la base de datos ejecutando la consulta, de la cual es resultado debe ser PRIMARY
SQL>select database_role from v$database;
6.- Abrir la instancia de Base de Datos y verificar que este abierta para operaciones de lectura y escritura. El resultado de la siguiente consulta debe ser, para OPEN_MODE = READ WRITE y para DATABASE_ROLE=PRIMARY
SQL>select open_mode, database_role from v$database;
Mi proceso de sincronización lo describo en la siguiente imagen
También les dejo los scripts que utilizo en .bat para transeferir los archives y hacer la recuperación en la BD.
Script de Transferencia de Producción a Réplica por FTP
TITLE Envio Replica CTS
:INICIO
cls
@ECHO OFF
cd G:\DatabaseProd\Arcs
if exist *.txt del *.txt
if not exist *.arc goto :FINAL
ren *.arc *.bck
dir /B *.bck >>ListaArchives.txt
echo open ftp-replica >>ftpenvio.txt
echo userftp>>ftpenvio.txt
echo pwd_userftp>>ftpenvio.txt
for /F "eol=t tokens=1" %%i in (ListaArchives.txt) do echo put %%i>>ftpenvio.txt
echo bye>>ftpenvio.txt
ftp -s:ftpenvio.txt
move *.bck G:\DatabaseProd\ArcsProcesados
ren G:\DatabaseProd\ArcsProcesados\*.bck *.ARC
:FINAL
timeout 120
GOTO :INICIO
Scripts de Recuperación en Réplica
@ECHO OFF
TITLE Recover Replica CTS
:RECOVER
cd C:\Archives
if not exist *.bck goto :FINAL
ren *.bck *.ARC
sqlplus / as sysdba @SQLRecover.sql
:FINAL
timeout 120
if exist *.ARC move *.ARC O:\ArchivesCargados
goto :RECOVER
El script SQLRecover.sql tiene el siguiente contenido
recover standby database;
auto
quit
Posteriormente estaré probando Oracle Dataguard, ya que lo implemente registraré mi experiencia aqui.
