Category: StandBy - Data Guard

ORA-12541: TNS:no listener en Switchover con DGMGRL



A continuación les mostraré un error que sucede con demasiada frecuencia al momento de hacer un Switchover en un Dataguard construído en Oracle 11g y que cuesta un poco encontrarlo

Y que aparece como un terrible ORA-12541: TNS:no listener




Para hacer un seguimiento al error, llevamos a cabo los siguientes


Nos conectamos desde cualquier nodo (Standby o primario) al DGMGRL

[oracle@nodo1-dg] $ dgmgrl
DGMGRL for Linux: Version 11.2.0.3.0 - Production

Copyright (c) 2000, 2009, Oracle. All rights reserved.

Welcome to DGMGRL, type "help" for information.

DGMGRL> connect sys/oracle1
Connected.



Mostramos la configuración generada y verificamos cual es nuestra Standby y nuestra base primaria

DGMGRL> show configuration

Configuration - conf_dgprod

Protection Mode: MaxPerformance
Databases:
prod2 - Primary database
prod - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS



Procedemos a realizar el Switchover

DGMGRL> switchover to prod;
Performing switchover NOW, please wait...
New primary database "prod" is opening...
Operation requires shutdown of instance "prod" on database "prod2"
Shutting down instance "prod"...
ORACLE instance shut down.
Operation requires startup of instance "prod" on database "prod2"
Starting instance "prod"...
Unable to connect to database
ORA-12541: TNS:no listener

Failed.
Warning: You are no longer connected to ORACLE.

Please complete the following steps to finish switchover:
start up and mount instance "prod" of database "prod2"

DGMGRL> quit



Y dentro del Switchover aparece el mensaje

ORA-12541: TNS:no listener

Acá vienen los cuestionamientos y preguntas, ya que si hacemos la conexión mediante TCP/IP con los string de conexión, no existen inconvenientes...entonces debemos buscar el error por otro lado



Por lo pronto, subimos la base de datos Standby que no se pudo hacer a través del Switchover

[oracle@nodo1-dg] $ sqlplus sys/oracle1@PROD2 as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Wed Sep 26 16:50:45 2012

Copyright (c) 1982, 2011, Oracle. All rights reserved.

Connected to an idle instance.

SQL> startup force nomount
ORACLE instance started.

Total System Global Area 1071333376 bytes
Fixed Size 1349732 bytes
Variable Size 226494364 bytes
Database Buffers 838860800 bytes
Redo Buffers 4628480 bytes
SQL> alter database mount standby database;

Database altered.

SQL> quit



Chequeamos la configuración para ver si ambas bases están disponibles

DGMGRL> show configuration

Configuration - conf_dgprod

Protection Mode: MaxPerformance
Databases:
prod - Primary database
prod2 - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS



Ahora vemos un detalle más acabado de la configuración , quizás podemos ver si por aquí está nuestro error

DGMGRL> show database verbose 'prod';

Database - prod

Role: PRIMARY
Intended State: TRANSPORT-ON
Instance(s):
prod

Properties:
DGConnectIdentifier = 'prod'
ObserverConnectIdentifier = ''
LogXptMode = 'ASYNC'
DelayMins = '0'
Binding = 'optional'
MaxFailure = '0'
MaxConnections = '1'
ReopenSecs = '300'
NetTimeout = '30'
RedoCompression = 'DISABLE'
LogShipping = 'ON'
PreferredApplyInstance = ''
ApplyInstanceTimeout = '0'
ApplyParallel = 'AUTO'
StandbyFileManagement = 'AUTO'
ArchiveLagTarget = '0'
LogArchiveMaxProcesses = '4'
LogArchiveMinSucceedDest = '1'
DbFileNameConvert = ''
LogFileNameConvert = ''
FastStartFailoverTarget = ''
InconsistentProperties = '(monitor)'
InconsistentLogXptProps = '(monitor)'
SendQEntries = '(monitor)'
LogXptStatus = '(monitor)'
RecvQEntries = '(monitor)'
SidName = 'prod'
StaticConnectIdentifier = '(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=nodo1-dg.oracleyyo.com)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=prod_DGMGRL)(INSTANCE_NAME=prod)(SERVER=DEDICATED)))'
StandbyArchiveLocation = 'USE_DB_RECOVERY_FILE_DEST'
AlternateLocation = ''
LogArchiveTrace = '0'
LogArchiveFormat = 'arc_%t_%s_%r.arc'
TopWaitEvents = '(monitor)'

