Archivo de la etiqueta: data guard

Evitar mensajes SWITCHOVER de dataguard en el alert log

Posted on por
Responder

Hoy vamos a ver un caso sencillo que puede dar algun susto si no sabemos de donde viene.

Ultimamente habreis visto que en el alert log de vuestras bases de datos donde tenemos Dataguards activados, tenemos unos sospechosos mensajes relativos al SWIRCHOVER del estilo 

 Mem# 0: +REDO1/WINTRA_STBY/ONLINELOG/group_12.430.1176371311
  Mem# 1: +REDO2/ORCL_SITE2/ONLINELOG/group_12.448.1176371317
2024-12-09T12:04:01.654207+01:00
ARC4 (PID:22664): Archived Log entry 1874 added for T-6.S-29707 ID 0xf4a75427 LAD:1
2024-12-09T12:04:02.545651+01:00
 rfs (PID:3350): Selected LNO:10 for T-5.S-22376 dbid 4104620583 branch 722623079
2024-12-09T12:04:02.595323+01:00
PR00 (PID:22983): Media Recovery Waiting for T-5.S-22376 (in transit)
2024-12-09T12:04:02.609412+01:00
Recovery of Online Redo Log: Thread 5 Group 10 Seq 22376 Reading mem 0
  Mem# 0: +REDO1/ORCL_SITE2/ONLINELOG/group_10.419.1176369743
  Mem# 1: +REDO2/ORCL_SITE2/ONLINELOG/group_10.437.1176369749
2024-12-09T12:04:02.973552+01:00
ARC1 (PID:22656): Archived Log entry 1875 added for T-5.S-22375 ID 0xf4a75427 LAD:1
2024-12-09T12:47:21.593967+01:00
 rfs (PID:5113): krsr_rfs_atc: Identified database type as 'PHYSICAL STANDBY': Client is Foreground (PID:26765)
2024-12-09T12:47:23.731609+01:00
SWITCHOVER VERIFY BEGIN
SWITCHOVER VERIFY COMPLETE
2024-12-09T13:32:28.283411+01:00
 rfs (PID:5336): krsr_rfs_atc: Identified database type as 'PHYSICAL STANDBY': Client is Foreground (PID:29093)
2024-12-09T13:32:30.524186+01:00
SWITCHOVER VERIFY BEGIN
SWITCHOVER VERIFY COMPLETE
2024-12-09T14:17:29.627321+01:00
 rfs (PID:3408): krsr_rfs_atc: Identified database type as 'PHYSICAL STANDBY': Client is Foreground (PID:540)
2024-12-09T14:17:31.443773+01:00
SWITCHOVER VERIFY BEGIN
SWITCHOVER VERIFY COMPLETE

La primera pregunta que nos hacemos es

Quien demonios esta haciendo el SWITHVER VERIFY en nuestro dataguard?

La respuesta es, que lo hace el propio Oracle.
Parece ser que, a Oracle se les ha escapado sin avisar un cambio que hace que el TFA ejecute periodicamente DGMGRL VALIDATE DATABASE, lo que nos genera estos mensajes en el alert.log.

Esta previsto que esto se solucione en AHF 24.8 , donde el comando validate no estara en el schedule del TFA.

Tenemos que esperarnos a que se libere esa version?

Afortunadamente no, ya que podemos eliminar esa ejecucion de nuestro profile de ejecucion con con el comando 

# tfactl modifyprofile db_dataguard disable

Eliminar un DR del Dataguard

Posted on por
Responder

Hoy vamos a ver un a entrada rápida de como eliminamos un DR de una configuración de dataguard.

Tenemos un entorno donde tenemos 2 Physycal standby y queremos eliminar la primera de ellas TEST_STBY1

Comprobemos la configuración de nuestro entorno, nos conectamos a la primaria y ejecutamos:

-bash-4.2$ . oraenv
ORACLE_SID = [oracle] ? TEST
The Oracle base has been set to /opt/app/oracle
-bash-4.2$ export ORACLE_SID=TEST
-bash-4.2$ dgmgrl /

