¡Caminando hacia el éxito!

Aprende en Comunidad

Avalados por :

Problema al aplicar archivelog en instancia de recuperación Oracle: Solución al error ORA-16139

  • Creado 01/03/2024
  • Modificado 01/03/2024
  • 23 Vistas
0
Cargando...

Encontré un problema con la actualización de la base de datos de Oracle. Después de actualizar la base de datos con la instancia de producción y realizar un switchover, Oracle no pudo aplicar ciertos archivos de archivelog en la instancia de recuperación ante desastres (DR).

A continuación se describe el problema:

La base de datos con standby físico se actualizó de 10.2.0.4 a 11.2.0.2.

Los pasos de actualización son los siguientes:

1. Suspender la replicación de Dataguard: por ejemplo, ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER;

2. Apagar la instancia standby física

3. Actualizar la base de datos en la instancia primaria

4. Reiniciar la instancia standby física con el nuevo ORACLE_HOME de 11gR2

5. Reanudar la replicación de Dataguard: por ejemplo, ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;

Sin embargo, surge un problema al intentar realizar el switchover, ya que no se logró aplicar el archivelog.

Error en la instancia standby:

=================

(1) ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

retorno:

ORA-16139: se requiere recuperación de medios

(2) alter database recover managed standby database finish;

retorno:

ERROR en la línea 1:

ORA-00283: sesión de recuperación cancelada debido a errores

ORA-00331: versión de registro 11.2.0.0.0 incompatible con la versión de ORACLE 10.2.0.0.0

ORA-00334: archivo de archivado: '/oracle/M3P/dbexe/11202/dbs/arch1_439_742671080.dbf'

Por favor, ayuda si alguien tiene alguna pista sobre esto,

Al Mamun

Pedro Pascal
Se unió el 07/03/2018
Pinterest
Telegram
Linkedin
Whatsapp

4 Respuestas

0
Cargando...

Hola Mamun,

Me enfrenté a un escenario similar hace aproximadamente dos años. Cuando me encontré con este problema, cambié el parámetro compatible a la versión anterior. Después de aplicar los archivos de redolog sin conexión, restauré el parámetro compatible. Después de un tiempo, durante nuestras fases de pruebas de escenarios de desastre, pudimos abrir el sistema sin ningún problema, pero en la fase de prueba descubrimos que los registros de "Entrega Saliente" y algunos otros documentos relacionados estaban corruptos. Después de una cuidadosa investigación y comprobaciones, descubrí que esos archivos de redolog sin conexión no se pudieron importar correctamente y corrompieron la inconsistencia de la base de datos.

Por esta razón, basándome en mis experiencias, te recomendé en mi primer mensaje que restaures el sitio de recuperación ante desastres desde el principio. Esto se debe a que creo que no quieres enfrentarte a una mala sorpresa cuando lleves tu sistema de desastres a productivo.

En resumen, cambiar el parámetro "compatible" funciona técnicamente, pero puede corromper la integridad.

Saludos cordiales,

Orkun Gedik

Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019
0
Cargando...

Gracias, el problema se resolvió con la Nota SAP 598470, gracias a Orkun Gedik y Volker Borowski por su contribución.

Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019
0
Cargando...

Hola Volker,

Por favor, revisa la Nota 598470 - Error debido al parámetro "compatible".

Saludos cordiales,

Orkun Gedik

Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019
0
Cargando...

Hola,

más adelante, al final de DBUA, el parámetro "compatible" se cambia a 11.2.0.

Los registros escritos entonces no serán recuperables con un parámetro compatible más bajo.

Entonces, ¿a qué está configurado "compatible" en tu standby?

Volker

Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019

contacto@primeinstitute.com

(+51) 1641 9379
(+57) 1489 6964

© 2024 Copyright. Todos los derechos reservados.

Desarrollado por Prime Institute

¡Hola! Soy Diana, asesora académica de Prime Institute, indícame en que curso estas interesado, saludos!
Hola ¿Puedo ayudarte?