Ata 12 · Captura de Dados Alterados em Oracle e SQL Server, Materialização das Views do ADMS, Transporte por Kafka, Relatórios e Continuidade em Contingência (28 de julho de 2026)

Ata consolidada a partir do documento técnico produzido sobre a sessão e da transcrição integral da gravação, com unificação dos temas e preservação dos pontos que dependem de validação no áudio original.

Data	28 de julho de 2026 (terça-feira)
Horário	09h01 às 10h49, horário de Brasília
Duração	1h48min25s
Plataforma	Microsoft Teams (reunião remota, com gravação e transcrição automática)
Natureza	Sessão técnica de levantamento com as equipes de banco de dados
Tema	Captura de dados alterados em Oracle e SQL Server, materialização das views proprietárias do ADMS, transporte por Kafka e Debezium, alimentação do Data Lake, requisitos de tempo de atualização e continuidade durante site switch
Cliente	Energisa (distribuição de energia)
Fornecedor	Syntropy Labs
Elaborado por	Syntropy Labs
Fontes	Documento técnico consolidado da sessão e transcrição integral da gravação do Microsoft Teams

1.13.1. Identificação e contexto da sessão

1.13.1.1. Origem e posicionamento no assessment

A sessão foi aberta com a mesma contextualização das demais: a revisão das integrações do ADMS foi solicitada desde a primeira implantação, em razão de um episódio de contingência, e a decisão foi conduzir uma avaliação de ponta a ponta com apoio de consultoria externa. Foi registrado que já haviam sido realizadas reuniões com mais de dez equipes e que ainda faltavam algumas frentes para completar o quadro, entre elas o atendimento e a equipe que dará sustentação posterior ao ADMS.

O convite às áreas foi explícito quanto ao formato esperado: além da descrição dos processos, as equipes foram solicitadas a apresentar as dores e os principais problemas na visão delas, no meio ou ao final da apresentação. Essa orientação define a natureza do registro desta ata, que é predominantemente um levantamento de fragilidades relatadas pelos próprios responsáveis técnicos.

1.13.1.2. Foco desta sessão

• Equipes de banco de dados e responsáveis pela captura de dados alterados em Oracle e em SQL Server.
• Mecanismos de captura: XStream no Oracle e captura nativa no SQL Server.
• Transporte por Kafka Connect com Debezium e publicação em tópicos.
• Materialização das views proprietárias do ADMS e implicações de mudança de estrutura.
• Alimentação do Data Lake e do Databricks e necessidades de relatórios.
• Fluxos legados de SCADA e OMS, redes de tecnologia operacional, DMZ e corporativa.
• Continuidade dos consumidores durante site switch e recuperação de desastre.
• Gestão de mudanças e dependência do fornecedor da plataforma.

1.13.1.3. Limites da sessão

A identificação automática de falantes não se manteve estável ao longo da gravação, de modo que o registro cronológico do Anexo A atribui as falas por papel funcional. Diversos nomes de tabelas, produtos e componentes foram capturados de forma foneticamente imprecisa e estão relacionados no Anexo B para confirmação. Não foram apresentados, na sessão, inventário de tópicos e partições, medições de vazão, esquemas das tabelas envolvidas nem documentação de site switch, itens que constam das evidências solicitadas.

1.13.2. Participantes e áreas envolvidas

Norberto da Silva Prado	Energisa, arquitetura e integração. Contextualização do assessment, histórico da implantação dos relatórios, apresentação do desenho de replicação dos dados de SCADA e condução das próximas agendas.
Wesley	Energisa, administração de banco de dados. Participou desde a configuração inicial da captura de dados alterados e do XStream no Oracle. Relatou os gargalos de volumetria e o comportamento do fluxo.
Eduardo César	Energisa, administração de banco de dados. Conhecimento dos bancos do ADMS, dos procedimentos de captura e da materialização no SQL Server. Relatou os riscos associados às atualizações do fornecedor.
João Carlos Franco Castellani	Syntropy Labs. Condução da análise arquitetural sobre desempenho, particionamento, evolução de esquema, classes de serviço e continuidade.
Vladimir Morozowski de Sousa	Syntropy Labs. Condução, gestão e acompanhamento do assessment e registro da sessão.

Foram citados, sem participação direta:

• Érica de Andrade e Santos, gestora do projeto, responsável pela articulação e pelas autorizações relacionadas ao fornecedor.
• Equipe de arquitetura, que desenvolveu o procedimento de materialização e assumiu parte da entrega dos relatórios, e equipe de DevOps, que a acompanhou nessa frente.
• Equipe de BI e de dados, responsável pela especificação e pela entrega dos relatórios, com parte do time incorporada à estrutura de arquitetura.
• Equipe de Kafka e integração, que metrificou e isolou as tabelas de maior volume.
• Schneider, fornecedora do ADMS, responsável pelo produto, pelos patches, pelos upgrades e pelos componentes proprietários, incluindo views e bibliotecas.
• Especialista do WFM, então em férias, cuja participação foi considerada necessária em sessão posterior.
• Equipes de F5 e de API Gateway, consultadas em sessão anterior sobre reapontamento e verificações de integridade para contingência.

1.13.3. Resumo executivo

A sessão aprofundou o assessment na camada que sustenta praticamente todas as integrações analisadas até aqui: a captura das mudanças nos bancos de dados. O encontro confirmou que a solução atual cumpre funções críticas, mas foi construída em etapas, sob pressão de implantação, com componentes customizados que carecem de governança, de observabilidade, de definição de acordo de nível de serviço e de responsável formal.

Vazão da captura no Oracle	Duas tabelas de alta volumetria fazem o consumo acumular atraso de 10 a 20 minutos, chegando a cerca de 30 minutos em picos, especialmente entre 10h e 11h30.	O fluxo deixa de sustentar o tempo quase real exigido pela operação.	Medir a vazão por etapa, revisar particionamento e paralelismo e isolar as tabelas ofensoras.
Ordenação sequencial	A leitura acompanha a sequência de números de mudança do Oracle, de modo que uma tabela de grande volume retém o avanço das demais.	Tabelas críticas atrasam por causa de tabelas analíticas.	Separar conectores e workloads por criticidade, com classes de serviço distintas.
Comandos não interpretados	Determinados comandos de definição de dados não são interpretados pelo conector e já quebraram o fluxo.	Interrupção da captura por operação rotineira de banco.	Levantar os comandos e versões envolvidos e submeter alterações a procedimento controlado.
Views proprietárias do ADMS	As views não são projeções simples: invocam funções e bibliotecas do produto e chegam a buscar informação em memória. A captura não opera sobre views.	Foi necessário criar uma camada de materialização em tabelas.	Rever a solução, formalizar sua propriedade e avaliar alternativas de contrato de dados.
Evolução de esquema pelo fornecedor	Atualizações podem incluir, remover ou alterar colunas, views e tabelas, sem comunicação prévia nem documentação do que muda.	A materialização e a captura precisam ser recriadas, com risco de indisponibilidade em produção.	Acordo formal de mudanças, detecção de desvio de esquema e automação da recriação.
Requisitos de atualização	Os intervalos de 5 e 10 minutos foram definidos pela duração dos jobs, sem requisito de negócio formalizado.	Não há como dimensionar corretamente nem priorizar entre consumidores.	Matriz de consumidor, finalidade, criticidade e acordo de nível de serviço.
Continuidade em site switch	A replicação para os consumidores corporativos considera o ambiente primário e não acompanha a troca para o secundário.	O ADMS segue operando em contingência enquanto BI e sistemas dependentes ficam sem atualização.	Desenhar o failover ponta a ponta, com reapontamento e teste periódico.
Duplicidade de acessos à fonte	Várias ferramentas leem as mesmas bases do ADMS para atender BI e sistemas corporativos distintos.	Complexidade, custo operacional e leitura redundante sobre a fonte.	Consolidar em uma solução única de integração, reutilizável pelos consumidores.

Diagnóstico central da sessão As fragilidades identificadas se dividem em dois grupos que exigem tratamentos diferentes. O primeiro é técnico e diz respeito a vazão, ordenação, particionamento, interpretação de comandos e acoplamento de esquemas. O segundo é de governança e diz respeito à ausência de documentação detalhada das alterações do fornecedor, à comunicação incompleta com as equipes de banco e à falta de responsabilização formal sobre procedimentos criados emergencialmente. Corrigir apenas o primeiro grupo produz alívio temporário: enquanto a mudança de esquema continuar chegando sem aviso, qualquer solução de captura permanecerá exposta.

1.13.4. Arquitetura atual de captura e transporte

1.13.4.1. Visão macro

1. As alterações ocorrem nos bancos Oracle e SQL Server que sustentam o ADMS e os sistemas associados.

2. No Oracle, a captura utiliza o XStream, mecanismo que observa os redo logs e disponibiliza as transações em fila interna do próprio banco.

3. O Kafka Connect, com o Debezium atuando como plugin, lê os eventos e os publica em tópicos específicos por tabela.

4. As aplicações interessadas e o ambiente de dados assinam os tópicos. O Databricks consome e grava o conteúdo no ambiente de Data Lake.

5. No SQL Server, a captura nativa é habilitada diretamente nas tabelas necessárias, e não no banco como um todo.

6. Quando a fonte é uma view, a Energisa executa um procedimento customizado que a materializa em tabela e, somente então, habilita a captura sobre essa tabela.

7. Fluxos legados de SCADA e de OMS utilizam uma ferramenta de extração e carga própria, passando pela rede de tecnologia operacional e pela DMZ até os bancos e aplicações corporativas.

1.13.4.2. Fluxo no Oracle

Origem	Bancos Oracle do ambiente do ADMS e dos sistemas corporativos.
Captura	Redo logs observados pelo XStream, com serviço de saída e fila interna do Oracle. Foi esclarecido na sessão que o XStream utiliza o mecanismo de captura do GoldenGate, empregando apenas a função de extração e não a de replicação.
Conector	Kafka Connect com o Debezium como plugin, que se conecta ao serviço de saída e produz no tópico específico daquela tabela.
Configuração	A configuração das filas e do serviço de saída dentro do Oracle é realizada pela equipe de administração de banco de dados.
Consumidores	Aplicações operacionais e o Databricks, que grava no ambiente de Data Lake.
Risco principal	Atraso em picos, retenção sequencial provocada por tabelas de grande volume e sensibilidade a determinados comandos de definição de dados.

1.13.4.3. Fluxo no SQL Server

Captura direta	Recurso nativo do SQL Server habilitado tabela a tabela, conforme a necessidade. Foi destacado que essa é a solução nativa do produto e que funciona bem.
Views do ADMS	Não são suportadas pela captura nativa. Além disso, não são projeções simples: parte delas invoca funções em bibliotecas que executam dentro dos processos dos serviços internos do produto, inclusive para buscar informações em memória, como as relacionadas ao SCADA.
Solução da Energisa	Procedimento customizado que consulta a view periodicamente, identifica os registros por chave e executa mesclagem, atualizando os existentes e inserindo os novos em uma tabela materializada.
Exceção adicional	Tabelas que utilizam truncamento do lado do fornecedor não podem receber a captura diretamente, porque isso provocaria erro na aplicação do ADMS. Para elas foi adotada a mesma alternativa de materialização.
Destino	A captura das tabelas materializadas segue para o Kafka e, a partir dele, para o Data Lake e os demais consumidores.
Risco principal	Mudanças de estrutura nas views ou nos objetos de origem exigem recriação e podem interromper a cadeia.

