Oracle y yo

alter database add standby logfile '+DiskGroup o ruta física' size XXM;

Un dato que puede servirnos, el proceso RFS que se ejecuta en nuestro ambiente Standby y que podemos ver algo así

Tue Nov 1 13:50:51 2011
RFS[1]: Successfully opened standby log 4: '+DGDATA/nliqstb/onlinelog/group_4.293.766066871'

Este proceso RFS es el encargado en la base de datos StandBy de recibir los datos desde la primaria y escribirlos a disco generando los archivelogs o la información de los standby de redo .El encargado de aplicar las transacciones que se encuentran en esos StandBy de Redo o en los archives que se encuentran en la StandBy es el proceso llamado MRP (Managed Recovery Process)

Siempre es beneficioso usar SRL , dado que cuando se produce un switch en la primaria, también se produce en la StandBy , lo que implica que también en nuestra base de datos StandBy se generan archives

A modo de resumen de los StandBy Redo Logs (SRL)

Son requeridos cuando :

#!/bin/bash
ORACLE_BASE=/export/home/dba/oracle; export ORACLE_BASE
ORACLE_HOME=$ORACLE_BASE/product/10.2.0; export ORACLE_HOME
ORACLE_SID=LSECORA; export ORACLE_SID
ORACLE_TERM=xterm; export ORACLE_TERM
PATH=/usr/sbin:$PATH; export PATH
PATH=$ORACLE_HOME/bin:$PATH; export PATH
LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib; export LD_LIBRARY_PATH
CLASSPATH=$ORACLE_HOME/JRE:$ORACLE_HOME/jlib:$ORACLE_HOME/rdbms/jlib; export CLASSPATH
NLS_DATE_FORMAT='dd/mm/yyyy hh24:mi'; export NLS_DATE_FORMAT

echo "Inicio proceso de borrado archivelogs"
rman < connect target
run{
catalog start with '/ruta_donde_quedan_los_archivelogs_en_nodo_standby';
delete noprompt archivelog all completed before 'SYSDATE -1/24';
}
quit;

Como se puede apreciar se catalogan los respaldos y se proceden a eliminar aquellos que se han generado hace más de 1 hora

