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)
        )
)
Anuncios

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. Leer más “DG Broker – Selecting the Apply Instance”

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

Leer más “Dataguard Broker | ORA-16801: redo transport-related property is inconsistent with database setting”

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.

Leer más “Switch Over : Rápido pasaje a contingencia.”