Oracle ERRORSTACK: como descobrir o SQL exato por trás de um ORA-00942

Quem administra Oracle Golden Gate há algum tempo já encontrou situações em que algum replicat apresenta o seguinte erro:
2026-09-22 18:44:46 ERROR OGG-00664 Error 942 on OCI call [ORA] - ORA-00942: table or view does not exist Help: https://docs.oracle.com/error-help/db/ora-00942/.
2026-09-22 18:44:48 WARNING OGG-00543 Unexpected threading library failure. Error code 16 (Device or resource busy).
O grande problema deste erro, é que ele não é especifico, o problema começa quando você não sabe qual tabela ou view, qual SQL, ou até mesmo qual sessão está provocando o erro durante o start do replicat.
REPLICAT ABENDED REP1 INTEGRATED 00:00:00 00:30:13
erro indicava claramente um problema de acesso a um objeto, mas não informava em quais objeto do banco rs.
Foi aí que usei um recurso extremamente útil do Oracle Database: EVENT + ERRORSTACK.
Este recuso funciona como um gatilho:
EVENT 942 habilitado
↓
Oracle continua trabalhando normalmente
↓
alguma sessão recebe ORA-00942
↓
evento é disparado
↓
Oracle gera o trace
↓
capturamos o contexto do erro
Nesse caso estamos dizendo ao Oracle:
Quando ocorrer um
ORA-00942, gere um error stack com informações detalhadas sobre a sessão no momento do erro.
Pronto !!
Agora sabemos quais objetos ele está relacionando os erros:
E finalmente apareceu o SQL que estava falhando:
SELECT ...
FROM sys."_BASE_USER" u,
sys.obj$ o,
sys.cdef$ cd,
sys.ccol$ cc,
sys.con$ c,
sys.col$ col
WHERE ...
Pronto.
Saímos de:
ORA-00942
table or view does not exist
para:
O Apply Receiver do GoldenGate está executando uma consulta contra objetos internos do Data Dictionary.
Ao executar os seguintes selects descobri a ausencia de grants corretos diretamente em objetos pertencentes ao schema SYS.
Mas o usuário tinha SELECT ANY TABLE
Essa foi outra parte interessante do troubleshooting.
O GGADMIN já possuía:
SELECT ANY TABLE
Mas mesmo assim estava tomando o seguinte erro:
ORA-00942: table or view does not exist
Isso acontece porque objetos internos do Oracle Data Dictionary, especialmente objetos do schema SYS, possuem proteção específica.
SELECT ANY TABLE não deve ser interpretado como acesso irrestrito a todas as tabelas internas do Data Dictionary.
Testando com GGADMIN, alguns desses objetos também retornavam ORA-00942.
A documentação do Oracle diferencia SELECT ANY TABLE de privilégios que permitem acesso ao Data Dictionary. Para esse cenário, o privilégio que resolveu o acesso necessário foi:
GRANT SELECT ANY DICTIONARY TO GGADMIN;
Após o grant, os objetos anteriormente inacessíveis passaram a ser consultados e o Integrated Replicat conseguiu prosseguir.
Em seguida meu processo no golden gate saiu do status de ABEND para RUNNING e problema foi resolvido.
Status Detalhado:
Cuidados em produção
ALTER SYSTEM SET EVENTS deve ser utilizado com critério.
Se você configurar:
ALTER SYSTEM SET EVENTS
'942 trace name errorstack level 3';
e o ambiente estiver gerando milhares de ORA-00942, poderá produzir grande quantidade de dados de diagnóstico.
Por isso, prefiro trabalhar com uma janela controlada:
Identificar erro reproduzível
Habilitar event
Reproduzir
Desabilitar imediatamente
Analisar o trace
Também é importante avaliar o escopo e impacto apropriados para o ambiente antes de utilizar eventos de diagnóstico em produção.
Conclusão
Às vezes o erro apresentado pela aplicação é apenas a ponta do problema.
Neste caso começamos com:
ORA-00942
O GoldenGate não mostrava qual objeto estava causando a falha.
Com um ERRORSTACK, conseguimos descobrir:
qual sessão
↓
qual módulo
↓
qual componente GoldenGate
↓
qual SQL
↓
quais objetos
↓
qual privilégio estava faltando
Para quem trabalha com Oracle, esse tipo de recurso muda bastante a abordagem de troubleshooting.
Em vez de:
“Qual tabela será que está faltando?”
passamos a perguntar ao próprio banco:
“Oracle, capture o contexto exatamente no momento em que esse erro acontecer.”
E foi isso que nos levou da mensagem genérica ORA-00942 até a causa real do problema.