Foi registrada uma diferença relevante de volumetria entre os dois lados: no SQL Server, o volume de alterações capturadas, sobretudo o originado das views materializadas, é pequeno, enquanto no Oracle o volume é muito maior. Isso concentra o problema de vazão em um dos fluxos e o problema de acoplamento de esquema no outro.

1.13.5. Materialização das views do ADMS

1.13.5.1. Por que a materialização foi criada

A especificação inicial do projeto de relatórios considerou majoritariamente tabelas e requisitos próximos de tempo real. Próximo à implantação, ao conversar com a equipe do fornecedor, identificou-se que parte relevante das fontes era composta por views do ADMS.

A constatação decisiva foi de natureza técnica: essas views não são simples objetos do banco. Elas utilizam um recurso que permite gerar bibliotecas executadas dentro dos processos dos serviços internos do próprio produto, e algumas delas buscam informações em memória, por exemplo quando envolvem o SCADA. Isso elimina a alternativa aparentemente mais simples, que seria habilitar a captura nas tabelas de origem e reconstruir a visão fora do produto, porque a lógica não está expressa apenas em SQL.

Somou-se a isso a identificação de tabelas que utilizam truncamento do lado do fornecedor. Como a habilitação da captura sobre uma tabela que sofre truncamento provoca erro na aplicação do ADMS, essas tabelas receberam o mesmo tratamento de materialização.

1.13.5.2. Funcionamento descrito

1. Um job do SQL Server aciona periodicamente o procedimento customizado.

2. O procedimento consulta a view e identifica todas as mudanças ocorridas desde a execução anterior.

3. Os registros são tratados por chave: os existentes são atualizados e os novos são inseridos, em operação de mesclagem.

4. A tabela materializada recebe a captura nativa do SQL Server.

5. O conector captura os eventos e os envia ao Kafka.

6. O fluxo segue para o Data Lake e para os consumidores finais.

Foi esclarecido na sessão que o procedimento não é um recurso nativo do produto nem do banco: trata-se de uma solução desenvolvida internamente pela equipe de arquitetura da Energisa, acionada por job do SQL Server.

1.13.5.3. Frequência e natureza do processamento

Os intervalos foram ajustados conforme a duração de cada execução. Jobs que terminavam em trinta ou quarenta segundos foram configurados para cinco minutos, e casos mais longos, incluindo uma execução próxima de seis minutos, foram configurados para dez minutos. A definição foi validada caso a caso, conforme o volume de cada tabela.

Reconhecimento explícito da natureza do processamento Foi registrado de forma direta pelos participantes que os intervalos não decorreram de definição de negócio, e sim da viabilidade técnica de execução dos jobs, e que a solução atende bem. Foi igualmente reconhecido que, por depender de um gatilho periódico que consulta a view e atualiza a tabela, esse fluxo não é tempo real por natureza, e sim micro-batch. Somente as tabelas com captura habilitada diretamente entregam a atualização no momento em que ela ocorre. Esse esclarecimento é relevante porque parte da expectativa registrada em sessões anteriores tratava toda a cadeia como se fosse de tempo real.

1.13.5.4. Fragilidade diante da evolução de esquema

A principal preocupação relatada pela equipe de banco não é o desempenho da materialização, que foi avaliada como funcionando bem, e sim o acoplamento da solução ao modelo de dados do fornecedor.

• O fornecedor pode incluir, remover ou alterar campos e objetos durante uma atualização de versão, e já foram observadas remoções de colunas que estavam sendo utilizadas em relatórios, além de tabelas que deixaram de existir.
• A materialização possui esquema definido e não absorve automaticamente essas alterações.
• Diante de uma mudança, é necessário recriar as estruturas, transformar novamente a view em tabela e recriar a captura, trabalho descrito como extenso.
• O cenário já ocorreu em homologação, com a participação da equipe de banco e da arquitetura, e ainda não ocorreu em produção, o que a equipe atribui ao fato de a captura específica não estar implantada no momento das atualizações anteriores.
• A captura habilitada diretamente sobre tabelas é resiliente à inclusão de coluna: o mecanismo entende a nova estrutura. A fragilidade é específica do caminho da view materializada.

Risco de diagnóstico incorreto em produção Foi registrado um ponto que merece destaque: quando essa falha ocorrer em produção, ela se manifestará como um incidente de banco de dados, embora a causa seja uma mudança de modelo não comunicada pelo fornecedor. Além do impacto direto, isso desloca o diagnóstico para a equipe errada e consome tempo de resposta em um momento crítico. A mitigação é tanto técnica, com detecção de desvio de esquema, quanto contratual, com comunicação prévia do que será alterado.

1.13.5.5. Propriedade e sustentação do componente

O procedimento de materialização foi desenvolvido às pressas pela equipe de arquitetura, no contexto emergencial descrito no item 1.13.9, para viabilizar a entrega da implantação. Foi registrado na sessão, com concordância expressa das equipes de banco, que um componente com essa criticidade precisa de uma equipe formalmente responsável por sua sustentação e evolução, questão que já havia sido levada à gestão do projeto e permanece em aberto.

• Definir a equipe proprietária do procedimento e o modelo de suporte.
• Formalizar código-fonte, versionamento, testes, documentação e monitoração.
• Estabelecer o fluxo de inclusão de novas views e tabelas e de desativação de objetos.
• Incluir a solução no catálogo de serviços e no processo de gestão de mudanças.
• Criar procedimento de resposta a incidentes, com recriação da captura, reprocessamento e reconciliação dos dados.

1.13.6. Gargalo de vazão no fluxo Oracle

1.13.6.1. Sintoma relatado

A dor apresentada pela administração de banco no lado Oracle é a incapacidade de consumir na mesma velocidade em que as mudanças são geradas. Foi relatado que, em determinados bancos e horários, uma mensagem gerada no banco naquele instante corresponde, do lado do consumo, a conteúdo produzido dez ou vinte minutos antes, chegando a cerca de trinta minutos em picos. O período citado como mais crítico é aproximadamente entre 10h e 11h30, sem que se tenha identificado qual processo de negócio se intensifica nesse intervalo. O efeito não ocorre o dia inteiro nem em todos os bancos, concentrando-se nos de maior volume transacional.

1.13.6.2. Causa provável

A explicação técnica apresentada pela própria equipe é que a leitura é sequencial. O Oracle gera as mudanças de forma sequencial, identificadas pelos números de mudança do sistema, e o mecanismo de captura acompanha essa sequência. Em consequência, quando o fluxo encontra uma tabela de volume muito elevado, ele fica retido nela e não prossegue para as demais, ainda que estas tenham pouca alteração pendente. O atraso, portanto, não se distribui proporcionalmente ao volume de cada tabela: ele se propaga para todas as que compartilham o mesmo fluxo.

1.13.6.3. Compartilhamento de infraestrutura e classes de serviço

Duas tabelas foram identificadas como responsáveis pela maior parte do volume. O isolamento foi feito pela equipe de Kafka, que conseguiu metrificar a contribuição de cada uma. O ponto arquitetural relevante é a natureza do consumo: essas tabelas atendem o ambiente de dados, que toleraria atraso de até cerca de trinta minutos, enquanto a mesma infraestrutura atende a operação, que depende de tempo quase real.

Classe de serviço menos crítica degradando a mais crítica A situação descrita é um caso claro de ausência de separação por classe de serviço: uma carga analítica, que admite atraso de meia hora, está degradando uma carga operacional que não admite. O tratamento não exige, necessariamente, mais infraestrutura. Exige separação de conectores e de workloads por criticidade, de modo que cada classe tenha vazão e acordo de nível de serviço próprios. Enquanto as duas compartilharem o mesmo caminho sequencial, qualquer aumento de volume analítico se converterá em atraso operacional.

1.13.6.4. Hipótese de particionamento e paralelismo

A hipótese técnica levantada pela consultoria é que o problema esteja relacionado ao particionamento dos tópicos correspondentes a essas tabelas. Com o conteúdo distribuído em mais partições, o consumo pode ocorrer em paralelo, tipicamente com um processo por partição, em lugar do processamento sequencial praticado quando não há particionamento adequado. A contrapartida é que a chave de partição precisa ser escolhida de modo a preservar a ordenação exigida pelos consumidores, ponto que precisa ser verificado tabela a tabela.

Foi também discutida a alternativa de uma leitura incremental, que dependeria de um campo capaz de identificar o que foi alterado, como um marcador temporal ou de versão. A equipe informou que as tabelas em questão não possuem esse campo, o que inviabiliza a abordagem sem alteração no modelo de dados do fornecedor e reforça a captura de mudanças como caminho.

1.13.6.5. Evidências necessárias para fechar o diagnóstico

• Nome exato das duas tabelas de maior volume e seus respectivos esquemas.
• Tópicos correspondentes, número de partições, chaves de mensagem, fator de replicação e configuração de ordenação.
• Número de tarefas do conector e parâmetros de leitura, lote e filas internas.
• Taxa de geração de eventos por segundo e volume em bytes, no pico e fora do pico.
• Atraso por partição, tempo entre o momento da mudança na origem e a ingestão, e acúmulo observado.
• Consumo de processador, memória, rede e disco nos componentes de captura, no conector, nos brokers e nos consumidores.
• Identificação da etapa em que o atraso se concentra: captura no banco, conector, broker ou consumidor.

1.13.7. Interpretação de comandos e quebra do fluxo

Uma segunda dor relatada no lado Oracle é a sensibilidade do conector a determinados comandos executados no banco. Foi registrado que qualquer alteração nas tabelas mapeadas exige cuidado elevado, porque existem comandos que o conector não consegue interpretar.

Inclusão de uma tabela cuja definição continha uma palavra que o conector não conseguiu interpretar.	Quebra do fluxo de captura.
Execução de um comando de remoção de um log de view materializada relacionado a uma tabela mapeada.	O conector não conseguiu interpretar o comando e o fluxo quebrou.

A consequência operacional é que operações rotineiras de banco de dados passam a exigir coordenação com a plataforma de eventos, sob pena de interromper a cadeia de integração. Para fechar o diagnóstico é necessário obter os comandos completos que provocaram as falhas, os registros e as pilhas de erro correspondentes e a versão e a configuração do conector utilizado, de modo a distinguir limitação de produto, defeito conhecido ou configuração inadequada.

Esse achado se conecta diretamente ao tema tratado no item 1.13.5.4: os mesmos comandos de definição de dados que quebram o conector são os que o fornecedor executa, sem aviso, durante as atualizações da plataforma.

1.13.8. Requisitos de tempo de atualização

Um dos pontos mais produtivos da sessão foi a separação entre linguagem técnica e requisito de negócio. A expressão tempo real vinha sendo usada de forma ampla desde a especificação inicial dos relatórios, mas a análise mostrou que os consumidores atuais toleram defasagem de cinco a dez minutos, e que o próprio mecanismo de materialização não é, por natureza, tempo real.