Database Status:
SUCCESS



De hecho, hay algo que nos debería llamar la atención, que es la configuración de este parámetro StaticConnectIdentifier

StaticConnectIdentifier = '(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=nodo1-dg.oracleyyo.com)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=prod_DGMGRL)(INSTANCE_NAME=prod)(SERVER=DEDICATED)))'



En este parámetro aparece un puerto que no corresponde al puerto que tenemos realmente nuestro listener, ya que estamos escuchando por el puerto 1530


Por ende , procedemos a cambiar ese parámetro dentro de la configuración del DGMGRL

DGMGRL> edit database 'prod' set property 'StaticConnectIdentifier'='(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=nodo1-dg.oracleyyo.com)(PORT=1530))(CONNECT_DATA=(SERVICE_NAME=prod_DGMGRL)(INSTANCE_NAME=prod)(SERVER=DEDICATED)))'
> ;
Property "StaticConnectIdentifier" updated
DGMGRL>



Mostramos nuevamente la la configuración en detalle de nuestras bases de datos configuradas en el DGMGRL

DGMGRL> show database verbose 'prod';

Database - prod

Role: PRIMARY
Intended State: TRANSPORT-ON
Instance(s):
prod

Properties:
DGConnectIdentifier = 'prod'
ObserverConnectIdentifier = ''
LogXptMode = 'ASYNC'
DelayMins = '0'
Binding = 'optional'
MaxFailure = '0'
MaxConnections = '1'
ReopenSecs = '300'
NetTimeout = '30'
RedoCompression = 'DISABLE'
LogShipping = 'ON'
PreferredApplyInstance = ''
ApplyInstanceTimeout = '0'
ApplyParallel = 'AUTO'
StandbyFileManagement = 'AUTO'
ArchiveLagTarget = '0'
LogArchiveMaxProcesses = '4'
LogArchiveMinSucceedDest = '1'
DbFileNameConvert = ''
LogFileNameConvert = ''
FastStartFailoverTarget = ''
InconsistentProperties = '(monitor)'
InconsistentLogXptProps = '(monitor)'
SendQEntries = '(monitor)'
LogXptStatus = '(monitor)'
RecvQEntries = '(monitor)'
SidName = 'prod'
StaticConnectIdentifier = '(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=nodo1-dg.oracleyyo.com)(PORT=1530))(CONNECT_DATA=(SERVICE_NAME=prod_DGMGRL)(INSTANCE_NAME=prod)(SERVER=DEDICATED)))'
StandbyArchiveLocation = 'USE_DB_RECOVERY_FILE_DEST'
AlternateLocation = ''
LogArchiveTrace = '0'
LogArchiveFormat = 'arc_%t_%s_%r.arc'
TopWaitEvents = '(monitor)'

Database Status:
SUCCESS

DGMGRL>



Chequemos lo mismo en el nodo2

DGMGRL> connect sys/oracle1
Connected.
DGMGRL>
DGMGRL> show database verbose 'prod2';

Database - prod2

Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 0 seconds
Apply Lag: 0 seconds
Real Time Query: OFF
Instance(s):
prod

