Monitoramento de Oracle Database: o que medir, quais views usar e a armadilha do Diagnostics Pack

Autor: Pedro Tebaldi PM do KeepGreen

Publicado ago/2026

Quando o Oracle começa a responder devagar, o time raramente descobre pelo banco. Descobre pelo ERP travado, pelo caixa que não fecha ou pelo lote noturno que estourou a janela. A essa altura, o DBA já está apagando incêndio sem saber em que ponto a instância parou.

O custo não é abstrato. Segundo a análise anual de interrupções do Uptime Institute, 57% das empresas dizem que a última parada relevante custou mais de US$ 100 mil. Além disso, uma em cada cinco passou de US$ 1 milhão.

Este guia percorre o monitoramento de banco de dados aplicado ao Oracle: quais camadas acompanhar e quais views consultar. Em seguida, mostra o que muda em RAC e Data Guard. Por fim, explica por que consultar o AWR sem checar o contrato pode gerar fatura inesperada.

Por que monitorar Oracle exige outra abordagem

O Oracle não expõe o problema pelo mesmo caminho que os demais bancos. Em um MySQL ou em um ajuste de performance no PostgreSQL, o diagnóstico costuma partir do consumo de recurso. Os suspeitos são conhecidos: CPU alta, disco saturado, conexões no limite.

Na arquitetura Oracle, esse caminho engana com frequência. A instância mantém uma wait interface própria, que registra em que evento cada sessão ficou bloqueada e por quanto tempo. Por isso, a pergunta certa não é “qual recurso está alto”, mas sim “onde a sessão está esperando”.

Essa diferença muda a ordem das prioridades. Um servidor com CPU folgada pode abrigar um banco parado em contenção de log file sync. Da mesma forma, um host com CPU no teto pode estar apenas processando trabalho útil. Sem a camada de espera, a operação lê o sintoma errado.

O que monitorar em um Oracle Database

Um Oracle Database em produção pede monitoração contínua em sete camadas:

Disponibilidade da instância: a instância está aberta e o listener responde.
Wait events: em que classe de espera as sessões ativas consomem tempo.
Sessões e bloqueios: quantas sessões estão ativas e quais estão travadas por outras.
Tablespace e ASM: espaço livre, ritmo de crescimento e saúde dos diskgroups.

Memória SGA e PGA: alocação, uso real e pressão sobre a memória do host.
Redo e archive: frequência de troca de log e ocupação da área de recuperação.
Backup RMAN: resultado do último job e idade do backup mais recente.

A tabela abaixo traduz cada camada em uma verificação concreta.

Wait events: onde o banco realmente está parado

Os wait events registram o tempo que cada sessão passa aguardando um recurso. Pode ser leitura de bloco em disco, confirmação de redo, latch de memória ou trava de linha.

Em seguida, o Oracle agrupa esses eventos em classes: User I/O, Concurrency, Commit e Configuration. Assim, a equipe lê a saúde do banco sem decorar centenas de nomes.

Na prática, três classes concentram a maior parte dos incidentes. User I/O cresce quando a aplicação lê muito bloco físico, geralmente por falta de índice. Commit sobe quando o redo não acompanha a taxa de transação. Já Concurrency denuncia disputa entre sessões, o caso clássico de bloqueio.

O ponto operacional é simples: alerte pela classe de espera dominante, não pelo evento isolado. Dessa forma, a equipe recebe um sinal estável mesmo quando o nome do evento muda entre versões.

Sessões bloqueadas: o alerta que vale por dez

Uma única sessão bloqueadora costuma travar dezenas de outras. Por isso, o alerta mais eficiente do conjunto não é de recurso. Ele dispara quando existem sessões esperando há mais de X segundos por outra sessão.

A consulta abaixo funciona em qualquer edição, sem depender de pacote licenciado.

-- Sessoes ativas em espera e quem as bloqueia
SELECT s.sid, s.username, s.event, s.wait_class,
       s.seconds_in_wait, s.blocking_session
  FROM v$session s
 WHERE s.status = 'ACTIVE'
   AND s.wait_class <> 'Idle'
 ORDER BY s.seconds_in_wait DESC
 FETCH FIRST 10 ROWS ONLY;