Critério proposto pela consultoria Tempo real é um requisito, e não uma preferência. Quando existe requisito, ele deve ser atendido. Quando não existe, o ideal é não implementar, porque a opção consome mais recursos, aumenta a complexidade e não se paga se não alterar o resultado do negócio. A pergunta correta não é com que velocidade o dado pode chegar, e sim qual decisão ou automação depende dele e o que muda se ele chegar cinco minutos depois.

Streaming e tempo real	Segundos ou frações de segundo, conforme o processo	Eventos operacionais e ações automáticas que não podem aguardar.	Maior complexidade, observabilidade e custo. Exige justificativa de negócio.
Tempo quase real	Até poucos minutos	Aplicações operacionais, painéis críticos e acompanhamento de despacho.	Pode usar streaming com tolerância controlada ou micro-batch curto.
Micro-batch	5 a 10 minutos	Materialização das views e a maioria dos relatórios discutidos.	Compatível com os jobs atuais, desde que existam acordo de nível de serviço e monitoramento.
Batch	Dezenas de minutos a horas	Consolidações e usos analíticos sem ação imediata.	Menor custo e simplicidade. Não deve compartilhar recursos críticos sem isolamento.

Foi apresentado ainda o padrão de arquitetura que combina as duas naturezas: um fluxo de streaming que alimenta a visão do que está acontecendo naquele momento, sustentando ação imediata, e um fluxo consolidado, de periodicidade maior, que sustenta a análise confiável. Nem todo relatório precisa da primeira via, e tratá-los como se fossem iguais é o que encarece a solução.

1.13.8.1. Elevação da expectativa operacional

A coordenação apresentou o contexto que explica a pressão por tempo real. Nos centros de operação, o operador trabalha com cerca de seis monitores e um painel de parede, e parte dos relatórios é exibida nesse painel. Antes do ADMS, a solução era cliente-servidor com processos em lote, e o intervalo entre o despacho de uma ordem de serviço e a sua visualização variava de três a sete minutos, com percepção de lentidão ou travamento nos horários de maior movimento. Com a nova plataforma, o despacho aparece praticamente de imediato.

A consequência foi registrada com precisão: uma vez que o operador experimenta esse comportamento, não aceita retroceder, e a tendência é que a necessidade aumente ao longo do tempo, inclusive por conta da abertura do mercado de energia. Ao mesmo tempo, para consultas e para a maioria dos relatórios, essa necessidade não existe, e os usuários já estão habituados ao modelo atual. A conclusão convergente foi que o requisito deve ser estabelecido por processo, e não por plataforma.

1.13.9. Relatórios, BI, Data Lake e Databricks

1.13.9.1. Histórico da implantação e a solução emergencial

A sessão registrou, com um nível de detalhe que não havia aparecido nas sessões anteriores, como a arquitetura atual de relatórios foi construída. O relato é relevante porque explica a origem dos componentes customizados hoje em operação.

1. O trabalho começou por volta de 2024, com a equipe de BI conduzindo a especificação junto com a equipe de desenvolvimento, processo que em determinado momento se perdeu.

2. As planilhas enviadas indicavam que praticamente tudo era necessário em tempo real e que as fontes eram tabelas. O levantamento ficou a cargo da própria equipe de BI e foi recebido nessa forma.

3. Com base nessa definição, foi adotada a captura nativa no SQL Server.

4. Próximo à implantação, ao conversar com a equipe do fornecedor, identificou-se que parte das fontes eram views com dependência de bibliotecas do produto, e também tabelas que utilizam truncamento, o que exigiu a alternativa de materialização.

5. Em setembro de 2025 seria realizada a implantação, com cerca de 59 relatórios anunciados como quase prontos. No dia da implantação, os relatórios não estavam prontos.

6. Para não comprometer o cronograma, que tinha compromisso contratual com o fornecedor e impacto financeiro relevante caso fosse postergado para o ano seguinte, foi feito um trabalho emergencial de adaptação dos relatórios já existentes na unidade de Mato Grosso do Sul.

7. Nesse contexto foi desenvolvido, às pressas, o procedimento de captura e repasse dos dados descrito no item 1.13.5.

8. A gestora do projeto acionou uma empresa que já havia passado por integrações semelhantes com o ADMS. A proposta apresentada foi de um produto de código fechado, a ser inserido no meio de um processo de integração, com valor considerado exorbitante, e a contratação não avançou.

9. A mesma solução emergencial foi repetida nas implantações seguintes, em Minas Rio e Sul-Sudeste, porque os relatórios continuavam não entregues.

10. Após um trabalho conjunto com outra empresa para entender por que a entrega não avançava, a direção de TI transferiu a frente de relatórios para a arquitetura, em conjunto com a equipe de DevOps, incorporando seis pessoas da equipe de BI à estrutura e contando com um engenheiro de dados.

Leitura arquitetural do histórico A cadeia de decisões descrita é coerente e defensável em cada etapa isolada: diante de um prazo contratual com impacto financeiro, adaptar relatórios existentes e criar um procedimento de captura foi a escolha correta. O que precisa ser corrigido é o efeito acumulado: uma solução concebida como emergencial foi replicada em três implantações sucessivas, permanece em operação e ainda não possui equipe responsável, documentação ou acordo de nível de serviço. O risco não está na decisão original, e sim na sua permanência sem governança.

1.13.9.2. Situação alvo

• A visão atual é centralizar os dados corporativos no Data Lake com Databricks, permitindo reuso além dos relatórios.
• Na ponta, o Power BI permanece como ferramenta de visualização. Anteriormente existia um data warehouse em instalações próprias que o alimentava.
• Foi mencionado que, caso houvesse necessidade efetiva de tempo real, a alternativa avaliada seria outra ferramenta de visualização, capaz de ler diretamente do barramento, hipótese descartada quando se concluiu que a necessidade não era essa.
• No Databricks, o formato Delta é utilizado a partir das camadas de refinamento. O formato adotado na camada de entrada ainda precisa ser confirmado com a equipe de dados.

1.13.9.3. Consumo interno e consumo regulatório

A discussão levantou a possibilidade de uma arquitetura bifurcada por finalidade. O caminho atual, com captura, transporte por Kafka e ingestão no Data Lake, permanece necessário para a disponibilização corporativa, para o compartilhamento externo e para o atendimento regulatório, já que é no Lake que esse dado é disponibilizado. Para os consumidores internos críticos, como os painéis do centro de operação, foi levantada a alternativa de uma réplica relacional na rede corporativa, o que reduziria a dependência da cadeia completa. A alternativa não foi decidida e depende das análises descritas no item 1.13.11.

1.13.10. SCADA, OMS legado e consolidação das integrações

1.13.10.1. Fluxo legado descrito

1. Dados de SCADA e dos sistemas OMS anteriores, principalmente eventos e alertas, são capturados por uma ferramenta de extração e carga fornecida por terceiro, que se conecta a cada base de SCADA.

2. A ferramenta gravava em uma base localizada na DMZ.

3. Da DMZ, os dados eram replicados para o lado corporativo.

4. Na rede operacional e na DMZ existia um sistema de visualização e análise dos dados de SCADA.

5. Do lado corporativo, dois sistemas corporativos também consomem essas informações.

6. Parte dos componentes e bancos já foi movida para a rede corporativa, e a replicação passou a ocorrer diretamente, sem a etapa intermediária.

1.13.10.2. Estado atual e proposta de normalização

O desenho apresentado na sessão refletia parcialmente o estado anterior e foi corrigido durante a própria conversa pelas equipes de banco, que confirmaram que os bancos envolvidos já estão na rede corporativa. A proposta em elaboração, apresentada como um exercício de arquitetura-alvo ainda em rascunho, contempla:

• Reconhecer que existem três agrupamentos do ADMS, com o G1 no data center da Paraíba e o G2 e o G3 no data center de Minas Gerais.
• Substituir o modelo atual, em que se reaproveitou o banco da primeira empresa migrada de cada agrupamento, por bancos nomeados e dedicados por agrupamento, com estrutura normalizada.
• Manter, na rede corporativa, uma réplica dos dados necessários de cada tabela, dimensionada pela necessidade real, para atender as soluções internas que dependem dessas informações.
• Reunir em uma única solução de integração o atendimento aos sistemas corporativos, ao BI e às demais demandas, em lugar de manter várias ferramentas lendo a mesma base do ADMS.
• Avaliar a substituição da ferramenta de extração de terceiro, implementada em Java e dependente do fornecedor para cada transformação, por uma solução nativa do próprio SQL Server ou pela passagem através do barramento, de modo a permitir reaproveitamento.

O argumento quantitativo para a consolidação foi apresentado na própria sessão: ao comparar a planilha de necessidades do BI com as tabelas já utilizadas pelos sistemas corporativos, verificou-se sobreposição relevante, da ordem de sete tabelas em comum entre as dez necessárias. Manter integrações separadas para os mesmos dados significa multiplicar leituras sobre a fonte, ferramentas a operar e pontos de falha.

1.13.10.3. Limitação das views proprietárias

Uma restrição técnica importante foi confirmada na conversa: uma réplica simples do banco não garante o funcionamento das views. Como parte delas depende de bibliotecas do fornecedor instaladas no servidor e de serviços internos do produto, inclusive com leitura de informações em memória, reproduzi-las fora do ambiente original exigiria instalar componentes do ADMS na rede corporativa e deter conhecimento técnico do produto. A tentativa já havia sido considerada anteriormente pelas equipes e foi avaliada como pouco prática.

1.13.11. Continuidade, site switch e reapontamento

1.13.11.1. Lacuna identificada

Os agrupamentos possuem ambientes primário e secundário em data centers distintos, em arranjo cruzado: o data center de Minas Gerais abriga o secundário do G1, e o da Paraíba abriga os secundários do G2 e do G3. O ponto levantado é que o processo de replicação e integração analisado considera a origem primária e, aparentemente, não contempla o secundário.

Consequência da lacuna Em um site switch ou em uma contingência, o ADMS permanece operacional no ambiente secundário, mas os consumidores corporativos deixam de receber atualização e ficam com a última informação disponível. Foi citado como cenário possível um dia inteiro sem atualização, o que é incompatível com consumidores que hoje trabalham com defasagem de cinco a dez minutos. O ADMS estaria funcionando, e o painel do centro de operação não estaria atualizado, situação em que a falha é percebida como problema da visualização, e não como consequência do chaveamento.

1.13.11.2. Ferramenta de site switch e documentação

O mecanismo de chaveamento entre ambientes é uma ferramenta construída pelo próprio fornecedor, que reaponta a aplicação de um lado para o outro. As equipes de banco não possuem o detalhamento de seu funcionamento. Existe documentação em PDF, já compartilhada com a consultoria, considerada insuficiente para esclarecer os pontos necessários. O encaminhamento acordado foi acumular as dúvidas e tratá-las em reunião específica com o fornecedor.

1.13.11.3. Alternativa de reapontamento por F5