DGMGRL> show configuration verbose;
Configuration - DR_TWO_STANDBY
  Protection Mode: MaxPerformance
  Databases:
    TEST      - Primary database
    TEST_STBY1    - Physical standby database
    TEST_STBY2 - Physical standby database
  Properties:
    FastStartFailoverThreshold      = '30'
    OperationTimeout                = '30'
    FastStartFailoverLagLimit       = '30'
    CommunicationTimeout            = '180'
    FastStartFailoverAutoReinstate  = 'TRUE'
    FastStartFailoverPmyShutdown    = 'TRUE'
    BystandersFollowRoleChange      = 'ALL'
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS

DGMGRL> show database  'TEST_STBY1';
Database - TEST_STBY1
  Role:            PHYSICAL STANDBY
  Intended State:  APPLY-ON
  Transport Lag:   14 hours 4 minutes 14 seconds
  Apply Lag:       14 hours 4 minutes 14 seconds
  Real Time Query: OFF
  Instance(s):
    TEST
Database Status:
SUCCESS

Tenemos claro que es la que queremos eliminar , de echo, podemos ver como lleva 14 horas. de retraso .
Para eliminarla ejecutaremos el comando Remove Database , si vemos el ejemplo, poderes ver como siempre ponemos el nombre de la base de datos entre comillas simples, en caso de no hacerlo, el dataguard lo tomará como minúsculas 


DGMGRL> disable database 'TEST_STBY1';
Disabled.

DGMGRL> remove database 'TEST_STBY1';
Removed database "TEST_STBY1" from the configuration

DGMGRL> show configuration verbose;

Configuration - MyTEST_STBY1
  Protection Mode: MaxPerformance
  Databases:
    TEST      - Primary database
    TEST_STBY2 - Physical standby database
  Properties:
    FastStartFailoverThreshold      = '30'
    OperationTimeout                = '30'
    FastStartFailoverLagLimit       = '30'
    CommunicationTimeout            = '180'
    FastStartFailoverAutoReinstate  = 'TRUE'
    FastStartFailoverPmyShutdown    = 'TRUE'
    BystandersFollowRoleChange      = 'ALL'
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS

DGMGRL> quit

Ya lo hemos eliminado, pero , deberemos de comprobar en nuestra base de datos primaria que no hemos dejado restos, para ello, buscaremos que los servicios y los destinos de archivado estén limpios de nuestra configuración anterior.

-bash-4.2$ sqlplus "/as sysdba"

SQL> set linesize 800;
SQL> show parameter log_archive_dest_

NAME                                 TYPE        VALUE

log_archive_dest_1                   string      location=USE_DB_RECOVERY_FILE_
                                                 DEST, valid_for=(ALL_LOGFILES,
                                                  ALL_ROLES)
log_archive_dest_2                   string      service="TEST_STBY1", LGWR ASYNC NOAFFIRM
                                             
log_archive_dest_3                   string      service="TEST_STBY2", LGWR ASYNC NOAFFIRM 
												
SQL>   show parameter log_archive_config;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_config                   string      dg_config=(TEST,TEST_STBY1,TEST_STBY2)

Podemos ver como el broker no ha limpiado la configuración, por lo que lo haremos nosotros a mano 

SQL> alter system set log_archive_dest_2='' scope=both;
SQL> alter system set log_archive_config='dg_config=(TEST,TEST_STBY2)' scope=both;



SQL> show parameter log_archive_config;
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_config                   string      dg_config=(TEST,TEST_STBY)
SQL> show parameter log_archive_dest_

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_1                   string      location=USE_DB_RECOVERY_FILE_
                                                 DEST, valid_for=(ALL_LOGFILES,
                                                  ALL_ROLES)
log_archive_dest_2                   string
log_archive_dest_3                   string      service="TEST_STBY2", LGWR ASYNC NOAFFIRM
SQL>

Con esto, podremos afirmar que nuestra configuración está limpia