Properties:
DGConnectIdentifier = 'prod2'
ObserverConnectIdentifier = ''
LogXptMode = 'ASYNC'
DelayMins = '0'
Binding = 'optional'
MaxFailure = '0'
MaxConnections = '1'
ReopenSecs = '300'
NetTimeout = '30'
RedoCompression = 'DISABLE'
LogShipping = 'ON'
PreferredApplyInstance = ''
ApplyInstanceTimeout = '0'
ApplyParallel = 'AUTO'
StandbyFileManagement = 'AUTO'
ArchiveLagTarget = '0'
LogArchiveMaxProcesses = '4'
LogArchiveMinSucceedDest = '1'
DbFileNameConvert = '/u02, /u03'
LogFileNameConvert = '/u02, /u03'
FastStartFailoverTarget = ''
InconsistentProperties = '(monitor)'
InconsistentLogXptProps = '(monitor)'
SendQEntries = '(monitor)'
LogXptStatus = '(monitor)'
RecvQEntries = '(monitor)'
SidName = 'prod'
StaticConnectIdentifier = '(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=nodo2-dg.oracleyyo.com)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=prod2_DGMGRL)(INSTANCE_NAME=prod)(SERVER=DEDICATED)))'
StandbyArchiveLocation = 'USE_DB_RECOVERY_FILE_DEST'
AlternateLocation = ''
LogArchiveTrace = '0'
LogArchiveFormat = 'arc_%t_%s_%r.arc'
TopWaitEvents = '(monitor)'

Database Status:
SUCCESS



Y vemos que también tiene problemas en el puerto del listener que está configurado


Editamos la propiedad StaticConnectIdentifier y le cambiamos el puerto

DGMGRL> edit database 'prod2' set property 'StaticConnectIdentifier'='(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=nodo2-dg.oracleyyo.com)(PORT=1530))(CONNECT_DATA=(SERVICE_NAME=prod2_DGMGRL)(INSTANCE_NAME=prod)(SERVER=DEDICATED)))';
Property "StaticConnectIdentifier" updated
DGMGRL>



Mostramos la configuración en detalle

DGMGRL> show database verbose 'prod2'

Database - prod2

Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 0 seconds
Apply Lag: 0 seconds
Real Time Query: OFF
Instance(s):
prod

Properties:
DGConnectIdentifier = 'prod2'
ObserverConnectIdentifier = ''
LogXptMode = 'ASYNC'
DelayMins = '0'
Binding = 'optional'
MaxFailure = '0'
MaxConnections = '1'
ReopenSecs = '300'
NetTimeout = '30'
RedoCompression = 'DISABLE'
LogShipping = 'ON'
PreferredApplyInstance = ''
ApplyInstanceTimeout = '0'
ApplyParallel = 'AUTO'
StandbyFileManagement = 'AUTO'
ArchiveLagTarget = '0'
LogArchiveMaxProcesses = '4'
LogArchiveMinSucceedDest = '1'
DbFileNameConvert = '/u02, /u03'
LogFileNameConvert = '/u02, /u03'
FastStartFailoverTarget = ''
InconsistentProperties = '(monitor)'
InconsistentLogXptProps = '(monitor)'
SendQEntries = '(monitor)'
LogXptStatus = '(monitor)'
RecvQEntries = '(monitor)'
SidName = 'prod'
StaticConnectIdentifier = '(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=nodo2-dg.oracleyyo.com)(PORT=1530))(CONNECT_DATA=(SERVICE_NAME=prod2_DGMGRL)(INSTANCE_NAME=prod)(SERVER=DEDICATED)))'
StandbyArchiveLocation = 'USE_DB_RECOVERY_FILE_DEST'
AlternateLocation = ''
LogArchiveTrace = '0'
LogArchiveFormat = 'arc_%t_%s_%r.arc'
TopWaitEvents = '(monitor)'

Database Status:
SUCCESS

DGMGRL>



Y vemos que ya han sido cambiado los datos, después de esto realizamos nuevamente el Switchover de ida y vuelta, sin ningún problema

DGMGRL> switchover to prod2;
Performing switchover NOW, please wait...
New primary database "prod2" is opening...
Operation requires shutdown of instance "prod" on database "prod"
Shutting down instance "prod"...
ORACLE instance shut down.
Operation requires startup of instance "prod" on database "prod"
Starting instance "prod"...
ORACLE instance started.
Database mounted.
Switchover succeeded, new primary is "prod2"