Foi retomada a hipótese, já discutida em sessão anterior com as equipes de F5 e de API Gateway, de utilizar verificações de integridade no balanceador para reapontar a origem ou o endpoint de integração durante o failover. A alternativa precisa ser desenhada em conjunto com rede, telecom, segurança, plataforma de eventos, administração de banco e fornecedor, porque envolve tipo de endpoint, autenticação, estado do conector e consistência da captura. Foi registrado na sessão que a convergência entre as duas conversas ajuda a fechar o quadro.

1.13.11.4. Réplica relacional e mecanismos nativos

Foi explorada a alternativa de manter, na rede corporativa, uma réplica do banco do ADMS, o que atenderia os consumidores internos com baixa latência e simplificaria os painéis do centro de operação, mantendo a captura e o Lake apenas para o dado regulatório e externo. A avaliação registrada é que, se os dados estivessem na rede corporativa, boa parte dos problemas atuais dos painéis deixaria de existir.

Log shipping	Já é utilizado como ferramenta de recuperação de desastre, levando bancos da rede corporativa para a Paraíba. Replica o banco inteiro, e não tabelas selecionadas, e depende de job e de liberações de firewall entre as redes.
Alta disponibilidade nativa	Foi esclarecido na sessão que se trata de mecanismo de alta disponibilidade, e não de replicação seletiva de dados.
Replicação assíncrona entre redes	Levantada como possibilidade, permitindo sincronização por canal de menor capacidade. Depende de análise de segurança e das restrições entre as redes operacional e corporativa.
Limitação transversal	Qualquer réplica esbarra na dependência das bibliotecas do fornecedor para o funcionamento das views, conforme o item 1.13.10.3.

O volume envolvido também foi dimensionado de forma preliminar: das mais de mil tabelas existentes, a estimativa citada é de algumas dezenas efetivamente utilizadas pelos consumidores, o que reforça a inadequação de replicar bancos inteiros e sugere a necessidade de um recorte por necessidade real.

1.13.12. Governança, gestão de mudanças e dependência do fornecedor

1.13.12.1. Processo existente

A Energisa possui processo formal de gestão de mudanças, com reunião semanal específica realizada às terças-feiras. As atualizações de ambiente são teoricamente condicionadas à autorização da Energisa: a gestão do projeto autoriza o fornecedor a atualizar o ambiente no horário determinado, e o time de sustentação é comunicado.

1.13.12.2. Lacunas identificadas

• A gestão de mudanças informa que haverá atualização, mas frequentemente não distingue com clareza se é um patch do produto do fornecedor, uma atualização de banco de dados ou uma mudança interna.
• Não foi identificado documento contendo a lista de objetos alterados, os impactos, as dependências, o plano de retorno e os testes requeridos. Foi afirmado de forma direta que esse documento não existe.
• As equipes de banco relatam não receber antecipadamente o detalhamento das mudanças em tabelas, views, colunas e aplicação, mesmo após solicitações reiteradas à gestão do projeto.
• O fornecedor mantém acesso direto e constante ao banco e à aplicação, e realiza a atualização como um pacote fechado, sem detalhar o que foi corrigido no caminho.
• O volume do portfólio e a quantidade de solicitações de mudança tornam o acompanhamento inviável para uma equipe de três administradores de banco: um deles pode estar ciente de uma atualização e os outros dois não.
• Não foi identificado sistema de gestão de configuração na rede de tecnologia operacional, o que impede conhecer previamente os itens afetados e os impactos de cada mudança.

Foi registrado ainda um elemento de contexto que agrava o quadro: a plataforma opera na rede de tecnologia operacional, sem acesso à internet, e a atualização é feita por transferência de pacotes para uma máquina específica. A sustentação do ambiente, tanto de TI quanto operacional, é da Energisa, enquanto a administração da aplicação e do banco pelo fornecedor ocorre por acesso direto. Essa combinação concentra a responsabilidade operacional de um lado e o controle da mudança do outro.

1.13.12.3. Encaminhamento com o fornecedor

O encaminhamento acordado foi acumular todas as dúvidas técnicas e conduzir uma reunião única e objetiva com o fornecedor, dado que as agendas com essa equipe são difíceis de marcar. A abordagem seria iniciar com a representação no Brasil e, conforme a natureza das questões, acionar as áreas de engenharia e de arquitetura do fabricante. Os temas a levar incluem o mecanismo de site switch, as bibliotecas que sustentam as views, a política de divulgação de alterações de esquema entre versões e a existência de compromisso de compatibilidade ou de política de descontinuação de objetos.

1.13.13. Alternativas e hipóteses técnicas discutidas

As alternativas abaixo surgiram como hipóteses ou direções de investigação. Nenhuma deve ser tratada como decisão de implementação sem validação de compatibilidade, segurança, licenciamento, desempenho e operação.

Particionar tópicos e ampliar o paralelismo	Atraso nas tabelas de alto volume.	Maior vazão e isolamento por partição.	Chave de particionamento, ordenação, tarefas, distribuição desigual e capacidade dos componentes.
Separar conectores e workloads por criticidade	Carga analítica degradando a operação.	Acordo de nível de serviço independente para operação e para dados.	Custo, número de conectores, gestão de deslocamentos e suporte.
Capturar e governar eventos de definição de dados	Mudança de esquema não detectada.	Acionar análise e recriação antes da produção.	Capacidade real de captura em cada banco, tratamento de views e integração com a gestão de mudanças.
Registro de esquemas com compatibilidade evolutiva	Consumidores quebram com a evolução do contrato.	Versionamento e regras explícitas de compatibilidade.	Formato de serialização, governança de contratos e comportamento na remoção de campos.
Persistir payload flexível em formato JSON	Esquema da view é volátil.	Evitar a parada imediata do transporte diante de mudança estrutural.	Qualidade, tipagem, consulta, governança e transferência de complexidade ao consumidor.
Automatizar a recriação da materialização	Upgrade exige intervenção manual extensa.	Reduzir o tempo de recuperação.	Detecção confiável da mudança, preservação de dados, recriação da captura e testes.
Acordo formal de mudanças com o fornecedor	Falta de visibilidade prévia.	Análise de impacto e preparação antes do upgrade.	Contrato, notas de versão, lista de objetos, prazo de antecedência e ambiente de homologação.
Reapontamento por F5	A integração não acompanha o site switch.	Failover mais transparente para os consumidores.	Verificação de integridade, endpoint, estado do conector, segurança entre redes e risco de dupla origem.
Réplica relacional na rede corporativa	Consumidores internos dependem da cadeia completa.	Baixa latência local e simplificação dos painéis.	Dependência de bibliotecas, replicação de banco inteiro, segregação de redes e recorte dos dados necessários.
Racionalizar ou substituir a ferramenta de extração legada	Múltiplas ferramentas e integrações customizadas.	Padrão único, reuso de dados e menor número de leituras na fonte.	Requisitos de transformação, eventos e alertas, latência, compatibilidade e migração.

1.13.13.1. Detalhamento da hipótese de payload flexível

A alternativa que recebeu maior detalhamento na sessão parte de uma inversão: em lugar de manter uma tabela materializada com esquema fixo, que quebra quando o fornecedor altera a view, o processo capturaria todos os campos presentes na view e os gravaria em uma estrutura de documento, sem esquema predefinido. Se o fornecedor incluir, remover ou alterar um campo, o transporte não é interrompido: o conteúdo continua sendo publicado e o tratamento da evolução passa a ser responsabilidade do consumidor, que aplica regras de retrocompatibilidade e versionamento de contrato.

As ressalvas foram registradas na própria discussão. Não estava claro como implementar essa abordagem no ambiente atual, e foi apontada a ausência de um mecanismo de armazenamento adequado na rede de tecnologia operacional. A alternativa também transfere complexidade para o consumidor e exige governança de qualidade e tipagem. Ainda assim, ela endereça diretamente a fragilidade estrutural descrita no item 1.13.5.4 e merece avaliação formal.

Foi mencionado, como elemento complementar, que a captura no Oracle contempla tanto eventos de manipulação quanto de definição de dados, o que abriria caminho para detectar a alteração estrutural no momento em que ela ocorre. A existência desse recurso e seu comportamento em cada banco precisam ser verificados.

1.13.14. Riscos consolidados

Atualização do fornecedor quebra a materialização e a captura em produção	Alta	Alto	Crítico	Avaliação de impacto por versão, testes automatizados, procedimento de resposta e acordo de mudanças
Atraso compromete processos operacionais de tempo quase real	Alta	Alto	Crítico	Isolar workloads, medir vazão por etapa e revisar particionamento e conectores
Falha de site deixa consumidores corporativos sem dados	Média	Alto	Alto	Arquitetura de failover ponta a ponta e teste de recuperação incluindo as integrações
Procedimento customizado sem responsável formal	Alta	Alto	Alto	Definir equipe proprietária, objetivo de nível de serviço, monitoração e ciclo de vida
Mudança de esquema causa perda silenciosa de dados	Média	Alto	Alto	Validação de contratos, reconciliação e alerta de desvio de esquema
Consumidores não identificados ou sem acordo de nível de serviço	Alta	Médio	Alto	Catálogo de dados, linhagem e matriz de consumidor, finalidade e prazo
Comando de definição de dados interrompe a captura	Média	Médio	Médio	Levantar comandos e versões, e submeter alterações a procedimento controlado
Duplicidade de leitura sobre a base do ADMS	Média	Médio	Médio	Racionalizar integrações e publicar produtos de dados reutilizáveis
Dependência de componentes proprietários para as views	Alta	Médio	Médio	Documentar limites, envolver o fornecedor e evitar replicações inviáveis

1.13.15. Decisões, consensos e encaminhamentos

1. As dores relatadas pelas equipes de banco devem constar formalmente do documento de achados do assessment.

2. A solução de materialização das views precisa ser revista e deve passar a ter equipe formalmente responsável por sua sustentação e evolução.

3. A expressão tempo real deve ser substituída por requisitos e acordos de nível de serviço mensuráveis por processo e por consumidor.

4. As duas tabelas de maior volume e suas configurações no barramento devem ser analisadas em detalhe, com envio dos nomes e dos esquemas à consultoria.

5. As dúvidas sobre upgrades, views, bibliotecas e site switch devem ser acumuladas para uma reunião única e objetiva com o fornecedor.

6. Serão produzidos desenhos da situação atual e múltiplas opções de arquitetura-alvo, incluindo alternativas para failover e para consolidação das integrações.

7. O desenho da arquitetura do XStream, elaborado à época da prova de conceito, será disponibilizado no repositório compartilhado do assessment.

8. Será realizada reunião com a equipe de dados e de Databricks para confirmar formato da camada de entrada, camadas, consumo e prazos.

9. A agenda com rede e telecom contribuirá para validar conectividade, F5, regras de firewall e restrições entre as redes operacional, DMZ e corporativa.

10. A sessão com o especialista do WFM será agendada após seu retorno de férias.

11. A consultoria seguirá consolidando e refinando o diagnóstico e retornará às equipes para validar achados específicos.

1.13.16. Plano de ação recomendado

