Archivo de la etiqueta: dataguard

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

Resincronizar un dataguard bastante desactualizado

Posted on por
Responder

Hoy veremos rapidamente una entrada de como podemos volver a dejar una PHYSICAL standby de nuevo sincronizada .
Supongamos que entramos a ver el estado de nuestro dataguard y nos encontramos con esto.

Configuration - TEST_SNDBY
  Protection Mode: MaxPerformance
  Members:
  TEST- Primary database
    Error: ORA-16724: cannot resolve gap for one or more members
    TEST_STBY- Physical standby database
      Warning: ORA-16809: multiple warnings detected for the member
Fast-Start Failover:  Disabled
Configuration Status:
ERROR   (status updated 50 seconds ago)

DGMGRL> show database 'TEST_STBY';
Database - TEST_SNDBY
  Role:               PHYSICAL STANDBY
  Intended State:     APPLY-ON
  Transport Lag:      104 days 20 hours 8 minutes 57 seconds (computed 1 second ago)
  Apply Lag:          104 days 20 hours 8 minutes 58 seconds (computed 2 seconds ago)
  Average Apply Rate: 0 Byte/s
  Real Time Query:    OFF
  Instance(s):
    TEST
  Database Warning(s):
    ORA-16853: apply lag has exceeded specified threshold
    ORA-16855: transport lag has exceeded specified threshold
Database Status:
WARNING

Que hacemos ahora?

Llevamos mas de tres meses de retraso, lo que probablemente significara casi el rehacer la database. La solucion desde la 19 es muy sencilla, y es resincronizar mediante red con el comando RECOVER STANDBY DATABASE FROM SERVICE TEST_DGMGRL; Los pasos exactos serian 
$ORACLE_HOME/bin/sqlplus "/as sysdba" << EOF
 recover managed standby database cancel;
 alter system set dg_broker_start=false;
 shutdown immediate;
 startup nomount;
 alter database mount standby database;
EOF
 
$ORACLE_HOME/bin/dgmgrl /  << EOF
RECOVER STANDBY DATABASE FROM SERVICE TEST_DGMGRL;
EOF

$ORACLE_HOME/bin/sqlplus "/as sysdba" << EOF
 alter system set dg_broker_start=true;
EOF

restaurar una base de datos desde el backup de una Standby

Posted on por
Responder

Hoy vamos a ver como anticipar un error en lo que puede ser una recuperacion larga

Supongamos que hemos recuperado una base de datos desde una standby database.
Si ese es el caso, cuando intentemos abrir la base de datos despues del recover tendremos un error

ORA-01666: control file is for a standby database



 Como lo prevenimos 

Vamos a ver primero como prevenir este error, y es simplemente añadiendo la  clausula primary a la cadena que vamos a usar para recuperar la base de datos desde ese standby backup 


rman target /
restore primary controlfile from '/backup/SID_STBY/standby_controlfile_backup';
exit;



Y pensareis, esto esta muy bien, pero.... y si ya tengo el backup restaurado


 Como lo solucionamos ?


 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;

 ALTER DATABASE ACTIVATE STANDBY DATABASE;

select name,open_mode ,database_role from v$database;

alter database open resetlogs

ORA-38870: cannot backup a control file that may have incorrect data file structure.

Posted on por
Responder

Hoy vamos a volver con una entrada rapida de un problema muy facil de solucionar.

A veces, podemos encnontrarnos en el alert.log con el error 

ORA-38870:cannot backup a control file that may have incorrect data file structure

Si miramos las trazas asustan bastante 

2018-10-23T16:08:43.542081+02:00
Errors in file /u01/app/oracle/diag/rdbms/test_stby/test/trace/test_m000_425.trc:
ORA-38870: cannot backup a control file that may have incorrect data file structure.
2018-10-23T16:13:43.189251+02:00
Starting control autobackup
********************  WARNING ***************************
The errors during Server autobackup are not fatal, as it
is attempted after sucessful completion of the command.
However, it is recomended to take an RMAN control file
backup as soon as possible because the Autobackup failed
with the following error:
ORA-38870: cannot backup a control file that may have incorrect data file structure.
********************  END OF WARNING *******************

Pero, buscando en la documentacion de Oracle, nos contraremos que

Error code: ORA-38870

Description: cannot backup a control file that may have incorrect data file structure.
This control file was created or converted based on a control file from a time different from the time of the database.
Action: Open database read-only to synchronize the control file with the database dictionary to fix the control file

Cualquier cosa relaccionada con una estructura invalida de un controlfile puede asustar bastante, pero , este alarmante problema se soluciona de manera muy rapida y sencilla, simplemente haciendo eso, abriendo la base de datos en modo lectura.
Y ya no volveremos a ver mas el problema

Parametro oculto _query_on_physical

Posted on por
Responder

Hoy vamos a ver una de estas entradas que contradicen algunas otras que podemos ver en internet.

Dado lo restrictivo de Oracle con el licenciamiento, seria muy interesante contar con una opcion que nos deshabilitara el Real-Time Query del Dataguard .
Si buscamos por internet, nos encontramos con un parametro oculto llamado _query_on_physical

Si Ejecutamos el comando 

alter system set "_query_on_physical"=false scope=spfile;

Deshabilitaremos el Active Dataguard, pero … ¿que dice Oracle de todo esto?
Oracle como siempre dice que nunca debemos de activar parametros ocultos en la base de datos a no ser que sea especificamente recomendado por el equipo de soporte

NOTE: Hidden parameter «_query_on_physical» is NOT an option to prevent Active Data Guard usage. It should NOT be used at all in any version of the Oracle Database.
It is unsupported to be set unless Oracle Support advises it for diagnostic reason

Asi que, ya sabeis, la unica opcion que nos da Oracle para no activarlo es «tener cuidado».

Como siempre, mas informacion en soporte:

  • Which are Supported Methods to Prevent Active Data Guard Usage When License is Not Available? (Doc ID 2269239.1)