Standby database no es mas que una tecnica mediante la cual creamos un espejo de nuestra(s) base(s) de datos de produccion cuya sincronizacion se la realiza mediante el paso de archivelogs desde el sitio maestro (produccion) hacia el esclavo (standby), dicha base de datos se mantiene en un estado de recuperacion hasta que el usuario de la orden de que se active.
La activacion de la base de datos standby se la puede realizar de dos formas:
- Activacion en caso de fallo de produccion.
- Activacion por switchover o intercambio de estados (standby se vuelve produccion y produccion se vuelve standby) en caso de mantenimiento o problemas temporales en el servidor de produccion.
Ahora explicaremos la tecnica para crear este esquema SIN TENER QUE BAJAR LA BASE DE PRODUCCION si esta se encuentra ya en modo archivelog (caso contrario necesariamente debemos bajarla una sola vez para activar el archiving):
Cabe señalar que la tecnica que describiremos a continuacion funcionara siempre que nuestra base de datos se encuentre instalada en filesystems en lugar de ASM o RAW DEVICES. En la siguiente entrada del blog describiremos la metodologia para crear una standby database cuando ocupemos ASM o RAW DEVICES.
1) Instalamos o creamos una nueva instancia de base de datos oracle en un servidor remoto QUE DE PREFERENCIA TENGA LA MISMA ESTRUCTURA QUE NUESTRO SERVIDOR DE PRODUCCION A NIVEL DE FILESYSTEMS. Y colocamos nuestra base de produccion en modo archivelog (si no lo esta, dicho sea de paso toda base de datos de produccion deberia estar en modo archivelog) y forzamos la generacion de redo en toda nuestra base de datos mediante: alter database force logging (al fin y al cabo esta es la manera en la que garantizaremos una sincronizacion perfecta entre el sitio maestro y el sitio standby) y forzamos el logging mediante ALTER DATABASE FORCE LOGGING; .
2) Colocamos a nuestros tablespaces read write en modo backup para ello:
alter tablespace nombre_del_tablespace begin backup. No es necesario poner en modo backup a nuestros tablespaces read only por que su SCN no necesita sincronizacion con el controlfile.
3) Una vez que tenemos nuestros tablespaces en modo backup (no se incrementa el SCN de los datafile) podemos crear nuestro standby controlfile mediate: alter database create standby controlfile as 'ruta_y_nombre_de_archivo';
4) Copiamos nuestros redo logs, datafiles, STANDBY CONTROLFILE(s) y spfile (o pfile) a las mismas ubicaciones en el servidor remoto mediante cualquier comando del sistema operativo ( por ejemplo copy (windows), cp o scp (unix)).
5) En la consola del servidor remoto iniciamos nuestra base de datos en modo nomount mediante: startup nomount;
6) Colocamos a nuestra base de datos en modo mount standby mediante: alter database mount standby database;
Este momento nuesta base de datos leera nuestro standby controlfile y automaticamente se colocara en modo recovery razon por la cual debemos enviar sistematicamente nuestros archivelogs desde nuestro sitio de produccion hacia nuestro sitio standby (mas adelante veremos las tecnicas para realizar esta tarea) para que sean aplicados.
7) Para aplicar los archivelogs que llegan desde nuestra base de produccion utilizamos el comando: recover automatic standby database; y colocamos AUTO cuando nos pida ingresar el modo de recuperacion (manual, AUTO, cancel).
Este momento la base de datos aplicara todos los archivelogs y nos pedira el siguiente, por lo que, cada vez que enviemos archivelogs hacia el sitio standby debemos realizar la accion descrita en el punto anterior.
En este punto si todo salio bien debemos tener nuestra standby database totalmente funcional.
El ciclo de vida de nuestra standby database consta de 5 partes:
- Generacion de archives en nuestra BD de produccion.
- Envio de archivelogs desde produccion hacia standby.
- Aplicar archives en standby.
- Eliminar archivelogs que ya fueron aplicados en standby.
- Respaldo de archivelogs de produccion.
A continuacion describiremos las tecnicas para alcanzar los 5 puntos del ciclo de vida de nuestra standby database.
1) GENERACION: Como deciamos anteriormente es sumamente necesario que nuestra base de datos de produccion se encuentre en modo archivelog y que force la generacion de redo para asegurar que nuestra base de datos standby sea una copia fiel de nuestra base de produccion, para lo cual debemos hacer lo siguiente.
Para activar el archiving (si tenemos nuestra base de datos en modo noarchivelog hacemos lo siguiente:
- Definimos dos rutas en el disco en las cuales se crearan los archivelogs (calcular el espacio requerido en funcion del tamaño de los archivelogs que es igual al tamaño de los redos, al numero de switchs diarios de redologs que podemos extraer de la vista v$log_history y al tiempo de permanencia antes de respaldarlos y eliminarlos mediante RMAN).
- Colocamos las ubicaciones de archving en los parametros log_archive_dest_1 y log_archive_dest_2 mediante ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=RUTA1' SCOPE SPFILE; y ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='LOCATION=RUTA2' SCOPE SPFILE;
- Bajamos nuestra base de datos mediante SHUTDOWN IMMEDIATE;
- La subimos inmediatamente en estado mount mediante STARTUP MOUNT;
- Activamos el archiving mediante ALTER DATABASE ARCHIVELOG;
- Abrimos la base mediante ALTER DATABASE OPEN;
Con esto completamos nuestro proceso de generacion de archivelog y forzado de logging.
2) ENVIO: Esta etapa se encarga de enviar los archivelogs generados hacia el servidor standby, para ello ocuparemos la segunda ubicacion de archivelogs, la primera la mantendremos para hacer backups de los archivelogs que contenga mediante RMAN. Dada la importancia de los archivelogs en un ambiente standby debemos protegerlos con copias de seguridad y mantenerlos por un tiempo prudencial.
Un script sencillo que puede servirnos para enviar los archivelogs desde la segunda ubicacion del servidor de produccion hacia la base standby podria ser:
enviar.sh
if [ -d /respaldo/jep/Scripts/standby/sem_v ] ; then
mv /respaldo/jep/Scripts/standby/sem_v /respaldo/jep/Scripts/standby/sem_r
ls /respaldo/jep/archivelogs > /respaldo/jep/Scripts/standby/archivos
contador=$(wc -l < /respaldo/jep/Scripts/standby/archivos)
contador1=1
while [ $contador1 -le $contador ]
do
linea=$(cat /respaldo/jep/Scripts/standby/archivos |head -$contador1
|tail -1)
existe=""
existe=$(echo $linea |grep gz)
echo $existe
if [ "$existe" != "" ] ; then
echo 'moviendo inicial'
mv -u /respaldo/jep/archivelogs/*.gz /standbyfra/ >> logfile1
else
echo 'comprimiendo ' $linea
comando='/usr/bin/gzip -9 /respaldo/jep/archivelogs/'$linea
$($comando) >> logfile1
mv -u /respaldo/jep/archivelogs/*.gz /standbyfra/ >> logfile1
fi
contador1=`expr $contador1 + 1`
done
echo 'moviendo final'
mv -u /respaldo/jep/archivelogs/*.gz /standbyfra/ >> logfile1
mv /respaldo/jep/Scripts/standby/sem_r /respaldo/jep/Scripts/standby/sem_v
echo 'ejecutado'
else
echo 'proceso ya esta en ejecucion'
fi
3) La eliminacion de los logs una vez aplicados en el standby podemos hacerlo desde un script que parta de un query a la vista v$log_history de la standby database, para ello no es necesario abrir la base standby, basta con que este en estado mount.
Espero que este procedimiento les sirva para implementar un sistema de alta disponibilidad con una base de datos standard, (OJO, LA BASE DE DATOS STANDBY TIENE QUE ESTAR TAMBIEN LICENCIADA).
Hasta una proxima oportunidad amigos.
