Renato Barros — Blog

Bem-vindo ao novo barros.inf.br

2026-11-04T00:00:00Z

Durante um bom tempo, o barros.inf.br foi apenas o meu currículo online. Funcionava bem para recrutadores, mas eu sentia falta de um lugar para registrar o que aprendo no dia a dia com Oracle, Exadata e Cloud.

A partir de agora o site passa a ser um blog técnico, organizado assim:

Blog — posts curtos: dicas rápidas, scripts, comandos e notas de campo.
Artigos — conteúdos mais longos e aprofundados, com passo a passo e explicações de arquitetura.
Projetos — as academias, guias interativos e cheat sheets que publiquei (GoldenGate, Data Guard, Exadata, DBATOOLKIT e outros).
Currículo — a versão completa do meu currículo, em português e em inglês.

O que você vai encontrar por aqui

Os temas principais serão Oracle Database (RAC, ASM, Data Guard, GoldenGate, RMAN), Exadata, performance tuning com AWR/ASH, migrações para OCI, AWS e Azure, e automação com Shell, Python, Terraform e Ansible.

A ideia é escrever de forma prática: o problema, o que verificar, os scripts e o porquê de cada passo.

Acompanhe

Você pode assinar o feed RSS ou me seguir no LinkedIn. Sugestões de temas são muito bem-vindas — é só entrar em contato.

Monitorando o Oracle Data Guard com SQL: status, lag e gaps

2026-11-03T00:00:00Z

Quando alguém pergunta “o standby está em dia?”, a resposta precisa vir em segundos — e com números. Neste artigo reúno as consultas que uso para avaliar um ambiente Oracle Data Guard (testadas em 19c), sem depender de ferramentas gráficas.

Onde executar: algumas views só trazem informação útil no standby (como V$DATAGUARD_STATS), outras fazem mais sentido no primário. Indico em cada passo.

1. Quem é quem: papel e modo de proteção

Comece confirmando o papel de cada banco e o modo de proteção configurado. Execute no primário e no standby:

SELECT name,
       db_unique_name,
       database_role,
       open_mode,
       protection_mode,
       protection_level,
       switchover_status
FROM   v$database;

O que observar:

DATABASE_ROLE deve ser PRIMARY de um lado e PHYSICAL STANDBY do outro.
Se PROTECTION_LEVEL for diferente de PROTECTION_MODE, o ambiente está operando abaixo do nível configurado (por exemplo, MAXIMUM AVAILABILITY caindo para RESYNCHRONIZATION).
OPEN_MODE = READ ONLY WITH APPLY indica Active Data Guard em uso.

2. Transport lag e apply lag

No standby, a view V$DATAGUARD_STATS mostra o atraso de transporte e de aplicação:

SELECT name,
       value,
       unit,
       time_computed,
       datum_time
FROM   v$dataguard_stats
WHERE  name IN ('transport lag', 'apply lag', 'apply finish time');

Interpretação rápida:

transport lag alto → problema de rede, de destino de archive (LOG_ARCHIVE_DEST_n) ou o primário não está enviando redo.
apply lag alto com transport lag baixo → o redo chegou, mas o MRP está parado, lento ou aguardando algo.
Compare DATUM_TIME com SYSDATE: se o valor estiver muito antigo, a estatística não está sendo atualizada — o que por si só já é um sinal de problema.

3. Processos de recuperação

A partir do 19c, prefira V$DATAGUARD_PROCESS (a antiga V$MANAGED_STANDBY está obsoleta). No standby:

SELECT name,
       role,
       action,
       client_role,
       thread#,
       sequence#,
       block#
FROM   v$dataguard_process
ORDER  BY role, name;

Procure pelo processo com ROLE = 'recovery apply slave' / 'managed recovery' (MRP). Se não houver MRP, a aplicação de redo não está rodando. Para iniciar o apply em tempo real:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

Se o ambiente é gerenciado pelo Data Guard Broker, prefira DGMGRL> EDIT DATABASE '<standby>' SET STATE='APPLY-ON'; para manter a configuração do broker consistente.

4. Existe gap de archive?

No standby:

SELECT thread#,
       low_sequence#,
       high_sequence#
FROM   v$archive_gap;

Nenhuma linha retornada é o resultado esperado. Se houver gap, verifique se os archives faltantes ainda existem no primário (ou no backup) e se o FAL (FAL_SERVER) está configurado.

5. Última sequência recebida x aplicada, por thread

Em ambientes RAC, olhe cada thread separadamente. No standby:

SELECT thread#,
       MAX(sequence#)                                   AS ultima_recebida,
       MAX(CASE WHEN applied = 'YES' THEN sequence# END) AS ultima_aplicada
FROM   v$archived_log
WHERE  resetlogs_change# = (SELECT resetlogs_change# FROM v$database)
GROUP  BY thread#
ORDER  BY thread#;

Uma diferença de uma ou duas sequências é normal (o archive corrente ainda está sendo aplicado). Diferenças maiores e crescentes merecem investigação.

6. Destinos de archive com erro (no primário)

SELECT dest_id,
       dest_name,
       status,
       type,
       database_mode,
       recovery_mode,
       gap_status,
       error
FROM   v$archive_dest_status
WHERE  status <> 'INACTIVE';

Qualquer valor em ERROR ou GAP_STATUS diferente de NO GAP precisa ser tratado antes que o lag cresça.

7. Verificação via Broker

Se o broker estiver habilitado, ele resume tudo em um comando:

DGMGRL> SHOW CONFIGURATION LAG;
DGMGRL> VALIDATE DATABASE '<standby>';

O VALIDATE DATABASE é especialmente útil antes de um switchover planejado: ele aponta se o standby está pronto para assumir.

Resumo: checklist rápido

Verificação	Onde	Resultado esperado
Papel e modo de proteção	Ambos	`PROTECTION_LEVEL = PROTECTION_MODE`
Transport / apply lag	Standby	Próximo de zero (segundos)
Processo MRP	Standby	Presente e aplicando
`V$ARCHIVE_GAP`	Standby	Nenhuma linha
`V$ARCHIVE_DEST_STATUS`	Primário	Sem erro, `NO GAP`

Com essas consultas em um script único, dá para responder em poucos segundos se o ambiente de DR está realmente pronto — e, melhor ainda, automatizar o envio desse resumo por e-mail. Esse será o tema de um próximo post.

Objetos inválidos antes e depois de uma mudança no banco

2026-10-28T00:00:00Z

Toda mudança em banco de produção (GMUD) tem um risco silencioso: objetos que ficam inválidos depois de um ALTER TABLE, de uma package recompilada ou de um grant removido. Se você não sabe quantos objetos já estavam inválidos antes, fica impossível afirmar se a mudança quebrou algo.

Por isso, no meu roteiro de execução, sempre registro a situação antes e depois.

Antes da mudança

Contagem por owner e tipo:

SELECT owner, object_type, COUNT(*) AS qtd
FROM   dba_objects
WHERE  status = 'INVALID'
GROUP  BY owner, object_type
ORDER  BY owner, object_type;

E a lista detalhada, com os mais recentemente alterados primeiro:

SELECT owner, object_name, object_type, last_ddl_time
FROM   dba_objects
WHERE  status = 'INVALID'
ORDER  BY last_ddl_time DESC;

Depois da mudança

Execute as mesmas consultas. Se surgiram novos inválidos, a coluna LAST_DDL_TIME ajuda a identificar o que foi afetado pela mudança — normalmente eles aparecem no topo da lista.

Para recompilar apenas um schema:

EXEC DBMS_UTILITY.COMPILE_SCHEMA(schema => 'NOME_DO_SCHEMA', compile_all => FALSE);

Ou, para o banco todo (com o usuário SYS), o script padrão:

@?/rdbms/admin/utlrp.sql

Dica

Guarde a saída das duas execuções junto com a evidência da GMUD. Se alguém perguntar dias depois “esse objeto ficou inválido por causa da mudança?”, você responde com dados — e não com memória.

Dica rápida: encontrando a sessão bloqueadora raiz no RAC

2026-10-20T00:00:00Z

Usuários reclamando de lentidão, telas travadas e muitas sessões em enq: TX - row lock contention. Antes de sair matando sessões, descubra quem está no topo da cadeia.

Em RAC, use sempre as views GV$ — o bloqueador pode estar em outra instância. A coluna FINAL_BLOCKING_SESSION já aponta a sessão raiz:

SELECT s.inst_id,
       s.sid,
       s.serial#,
       s.username,
       s.machine,
       s.program,
       s.sql_id,
       s.event,
       s.seconds_in_wait,
       s.blocking_instance,
       s.blocking_session,
       s.final_blocking_instance,
       s.final_blocking_session
FROM   gv$session s
WHERE  s.blocking_session IS NOT NULL
ORDER  BY s.seconds_in_wait DESC;

Depois, olhe a sessão raiz com calma — o que ela está fazendo, há quanto tempo está INACTIVE, qual o último SQL:

SELECT inst_id, sid, serial#, username, status, machine, program,
       sql_id, prev_sql_id, last_call_et, logon_time
FROM   gv$session
WHERE  (inst_id, sid) IN (
         SELECT DISTINCT final_blocking_instance, final_blocking_session
         FROM   gv$session
         WHERE  final_blocking_session IS NOT NULL
       );

Uma sessão INACTIVE com LAST_CALL_ET alto segurando lock geralmente é transação aberta sem COMMIT — muitas vezes de uma ferramenta cliente esquecida aberta. Antes de encerrar, alinhe com o responsável pela aplicação. Se for preciso matar, em RAC informe a instância:

ALTER SYSTEM KILL SESSION 'sid,serial#,@inst_id' IMMEDIATE;