Etiqueta: dataguard broker

DataGuard

Error: ORA-12514: TNS:listener does not currently know of service requested in connect descriptor dgmrl

Problema

PRIMARY SITE: Dos Nodos

En la configuracion del Dataguard Broker, al habilitar los procesos DMON, cuando intenta conectar con la base STANDBY, nos arroja el siguiente error:

Errors in file /u01/oracle/PROD/db/11.2.0.4/admin/PROD_srvebsdbpa/diag/rdbms/prod/PROD/trace/PROD_ora_27714.trc:
ORA-16038: log 2 sequence# 666656 cannot be archived
ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
ORA-00312: online log 2 thread 1: '/data1/oracle/PROD/db/apps_st/redo1/PROD_redog2m1.rdo'
ORA-00312: online log 2 thread 1: '/data1/oracle/PROD/db/apps_st/redo2/PROD_redog2m2.rdo'
USER (ospid: 27714): terminating the instance due to error 16038

Solucion

Editar el archivo listener.ora en ambos nodos y agregamos la entrada para DGMGRL

Esto previene la aparicion del error ORA-12154 que podemos observar al momento de startup de la standby database luego de realizar un switchover o al momento de comenzar con la sincronizacion luego de terminar de configuarar una instancia de dataguard , utilizando el feature dataguard broker.

Asegurase de que el GLOBAL_DBNAME esta seteado bajo la siguiente nomenclatura db_unique_name_DGMGRL.db_domain

SID_LIST_LISTENER =
  (SID_LIST =
 (SID_DESC =
        (GLOBAL_DBNAME = <DB_UNIQUE_NAME>_dgmgrl)
        (ORACLE_HOME = /u01/oracle/product/11.2.0/db_1)
        (SID_NAME = PRODAT)
        )
)
DataGuard, DB - 11gR2, Oracle 12c, RAC, RMAN

Error 1033 received logging on to the standby

Estuvimos armado una STANDBY en el dia de ayer, como un segundo sitio de contingencia, por que tenemos programado realizar una migracion a 12c.

Como nuestro cliente no tiene licencias de Oracle Golden Gate, la estrategia de llevar la data al nuevo servidor, fue la opcion de Oracle Dataguard.

Para ello:

Nuestro Plan fue llevar desde el PRIMARY SITE a una segunda STBY SITE por medio de la configuracion de Dataguard Broker.

Problema

En este caso y como parte de las tareas planificadas se decidio que el equipo local lleve a cabo las tareas de configuracion.

Al ejecutar el siguiente comando para habilitar la configuracion el DG_BROKER en el STBY SITE:

ALTER SYSTEM SET DG_BROKER_START = TRUE;

Notamos que habilitaron el envio de los redo, a pesar no haber terminado la configuracion del borker.

En el PRIMARY SITE , al ver que estaba habilitado el envio de los redo, se intento agregar la instancia al broker:

DGMGRL>
add database "PRODAR" as connect identifier is "PRODAR" maintained as physical;
Error: ORA-01033: ORACLE initialization or shutdown in progress

Failed.

Esto dio la orden en el sitio primario que comience con el envio de redo, pero notaron que no los enviaba y que el alert log comenzo a mostrar el error: Error 1033 received logging on to the standby Seguir leyendo «Error 1033 received logging on to the standby» →

DataGuard, DB - 10gR2

Oracle Dataguard | How to open a standby database in read only mode

Pasos a seguir para poder ejecutar queries dentro de nuestra base de datos en standby 10G.

Esto nos puede ayudar a sacar un reporte que requiere consumo dentro de la base productiva que nos pueda llegar afectar de alguna manera la performance de la base y su operacion , relacionada con la carga proporcional de trabajo de cada nodo.
Es por ello que se realiza la extraccion del reporte en la standby que poseamos.

Ejecutar los siguientes comandos en la base de datos en standby:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL> ALTER DATABASE OPEN READ ONLY;

Realizamos las consultas necesarias.

Retornamos al estado anterior.

SQL> STARTUP FORCE MOUNT;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

Aunque la base de datos la tengamos en modo de solo lectura, los archived logs del servidor primario se continuarán enviando al de standby, y cuando este se regrese a su estado anterior (MODO RECOVERY), todos los archived logs que se hayan acumulado serán aplicados.

En la versión 11G, Oracle permite que se ejecuten queries de consulta con el modo de recuperación activo.

Eso lo veremos en el proxímo articulo.

DataGuard, RAC

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. Seguir leyendo «DG Broker – Selecting the Apply Instance» →

DataGuard

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>

Seguir leyendo «Dataguard Broker | ORA-16714: The value of property ArchiveLagTarget is inconsistent with the database setting.» →

DataGuard

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.

Seguir leyendo «Switch Over : Rápido pasaje a contingencia.» →

DataGuard, DB - 10gR2

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

Seguir leyendo «Configurando Dataguard Broker» →