Oracle Dataguard | How to Add Standby redo Logs

Wireless Information System for Emergency Resp...

Image via Wikipedia

Como Agregar STANDBY REDO LOGS

Cuando decidimos trabajar con STANDBY REDOLOGS FILE es seguro que estamos por habilitar nuestra base secundaria en el modo Maximum Availability y Maximum Protection .

Un dato importante para la configuracion de los STANDBY REDOLOGS es que posean el mismo tamañano que los ONLINE REDOLOGS del sitio primario por una cuestion de performance.

Si utilizamos la consola de DG_BROKER de GRID CONTROL se encarga hacer todo de manera automatica.

Pero si lo hacemos de la forma manual es importante no olvidarnos de crearlos.

Cuando lo hago por linea de comandos como utilizo ASM , voy a dejar que OMF se encargue de crearlos con los nombres correspondientes.

Les recuerdo que en el caso de no utilizar OMF deben colocarlos con un nombre apropiado y en el path correspondiente.

Agregando los nuevos grupos

Como primer paso obtenemos en nuestra standby cuales son los REDO LOGS que tenemos en la base. (más…)

DG Broker – Selecting the Apply Instance

Cuando trabajamos en un ambiente de alta disponibilidad como es el RAC de Oracle, podemos tener varias instancias de una misma base standby.

Podemos poner de Ejemplo un sitio primario como TEST y otro secundario como TESTDG.

La instalacion cuenta con tres nodos para cada sitio.

Entonces podemos decir que contamos con el siguinete escenario:

  • Tenemos tres NODOS en el sitio primario con una base TEST en RAC.
  • Tenemos tres NODOS en el sitio de contingencia para la base TESTDG, tambien en RAC.
  • El sitio primario esta configuracon con DG_BROKER.
  • El sitio secundario esta configurado con con DG_BROKER.

Cuando trabajamos con el DG BROKER, y perdemos la instancia dataguard TESTDG2 que esta aplicando, automaticamente el broker switchea al primer nodo ( o al que se encuentre disponible en caso de tener mas nodos ) y comienza aplicar en la instancia TESTDG1. (más…)

ORACLE DATAGUARD – create a standby database by manual steps

RECUPERAMOS UNA BASE STANDBY SIN DUPLICATE

Para poder hacer una standby de forma manual sin tener que recurrir al duplicate database for standby,
podemos usar la forma tradicional.
Para ello como paso previo vamos a setear los parametros que sean necesarios necesarios.
Una vez que tenemos las configuraciones en forma correcta tomamos un backup y luego generamos un controlfile en la base primaria para la base standby.

run {
allocate channel disk1 device type disk
format '/u03/rman_database_backup/STBYcontrolfile.ctl';
backup current controlfile for standby;
}

Una vez que tenemos el backup tanto con el controlfile standby, pasamos del sitio primario al secundario.

[oracle@sdat0101lx]$ ls
STBYcontrolfile.ctl
JVPAR_t679670423_s345_p1_dbf
JVPAR_t679671275_s347_p1_arc
JVPAR_t679671249_s346_p1_dbf
JVPAR_t679671344_s348_p1_ctl

[oracle@sdat0101lx]$ scp STBYcontrolfile.ctl oracle@nodo1jvarlx:/u03/rman_database_backup/
oracle@nodo1jvarlx's password:
STBYcontrolfile.ctl

(más…)

Archive GAP – Concepts

Archive boxes in the archive of the Netherland...

Image via Wikipedia

Un ARCHIVE GAP, es una serie de archive redo log files que se crea cuando la base no es capaz de aplicar el siguiente REDO, generado por la base primaria.

Un GAP ocurre cuando:

  • Un corte, fallas en la red evitan el envio de logs.
  • Creacion de una Nueva Base Standby, con un backup antiguo.
  • Shutdown de la Base secundaria cuando Base Primaria esta en modo OPEN.

Cuando reanudamos la transmision por que recuperamos la conexion de red, los servicios de transporte de REDO detectan automaticamente el REDO GAP e intenta resolverlo, enviando un pedido del REDO faltante al sitio primario.

Que tiempo puede llevar resolver un problema de este tipo ?

Cito la documentacion oficial del Oracle:

" El tiempo necesario para resolver un REDO GAP es directamente proporcional
  al tamaño de GAP e inversamente proporcional al rendimiento efectivo del enlace
  de red entre la base de datos redo_source y la redo_transport_destination ".

(más…)