Bom, antes de mais nada plz :
- diga pra gente se a sua config é de múltiplos stand-by (ie, primary
transportando/enviando os redos para múltiplos targets de uma vez) OU é cascade
(ie, após ser aplicado no standby#1 o redo é re-enviado para o standby#2, que
tem como "primary"/origem o standby#1 ?
- mostre as configs referentes à dataguard dos 3 databases (em especial
FAL_xx, os destinos de archive E seus states, se é maximum performance ou não,
etc), E nos diga se vc tem os standby são
- diga se tem o DG BROKER configurado & ativo ou não, e se tem mostre o
resultado de um show configuration verbose; , de um show database;
- diga se vc tem (como recomendado) standby redo logfiles ou não
Com isso provavelmente poderemos eliminar alguns possíveis bugs, mas não é só
isso, faça o seguinte também :
=> conecte como sys/senha@hoststring AS SYSDBA a partir de cada um dos bancos
(NÂO confie só no TNSPING, tenta conectar mesmo, ida e volta)
=> consulte o alert.log E os trace files gerados no servidor de todos os 3
databases procurando por erros/warnings
=> navegue até o local dos teus archives e CONFIRME se os archives não
aplicados que formaram o gap que vc reportou estão fisicamente presentes ou
não, a PERMISSÂO deles no Sistema Operacional, e os Tamanhos reportados
=> CONFIRME que a área de archive em todos os bancos (mas claro
principalmente nesse que está com gap) não está nem perto de se esgotar, que
está disponível/online, etc
=> veja as MENSAGENS e STATUS referentes ao dataguard em todos os databases,
com queries tipo :
select * from (select to_char(timestamp, 'dd/mm/yyyy hh24:mi:ss') time,
MESSAGE, ERROR_CODE, DEST_ID, SEVERITY,FACILITY from V$DATAgUARD_STATUS order
by timestamp desc) where rownum < 300;
select inst_id,process,pid,status,thread#,sequence#, block# from
v$managed_standby where process like 'MRP%'
select * from V$STANDBY_EVENT_HISTOGRAM;
SELECT * FROM V$RECOVERY_PROGRESS;
Imagino que essas investigações já devem te dar alguma indicação...
[]s
Chiappa
