Em um cenário em que o Oracle Golden Gate é usado para replicar um site primário com um banco de dados Oracle RAC para um site secundário (e ativo/ativo de volta), suspeitamos de alterações inesperadas do site secundário não utilizado.
O problema é um pouco difícil de depurar, pois não temos acesso direto ao DBA. Gostaria de saber se existe uma maneira fácil com acesso SQL sem privilégios no lado primário para ver se alguma alteração é recebida do outro banco de dados?
Posso ver contadores ou timestamps de atividade OGG que me ajudem a rastrear DML feito?
Pelo que entendi, pude ver alterações do usuário OGG ao configurar gatilhos ou auditoria - no entanto, ambos não estão disponíveis nesta situação.
A resposta curta é 'Não', você não pode provar isso de forma confiável sem detalhes de nível inferior. Auditoria e Triggers funcionarão a partir da camada de banco de dados. Se você tiver acesso aos arquivos do GoldenGate Trail (arquivos com todas as alterações extraídas), poderá ver exatamente o que o GoldenGate replicará usando
logdump(outro binário que vem com o OGG).Parece que você tem replicação bidirecional (volta ativa-ativa). Nesse caso, seu processo de extração deve ser configurado para ignorar seu usuário OGG, pois você não deseja replicar as alterações de volta para a fonte.
Outra coisa a considerar se os gatilhos estão ou não habilitados em seu site não utilizado/secundário. Eu vi coisas estranhas acontecerem quando os gatilhos não estão desabilitados no lado receptor (registros de histórico duplicados, violações de chave exclusivas, etc).
Além disso, se o seu site secundário não for usado, talvez o DataGuard seja uma solução melhor. Tudo depende do seu software e arquitetura de infraestrutura. Não será uma solução bidirecional, mas sem dúvida uma solução mais simples que o OGG.