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

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 Leer más “Error 1033 received logging on to the standby”

Oracle Redirected Restore File Name Variables

En la siguiente tabla podemos encontrar el listado de las variables que podemos especificar al momento de redireccionar nuestras piezas (Pieces from a backupset pieces on restore.)

Estas nos ayudaran a trabajar en el redireccionamiento de almacenamiento en nuestros nuevos TARGETS:

Variable Description
%U Note: This variable covers most cases.This variable specifies a system-generated unique file name with the following format:

data-D-%d_id-%I_TS-%N_FNO-%f.

The %d variable specifies the database name. For example, data-D-prod_id-22398754_TS-users_FNO-7.

%b This variable specifies the file name without the fully qualified directory path. For example, the data file name /oradata/prod/financial.dbf becomes financial.dbf.This variable preserves the names of the data files while you move them to different directory. You can use this variable when you create an image copies. The variable cannot be used for OMF data files or backup sets.
%f Specifies the absolute file number of the data file for which the new name is generated. For example, if data file 2 is duplicated, then %f generates the value 2.
%I This variable is optional and specifies the database ID (DBID).
%N This variable is optional and specifies the tablespace name.

kcrr.c Error 1031 received logging on to the standby | Oracle standby

PING[ARC1] heartbeat failed to connect to standby . error is 1031

Water supply in Buenos Aires was provided by a...
Water supply in Buenos Aires was provided by a private company from 1993 to 2006. (Photo credit: Wikipedia)

En la semana anduve Auditando un Dataguard en una Empresa de Servicios en Buenos Aires y el motivo de mi visita era ayudar al DBA local con un problema que habia surgido a partir de la reinstalacion de su SECONDARY SITE.

El error se basaba en que el proceso ARCHIVER de la base primaria estaba fallando .

Revisando el alert de la base me econtre con el siguiente error:

Errors in file /u01/app/oracle/admin/ORCL/bdump/orcl1_arc1_8881.trc:
ORA-01031: insufficient privileges
PING[ARC1]: Heartbeat failed to connect to standby 'ORCLDG'. Error is 1031.

Como tenia seguridad de que estaba ocurriendo, me diriji al trace que despliega el proceso ARC  y lo edite para mostrar al DBA que ocurria:

*** 2012-05-16 13:27:50.745 60680 kcrr.c
Error 1031 received logging on to the standby
Error 1031 connecting to destination LOG_ARCHIVE_DEST_2 standby host 'ORCLDG'
Error 1031 attaching to destination LOG_ARCHIVE_DEST_2 standby host 'ORCLDG'
ORA-01031: insufficient privileges
*** 2012-05-16 13:27:50.748 60680 kcrr.c
LGWR: Error 1031 creating archivelog file 'ORCLDG'
*** 2012-05-16 13:27:50.749 58942 kcrr.c
kcrrfail: dest:2 err:1031 force:0 blast:1
*** 2012-05-16 13:27:51.696 70891 kcrr.c
Sending online log thread 1 seq 143 [logfile 1] to standby
Opening logfile [logno 1]
LGWR: Archivelog for thread 1 sequence 143 will NOT be compressed
*** 2012-05-16 13:27:51.940 71016 kcrr.c
Shutting down [due to no more ASYNC destination]
LNS1: Doing a channel reset for next time around...

El problema se encontraba aqui: ORA-01031: insufficient privileges. Leer más “kcrr.c Error 1031 received logging on to the standby | Oracle standby”

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.

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

Leer más “ORACLE DATAGUARD – create a standby database by manual steps”

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 Leer más “Alta Disponibilidad I – Configurando Dataguard en Oracle”