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 ".

Sigue leyendo

Resolving Archive Gap – Detection and Resolution

Oracle Data Guard

Image by Fenng(dbanotes) via Flickr

DATAGUARD NOT APPLIED

Cuando trabajamos con un sitio de contingencia, tenemos que estar atentos a que en el site donde radica la base stanby se esten aplicando los logs.

Para ello podemos tener algunas herramientas desde el grid control cuando tenemos el broker configurado, donde podemos monitorear varias cosas como si hay logs encolados o si hay gaps. Tambien si nos esta faltando un archive.

Sigue leyendo

Dataguard Broker | ORA-16714: The value of property ArchiveLagTarget is inconsistent with the database setting.

DG Broker: Resolviendo Inconsistencias de Configuración

En un caso de prueba que estabamos evaluando tiempos de performance de servicios, discos y por hecho la base de datos. El  analisis consistia en que impacto tendría la aplicación en la base corriendo con  disco rapidos y lentos. Sobre esas mismos tests, uno en particular consistia en cambiar el modo de trabajo del dataguard de MAXIMUM AVAILAVILITY a MAXIMUM PERFORMANCE.

Como pasamos de AVAILAVILITY a PERFORMANCE, aumenta el riego de DATA LOST, es por ello que configuramos el parámetro archive_lag_target en 1200 segundos para que en el momento de que haya pocas transacciones el log se cierre de todas maneras y nos asegure la menor perdidad de datos en caso de tener que pasar a contingencia.

SQL> sho parameter archive_lag 

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
archive_lag_target		     integer	 1200
SQL>

Sigue leyendo

Dataguard Broker | ORA-16801: redo transport-related property is inconsistent with database setting

database schema

database schema (Photo credit: gnizr)

WARNING ORA-16801: redo transport-related property is inconsistent

En una tarea cotidiana me toca recrear el sitio de contingencia, finalizada la misma y confirmando que se estan aplicando los logs y que todo estaba sincronizado, me encuentro con un warning el DGBROKER. Revisando desde la consola del Grid Control y la consola dgmrl lo confirmo, ORA-16801.

DGMGRL> show database verbose "DAPRO";
Database
  Name:            DAPRO
  Role:            PRIMARY
  Enabled:         YES
  Intended State:  ONLINE
  Instance(s):
    DAPRO1
    DAPRO4
   ...
   ...
    LogArchiveTrace(*)
    LogArchiveFormat(*)
    LatestLog(*)
    TopWaitEvents(*)
    (*) - Please check specific instance for the property value

Current status for "DAPRO":
Warning: ORA-16809: multiple warnings detected for the database

Sigue leyendo

Switch Over : Rápido pasaje a contingencia.

级联传送 Data Guard 的归档日志

Image by Fenng(dbanotes) via Flickr

El cápitulo siguiente esta dedicado al un pasaje a contingencia de Producción de una manera ordenada y prolija, este es el caso cuando programamos la tarea con atelación o bien cuando tenemos algún escenario como la falta de storage en el sitio productivo y en contigencia hay espacio holgado (Tiene que creermelo, esto lo he visto en muchos clientes).

Entonces, manos a la obra !

Como primer medida abrimos una termial de SQLPLUS en PROD Y CO con sus respectivos alerts para verificar que movimientos ocurre en la base y si todo esto es transparente.

  • Verificamos que la base PRIMARIA se encuentre en modo OPEN.
  • Verificamos que la SECUNDARIA se encuentre en modo MOUNT y que haya aplicado los logs.
  • Verificamos que los listeners estén Levantados.

Si sos un administrador proactivo esto estará en tus controles diarios y no te verás incluido en apuros a la hora de switchear.

Sigue leyendo

Alta Disponibilidad I – Configurando Dataguard en Oracle

DUPLICATE DATABASE FOR STANDBY

Es importante que consideremos que un posible desastre puede ocurrirle a nuestra base de datos productiva y en muchos casos puede que devenga en una pérdida total de servicio o del servidor mismo, donde si bien existe la posibilidad de hacer un restore de la base en un host distinto, es mucho el tiempo que nos llevaría hacerlo(Criticidad del Negocio) , sin tener los datos desde el punto en que se tomo el backup al momento de la pérdida, desatención del en el negocio, etc.

Es ahi donde ponemos en marcha nuestro plan de tener una base de datos secundaria, con la copia de todos los datos, y que pueda entrar rapidamente en contigencia en caso de que la base primaria de producción sufra una caida, se rompa un disco, no haya red, o hasta la perdidad completa del edificio donde se halla el servidor.

Oracle, nos provee una herramienta llamada dataguard, donde podemos generar una base standby, que sera la encargada de entrar en contingencia por medio de SWICTH_OVER o FAIL_OVER. También hay otros modos como DATAGUARD BROKER, que nos provee las mismas funcionalidades, pero en solo una ejecución de comandos.

Básicamente la estructura es una base Productiva, y n contingencias.

Cada contigencia es altamente recomendable tenerla en un host fuera del productivo, en lo posible en otro edificio.

Esquema Básico de Dataguard Sigue leyendo

Configurando Dataguard Broker

Oracle nos ofrece esta herramienta para poder hacer pasaje automatico en caso de tener un switch o un fail, y su uso una vez configurado  es tan sencillo como conectarse a la consola del administrador con el comando dgmgrl o desde el Entrerprise Manager con solo haciendo un click.

Yo en este caso voy a disponibilizar el modo de configuración desde la linea de comandos ya que me parece super práctico y nos sirve para conocer un poco más el modo en que trabaja.

Es importante saber que tanto desde la consola del GRID CONTROL o desde comandos hay que hacer una configuración previa que incluye:

  • Configuración de Listener en primaria y secundaria.
  • Configuración de Parametros de la base.
  • Creación de los archivos de configuración del broker. (Debemos ser sysdba)
  • En el caso de trabajar con una base que esta en RAC, hay que hacer la configuración con srvctl. (En este caso yo voy a presentarlo en una instancia en RAC y serán informados de ello para que sepan que el modo es el mismo para la single instance, menos este paso.)

CONFIGURANDO LISTENERS

Comenzaremos configurando los listeners, tanto en nuestra base primaria como en nuestra standby.
Es muy importante este paso ya que si el broker no ve el servicio no podrá hacer ninguna operación de switcheo.

# listener.ora.saturno01 Network Configuration File: /u01/app/oracle/product/10.2.0/db_mbpro/network/admin/listener.ora.saturno01
# Generated by Oracle configuration tools.

MBPRO_SATURNO01 =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = saturno01-vip.danahomelinux.com)(PORT = 1526)
(IP = FIRST))
(ADDRESS = (PROTOCOL = TCP)(HOST = saturno01.danahomelinux.com)(PORT = 1526)
(IP = FIRST))
)
)

SID_LIST_MBPRO_SATURNO01 =
(SID_LIST =
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_mbpro)
(PROGRAM = extproc)
)
(SID_DESC =
(GLOBAL_DBNAME = MBPRO_DGMGRL.danahomelinux.com)
(ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_mbpro)
(SID_NAME = MBPRO1)
)
)

Una vez realizada la tarea, procedemos a relodear el listener, y luego con un status service vemos si los cambios fueron impactados.

lsnrctl status MBPRO_SATURNO01
lsnrctl service MBPRO_SATURNO01

Sigue leyendo