Tablespace e ASM: o alerta precisa ser preditivo

Quase todo ambiente dispara alerta de tablespace em um percentual fixo de uso. Entretanto, esse limiar isolado falha nos dois sentidos.

Em um datafile com autoextend ativo, um tablespace quase cheio pode ser irrelevante porque o arquivo ainda cresce. Já em um tablespace estático de 2 TB, a mesma leitura significa poucas horas de folga.

O critério útil combina três sinais: percentual de uso, espaço absoluto restante e velocidade de crescimento nos últimos sete dias. Assim, o alerta responde à pergunta que interessa ao plantão: quantos dias faltam para acabar.

Na prática, um bom ponto de partida combina dois gatilhos independentes. O alerta de atenção dispara quando restam menos de sete dias de folga projetada. Já o crítico dispara com menos de dois dias ou com espaço livre abaixo do maior objeto do tablespace. Depois disso, calibre pela criticidade de cada base.

Vale destacar que a view DBA_TABLESPACE_USAGE_METRICS já considera o autoextend no cálculo, ao contrário de consultas antigas sobre DBA_FREE_SPACE. Em ambientes com ASM, acompanhe também o espaço livre por diskgroup e o estado de rebalance. Esse acompanhamento alimenta diretamente o planejamento de capacidade do ambiente.

Memória: SGA, PGA e o mito do hit ratio alto

O buffer cache hit ratio aparece em quase todo dashboard de Oracle, embora seja um dos indicadores mais enganosos do conjunto. Uma query ruim que varre a mesma tabela repetidas vezes empurra o hit ratio para perto do máximo, ainda que destrua a performance do banco.

Portanto, trate o hit ratio como contexto, nunca como alerta. Os sinais que realmente importam na camada de memória são outros. Vale acompanhar o crescimento sustentado da PGA alocada, as execuções que estouram para o disco temporário e a pressão de memória no sistema operacional.

Esse último ponto conecta o banco ao host. Quando a SGA somada à PGA ultrapassa a memória física disponível, o sistema começa a paginar e a latência dispara. Por isso, o consumo de memória do servidor precisa ser lido junto com as métricas da instância, nunca em painéis separados.

AWR, ASH e Statspack: quando a licença entra na conta

Aqui mora o detalhe que a maioria dos conteúdos sobre Oracle omite. O AWR e o ASH pertencem ao Diagnostics Pack, um produto licenciado à parte do Oracle Database Enterprise Edition. Consultar essas informações sem o contrato correspondente configura uso não licenciado.

A regra está na documentação oficial de licenciamento: todas as views com prefixo DBA_HIST_ fazem parte do pacote.

Existem seis exceções liberadas: DBA_HIST_SNAPSHOT, DBA_HIST_DATABASE_INSTANCE, DBA_HIST_SNAP_ERROR, DBA_HIST_SEG_STAT, DBA_HIST_SEG_STAT_OBJ e DBA_HIST_UNDOSTAT.

O valor envolvido explica o cuidado. Na lista de preços vigente, de 3 de agosto de 2026, o Diagnostics Pack custa US$ 7.500,00 por processador, mais US$ 1.650,00 anuais de suporte.

Um ambiente com oito processadores licenciados por engano vira uma conta relevante em auditoria.

Como evitar o uso acidental do pacote

Ambos os pacotes vêm habilitados por padrão na Enterprise Edition. Ou seja, basta um DBA abrir a aba de performance do Enterprise Manager para consumir a funcionalidade. Para bloquear o acesso de forma definitiva, ajuste o parâmetro CONTROL_MANAGEMENT_PACK_ACCESS para NONE nos bancos que não têm o contrato.

Feita essa trava, a monitoração passa a se apoiar nas views dinâmicas e no Statspack. Ambos cobrem a operação do dia a dia sem risco contratual.

Oracle RAC e Data Guard: o que muda

Em cluster RAC, a monitoração ganha uma dimensão nova: o interconnect entre os nós. Latência ou perda de pacotes nessa rede aparece como esperas da classe Cluster, principalmente gc buffer busy e gc cr block busy. Acompanhe também os eventos de eviction, que indicam nó expulso do cluster.

