Archivo de la categoría: Dataguard

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)

Datafiles UNAMED en dataguard

Posted on por
Responder

Hoy vamos a ver un a pequeña entrada de un error bastante común en dataguard.

El problema se da cuando la base de datos standby deja de aplicar 

DGMGRL> show configuration verbose
Configuration - test
  Protection Mode: MaxPerformance
  Members:
  DBTEST        - Primary database
    DBTEST_STBY   - Physical standby database
      Error: ORA-16810: multiple errors or warnings detected for the database

Ante un error tan genérico como este, lo primero que hemos de hacer es buscar en el alert.log de la base de datos del standby.
En este alert.log ya vemos un error mas claro 

Errors in file /u01/app/oracle/diag/rdbms/dbtest_stby/dbtest/trace/dbtest_mrp0_3972.trc:
ORA-01111: name for data file 21 is unknown - rename to correct file
ORA-01110: data file 21: '/u01/app/oracle/product/12.1.0.2/dbhome_1/dbs/UNNAMED0021'
ORA-01157: cannot identify/lock data file 21 - see DBWR trace file
ORA-01111: name for data file 21 is unknown - rename to correct file
ORA-01110: data file 21: '/u01/app/oracle/product/12.1.0.2/dbhome_1/dbs/UNNAMED0021'

Que es ese datafile que aparece en el $ORACLE_HOME/dbs llamado UNNAMED?

La respuesta nos la da oracle en la nota ID 739618.1..
Estos ficheros aparecen en el equipo de standby cuando se ha creado un datafile en el primario y el secundario no ha podido crearlo (por falta de espacio, error de configuración …. )

Como lo solucionamos ?

Lo primero que tenemos que hacer es cambiar el STANDBY_FILE_MANAGEMENT a MANUAL ya que vamos a modificar manualmente la ubicación de ficheros.

ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=MANUAL;

Tras esto, identificaremos en la base de datos primary cual es la ubicación correcta del fichero, si miramos en el extracto anterior del alert.log, veremos que se trata del datafile 21, así pues, iremos a la base de datos primary y veremos donde esta ubicado .

SQL>   select file_name,tablespace_name,bytes/1024/1024/1024 Gb
  from dba_data_files where file_id=21;

FILE_NAME  		                      TABLESPACE_NAME      GB 
----------------------------------------------------------------
+DATA_01/DBTEST/DATAFILE/testdf.791.968123327   TESTDF           5

Ahora tenemos que ir al standby y mover el fichero UNNAMED a su lugar correcto, para ello no usaremos el MOVE sino el comando CREATE DATAFILE AS 

alter database create datafile 
'/u01/app/oracle/product/12.1.0.2/dbhome_1/dbs/UNNAMED0021'
 as '+DATA_01' ;

Como podéis ver, no ha indicado el nombre que debe de tener el datafile, solamente la ruta, esto es por que tenemos definido el parametro db_recovery_file_dest que nos lo dejara con el nombre correcto.

Posible errores

Efectivamente, con el comando anterior no va a funcionar, ya que nos dara el error 

ERROR at line 1:
ORA-01136: specified size of file 204 (80 blocks) is less than original size of
655360 blocks
ORA-01111: name for data file 204 is unknown - rename to correct file
ORA-01110: data file 204:
'/u01/app/oracle/product/12.1.0.2/dbhome_1/dbs/UNNAMED0021'

Que hemos echo mal ?

No hemos echo nada mal, lo que ocurre es que cuando la ubicación de destino es dentro el ASM tendremos que indicarle el tamaño exacto del fichero .
En el alert nos ha indicado que el tamaño es de 655360 blocks
Si miramos el tamaño de bloque que tenemos :

SQL> show parameter block_size
NAME               TYPE        VALUE
------ --------------------------------------
db_block_size     integer       8192

Llevando a cabo una pequeña operacion aritmética 655360 *8192=5368709120

Ya podemos ejecutar el comando completo 

alter database create datafile 
'/u01/app/oracle/product/12.1.0.2/dbhome_1/dbs/UNNAMED0021' 
as '+DATA_01'size 5368709120;

Con esto tenemos el problema solucionado.

Volvemos a poner el standby en modo management auto 

ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;

Y activamos el broker de nuevo desde el primario. 

DGMGRL> show configuration verbose
Configuration - test
  Protection Mode: MaxPerformance
  Members:
  DBTEST        - Primary database
    DBTEST_STBY   - Physical standby database
      Error: ORA-16810: multiple errors or warnings detected for the database

DGMGRL> enable database 'DBTEST_STBY'
Disabled.
DGMGRL> enable database 'DBTEST_STBY'
Enabled.
DGMGRL> show configuration verbose
Configuration - test
  Protection Mode: MaxPerformance
  Members:
  DBTEST        - Primary database
    DBTEST_STBY   - Physical standby database
.
.

Configuration Status:
SUCCESS

Como siempre , mas información en las notas de soporte

  • How to resolve ORA-01111 ORA-01110 ORA-01157 in a physical standby database (Doc ID 1416554.1)
  • Background Media Recovery terminated with ORA-1274 after adding a Datafile (Doc ID 739618.1)