P0	Documentar as duas tabelas de maior volume, tópicos, partições, conectores, volumetria e atraso por etapa	Kafka, administração de banco e arquitetura	Ficha técnica e painel de atraso e vazão
P0	Criar matriz de consumidores, finalidade, criticidade e prazo de atualização	Dados e BI, negócio e arquitetura	Catálogo de consumidor, tabela, tópico e acordo de nível de serviço
P0	Formalizar a propriedade do procedimento de materialização	Gestão de arquitetura	Matriz de responsabilidades, repositório, objetivo de serviço e procedimento de resposta
P0	Consolidar as questões para a reunião com o fornecedor	Coordenação, consultoria e administração de banco	Questionário técnico único e agenda com especialistas
P0	Mapear o failover ponta a ponta e testar o impacto nos conectores e consumidores	Arquitetura, redes, Kafka e fornecedor	Diagrama de contingência, objetivos de recuperação e roteiro de teste
P1	Revisar particionamento, paralelismo e isolamento das tabelas de alto volume	Kafka e integração	Proposta técnica com medição antes e depois
P1	Implantar detecção de desvio de esquema e validação de contratos	Arquitetura de dados e administração de banco	Alertas, pipeline de validação e política de compatibilidade
P1	Revisar a materialização para automação da recriação e reconciliação	Administração de banco e engenharia	Prova de conceito controlada e procedimento de retorno
P1	Atualizar os diagramas da situação atual dos fluxos legados e consumidores	Arquitetura	Diagramas validados pelas equipes
P1	Construir alternativas de arquitetura-alvo comparáveis	Consultoria e arquitetura da Energisa	Opções com custo, risco, prazo, dependências e recomendação
P2	Avaliar a racionalização ou substituição da ferramenta de extração legada	Arquitetura e sistemas consumidores	Análise de viabilidade e plano de migração
P2	Definir a estratégia para o dado interno em relação ao Lake e ao uso regulatório	Arquitetura de dados, segurança e negócio	Princípios de distribuição e arquitetura-alvo

1.13.17. Questões em aberto e evidências necessárias

1.13.17.1. Para a equipe de Kafka e integração

• Quais são os nomes exatos das duas tabelas de maior volume e os tópicos correspondentes?
• Qual é a configuração de partições, chaves, tarefas, leitura, lote e filas do conector?
• O atraso se concentra na captura do banco, no conector, no broker, no consumidor ou em várias etapas?
• Como a ordenação é garantida hoje e qual granularidade de ordenação é efetivamente necessária?
• Quais comandos de definição de dados não são suportados e qual é a versão e a configuração do conector?

1.13.17.2. Para o fornecedor da plataforma

• Qual é o mecanismo técnico do site switch e quais endpoints mudam durante o chaveamento?
• Quais objetos e bibliotecas sustentam as views utilizadas pelas integrações?
• Como são divulgadas as alterações de esquema entre versões e patches?
• Existe compromisso de compatibilidade ou política de descontinuação de views, campos e tabelas?
• É possível fornecer notas técnicas de versão, comparação de esquema e testes de impacto antes da produção?
• Existe interface estável recomendada pelo fabricante para a extração desses dados?

1.13.17.3. Para dados, BI e Databricks

• Quais relatórios e consumidores realmente precisam de cinco, dez ou trinta minutos, e quais admitem processamento em lote?
• Qual formato é utilizado na camada de entrada e a partir de quando os dados passam a Delta?
• Como são tratadas evolução de esquema, reprocessamento, deduplicação, eventos atrasados e qualidade?
• Quais tabelas são compartilhadas entre BI e os sistemas corporativos consumidores?
• Quais dados precisam permanecer no Lake por razões regulatórias ou de compartilhamento externo?

1.13.17.4. Para redes, telecom e segurança

• Quais fluxos são permitidos entre as redes operacional, DMZ e corporativa, e em quais direções?
• O balanceador pode realizar verificação de integridade consistente e reapontar entre os ambientes primário e secundário?
• Quais portas, certificados, resolução de nomes e regras de firewall seriam necessárias?
• Como evitar leitura da origem incorreta ou reconexão com posições incompatíveis após o chaveamento?

1.13.18. Roteiro para as próximas sessões

Rede e telecom	Validar conectividade entre as redes, regras de firewall, papel do balanceador e restrições entre os ambientes operacional, DMZ e corporativo. Agendada para o dia seguinte a esta sessão.
Dados e Databricks	Confirmar a ingestão a partir do barramento, a camada de entrada, o uso do formato Delta e a arquitetura das camadas. Apresentar a linhagem completa do dado do ADMS até a visualização. Validar a latência observada e o prazo requerido por relatório. Identificar tabelas compartilhadas e oportunidades de produto de dados único. Revisar o tratamento de evolução de esquema, reprocessamento e reconciliação.
Fornecedor da plataforma	Reunião única e objetiva, iniciada com a representação no Brasil e ampliada às áreas de engenharia e arquitetura conforme a natureza das questões, tratando site switch, bibliotecas das views, política de mudanças e compatibilidade.
Especialista do WFM	Agendada após o retorno de férias, para completar a cobertura da força de trabalho e das integrações associadas.

1.13.19. Conclusão do assessment desta sessão

Esta sessão alcançou a camada mais profunda do assessment, aquela em que as integrações deixam de ser desenhos e passam a ser mecanismos concretos de captura, transporte e materialização de dados. O quadro obtido é consistente com o levantado nas sessões anteriores, mas acrescenta a explicação de origem para vários achados que até aqui apareciam apenas como sintomas.

Três conclusões se destacam. A primeira é que o atraso relatado no consumo dos eventos não decorre de capacidade insuficiente, e sim de ausência de separação por classe de serviço: uma carga analítica que tolera meia hora de defasagem está retendo, por leitura sequencial, uma carga operacional que não tolera. A segunda é que a materialização das views, criada sob pressão de prazo e mantida em três implantações sucessivas, é hoje um componente crítico sem responsável formal, exposto a mudanças de esquema que chegam sem aviso. A terceira é que a continuidade dos consumidores corporativos durante um chaveamento de site não está resolvida, o que significa que o ADMS pode operar em contingência enquanto a informação apresentada aos centros de operação permanece congelada.

Uma quarta observação atravessa as três anteriores: boa parte do risco não é técnica, e sim 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 componentes customizados transformam problemas previsíveis em incidentes de produção diagnosticados na equipe errada. Nenhuma dessas questões se resolve apenas com arquitetura, e todas precisam ser tratadas antes que o volume das próximas implantações as amplifique.

Anexo A · Registro cronológico revisado da sessão

Registro cronológico revisado do conteúdo inteligível da sessão, com a marcação de tempo da gravação. Como a associação automática entre rótulos de falante e pessoas não se manteve estável ao longo do encontro, as falas são atribuídas por papel funcional. Saudações, repetições, sobreposições, problemas de compartilhamento de tela e trechos corrompidos pelo reconhecimento automático de voz foram condensados ou omitidos, e os termos técnicos capturados de forma imprecisa foram normalizados quando o contexto permitiu identificação segura.

00:01:53 Coordenação Energisa: Abre a sessão explicando que a revisão das integrações do ADMS foi solicitada desde a primeira implantação, em razão de um momento de contingência, e que a decisão foi realizar uma revisão de ponta a ponta com apoio de consultoria externa.

00:02:35 Coordenação Energisa: Apresenta os participantes das equipes de banco: um responsável que acompanhou desde o início a configuração da captura e do XStream no Oracle, e outro com conhecimento próximo dos bancos do ADMS, das configurações e dos procedimentos desenvolvidos especificamente para o projeto.

00:03:13 Coordenação Energisa: Explicita o formato esperado: além dos processos, as equipes devem apresentar suas dores e o que consideram importante registrar, já que se trata de uma revisão.

00:03:24 Coordenação Energisa: Informa que já foram realizadas reuniões com mais de dez equipes e que ainda faltam frentes para compor o quadro completo, entre elas o atendimento e a equipe que dará sustentação posterior ao ADMS.

00:04:14 Consultoria: Registra que o processo das equipes de banco é fundamental na cadeia de integração e reforça o convite para que apresentem os principais problemas na visão delas.

00:04:42 Coordenação Energisa: Delimita o escopo da sessão: equipes de administração de banco e responsáveis pela captura de dados alterados, tanto em Oracle quanto em SQL Server, esclarecendo que o ADMS utiliza SQL Server e os demais sistemas corporativos utilizam Oracle.

00:05:11 Consultoria: Descreve o entendimento prévio da arquitetura: a captura alimenta o Kafka, e entre os assinantes estão o Databricks e as próprias aplicações. Solicita o desenho da solução.

00:07:09 Consultoria: Detalha o entendimento do caminho: o XStream se conecta e disponibiliza o conteúdo, o conector faz a conexão com o banco e o Kafka consome, com um conector específico responsável por essa integração.

00:08:05 DBA Oracle: Explica o funcionamento do lado Oracle: o XStream cria uma fila dentro do banco, na qual ficam disponíveis as transações capturadas, e o conector se conecta ao banco e extrai esse conteúdo. Informa que foi ele quem configurou esse mecanismo.

00:08:41 DBA SQL Server: Explica que, do lado SQL Server, é utilizada a solução nativa de captura, habilitada somente nas tabelas necessárias e não no banco como um todo, com o mesmo padrão de consumo pelo conector e pelo Kafka.

00:09:07 Consultoria: Consolida o entendimento: solução nativa de captura no SQL Server e solução específica no Oracle, com o conector conectando-se aos dois produtos, enviando os eventos de mudança de estado ao Kafka, onde as aplicações interessadas assinam os tópicos e o Databricks grava no ambiente de dados.

00:10:08 Coordenação Energisa: Pergunta às equipes quais são as dores em relação a esse cenário.

00:10:16 DBA Oracle: Registra que a maior dor do lado Oracle está relacionada ao conector e ao barramento, e não ao banco.

00:10:36 DBA Oracle: Descreve o cenário de duas tabelas cujo volume de mudanças é muito elevado e cuja captura o conector não consegue consumir na mesma velocidade em que o banco aplica as transações.

00:11:14 DBA Oracle: Exemplifica: uma mensagem gerada no banco naquele momento corresponde, no consumo, a conteúdo produzido dez ou vinte minutos antes, dependendo do horário do dia.

00:11:38 DBA Oracle: Apresenta a segunda dor: qualquer mudança nas tabelas mapeadas exige cuidado elevado, porque existem comandos que o conector não consegue interpretar.

00:12:08 DBA Oracle: Relata dois casos concretos: a inclusão de uma tabela cuja definição continha uma palavra não interpretada, que quebrou o fluxo, e a remoção de um log de view materializada relacionado a uma tabela mapeada, que também quebrou o fluxo.

00:12:43 DBA Oracle: Sintetiza que os problemas atuais estão mais relacionados ao barramento e ao conector: ou não consegue consumir na velocidade necessária, ou não consegue interpretar os comandos executados no banco.

00:13:20 Consultoria: Caracteriza o quadro como gargalo com acúmulo e questiona a diferença de tempo observada.

00:13:43 DBA Oracle: Esclarece que o efeito não ocorre o dia inteiro e que se concentra aproximadamente entre 10h e 11h30, sem que se saiba qual processo de negócio se intensifica nesse intervalo.

00:14:06 DBA Oracle: Registra que o efeito também não ocorre em todos os bancos, concentrando-se nos de maior volume transacional, e que nesse período o fluxo não consegue manter o tempo quase real.