No Data Guard, o indicador central é o atraso do standby. Existem dois números distintos que costumam ser confundidos. O transport lag mede quanto redo ainda não chegou ao standby. Já o apply lag mede quanto redo chegou mas ainda não foi aplicado. Ambos saem de V$DATAGUARD_STATS.

Vale ressaltar um ponto que passa despercebido: um standby com apply lag crescente continua reportando status normal. Como resultado, a réplica parece saudável enquanto o RPO real se deteriora hora após hora. Esse é exatamente o tipo de falha silenciosa que estratégias de alta disponibilidade precisam cobrir com alerta próprio.

Como monitorar Oracle sem o Enterprise Manager

Monitorar Oracle sem o Enterprise Manager é perfeitamente viável. Basta criar um usuário dedicado com permissão de leitura sobre um conjunto pequeno de views dinâmicas.

Em seguida, uma plataforma de monitoração unificada coleta essas métricas. A abordagem cobre disponibilidade, esperas, tablespace, memória e backup sem tocar em recurso licenciado à parte.

Esse modelo de coleta sem agente tem uma vantagem prática relevante. Como a conexão acontece via SQL*Net, um único coletor atende dezenas de instâncias. Dessa forma, ninguém precisa instalar software em cada servidor de banco.

Usuário de monitoração com privilégio mínimo

Conceder DBA ao usuário de monitoração é o atalho mais comum e o mais perigoso. O correto é liberar apenas as views necessárias, uma a uma.

-- Usuario de monitoracao com privilegio minimo
CREATE USER opsmon IDENTIFIED BY "senha_forte";
GRANT CREATE SESSION TO opsmon;

GRANT SELECT ON v_$instance          TO opsmon;
GRANT SELECT ON v_$session           TO opsmon;
GRANT SELECT ON v_$system_event      TO opsmon;
GRANT SELECT ON v_$sysmetric         TO opsmon;
GRANT SELECT ON v_$pgastat           TO opsmon;
GRANT SELECT ON v_$rman_status       TO opsmon;
GRANT SELECT ON dba_tablespace_usage_metrics TO opsmon;

Em ambientes multitenant, replique a concessão no container correto. Além disso, prefira views GV$ quando o banco roda em RAC, já que elas agregam todos os nós da instância.

Alertas que não viram ruído: limiar fixo ou baseline

Limiar fixo funciona bem para eventos binários. Instância fora do ar, listener sem resposta, backup com falha: nesses casos, o alerta não admite ambiguidade e deve disparar sempre.

Para métricas de carga, porém, o limiar fixo cria ruído. Um banco processa 800 sessões ativas às 10h da manhã e 40 às 3h da madrugada. Nenhum número único serve aos dois momentos. Consequentemente, a equipe passa a ignorar o alerta, o que anula a própria monitoração.

A alternativa é a baseline por janela horária: compare o valor atual com o comportamento típico daquele dia da semana e daquele horário. Dessa forma, o desvio vira o gatilho, não o valor absoluto. O mesmo raciocínio vale para a monitoração dos servidores que sustentam o banco, onde o pico previsível também não deveria acordar ninguém.

Conclusão

Monitorar Oracle bem não exige colecionar centenas de métricas. Exige acertar a ordem: primeiro a disponibilidade da instância, depois a classe de espera dominante, em seguida as camadas de espaço, memória, redo e backup. Esse encadeamento entrega diagnóstico, não apenas dashboard bonito.

Dois cuidados separam a operação madura da amadora. O primeiro é tratar limiar fixo como exceção, reservando-o aos eventos binários. O segundo é conferir o contrato antes de apoiar a rotina em AWR ou ASH. Ambos pertencem a um pacote licenciado à parte.

Na prática, o banco quase nunca opera sozinho. Ele convive com aplicação, rede e servidores. Além disso, o chamado nasce onde o usuário sente. Por isso, a métrica do Oracle rende muito mais ao lado do restante do ambiente, em uma única plataforma como o OpMon. Um console isolado do DBA entrega bem menos.

Quer avaliar como está a visibilidade do seu ambiente Oracle hoje? Fale com um especialista da OpServices e receba um diagnóstico do seu cenário atual.