DBA/CDC: Captura de Dados Alterados e Materialização de Views do ADMS

Projeto: DSB26201 — Avaliação de arquitetura de integração ADMS (Energisa) Fonte: Reuniao-DBA — "Assessment Integração ADMS - DBA - CDC (Consultoria Syntropy)" (VTT, 28/07/2026, 09h01–10h49, 1h48min) + screenshot "adr0002-conector-kafka-source-debezium-xstream-XStream.drawio.png" + Ata 12 (Assessment_Consolidado) Status: Rascunho para validação Elaborado por: Consultoria Syntropy

Por que este artefato existe

Esta sessão desceu ao nível mais concreto do assessment: os mecanismos reais de captura, transporte e materialização de dados que sustentam praticamente todas as integrações já mapeadas nas sessões anteriores. Participaram Wesley (DBA Oracle, responsável pela configuração original do XStream) e Eduardo César (DBA SQL Server/bancos do ADMS), com Norberto contextualizando e Castellani conduzindo a análise arquitetural.

A Ata 12 chega a uma conclusão que atravessa este engajamento inteiro: boa parte do risco identificado nesta sessão não é técnico, é de governança. A ausência de documentação sobre o que muda a cada atualização do fornecedor, a comunicação incompleta com as equipes de banco e a falta de propriedade formal sobre um componente customizado crítico transformam problemas previsíveis em incidentes de produção diagnosticados pela equipe errada.

Diagrama 1 — Arquitetura atual de captura de dados alterados (CDC)

Esta é a visão macro construída em conjunto com o próprio screenshot fornecido pela equipe (adr0002-conector-kafka-source-debezium-xstream-XStream.drawio.png), que documenta o lado Oracle: redo logs → XStream (usando o mecanismo de captura do GoldenGate, apenas a função de extração) → Kafka Connect com Debezium como plugin → tópico específico por tabela dentro do Openshift. O diagrama acima estende essa visão para incluir o lado SQL Server, que é onde está o achado mais relevante da sessão: as views proprietárias do ADMS não são objetos simples do banco — invocam DLLs e funções que executam dentro dos processos internos do produto, algumas buscando informação em memória (por exemplo, dados de SCADA). Isso torna tecnicamente impossível aplicar CDC diretamente sobre elas, e também inviabiliza a alternativa aparentemente mais simples de capturar as tabelas de origem e reconstruir a view fora do produto.

A solução que a Energisa construiu para contornar isso — um procedimento customizado que materializa a view em tabela via merge por chave, rodando a cada 5 ou 10 minutos — nasceu sob pressão de prazo contratual (implantação de Mato Grosso do Sul, setembro de 2025, quando 59 relatórios anunciados como "quase prontos" não estavam) e foi replicada, sem revisão, em duas implantações subsequentes (Minas Rio, Sul-Sudeste). Hoje é um componente crítico em produção sem equipe formalmente responsável por sua sustentação e evolução — ponto que a própria Ata trata como consenso entre consultoria e equipes de banco.

Diagrama 2 — O risco central: mudança de esquema do fornecedor vira "incidente de banco"

Este é o ponto que a Ata 12 classifica como diagnóstico central da sessão. O fornecedor (Schneider) atualiza o ambiente do ADMS sem detalhar o que muda — "ela fala que vai atualizar o ambiente, mas não detalha para a gente", nas palavras registradas na sessão. Quando uma view muda de estrutura, a materialização não absorve a mudança automaticamente: é necessário recriar a tabela materializada e recriar o CDC do zero, um trabalho descrito como extenso. Isso já aconteceu uma vez, mas apenas em homologação, com acompanhamento das equipes de banco e arquitetura — ainda não ocorreu em produção.

A implicação, que a própria Ata destaca como risco de diagnóstico incorreto, é o que torna este achado mais grave do que um simples bug: quando essa falha ocorrer em produção, ela vai se manifestar como um incidente de banco de dados, quando a causa real é uma mudança de modelo não comunicada pelo fornecedor. Isso não apenas causa o impacto direto — desloca a investigação para a equipe errada e consome tempo de resposta justamente no momento mais crítico. A mitigação discutida na sessão combina duas frentes: técnica (detecção de desvio de esquema, ou uma alternativa de payload flexível em formato JSON sem esquema fixo) e contratual (acordo formal de comunicação prévia de mudanças com o fornecedor).

Diagrama 3 — A lacuna de continuidade: site switch deixa consumidores corporativos congelados

Os agrupamentos do ADMS (G1 no data center da Paraíba, G2 e G3 no de Minas Gerais) possuem ambientes primário e secundário em arranjo cruzado, com mecanismo de site switch controlado pelo próprio fornecedor. O ponto levantado nesta sessão é que o processo de replicação/captura de dados analisado considera apenas a origem primária — aparentemente não contempla o ambiente secundário.