Borrado de archivelogs mediante shell script
find /ruta_donde_quedan_los_archivelogs_en_nodo_standby/* -type f -mtime +1 -exec rm -rf {} \;

En el fondo se borran los archivelogs que sean mayores a 1 día y a esa búsqueda le aplica la ejecución del comando rm -rf , o sea, los elimina

Borrado de archivelogs mediante configuración de RMAN , siempre y cuando usemos FRA
Si se respaldan los archivelogs en la instancia StandBy , situación que es bastante óptima, se puede ejecutar este comando en RMAN

CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;

Incluso si se respaldan en la instancia primaria, se puede ejecutar este comando (también en la primaria)

Con lo cual , cada vez que se respalden los archivelogs y estos hayan sido aplicados, serán eliminados de la faz de la tierra

Actualización :

Para eliminar archives , desde una base de datos Standby 9i , he acá la shell

#!/bin/ksh

# Quien
# Hector Ulloa Ligarius

# Cuando
# 03 de Enero del 2012

# Que
# Eliminar archive ya aplicados en la Standby

# Cron
# 00 * * * * /home/oracle/hp/scripts/BorrarArchivelog.sh > /home/oracle/hp/scripts/BorrarArchivelog.log 2>&1

ORACLE_HOME=/home/oracle/app/product/9.2.0
PATH=$PATH:$ORACLE_HOME/bin
ORACLE_SID=XX
export ORACLE_HOME
export ORACLE_SID

rman target / << EOF
delete archivelog until time "sysdate -1/24";
YES
exit
EOF

Con la instrucción "delete archivelog until time" , borramos los archives que tengan más de una hora de antigüedad, se puede usar el noprompt para que no tengamos que colocar el YES , como respuesta al comando delete archivelog

ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=standby LGWR SYNC AFFIRM';

MAXIMA DISPONIBILIDAD (MAXIMUM AVAILABILITY)
Este modo de protección no afecta la base de datos y proporciona un alto nivel de protección de los datos, tal cual en el modo de máxima protección , las transacciones no se comitean hasta que el redo data sea aplicado en los redologs de la base de datos standby , por lo menos en una de ellas (si existe más de una)

Si no se puede escribir el redo data , en por lo menos una StandBy , la base de datos primaria no se cae

La configuración de la máxima disponibilidad pasa por la siguiente configuración

- Proceso que lleva a cabo el archive de los redo : LGWR
- Modo de transmisión a través de la red : SYNC
- Opción de escritura en disco : AFFIRM
- ¿Necesarios los redo de standby? : SI
- Tipo de Standby soportadas : StandBy física y lógica

Ej:

ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=standby LGWR SYNC AFFIRM';

OBS : El seteo de la máxima disponibilidad con la máxima protección es la misma, lo que cambia es como seteamos nuestra base de datos

alter database set standby database to maximize {AVAILABILITY | PERFORMANCE | PROTECTION};

MAXIMA PERFORMANCE (MAXIMUM PERFORMANCE)
Este modo de protección ofrece la mayor seguridad en la base de datos sin perder nada en la performance de la base de datos primaria, acá las transacciones de la base de datos primaria se les generá commit sólo cuando la transacción llega a los redo locales.
Este modo se debiese usar cuando la red hacía la StandBy no es lo suficientemente óptima y se producen delays al momento de traspasar paquetes a través de TCP.

La configuración de la máxima performance pasa por la siguiente configuración

- Proceso que lleva a cabo el archive de los redo : LGWR o ARCH
- Modo de transmisión a través de la red : ASYNC cuando se usa LGWR
- Opción de escritura en disco : NOAFFIRM
- ¿Necesarios los redo de standby? : NO
- Tipo de Standby soportadas : StandBy física y lógica

Cuando LGWR envía los archives en modo ASYNC, LGWR no espera la respuesta de I/O de la red para completar la tarea, simplemente se desliga, pero no es tan así, sino que deja la actividad de envío del archive a un proceso intermedio llamado LGWR network server process (LNS) y es este proceso el que espera por el I/O de la red y para poder almacenar el redo data que trae el LGWR el LNS posee un buffer , el cual se puede setear sólo en Oracle9i y Oracle10gr1. Este dato se modifica en el parámetro ASYNC de los destinos de archive.

Ej:

ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=standby LGWR ASYNC=1024 NOAFFIRM';

El tamaño del buffer que usa el LNS esta dado por el dato puesto en el parámetro ASYNC * 512 bytes , o sea, 524288 bytes , por lo tanto, estaríamos usando un buffer de 512Kb

Como el proceso LNS es más rápido que el proceso LGWR , esto significa que el buffer entre ambos nunca se llenará y por ende el LGWR no se detendría.

Desde Oracle10gr2 ya no se usa este buffer , lo que hace el proceso LNS es leer directamente desde los redologs de la primaria.

El uso de ARCH para enviar archive a través de la red hacía las Standby, no impacta en la performance de la base de datos, el único problema es que hay que disponer de varios grupos de redo , para que LGWR nunca se encuentre con que un redolog está siendo ocupado por un ARCH

Siempre tener en cuenta lo siguiente

SYNC-ASYNC : Indicamos que usamos sincronismo o asincronismo para el envío de los archives a la standby y el proceso que lleva los archives, ya sea el LGWR o el ARCH no espera la respuesta de la red
AFFIRM-NOAFFIRM : Indica que espera o no espera la respuesta de disco en el ambiente standby cuando se aplican los redo data, en el fondo es como un asincrónico/sincrónico de
disco

Interesante cierto?

Ya sabemos entonces, que la idea es utilizar ASYNC y NOAFFIRM cuando estamos en máxima performance.

Cuando no se especifica LGWR ni ARCH , el defecto es ARCH , por ende se utiliza ASYNC y por defecto NOAFFIRM.

También recordar que se puede cambiar desde ASYNC a SYNC cuando trasladamos archives con LGWR, no con ARCH.

Y si quieres saber como está tu base de datos, pues deberías ejecutar la siguiente consulta

select protection_mode, protection_level from v$database

Algunos links de ayuda

Métodos de protección en 10gr2

Métodos de protección en 9i

Managing Redo Transport Services for Data Protection Modes