DGMGRL> switchover to prod;
Performing switchover NOW, please wait...
New primary database "prod" is opening...
Operation requires shutdown of instance "prod" on database "prod2"
Shutting down instance "prod"...
ORACLE instance shut down.
Operation requires startup of instance "prod" on database "prod2"
Starting instance "prod"...
ORACLE instance started.
Database mounted.
Switchover succeeded, new primary is "prod"
DGMGRL>


Asunto arreglado :>>

by Ligarius
17.10.12. 10:01:31. 1344 words, 9088 views. Categories: Base de datos, StandBy - Data Guard ,

11gr2 : DUPLICATE DATABASE FOR STANDBY FROM ACTIVE DATABASE



En el siguiente documento, les explico como generar una Standby mediante el comando DUPLICATE DATABASE FOR STANDBY FROM ACTIVE DATABASE, la verdad es bastante poderoso y fácil de llevar a cabo



Espero les sirva

El documento para descargar desde acá

DUPLICATE DATABASE FOR STANDBY

Links asociados

Datafile UNNAMED en una Standby...¿reconstrucción?

Como borrar archives por el lado del servidor de StandBy (Actualizado)

¿Qué son los StandBy de Redologs?

Modos de Protección en bases de datos StandBy (Protection Mode in StandBy)


by Ligarius
28.09.12. 05:50:02. 84 words, 5815 views. Categories: Base de datos, Oracle11gR2, StandBy - Data Guard ,

Datafile UNNAMED en una Standby...¿reconstrucción?



Estaba chequeando una base de datos Standby (sin alertas, en un cliente) y aparece el error




Tue Jun 19 06:54:51 2012
Media Recovery Log /oracle/FPR/oraarch/FPRarch/1_15236_765570470.dbf
File #55 added to control file as 'UNNAMED00055' because the parameter STANDBY_FILE_MANAGEMENT is set to MANUAL
The file should be manually created to continue.

Errors with log /oracle/FPR/oraarch/FPRarch/1_15236_765570470.dbf
MRP0: Background Media Recovery terminated with error 1274
Tue Jun 19 06:54:53 2012
Errors in file /oracle/FPR/saptrace/background/fpr_mrp0_24480.trc:
ORA-01274: cannot add datafile '/oracle/FPR/sapdata2/sr3_28/sr3.data28' - file could not be created
Some recovered datafiles maybe left media fuzzy
Media recovery may continue but open resetlogs may fail


Y al día de hoy

Wed Jul 11 15:22:33 2012
Errors in file /oracle/FPR/saptrace/background/fpr_mrp0_8413.trc:
ORA-01111: name for data file 55 is unknown - rename to correct file
ORA-01110: data file 55: '/oracle/FPR/102_64/dbs/UNNAMED00055'
ORA-01157: cannot identify/lock data file 55 - see DBWR trace file
ORA-01111: name for data file 55 is unknown - rename to correct file
ORA-01110: data file 55: '/oracle/FPR/102_64/dbs/UNNAMED00055'

La pregunta es ¿cómo arreglar esto sin necesidad de recrear la Standby?


Pues, he aquí el paso a paso

1.- Chequear el nombre del datafile tanto en la Standby como en la primaria

En la alerta de la Standby aparece el id del datafile , por ende lo buscamos por ese nombre

select file# , name from v$datafile where file# = 55;

Y en la primaria , también lo buscamos por el mismo ID


2.- En la Standby cambiamos la forma de operar la Standby

alter system set standby_file_management='auto' scope=both;


3.- Renombramos el datafile perdido , en la Standby y le colocamos el nombre que debiese tener

alter database create datafile '/oracle/FPR/102_64/dbs/UNNAMED00055' as '/oracle/FPR/sapdata2/sr3_28/sr3.data28';


4.- Y procedemos a bajar y dejar en modo de recuperación la Standby

startup nomount;
alter database mount standby database;
alter database recover managed standby database disconnect;


Todo lo anterior se produce, por un pequeño parámetro en la primaria... este parámetro es el STANDBY_FILE_MANAGEMENT, que siempre debe estar en AUTO


Espero les sirva y no hayan destrozado su Standby :>>