A consequência prática, registrada com precisão na Ata: em um site switch ou contingência, o ADMS continua operacional no ambiente secundário, mas os consumidores corporativos (Data Lake, BI, e por extensão os painéis do centro de operação) deixam de receber atualização e ficam com a última informação disponível antes do chaveamento — um cenário citado como possivelmente durando um dia inteiro. O efeito mais insidioso não é o gap de dados em si, mas como ele é percebido: como "problema da tela" ou do sistema de visualização, não como consequência direta do failover. As equipes de banco não têm o detalhamento de como o mecanismo de site switch do fornecedor funciona; a documentação existente (PDF já compartilhado com a consultoria) foi considerada insuficiente, e o encaminhamento acordado foi consolidar as dúvidas técnicas para uma reunião única e objetiva com o fornecedor.

Achados de fidelidade

1. A própria Ata 12 flagra uma inconsistência de data — e a confirmamos. O Anexo B da Ata inclui um item incomum entre as Atas revisadas até aqui: "Especialista do WFM [...] A data de retorno de férias citada na gravação está inconsistente com o calendário da sessão e deve ser confirmada." Fomos ao trecho exato do VTT (01:45:17–01:45:25): "O Eduardo conhece o ESO e do WFM e tá de férias. Acho que chegar dia 3 de outubro seria só na outra semana." A sessão ocorreu em 28/07/2026 — "3 de outubro" é mais de dois meses à frente, e o restante do roteiro da Ata trata esse retorno como algo a agendar "na semana seguinte", ao lado de reuniões já marcadas para a mesma semana (dados/Databricks na quinta ou sexta, rede/telecom no dia seguinte). Quase certamente um erro de mês/data do reconhecimento automático de voz. Vale a pena confirmar a data real antes de tratá-la como prazo em qualquer planejamento.

2. Mais uma variante fonética de "Castellani", distinta do "Cassiano" já tratado. Aos 00:02:53 do VTT, logo após alguém dizer "e aí o castelani vai conduzir", o reconhecimento automático produz "Beleza, Cassiane, beleza?" — mais uma renderização do nome do consultor, somando-se a "Castelão", "Castelano" e "cassilani" já observados em sessões anteriores. O contexto aqui deixa claro que se trata do próprio consultor sendo endereçado por outro participante, não de um terceiro — diferente do "Cassiano" mencionado em três sessões anteriores (GIS, WFM, Monitoramento) em contextos de agendamento com alguém da equipe de dados. Não reabrimos essa segunda questão, já resolvida por você; registramos apenas que são dois fenômenos de transcrição distintos, para não misturá-los.

3. Achado técnico mais sólido da sessão, com boa cobertura na Ata. O componente de materialização de views — criado emergencialmente, replicado em três implantações, hoje crítico e sem dono formal — e o risco de diagnóstico incorreto quando o fornecedor mudar esquema em produção são tratados de forma consistente entre VTT e Ata, sem hedges contraditórios. É o achado com maior densidade de evidência direta (nomes dos responsáveis, cronologia da implantação de 2024–2025, números específicos) de toda a sessão.

4. Números conferem sem discrepância. Atraso de 10 a 20 minutos (30 em picos) concentrado entre 10h e 11h30, os ~59 relatórios anunciados para a implantação de setembro de 2025, a sobreposição de ~7 tabelas em comum entre BI e sistemas corporativos, e a ordem de mil tabelas existentes no banco com apenas dezenas efetivamente usadas — todos consistentes entre o VTT e a Ata.

5. Screenshot corrobora e complementa, sem contradizer. O diagrama adr0002-conector-kafka-source-debezium-xstream-XStream.drawio.png documenta exatamente o lado Oracle descrito na Ata e no VTT (redo logs → captura/fila → Outbound Server → Kafka Connect com Debezium e interface XStream Out → tópicos por tabela dentro do Openshift). Não cobre o lado SQL Server nem a materialização de views — o que é esperado, já que o próprio nome do arquivo (ADR, Architecture Decision Record) sugere que documenta uma decisão específica do lado Oracle, não a arquitetura completa de CDC.

Próximo passo

Confirmar com Wesley e Eduardo César a data real de retorno de férias do especialista do WFM (a Ata já sinalizou a suspeita; o VTT aponta "3 de outubro", incompatível com o calendário da própria sessão). Em paralelo, priorizar a formalização de propriedade do procedimento de materialização de views — hoje o item de maior risco acumulado da sessão — e consolidar as perguntas técnicas para a reunião única com a Schneider sobre site switch, bibliotecas das views e política de comunicação de mudanças de esquema, conforme já encaminhado na própria Ata.