00:14:36 DBA SQL Server: Informa que o isolamento das tabelas responsáveis foi feito pela equipe de Kafka, que conseguiu metrificar a contribuição de cada uma.

00:14:43 DBA Oracle: Confirma que são duas tabelas de volume muito grande, que atendem o ambiente de dados e cujo consumo toleraria atraso de até cerca de trinta minutos, sem necessidade de tempo real.

00:15:08 DBA Oracle: Aponta o ponto central: como essas tabelas compartilham a infraestrutura com a operação, que depende de tempo quase real, o efeito se propaga.

00:15:21 DBA Oracle: Explica a causa técnica: a leitura é sequencial, o banco gera as mudanças sequencialmente por números de mudança do sistema, e o fluxo fica retido em uma tabela e não prossegue para as demais.

00:15:46 Consultoria: Solicita os nomes das tabelas para registro no documento e para análise da configuração no barramento e dos tópicos correspondentes.

00:15:58 Consultoria: Levanta a hipótese de que se trate de um problema de particionamento: com particionamento adequado, o consumo ocorre em paralelo, tipicamente com um processo por partição, enquanto sem ele o processamento é sequencial.

00:16:30 Consultoria: Ressalva que a chave de partição precisa ser escolhida de modo a garantir a ordenação necessária.

00:17:04 Consultoria: Explora a alternativa de leitura incremental, que dependeria de um campo capaz de identificar o que foi alterado.

00:17:14 DBA Oracle: Informa que as tabelas não possuem esse marcador temporal.

00:17:21 Consultoria: Solicita também o esquema dessas tabelas, para registro e análise.

00:18:16 DBA SQL Server: Registra que, do seu lado, não houve problemas de lentidão nem incidentes em produção relacionados a esse cenário.

00:18:22 DBA SQL Server: Apresenta sua principal preocupação: o fornecedor realiza atualizações do modelo de dados e altera estruturas.

00:19:00 DBA SQL Server: Explica a solução interna adotada: como a captura não funciona sobre views, apenas sobre tabelas, as views foram transformadas em tabelas.

00:19:20 DBA SQL Server: Registra que, quando o fornecedor muda a origem do dado, é necessário um trabalho extenso de recriação das tabelas e, na sequência, da captura, procedimento criado pela equipe de arquitetura.

00:19:52 DBA SQL Server: Sintetiza sua preocupação principal: a solução está acoplada a uma eventual mudança do fornecedor, que informa que vai atualizar o ambiente, mas não detalha o que será alterado.

00:20:08 DBA SQL Server: Informa que o cenário ocorreu apenas em homologação e manifesta a expectativa de que, em algum momento, ocorrerá também em produção.

00:21:07 DBA SQL Server: Esclarece a origem da solução: havia a necessidade de capturar views, o que não é suportado em nenhum dos dois bancos, e por isso foi adotada a transformação da view em tabela.

00:21:27 DBA SQL Server: Avalia que a solução funciona muito bem, mas que a preocupação permanece: uma mudança de estrutura pelo fornecedor sempre gerará impacto e será tratada como problema da equipe de banco, quando o correto seria criar a captura e apenas monitorá-la.

00:22:06 Consultoria: Pergunta se as views são produzidas pelo próprio ADMS.

00:22:12 DBA SQL Server: Confirma que são views da própria arquitetura do produto do fornecedor.

00:22:21 Consultoria: Caracteriza a solução como materialização dessas views.

00:22:32 DBA SQL Server: Detalha o funcionamento: um job do SQL Server executa a cada cinco minutos, identifica todas as mudanças ocorridas, faz a mesclagem com a transformação em tabela, atualiza o que mudou e insere o que não existe, utilizando uma chave.

00:23:05 DBA SQL Server: Esclarece que se trata de um procedimento criado pela equipe de arquitetura da Energisa, acionado por job, e não de recurso nativo.

00:23:33 DBA SQL Server: Explica a finalidade: permitir que o conteúdo da view seja capturado e chegue ao ambiente de dados, para o usuário final.

00:23:44 Consultoria: Pergunta qual é o objetivo do dado e se outros sistemas o consomem.

00:24:01 DBA SQL Server: Informa que, da perspectiva da equipe de banco, o destino é sempre o Data Lake, e que não sabe precisar quem consome o dado na ponta, além do uso regulatório conhecido. O papel da equipe é entregar o dado.

00:24:43 Consultoria: Consolida o entendimento do fluxo completo: o procedimento roda, identifica o que foi alterado, materializa, grava na tabela correta, a captura processa e envia ao Lake.

00:25:09 DBA SQL Server: Confirma e delimita: esse caminho não é tempo real. Somente as tabelas com captura habilitada diretamente entregam a atualização no momento em que ela ocorre.

00:26:04 Consultoria: Pergunta se o intervalo de cinco minutos atende a um requisito de negócio ou se foi definido arbitrariamente.

00:26:23 DBA SQL Server: Responde que foi definido tecnicamente: as validações mostraram que o job executava em trinta ou quarenta segundos, e cinco minutos foi considerado tempo aceitável e suficiente para concluir e reexecutar.

00:26:58 DBA SQL Server: Complementa que, em casos que demoravam cerca de seis minutos, o intervalo foi ampliado para dez minutos, com validação caso a caso conforme o volume das tabelas, e reforça que não houve definição de negócio para esse cenário, embora o resultado atenda bem.

00:27:48 Consultoria: Reconstrói o quadro completo: o ADMS possui suas tabelas e disponibiliza views para consumo, parte dessas views precisa ser enviada, e para isso existe um processo customizado de materialização que roda em intervalo definido pela duração da execução, variando de cinco a dez minutos, cujo resultado alimenta a captura e segue o fluxo normal.

00:29:02 Consultoria: Identifica o ponto crítico: quando há alteração sobre essas views, a estrutura se quebra e é necessário intervir.

00:29:19 DBA SQL Server: Confirma e registra que, em uma eventual atualização do fornecedor, será necessário recriar todo o cenário de views, transformar novamente em tabela, remover e criar de novo, porque a solução não prevê essa mudança de estrutura.

00:30:37 DBA SQL Server: Relata que o fornecedor não avisa a equipe de banco: durante uma atualização pode inserir campo novo, alterar ou remover, sem detalhar, e que isso deveria estar previsto em contrato.

00:31:10 DBA SQL Server: Registra que nunca recebeu documentação indicando quais tabelas ou colunas seriam alteradas, e que o cenário ocorreu em homologação com atualização de versão. Em produção ainda não ocorreu, mas quando ocorrer será tratado como problema de banco de dados, embora a causa seja a atualização.

00:31:47 Coordenação Energisa: Avalia que o tema merece uma conversa específica com a equipe do fornecedor.

00:32:14 DBA SQL Server: Delimita o escopo do risco: a captura de uma tabela habilitada diretamente é resiliente à inclusão de coluna, porque o mecanismo entende a nova estrutura. O problema é específico da view transformada em tabela.

00:32:43 Consultoria: Introduz a analogia de interface: a view funciona como uma interface de acesso à base e, em teoria, o fornecedor deveria manter uma estratégia de evolução com retrocompatibilidade, ainda que não seja um contrato formal, dado que atende diversos clientes.

00:34:03 Consultoria: Apresenta a alternativa de armazenar o conteúdo em estrutura sem esquema predefinido, adequada a estruturas voláteis, transferindo o tratamento da evolução para o consumidor.

00:35:39 Consultoria: Pergunta se o volume de transações gerado por essas estruturas é elevado.

00:35:57 DBA SQL Server: Informa que no SQL Server o volume de alterações é muito pequeno, sobretudo o originado dessas views.

00:36:27 DBA SQL Server: Confirma que o volume no lado Oracle é muito maior.

00:36:39 Consultoria: Solicita a volumetria da quantidade de tabelas materializadas.

00:36:57 DBA SQL Server: Informa não ter o número exato de memória e indica a coordenação como detentora do levantamento.

00:37:12 Coordenação Energisa: Passa a relatar o histórico do projeto de relatórios: começou por volta de 2024, com especificação conduzida pela equipe de BI junto ao desenvolvimento, processo que em determinado momento se perdeu.

00:37:34 Coordenação Energisa: Registra que as planilhas enviadas indicavam praticamente tudo como necessário em tempo real e todas as fontes como tabelas, e que o levantamento ficou a cargo da própria equipe de BI.

00:38:04 Coordenação Energisa: Relata que, próximo à implantação, ao conversar com a equipe do fornecedor, identificou-se a existência de views que não são simples objetos do banco: elas utilizam um recurso que gera bibliotecas executadas dentro dos processos dos serviços internos do produto.

00:38:47 Coordenação Energisa: Complementa que algumas dessas funções buscam informações em memória, por exemplo quando envolvem o SCADA, o que elimina a alternativa de capturar as tabelas de origem e reconstruir a visão externamente.

00:39:19 Coordenação Energisa: Registra a segunda restrição identificada: algumas tabelas utilizam truncamento do lado do fornecedor, e a habilitação da captura sobre elas provocaria erro na aplicação do ADMS, o que levou à adoção da mesma alternativa.

00:40:15 Coordenação Energisa: Relata o episódio da implantação: no mês nove de 2025 seria realizada a implantação e, do lado da equipe de BI, cerca de 59 relatórios eram anunciados como quase prontos. No dia, os relatórios não estavam prontos.

00:40:35 Coordenação Energisa: Descreve a solução emergencial: adaptar os relatórios já existentes na unidade em implantação para não comprometer o cronograma, que tinha compromisso com o fornecedor e impacto financeiro relevante caso fosse postergado.

00:41:30 Coordenação Energisa: Registra que foi nesse contexto que o procedimento de captura e repasse foi desenvolvido às pressas, e que a gestão do projeto acionou uma empresa que já havia passado por integrações semelhantes.

00:41:51 Coordenação Energisa: Relata que essa empresa havia tido um ano de preparação para resolver o mesmo problema, mas apresentou uma solução de código fechado a ser inserida no meio do processo de integração, com valor considerado exorbitante, e a contratação não avançou.

00:42:46 Coordenação Energisa: Registra que a solução atual permaneceu e precisa ser revista, e que já havia levado à gestão do projeto a necessidade de uma equipe formalmente responsável pelo procedimento, uma vez que foi a arquitetura quem o desenvolveu.

00:43:05 DBA SQL Server: Manifesta concordância expressa: é fundamental existir equipe responsável pela administração desse componente.

00:43:24 Coordenação Energisa: Relata que o mesmo trabalho emergencial precisou ser repetido nas implantações seguintes, porque os relatórios continuavam não entregues.

00:43:58 Coordenação Energisa: Descreve o desdobramento: após um trabalho conjunto com outra empresa para entender por que a entrega não avançava, a direção de TI transferiu a frente de relatórios para a arquitetura em conjunto com DevOps, incorporando seis pessoas da equipe de BI e contando com um engenheiro de dados.

00:45:00 Consultoria: Pergunta se os relatórios são feitos em Power BI.

00:45:08 Coordenação Energisa: Confirma o uso do Power BI na ponta, relata a existência anterior de um data warehouse em instalações próprias e informa que a visão atual é centralizar no Data Lake, com Databricks, permitindo reuso além dos relatórios.

