« Problemas con el OUI de Grid Control 11.1.0.1 y Base de datos 11.2.0.2Ahora Oracle soporta RAC en VMWare !!! (Oracle Support on VMWare) »

Modos de Protección en bases de datos StandBy (Protection Mode in StandBy)




Cada vez que configuramos un Data Guard (StandBy mas envío de archives automáticos) siempre vamos a quedar enmarcados en unos de estos tipos de disponibilidad de la StandBy :

MAXIMA PROTECCION (MAXIMUM PROTECTION)
MAXIMA DISPONIBILIDAD (MAXIMUM AVAILABILITY)
MAXIMA PERFORMANCE (MAXIMUM PERFORMANCE)

Con los 3 modos siempre estamos protegiendo los datos, pero la gran diferencia está en como actúa la base de datos primaria cuando la StandBy tiene problemas





MAXIMA PROTECCION (MAXIMUM PROTECTION)
Este modo garantiza que no hay perdida de datos si la base de datos primaria falla

Con este nivel de protección cada redo data -vector de redo generado en la primaria- debe ser aplicado por lo menos en una StandBy , en los on line redo logs y además en los redo de stanby de esa Standby sólo allí se produce el commit

Si por ABC motivo el redo data no es escrito en una StandBy , la base de datos primaria se viene abajo (shutdown), si existen 2 StandBy en máxima protección , basta que los redo data sean escritos en 1 de ellas, para que la base de datos productiva siga arriba.

La configuración de la máxima protección 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 sólo en 9i , física y lógica en 10g

Ej:

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

by Ligarius
12.11.10. 19:21:41. 1085 words, 9090 views. Categories: Base de datos, StandBy - Data Guard ,