Bom, com CERTEZA não parece ser algo simples, não : acho que vc vai acabar tendo que abrir um Chamado no Suporte Oracle mesmo... De momento, eu recomendo : a. cheque se de repente esse banco não está numa encarnação diferente, ou se no passado ele foi convertido de snapshot standby de volta para physical standby , tipo o que é mostrado na nota metalink/mos V$ARCHIVE_GAP doesn't show a existing GAP (Doc ID 974730.1) : claro, aqui ele está reportando BUG causando a V$ARCHIVE_GAP não funcionar, mas não é impossível que um dos bugs influencie alguma outra V$ b. execute os script de verificação e os passos indicados nas notas metalink/mos "Troubleshooting Data Guard" (Doc ID 237213.1) e (principalmente) na "Data Guard Physical Standby - Configuration Health Check" (Doc ID 1581388.1)... Em especial também faz uma consulta com SELECT * na V$DATABASE, V$INSTANCE, v$dataguard_status e views relacionadas procurando por eventuais diferenças nos databases : afora algumas coisas específicas pra standby (como a ROLE, o STATUS de abertura, etc) o resto Deveria ser similar nos dois databases c. não deveria acontecer, mas TALVEZ (por qquer motivo) vc tenha caído numa situação onde alguma sequência de archive mais antiga tenha falhado no envio ou na aplicação mas as subsequentes aplicaram ok : faz (no SQL DEVELOPER, já que vai ser uma consulta com muitas colunas e linhas) SELECT * ORDER BY SEQUENCE# nas views todas relacionadas a redo log ao invés de pedir o MAX como os scripts mostram ===> SE nenhuma dessas checagens/destes procedimentos mostrou nada, tua Alternativa Única é mesmo um chamado no Suporte Oracle, creio... []s Chiappa
[oracle_br] Re: Sincronismo standby
jlchia...@yahoo.com.br [oracle_br] Fri, 11 May 2018 11:43:25 -0700
- [oracle_br] Sincronism... Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]
- [oracle_br] Re: S... jlchia...@yahoo.com.br [oracle_br]
- Re: [oracle_br] S... Junior Cesar juniorcesa...@yahoo.com.br [oracle_br]
- Re: [oracle_b... jlchia...@yahoo.com.br [oracle_br]