00:46:28 Consultoria: Estabelece a distinção conceitual entre tempo real e consolidação: no primeiro caso há consumo de um fluxo contínuo que sustenta indicadores imediatos, e no segundo há um relatório consolidado de periodicidade maior. Descreve o padrão que combina os dois, com ação imediata de um lado e análise confiável do outro.

00:48:04 Coordenação Energisa: Registra que, se houvesse necessidade efetiva de tempo real, a alternativa avaliada seria outra ferramenta de visualização capaz de ler diretamente do barramento, mas que a centralização no Data Lake prevaleceu por permitir reuso dos dados para outras finalidades.

00:48:35 Coordenação Energisa: Conclui que a necessidade de tempo real não existia como se supunha e que uma defasagem de cinco a dez minutos seria aceitável.

00:49:02 Consultoria: Propõe estabelecer definições formais de classes de atualização, distinguindo tempo real, micro-batch e processamento em lote, conforme a janela de cada processo e a definição da empresa.

00:50:17 Coordenação Energisa: Apresenta o contexto operacional que eleva a expectativa: nos centros de operação o operador trabalha com cerca de seis monitores e um painel de parede, no qual parte dos relatórios é exibida.

00:50:51 Coordenação Energisa: Descreve a mudança percebida: com a nova plataforma, o despacho de uma ordem de serviço aparece praticamente de imediato, enquanto antes a solução era cliente-servidor com processos em lote.

00:51:13 Coordenação Energisa: Detalha que antes o intervalo variava de três a sete minutos e que, nos horários de maior movimento, o operador tinha a percepção de que o sistema estava lento ou travado.

00:51:55 Coordenação Energisa: Registra que, uma vez experimentado o novo comportamento, não se aceita retroceder, e que a tendência é a necessidade aumentar com o tempo, embora para consultas e para a maioria dos relatórios essa necessidade não exista.

00:52:35 Consultoria: Estabelece o critério: tempo real é um requisito. Se existe requisito, deve ser atendido. Se não existe, o ideal é não implementar, porque consome mais recursos, aumenta a complexidade e não se paga se não alterar o resultado do negócio.

00:53:30 Consultoria: Complementa que o processamento imediato faz sentido quando habilita automação ou decisão que não pode aguardar, e não quando o resultado será consumido horas depois por uma pessoa.

00:56:54 Consultoria: Detalha a alternativa de payload flexível: gravar o resultado da view em estrutura de documento sem esquema predefinido, capturando todos os campos existentes, de modo que uma alteração feita pelo fornecedor não interrompa o transporte.

00:57:30 Consultoria: Explica que, nessa abordagem, o consumidor passa a resolver a evolução do contrato, aplicando regras de retrocompatibilidade e versionamento, e que o produtor deixa de quebrar.

00:58:07 Coordenação Energisa: Observa que o uso de um registro de esquemas seria uma forma de implementar esse tratamento.

00:58:49 Coordenação Energisa: Registra a ressalva prática: não há clareza sobre como implementar essa gravação no SQL Server do ambiente e não existe mecanismo de armazenamento adequado na rede de tecnologia operacional.

00:59:24 Coordenação Energisa: Aponta a segunda linha de mitigação: estabelecer acordo com o fornecedor para comunicação prévia de qualquer mudança estrutural.

00:59:43 Consultoria: Argumenta que qualquer alteração deveria passar por ambiente controlado antes da produção, o que já ofereceria oportunidade de análise.

01:00:05 Consultoria: Sugere identificar e gerar eventos de definição de dados, de modo a anunciar a alteração no ambiente de homologação e permitir preparar o procedimento antes de replicá-lo em produção.

01:00:38 Coordenação Energisa: Pergunta às equipes de banco se existe hoje algum processo automático de detecção de mudança de definição de uma view.

01:00:47 DBA SQL Server: Responde que não existe.

01:01:05 Consultoria: Registra que a captura no Oracle contempla tanto eventos de manipulação quanto de definição de dados, recurso que precisaria ser verificado.

01:01:33 DBA SQL Server: Reforça que a preocupação central é a forma como o fornecedor atualiza o ambiente: atualiza a homologação sem avisar a equipe de banco, mesmo após solicitações reiteradas à gestão do projeto.

01:02:17 Consultoria: Confirma que a plataforma opera na rede de tecnologia operacional, sem acesso à internet.

01:02:30 Coordenação Energisa: Descreve o mecanismo de atualização, por transferência de pacotes para uma máquina específica, e registra desconhecer como o fornecedor comunica essas atualizações.

01:02:44 Coordenação Energisa: Avalia que a mudança deveria ser previamente comunicada, com a relação do que será alterado, para permitir análise prévia.

01:02:53 DBA SQL Server: Afirma que nunca recebeu esse detalhamento, apesar de tê-lo solicitado, e que a atualização chega como um pacote fechado, sem informação sobre o que foi corrigido no caminho, citando um incidente ocorrido na última atualização de produção.

01:03:41 Consultoria: Pergunta quem construiu e quem sustenta o procedimento que executa no banco.

01:03:56 DBA SQL Server: Responde que foi o time interno, de arquitetura, e confirma que a sustentação é da própria Energisa.

01:04:36 Consultoria: Pergunta quem sustenta os servidores e bancos da rede operacional.

01:05:09 DBA SQL Server: Confirma que a sustentação é da Energisa, tanto na rede corporativa quanto na operacional, e que o fornecedor possui acesso ao ambiente.

01:05:42 DBA SQL Server: Esclarece o fluxo teórico: o fornecedor não altera o ambiente sem permissão, a autorização parte da gestão do projeto e a janela é determinada pela Energisa. Registra, porém, que o fornecedor tem acesso direto ao banco e à aplicação e permanece constantemente conectado.

01:06:20 DBA SQL Server: Relata que, mesmo respondendo pelo banco, por vezes não é avisado previamente, e que o aviso chega ao time de sustentação.

01:06:43 DBA SQL Server: Delimita a lacuna com precisão: existe alinhamento prévio sobre a atualização, mas não existe documento indicando o que será alterado.

01:07:25 Consultoria: Pergunta se existe sistema de gestão de configuração que permita conhecer os itens atualizados e os impactos.

01:07:51 Coordenação Energisa: Avalia que na rede operacional esse sistema não existe.

01:08:04 Consultoria: Pergunta sobre o processo de gestão de mudanças e a notificação das áreas afetadas.

01:08:48 Coordenação Energisa: Confirma a existência de equipe e de processo de gestão de mudanças, com reunião específica semanal realizada às terças-feiras.

01:09:12 DBA SQL Server: Qualifica a limitação: o portfólio é muito grande e o volume de solicitações é elevado, de modo que o controle se torna inviável para uma equipe de três administradores de banco. Um pode estar ciente de uma atualização e os outros dois não.

01:10:34 DBA SQL Server: Complementa que o fluxo existe, mas não deixa claro o que será efetivamente modificado, nem se a atualização é do fornecedor ou interna.

01:11:14 DBA SQL Server: Registra que o ambiente está estável há um bom tempo e que, em produção, ainda não ocorreu o cenário de captura e views atualizadas. Apenas em homologação.

01:11:42 Coordenação Energisa: Avalia que isso ocorreu porque a captura específica ainda não estava implantada no momento das atualizações anteriores, e que houve patches de correção de lacunas do projeto.

01:12:39 DBA SQL Server: Propõe rever com o fornecedor a forma como as atualizações são realizadas e deixar alinhado o impacto de uma eventual alteração de views.

01:13:00 Coordenação Energisa: Registra que o que está sob captura direta é tratado automaticamente, inclusive com versionamento por registro de esquemas, e levanta a hipótese de o próprio procedimento gerar um evento específico e tomar a ação de refazer a estrutura e reenviar, ponderando o efeito sobre quem consome.

01:13:47 DBA SQL Server: Relata que o fornecedor já removeu campos que estavam sendo utilizados em relatórios e que já foram observadas tabelas que deixaram de existir, concluindo que não se trata de atualização simples.

01:14:58 DBA SQL Server: Indica as duas tabelas de maior estrutura e volume envolvidas no cenário relatado, cujos nomes constam do Anexo B para confirmação.

01:15:24 Coordenação Energisa: Compartilha o desenho elaborado à época da prova de conceito do XStream, que descreve o funcionamento do mecanismo.

01:15:48 Coordenação Energisa: Descreve o desenho: o mecanismo observa os redo logs, existe fila dentro do próprio Oracle, um serviço de saída se comunica com o cliente, que é o conector, e o Debezium atua como plugin dessa solução, produzindo no tópico específico daquela tabela.

01:16:49 Coordenação Energisa: Esclarece que a configuração do serviço de saída e das filas dentro do Oracle é feita pela equipe de administração de banco.

01:17:10 DBA SQL Server: Complementa que o XStream utiliza o mecanismo de captura do GoldenGate, empregando apenas a função de extração de dados, e não a de replicação.

01:18:06 Consultoria: Solicita o envio do desenho ao repositório compartilhado do assessment.

01:18:20 Coordenação Energisa: Informa que será agendada reunião com a equipe de dados para esclarecer as dúvidas remanescentes.

01:18:43 Consultoria: Pergunta qual formato é utilizado quando o dado chega ao Databricks.

01:18:59 Coordenação Energisa: Informa que o formato Delta é utilizado nas camadas de refinamento e que, na camada de entrada, acredita que não, ponto a confirmar com a equipe de dados.

01:19:19 Coordenação Energisa: Apresenta o segundo tema: existe uma solução interna que buscava dados dos sistemas de SCADA, principalmente dos sistemas OMS anteriores, para alimentar aplicações que consomem eventos e alertas.

01:19:53 Coordenação Energisa: Identifica a ferramenta utilizada, fornecida por terceiro, que funciona como mecanismo de extração e carga, capturando essas informações e gravando em uma base.

01:20:03 Coordenação Energisa: Descreve o caminho: a base ficava na DMZ e replicava para o lado corporativo. Na rede operacional e na DMZ existia um sistema de visualização e análise dos dados de SCADA, e do lado corporativo dois sistemas corporativos também necessitam dessas informações.

01:20:44 Coordenação Energisa: Registra a oportunidade: reaproveitar essa ferramenta para evitar que mais de um mecanismo faça leitura da mesma base do ADMS.

01:21:21 Coordenação Energisa: Relata que questionou os responsáveis sobre a real necessidade de tempo real nesse fluxo e que a resposta foi afirmativa, para manter uma solução única.

01:22:11 Coordenação Energisa: Apresenta o desenho da situação atual e da proposta, mostrando a rede operacional, a captura em cada base de SCADA e o que já foi implantado.

01:23:07 Coordenação Energisa: Explica a estrutura por agrupamentos: existem três agrupamentos no ADMS, com o G1 no data center da Paraíba e o G2 e o G3 no de Minas Gerais.

01:23:19 DBA SQL Server: Corrige o desenho, informando que o banco em questão já foi transferido para a rede corporativa.

01:24:16 Coordenação Energisa: Detalha que já existia um banco por empresa, utilizado pelos sistemas corporativos, e que foi reaproveitado o banco da primeira empresa migrada de cada agrupamento.

