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

Responder a