Avalados por :

Problema ao aplicar archivelog na instância de recuperação Oracle: Solução para o erro ORA-16139

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

Encontrei um problema com a atualização do banco de dados Oracle. Após atualizar o banco de dados com a instância de produção e realizar um switchover, o Oracle não conseguiu aplicar certos arquivos de archivelog na instância de recuperação de desastres (DR).

A seguir, descrevo o problema:

O banco de dados com standby físico foi atualizado de 10.2.0.4 para 11.2.0.2.

Os passos de atualização são os seguintes:

1. Suspender a replicação do Dataguard: por exemplo, ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER;

2. Desligar a instância standby física

3. Atualizar o banco de dados na instância primária

4. Reiniciar a instância standby física com o novo ORACLE_HOME de 11gR2

5. Retomar a replicação do Dataguard: por exemplo, ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;

No entanto, surge um problema ao tentar realizar o switchover, pois não foi possível aplicar o archivelog.

Erro na instância standby:

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

(1) ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

retorno:

ORA-16139: recuperação de mídia necessária

(2) alter database recover managed standby database finish;

retorno:

ERRO na linha 1:

ORA-00283: sessão de recuperação cancelada devido a erros

ORA-00331: versão do log 11.2.0.0.0 incompatível com a versão do ORACLE 10.2.0.0.0

ORA-00334: arquivo de archivamento: '/oracle/M3P/dbexe/11202/dbs/arch1_439_742671080.dbf'

Por favor, ajude se alguém tiver alguma pista sobre isso,

Al Mamun

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

4 Respuestas

0
Cargando...

Olá Mamun,

Enfrentei um cenário semelhante cerca de dois anos atrás. Quando me deparei com esse problema, alterei o parâmetro "compatível" para a versão anterior. Após aplicar os arquivos de redo log offline, restaurei o parâmetro "compatível". Após algum tempo, durante nossas fases de testes de cenários de desastre, conseguimos abrir o sistema sem nenhum problema, mas na fase de teste descobrimos que os registros de "Entrega de Saída" e alguns outros documentos relacionados estavam corrompidos. Após uma investigação cuidadosa e verificações, descobri que esses arquivos de redo log offline não puderam ser importados corretamente e corromperam a consistência do banco de dados.

Por esse motivo, com base em minhas experiências, recomendei em minha primeira mensagem que você restaure o site de recuperação de desastres desde o início. Isso porque acredito que você não quer se deparar com uma surpresa desagradável ao levar seu sistema de desastres para a produção.

Em resumo, alterar o parâmetro "compatível" funciona tecnicamente, mas pode corromper a integridade.

Atenciosamente,

Orkun Gedik

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

O problema foi resolvido com a Nota SAP 598470, graças a Orkun Gedik e Volker Borowski por sua contribuição.

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

Olá Volker,

Por favor, revise a Nota 598470 - Erro devido ao parâmetro "compatível".

Cumprimentos,

Orkun Gedik

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

Olá,

Mais tarde, no final do DBUA, o parâmetro "compatível" é alterado para 11.2.0.

Registros gravados então não serão recuperáveis com um parâmetro compatível mais baixo.

Então, o que está configurado como "compatível" no seu 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?