01:25:13 Coordenação Energisa: Apresenta a proposta de consolidação: se já existe esse processo e também o que passa pelo barramento, e se parte das tabelas será usada igualmente pelos relatórios, a necessidade é conjunta e deveria ser atendida pela mesma ferramenta.

01:25:29 Coordenação Energisa: Relata ter consultado o fornecedor da ferramenta de extração sobre suas capacidades e ter concluído que, por depender de implementações em Java para cada transformação, é preferível avaliar sua substituição por uma solução nativa do próprio SQL Server ou pela passagem através do barramento, de modo a permitir reuso.

01:28:09 Coordenação Energisa: Apresenta o argumento quantitativo: ao comparar a planilha de necessidades do BI com as tabelas já utilizadas, verificou-se sobreposição da ordem de sete tabelas em comum entre as dez necessárias.

01:28:32 Coordenação Energisa: Descreve a normalização proposta: criar bancos nomeados por agrupamento, em lugar de reutilizar o banco de uma empresa específica, mantendo na rede corporativa uma réplica dos dados necessários de cada tabela para as soluções internas.

01:29:56 DBA SQL Server: Observa que essa abordagem atenderia também os painéis do centro de operação.

01:30:05 DBA SQL Server: Argumenta que, com os dados do ADMS disponíveis na rede corporativa, o atendimento seria muito mais rápido e não haveria necessidade de recorrer à cadeia completa para o consumo interno.

01:31:36 Coordenação Energisa: Pondera que o Data Lake permanece necessário como local centralizado, inclusive para finalidades além dos relatórios.

01:32:00 DBA SQL Server: Concorda e delimita: para o atendimento regulatório o dado precisa estar no Lake, porque é lá que ele é disponibilizado, mantendo-se a captura e o XStream. Para o dado interno crítico, a réplica na rede corporativa resolveria.

01:33:26 Consultoria: Levanta os mecanismos nativos de replicação e alta disponibilidade do banco como possibilidades.

01:33:40 DBA SQL Server: Esclarece que o mecanismo citado é de alta disponibilidade e não de replicação seletiva de dados.

01:34:01 DBA SQL Server: Registra dúvida sobre a viabilidade dessa comunicação entre as redes, dada a segregação existente.

01:34:35 Consultoria: Argumenta que existem modos síncrono e assíncrono, e que o modo assíncrono permitiria sincronização por canal de menor capacidade.

01:36:06 Consultoria: Menciona o mecanismo de envio de logs como alternativa.

01:36:17 DBA SQL Server: Confirma que esse mecanismo já é utilizado como ferramenta de recuperação de desastre, levando os bancos da rede corporativa para a Paraíba, e que poderia ser configurado, dependendo das liberações de firewall.

01:37:04 Coordenação Energisa: Pergunta se a replicação abrangeria o banco inteiro ou permitiria selecionar tabelas.

01:37:16 DBA SQL Server: Confirma que o mecanismo replica o banco inteiro, e não tabelas selecionadas.

01:37:25 Coordenação Energisa: Dimensiona o problema: das mais de mil tabelas existentes, a estimativa é de algumas dezenas efetivamente utilizadas.

01:37:44 Coordenação Energisa: Retoma a limitação decisiva: a réplica dependeria da infraestrutura de serviços do produto para que as views funcionassem, tentativa que já havia sido considerada anteriormente.

01:38:07 Coordenação Energisa: Conclui que seria necessário instalar componentes do ADMS na rede corporativa para que as views funcionassem, o que não faz sentido.

01:38:58 DBA SQL Server: Confirma que o mecanismo de envio de logs replica o conteúdo das tabelas do jeito que estiver, mas que as views dependem das bibliotecas do fornecedor instaladas no servidor.

01:39:51 DBA SQL Server: Reconhece a restrição: as bibliotecas do fornecedor seriam necessárias do outro lado para que as views funcionassem.

01:40:30 Coordenação Energisa: Apresenta o último ponto do desenho: os ambientes secundários. O data center de Minas Gerais abriga o secundário do G1, e o da Paraíba abriga os secundários do G2 e do G3.

01:40:55 Coordenação Energisa: Identifica a lacuna: o processo implantado não considera esses ambientes, de modo que, em um chaveamento, seria necessário replicar os dados do secundário para o banco corporativo, o que não ocorre.

01:41:14 Coordenação Energisa: Dimensiona o impacto: os consumidores ficariam com a última atualização disponível, podendo passar um dia sem a informação.

01:41:33 Coordenação Energisa: Conclui que a solução a ser desenhada precisa contemplar esse cenário de forma única, válida para todos os consumidores.

01:41:45 Coordenação Energisa: Registra que uma das alternativas consideradas é utilizar o balanceador para realizar o reapontamento, retomando a conversa mantida anteriormente com aquela equipe, e observa que os temas começam a convergir.

01:42:16 Coordenação Energisa: Informa que está elaborando desenhos da situação atual e alternativas de arquitetura-alvo, para posterior avaliação de viabilidade e de necessidade.

01:42:32 Coordenação Energisa: Diferencia o impacto por consumidor: algumas soluções aceitariam um ou dois dias sem consumo, mas a solução de relatórios, ainda que não seja de tempo real, precisa do dado disponível dentro de cinco a dez minutos.

01:42:56 Coordenação Energisa: Descreve o cenário concreto: durante uma manutenção ou problema com chaveamento, o ADMS estará funcionando, mas o sistema de visualização não estará apresentando a informação.

01:43:45 Coordenação Energisa: Observa que as necessidades vêm aumentando e que, com a abertura do mercado de energia, cresce a demanda por informação próxima do tempo real, o que exige escolher uma alternativa única em lugar de manter duas soluções.

01:44:38 DBA SQL Server: Esclarece que o mecanismo de envio de logs é utilizado apenas na rede corporativa e não se aplica ao ADMS.

01:44:58 DBA SQL Server: Informa que a ferramenta que realiza o chaveamento entre os ambientes foi construída pelo próprio fornecedor e aponta a aplicação de um lado para o outro, sem que a equipe tenha o detalhamento de seu funcionamento.

01:45:20 Coordenação Energisa: Registra que existe documentação em PDF, já compartilhada com a consultoria, porém pouco detalhada, e propõe acumular todas as dúvidas para uma reunião única com o fornecedor, dado que essas agendas são difíceis de marcar.

01:46:27 Coordenação Energisa: Apresenta a agenda seguinte: sessão de rede e telecom no dia seguinte e sessão com a equipe de dados na sexta-feira à tarde.

01:46:57 Coordenação Energisa: Registra que a sessão com o especialista sênior do WFM será agendada após seu retorno de férias.

01:47:31 Coordenação Energisa: Detalha a estratégia de contato com o fornecedor: iniciar com a representação no Brasil e, conforme a natureza das questões, acionar as áreas de engenharia e arquitetura.

01:47:55 Consultoria: Informa que o trabalho está na fase de consolidação e refinamento do diagnóstico e que a consultoria retornará às equipes para validar e confirmar achados específicos.

Anexo B · Termos normalizados e itens que exigem confirmação

A transcrição automática capturou de forma imprecisa nomes de produtos, componentes, tabelas e sistemas. Nesta ata, os elementos foram descritos preferencialmente por sua função. Os itens abaixo devem ser confirmados antes de constarem em desenho de arquitetura ou em documento formal.

XStream	Mecanismo de captura do Oracle que observa redo logs e disponibiliza as transações em fila interna, com serviço de saída.	Foi informado que utiliza a captura do GoldenGate, apenas a função de extração.
Debezium e Kafka Connect	Conector que lê os eventos capturados e publica nos tópicos.	Versão e configuração devem ser levantadas para o diagnóstico de interpretação de comandos.
Captura nativa do SQL Server	Recurso do produto habilitado tabela a tabela.	Não opera sobre views, o que motivou a materialização.
Log de view materializada	Objeto do Oracle cuja remoção quebrou o fluxo de captura.	O comando exato e o registro do erro devem ser obtidos.
Tabelas de maior volume	Duas tabelas do lado Oracle responsáveis pela maior parte do volume capturado.	Os nomes citados na sessão remetem a instalação e a despacho, e precisam ser confirmados junto com os esquemas.
Ferramenta de extração legada	Solução de terceiro utilizada como mecanismo de extração e carga para os dados de SCADA e dos sistemas OMS anteriores.	Nome do produto e do fornecedor a confirmar.
Sistema de visualização de alarmes	Solução que realizava a análise dos dados de SCADA na rede operacional e na DMZ.	Nome a confirmar.
Sistemas corporativos consumidores	Dois sistemas corporativos que consomem eventos e alertas originados do SCADA.	Nomes capturados de forma imprecisa, a confirmar.
Agrupamentos G1, G2 e G3	Agrupamentos de empresas no ADMS, com o G1 no data center da Paraíba e o G2 e o G3 no de Minas Gerais.	Consistente com o registrado em atas anteriores.
Ferramenta de site switch	Mecanismo do fornecedor que reaponta a aplicação entre os ambientes primário e secundário.	Documentação em PDF considerada insuficiente.
Mecanismo de envio de logs	Recurso do SQL Server utilizado como ferramenta de recuperação de desastre na rede corporativa.	Replica bancos inteiros, e não tabelas selecionadas.
Especialista do WFM	Profissional sênior indicado como necessário em sessão posterior.	A data de retorno de férias citada na gravação está inconsistente com o calendário da sessão e deve ser confirmada.

Além dos termos, os seguintes dados quantitativos foram registrados como informados e devem ser confirmados por inventário:

• O atraso de 10 a 20 minutos, chegando a cerca de 30 minutos em picos, e a janela aproximada entre 10h e 11h30.
• Os intervalos de 5 e de 10 minutos dos jobs de materialização e a duração média de execução de cada um.
• A quantidade de views materializadas atualmente em operação.
• Os cerca de 59 relatórios previstos para a implantação de setembro de 2025.
• A sobreposição de aproximadamente sete tabelas em comum entre as dez necessárias ao BI.
• A ordem de mil tabelas existentes no banco e a estimativa de algumas dezenas efetivamente utilizadas.
• O número de administradores de banco envolvidos no acompanhamento das mudanças.

1.13.20. Observações finais

Esta ata foi consolidada a partir de dois documentos referentes à mesma sessão: o documento técnico produzido sobre a reunião e a transcrição integral da gravação. Os temas foram unificados por assunto, preservando integralmente o conteúdo das duas fontes, incluindo os pontos em que a transcrição traz detalhe adicional, entre eles o histórico completo da implantação dos relatórios, a natureza das bibliotecas que sustentam as views, o dimensionamento das tabelas efetivamente utilizadas, a proposta de normalização dos bancos por agrupamento e a convergência com a discussão anterior sobre reapontamento por balanceador.

A atribuição nominal das falas não foi aplicada no registro cronológico porque a associação automática entre rótulos e pessoas não se manteve estável. Os participantes estão identificados no item 1.13.2, com base nas apresentações feitas na abertura. As classificações de severidade, as prioridades do plano de ação e as estimativas têm caráter indicativo e serão refinadas com as evidências solicitadas às equipes e com as sessões complementares já acordadas.