Menu de navegação

[gioracleParticipante]

Olá pessoALL !

Estamos aqui na empresa montando uma POC com Oracle CDC e Kafka para replicação de dados. Para isso, precisaremos ter uma retenção de 24 horas, archive log habilitado e alguns privilégios de Flashback Query.

A pergunta é: Alguém conhece algum material que mostre o quanto uma estratégia pode impactar na performance do banco de dados ?

Atualmente utilizamos a versão 19c com Oracle Linux.

Obrigado de antemão !

[José Laurindo ChiappaModerador]

Blz ? Então, primeiro existem DOIS tipos de CDC (trigger-based E redo log based) : pelo que vc diz, apesar de não ter explicitado, Suponho aqui que estamos falando de CDC REDO LOG BASED… E outro ponto, antes de te responder : já DESDE a versão 11g (cfrme https://docs.oracle.com/cd/E11882_01/server.112/e25554/cdc.htm#DWHSG016 já mostra) a Oracle vem Aposentando o CDC e recomendando adquirir , instalar e usar o GoldenGate no lugar dele, SUPONHO que se vc está indo atrás do CDC é porque existe algum impeditivo de usar o GG, que seria a melhor opção…
Muito bem : isso dito, a sua resposta é : o overhead causado pelo CDC redo log based é que vc TEM que ativar o log extendido, então o tamanho do redo log gerado VAI ser maior – porém, é impossível estabelecer um percentual genérico e geral para esse overhead, pois ele depende FUNDAMENTALMENTE do SEU ambiente, que é DIFERENTE do meu, e diferente do de qquer um… Por exemplo, QUAL é a frequência de geração de redo log archives no seu banco ? Vc ESTÁ com gargalos de I/O de modo geral nesse banco ou não ?? O teu REDO está tunado , ie, os seus REDO LOG FILES estão já no maior tamanho possível(dado espaço livre) E os parâmetros de frequência de log file switch (principalmente o archive_lag_target e talvez o fast_start_mttr_target) estão setados de uma forma que causam a menor frequência possível de archives e de log switches, para ALIVIAR o sistema de I/O, tendo em vista as suas necessidades de recuperação de dados ??
SE o seu REDO LOG FILE estiver bem tunado E de modo geral o seu ambiente não sofre de gargalo de I/O, eu ditia que o impacto de vc AUmentar o volume de redo setando redo extendido pra atender ao CDC vai ser pequeno, na ordem de 10% se tanto – isso como eu disse acima é uma ESTIMATIVA, só mesmo vc fazendo os teste EXATOS e REALISTAS no SEU ambiente específico é que vão te dar uma resposta mais firme…
E de resto, afora o impacto por overhead de I/O, TODOS os outros pontos que vc cita (como Retenção aumentada, por exemplo) não causam impacto na performance do banco : vão causar é MUITO mais consumo de espaço em disco, mas devem ser inócuos para a performance em si…

Abraços,

Chiappa

[gioracleParticipante]

@jlchiappa

Muito obrigado pelo retorno. Desculpe a demora em responder e agradecer, e também a falta de detalhes em meu questionamento.

Sim a idéia é uma estratégia redo log based. A escolha se deve ao fato de que utilizamos o kafka, e um dos conectores disponíveis para ele (CDC), avaliamos ser um dos mais adequados para nos ajudar em uma estatégia de replicação. Para ser mais exato, a idéia não é replicar todo o banco de dados, mas apenas algumas tabelas específicas em um DW.

Concordo que o GoldenGate seria o melhor dos mundos, mas não nos é uma alternativa viável no momento por uma série de motivos não técnicos.

Agradeço pelas informações e pelo seu tempo dedicado a resposta de meu post. Como sempre, impecável !

[José Laurindo ChiappaModerador]

Blz ? Então, já que são POUCAS as tabelas e (imagino) vc pode facilmente criar uma query que correlacione os dados dessas poucas, Não Deixe de analisar seriamente a possibilidade de criar uma VIEW MATERIALIZADA com refresh automático para ter esses dados no Oracle : esse objeto VIEW MATERIALIZADA vc pensa nele como uma ‘cópia’ dos dados contidos na query que vc indicar, e aí AUTOMAGICAMENTE cfrme as tabelas originais sofrem INSERT/UPDATE/DELETE os dados vão sendo copiados/removidos da VIEW MATERIALIZADA …. A vantagem desse cara é que a sua solução de transferência de dados ia fazer uma leitura simples da view materializada, e aí já teria os dados sempre atualizados – não faço a menor idéia se a sua solução aí (KAFKA) é compatível com views materializadas, mas veja lá… E logicamente, se o destino FINAL dos dados é um database gerido por um SGBD que vai apresentar os dados na forma de um DW, talvez exista a possibilidade de esse database DW ler diretamente os dados da vm, OU do Oracle simplesmente enviar os dados dessa VM pro destino numa forma qquer (arquivos, talvez) , veja aí também…

[José Laurindo ChiappaModerador]

De resto, se resultar que Necessariamente a melhor opção é mesmo implementar CDC redo log based, é só prestar atenção nos pontos que indiquei na minha resposta que deve dar bom : como eu disse, não conheço essa tool KAFKA mas o redo log no Oracle existe faz quase 30 anos, é algo já muito bem pensado/implementado, dificilmente vc vai ter issues com ele por si, não…

Abraços,

Chiappa

[Autor]

Posts