by Ligarius
19.07.12. 09:08:02. 376 words, 4654 views. Categories: StandBy - Data Guard ,

¿Qué son los StandBy de Redologs?



Una muy buena pregunta, que no todos somos capaces de responder :)



Los StandBy Redo, son estructuras creadas en una instancia StandBy (que debiesen tener el mismo tamaño que los redo de la primaria) que sirven para recibir las transacciones desde el ambiente productivo, esto hace que ante un Crash de la base productiva se pierdan menos datos, dado que la primera estructura donde llegan las transacciones son estos StandBy de redo, en vez de la aplicación directa de los archives sobre los datafiles, como suele ocurrir en las bases de datos Standby comunes sin REAL-TIME Apply

Con la característica de Real-Time Apply las transacciones de la primaria es aplicado a la Standby a través de los StandBy Redo Logs (SRL), esto hace que no tengamos que esperar a que el archive este realmente generado para su posterior aplicación, o sea, beneficios por todos lados .

Explicado de otra forma, si tenemos redo de standby generados, basta con que hagamos un commit y la transaccion será aplicada de inmediato en la base de datos Standby.

Para poder generar los Standby Redo Logs (SRL) se ejecuta este simple comando

alter database add standby logfile '+DiskGroup o ruta física' size XXM;



Un dato que puede servirnos, el proceso RFS que se ejecuta en nuestro ambiente Standby y que podemos ver algo así

Tue Nov 1 13:50:51 2011
RFS[1]: Successfully opened standby log 4: '+DGDATA/nliqstb/onlinelog/group_4.293.766066871'



Este proceso RFS es el encargado en la base de datos StandBy de recibir los datos desde la primaria y escribirlos a disco generando los archivelogs o la información de los standby de redo .El encargado de aplicar las transacciones que se encuentran en esos StandBy de Redo o en los archives que se encuentran en la StandBy es el proceso llamado MRP (Managed Recovery Process)

Siempre es beneficioso usar SRL , dado que cuando se produce un switch en la primaria, también se produce en la StandBy , lo que implica que también en nuestra base de datos StandBy se generan archives



A modo de resumen de los StandBy Redo Logs (SRL)

Son requeridos cuando :

  • Se ocupa el modo de máxima protección y máxima disponibilidad
  • Cuando se requiere ocupar REAL-TIME APPLY
  • Cuando se ocupan cascadas de Standby, o sea, desde una primaria, debemos generar 2 StandBy, pero para no sobrecargar la primaria, se envian la información de redo desde la primera StandBy hacía la segunda StandBy

    Algo así : Primaria ------(Txs)----> Standby#1 ------(Txs)----> Standby#2



    Sus ventajas :

  • Los StandBy Redo logs, pueden estar en Raw Devices, ASM o File Systems
  • Pueden ser multiplexados
  • Ante un crash y posteriorfailover, se puede aplicar más data desde los SRL que desde los mismos archives de ambiente productivo



    Se puede consultar los StandBy de redo logs generados en una standby

    SQL> SELECT GROUP#,THREAD#,SEQUENCE#,ARCHIVED,STATUS FROM V$STANDBY_LOG;
    
        GROUP#    THREAD#  SEQUENCE# ARC STATUS
    ---------- ---------- ---------- --- ----------
             4          1          0 NO  UNASSIGNED
             5          1          0 NO  UNASSIGNED
             6          0          0 YES UNASSIGNED
            10          0          0 YES UNASSIGNED
            11          0          0 YES UNASSIGNED
            12          0          0 YES UNASSIGNED
    
    6 rows selected

    .



    Explicación de los modos

    Documentación Oficial
    Creando StandBy Físicas
    Sobre Standby



  • by Ligarius
    01.11.11. 16:20:04. 522 words, 5456 views. Categories: Base de datos, StandBy - Data Guard ,

    Como borrar archives por el lado del servidor de StandBy



    Me imagino que debe ser una pregunta muy común... ¿Cómo eliminar los archives que se trasladan hacía mi nodo StandBy?



    Este es el esquema

    1.- Tengo una instancia primaria que genera archive los cuales son envíados mediante DataGuard a mi instancia StandBy en otro nodo.

    2.- Los archives que son generados en la instancia primaria son generados a disco y no están bajo arquitectura ASM ni Flash Recovery Area

    3.- Los archives que son copiados en la instancia StandBy caen sólo a una ruta, es una base de datos en FileSystems comunes y no posee Flash Recovery Area

    Entonces la pregunta de cajón es ¿Cómo genero algo que me vaya borrando los archives desde la StandBy?

    En mi ambiente productivo tengo controlado esto a raíz de los respaldos que se producen mediante RMAN.

    Pues he acá algunos códigos que se pueden colocar en práctica


    Borrado de archivelogs catalogandolos con RMAN
    Esto se debe llevar a cabo en la instancia StandBy (borra_archivelog.sh)

    #!/bin/bash
    ORACLE_BASE=/export/home/dba/oracle; export ORACLE_BASE
    ORACLE_HOME=$ORACLE_BASE/product/10.2.0; export ORACLE_HOME
    ORACLE_SID=LSECORA; export ORACLE_SID
    ORACLE_TERM=xterm; export ORACLE_TERM
    PATH=/usr/sbin:$PATH; export PATH
    PATH=$ORACLE_HOME/bin:$PATH; export PATH
    LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib; export LD_LIBRARY_PATH
    CLASSPATH=$ORACLE_HOME/JRE:$ORACLE_HOME/jlib:$ORACLE_HOME/rdbms/jlib; export CLASSPATH
    NLS_DATE_FORMAT='dd/mm/yyyy hh24:mi'; export NLS_DATE_FORMAT

    echo "Inicio proceso de borrado archivelogs"
    rman < connect target
    run{
    catalog start with '/ruta_donde_quedan_los_archivelogs_en_nodo_standby';
    delete noprompt archivelog all completed before 'SYSDATE -1/24';
    }
    quit;

    Como se puede apreciar se catalogan los respaldos y se proceden a eliminar aquellos que se han generado hace más de 1 hora



    Borrado de archivelogs mediante shell script
    find /ruta_donde_quedan_los_archivelogs_en_nodo_standby/* -type f -mtime +1 -exec rm -rf {} \;

    En el fondo se borran los archivelogs que sean mayores a 1 día y a esa búsqueda le aplica la ejecución del comando rm -rf , o sea, los elimina



    Borrado de archivelogs mediante configuración de RMAN , siempre y cuando usemos FRA :)
    Si se respaldan los archivelogs en la instancia StandBy , situación que es bastante óptima, se puede ejecutar este comando en RMAN

    CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;

    Incluso si se respaldan en la instancia primaria, se puede ejecutar este comando (también en la primaria)

    Con lo cual , cada vez que se respalden los archivelogs y estos hayan sido aplicados, serán eliminados de la faz de la tierra

    Actualización :

    Para eliminar archives , desde una base de datos Standby 9i :) , he acá la shell

    #!/bin/ksh

    # Quien
    # Hector Ulloa Ligarius

    # Cuando
    # 03 de Enero del 2012

    # Que
    # Eliminar archive ya aplicados en la Standby

    # Cron
    # 00 * * * * /home/oracle/hp/scripts/BorrarArchivelog.sh > /home/oracle/hp/scripts/BorrarArchivelog.log 2>&1

    ORACLE_HOME=/home/oracle/app/product/9.2.0
    PATH=$PATH:$ORACLE_HOME/bin
    ORACLE_SID=XX
    export ORACLE_HOME
    export ORACLE_SID

    rman target / << EOF
    delete archivelog until time "sysdate -1/24";
    YES
    exit
    EOF

    Con la instrucción "delete archivelog until time" , borramos los archives que tengan más de una hora de antigüedad, se puede usar el noprompt para que no tengamos que colocar el YES , como respuesta al comando delete archivelog :)




    by Ligarius
    02.04.11. 14:03:43. 286 words, 5795 views. Categories: Base de datos, StandBy - Data Guard ,

    1 2 >>