Desde 1999, para atender o back office, nosso banco utiliza o sistema bancário integrado BISKVIT na plataforma Progress OpenEdge, amplamente utilizada em todo o mundo, inclusive no setor financeiro. O desempenho deste SGBD permite ler até um milhão ou mais registros por segundo em um banco de dados (BD). Nosso Progress OpenEdge atende cerca de 1,5 milhão de depósitos individuais e cerca de 22,2 milhões de contratos de produtos ativos (empréstimos e hipotecas de automóveis), e também é responsável por todas as liquidações com o regulador (Banco Central) e SWIFT.
Utilizando o Progress OpenEdge, nos deparamos com a necessidade de fazê-lo funcionar com o Oracle DBMS. Inicialmente, esse pacote era o gargalo de nossa infraestrutura - até instalarmos e configurarmos o Pro2 CDC - um produto Progress que permite enviar dados do SGBD Progress para o SGBD Oracle diretamente, online. Neste post contaremos detalhadamente, com todas as armadilhas, como fazer amizade efetivamente entre OpenEdge e Oracle.
Como aconteceu: upload de dados para QCD via compartilhamento de arquivos
Primeiro, alguns fatos sobre nossa infraestrutura. O número de usuários ativos do banco de dados é de aproximadamente 15 mil. O volume de todos os bancos de dados produtivos, incluindo réplica e standby, é de 600 TB, o maior banco de dados tem 16,5 TB. Ao mesmo tempo, as bases de dados são constantemente reabastecidas: só no último ano, foram adicionados cerca de 120 TB de dados produtivos. O sistema é alimentado por 150 servidores frontais na plataforma x86. Os bancos de dados estão hospedados em 21 servidores da plataforma IBM.
Sistemas front-end, vários sistemas bancários principais e serviços bancários são integrados ao OpenEdge Progress (BISCUIT IBS) por meio do barramento Sonic ESB. O upload de dados para o QCD ocorre por meio da troca de arquivos. Até certo momento, tal solução apresentava dois grandes problemas ao mesmo tempo - baixo desempenho de upload de informações para um data warehouse corporativo (CDW) e muito tempo para realizar reconciliação de dados (reconciliação) com outros sistemas.
Por isso, começamos a buscar uma ferramenta que pudesse agilizar esses processos. A solução para ambos os problemas foi o novo produto Progress OpenEdge – Pro2 CDC (Change Data Capture). Então, vamos começar.
Instale Progress OpenEdge e Pro2Oracle
Para executar o Pro2 Oracle no computador Windows do administrador, basta instalar o Progress OpenEdge Developer Kit Classroom Edition, que pode ser de graça. Diretórios de instalação padrão do OpenEdge:
DLC: C:ProgressOpenEdge
WRK: C:OpenEdgeWRK
Os processos ETL requerem licenças Progress OpenEdge versão 11.7+ - nomeadamente OE DataServer para Oracle e 4GL Development System. Essas licenças estão incluídas no Pro2. Para operação completa do DataServer for Oracle com um banco de dados Oracle remoto, o Full Oracle Client é instalado.
No servidor Oracle você precisa instalar o Oracle Database 12+, criar um banco de dados vazio e adicionar um usuário (vamos chamá-lo CDC).
Para instalar o Pro2Oracle, baixe a distribuição mais recente no centro de download. Descompacte o arquivo em um diretório C:Pro2 (Para configurar o Pro2 no Unix, a mesma distribuição é usada e os mesmos princípios de configuração se aplicam).
Criando um banco de dados de replicação CDC
Banco de dados de replicação cdc (reposição) Pro2 é usado para armazenar informações de configuração, incluindo o mapa de replicação, nomes de bancos de dados replicados e suas tabelas. Ele também contém uma fila de replicação, que consiste em notas sobre o fato de uma linha da tabela no banco de dados de origem ter sido alterada. Os dados da fila de replicação são usados por processos ETL para identificar linhas que precisam ser copiadas para o Oracle a partir do banco de dados de origem.
Estamos criando um banco de dados CDC separado.
Procedimento para criar um banco de dados
- No servidor de banco de dados criamos um diretório para o banco de dados cdc - por exemplo, no servidor /banco de dados/cdc/.
- Crie um manequim para o banco de dados cdc: procopiar $DLC/cdc vazio
- Habilite o suporte para arquivos grandes: proutil cdc -C EnableLargeFiles
- Preparamos um script para iniciar o banco de dados cdc. Os parâmetros iniciais devem ser semelhantes aos parâmetros iniciais do banco de dados replicado.
- Iniciamos o banco de dados cdc.
- Conecte-se ao banco de dados cdc e carregue o esquema Pro2 do arquivo cdc.df, que está incluído no Pro2.
- Criamos os seguintes usuários no banco de dados cdc:
pro2adm – para conexão a partir do painel administrativo do Pro2;
pro2etl – para conectar processos ETL (ReplBatch);
pro2cdc – para conectar processos CDC (CDCBatch);
Ativando o OpenEdge Change Data Capture
Agora vamos ativar o próprio mecanismo CDC, com a ajuda do qual os dados serão replicados para uma área tecnológica adicional. Para cada banco de dados de origem Progress OpenEdge, você precisa adicionar áreas de armazenamento separadas nas quais os dados de origem serão duplicados e ativar o próprio mecanismo usando o comando proutil.
Procedimento de exemplo para o banco de dados bisquit
- Copiando do catálogo C:Pro2db arquivo cdcadd.st para o diretório do banco de dados de origem bisquit.
- Nós descrevemos em cdcadd.st extensões de tamanho fixo para regiões "ReplCDCArea" и "ReplCDCArea_IDX". Você pode adicionar novas áreas de armazenamento online: prostrct addonline bisquit cdcadd.st
- Ative o OpenEdge CDC:
proutil bisquit -C enablecdc área "ReplCDCArea" indexarea "ReplCDCArea_IDX" - Os seguintes usuários devem ser criados no banco de dados de origem para identificar os processos em execução:
a. pro2adm – para conexão a partir do painel administrativo do Pro2.
b. pro2etl – para conectar processos ETL (ReplBatch).
c. pro2cdc – para conectar processos CDC (CDCBatch).
Criando um suporte de esquema para DataServer for Oracle
Em seguida, precisamos criar um banco de dados Schema Holder no servidor onde os dados do Progress DBMS serão replicados para o Oracle DBMS. DataServer Schema Holder é um banco de dados Progress OpenEdge vazio, sem usuários ou dados de aplicação, contendo um mapa de correspondência entre tabelas de origem e tabelas externas do Oracle.
O banco de dados Schema Holder para Progress OpenEdge DataServer for Oracle for Pro2 deve estar localizado no servidor de processos ETL; ele é criado separadamente para cada filial.
Como criar um suporte de esquema
- Descompacte a distribuição Pro2 em um diretório /pro2
- Crie e vá para o diretório /pro2/dbsh
- Crie um banco de dados Schema Holder usando o comando copiar $DLC/bisquitsh vazio
- Realizando a conversão biscoito na codificação necessária - por exemplo, em UTF-8 se os bancos de dados Oracle tiverem codificação UTF-8: proutil bisquitsh -C convchar converte UTF-8
- Depois de criar um banco de dados vazio biscoito conecte-se a ele no modo de usuário único: pró biscoito
- Vamos ao Dicionário de Dados: Ferramentas -> Dicionário de Dados -> DataServer -> Utilitários ORACLE -> Criar Esquema DataServer
- Suporte de esquema de lançamento
- Configurando o broker Oracle DataServer:
a. Inicie o AdminServer.
proadsv -start
b. Início do corretor Oracle DataServer
oraman -nome orabroker1 -start
Configurando o painel administrativo e o esquema de replicação
Através do painel administrativo do Pro2 são configurados os parâmetros do Pro2, incluindo configuração do esquema de replicação e geração de processos ETL (Processor Library), programas de sincronização primária (Bulk-Copy Processor), triggers de replicação e políticas OpenEdge CDC. Existem também ferramentas primárias para monitorar e gerenciar processos de ETL e CDC. Primeiro de tudo, configuramos os arquivos de parâmetros.
Como configurar arquivos de parâmetros
- Vá para o catálogo C:Pro2bpreplScripts
- Abra o arquivo para edição replProc.pf
- Adicione parâmetros de conexão ao banco de dados de replicação CDC:
# Banco de dados de replicação
-db cdc -ld repl -H <nome do host do banco de dados principal> -S <porta do corretor do banco de dados cdc>
-U pro2admin -P <senha> - adicionar à replProc.pf parâmetros de conexão com bancos de dados de origem e Schema Holder na forma de arquivos de parâmetros. O nome do arquivo de parâmetros deve corresponder ao nome do banco de dados de origem que está sendo conectado.
# Conecte-se a todas as fontes replicadas BISQUIT
-pf bpreplscriptsbisquit.pf - adicionar à replProc.pf parâmetros para conexão ao Schema Holder.
#Target Pro Suporte de esquema DB
-db biscoito -ld biscoito
-H <nome do host do processo ETL>
-S <porta do corretor biskuitsh>
-db bisquitsql
-ld bisquitsql
-dt ORÁCULO
-S 5162 -H <nome de host do corretor Oracle>
-DataService orabroker1 - Salve o arquivo de parâmetros replProc.pf
- Em seguida, você precisa criar e abrir arquivos de parâmetros para edição para cada banco de dados de origem conectado no diretório C:Pro2bpreplScripts: bisquit.pf. Cada arquivo pf contém parâmetros para conexão com o banco de dados correspondente, por exemplo:
-db bisquit -ld bisquit -H <nome do host> -S <porta do corretor>
-U pro2admin -P <senha>
Para configurar os atalhos do Windows, você precisa ir ao diretório C:Pro2bpreplScripts e edite o atalho “Pro2 – Administração”. Para fazer isso, abra as propriedades do atalho e na linha Começar indique o diretório de instalação do Pro2. Operação semelhante deve ser feita para os atalhos “Pro2 – Editor” e “RunBulkLoader”.
Configuração de administração Pro2: carregando a configuração inicial
Vamos iniciar o console.
Vá para “Mapa do banco de dados”.
Para vincular bancos de dados no Pro2 – Administração, acesse a aba Mapa do banco de dados. Adicionar mapeamento de bancos de dados de origem - Titular do Esquema - Oracle.
Ir para a aba Mapeamento. Listado Banco de dados de origem Por padrão, o primeiro banco de dados de origem conectado é selecionado. À direita da lista deve haver uma inscrição Todos os bancos de dados conectados — os bancos de dados selecionados estão conectados. Abaixo, à esquerda, você verá uma lista de tabelas de progresso do bisquit. À direita está uma lista de tabelas do banco de dados Oracle.
Criando esquemas SQL e bancos de dados no Oracle
Para criar um mapa de replicação, você deve primeiro gerar Esquema SQL no Oráculo. Na Administração Pro2 executamos o item de menu Ferramentas -> Gerar Código -> Esquema de Destino, então na caixa de diálogo Selecione Banco de Dados selecione um ou mais bancos de dados de origem e mova-os para a direita.
Clique em OK e selecione o diretório para salvar os esquemas SQL.
Em seguida criamos a base. Isto pode ser feito, por exemplo, através de Desenvolvedor Oracle SQL. Para fazer isso, nos conectamos ao banco de dados Oracle e carregamos o esquema para adição de tabelas. Após alterar a composição das tabelas Oracle, é necessário atualizar os esquemas SQL no Schema Holder.
Após a conclusão do download com sucesso, saia do banco de dados bisquitsh e abra o painel administrativo do Pro2. As tabelas do banco de dados Oracle devem aparecer na guia Mapeamento à direita.
Mapeamento de tabela
Para criar um mapa de replicação, no painel administrativo do Pro2, acesse a aba Mapeamento e selecione o banco de dados de origem. Clique em Mapear Tabelas, selecione Selecionar Alterações à esquerda das tabelas que devem ser replicadas no Oracle, mova-as para a direita e confirme a seleção. Um mapa será criado automaticamente para as tabelas selecionadas. Repetimos a operação para criar um mapa de replicação para outros bancos de dados de origem.
Gerando biblioteca de processador de replicação Pro2 e programas de processador de cópia em massa
A Biblioteca do Processador de Replicação foi projetada para processos de replicação personalizados (ETLs) que processam a fila de replicação Pro2 e enviam alterações para o banco de dados Oracle. Os programas da biblioteca do processador de replicação são salvos automaticamente no diretório após a geração bprepl/repl_proc (parâmetro PROC_DIRECTORY). Para gerar a biblioteca do processador de replicação, vá para Ferramentas -> Gerar Código -> Biblioteca do Processador. Após a conclusão da geração, os programas aparecerão no diretório bprepl/repl_proc.
Os programas Bulk Load Processor são usados para sincronizar bancos de dados Progress de origem com o banco de dados Oracle de destino baseado na linguagem de programação Progress ABL (4GL). Para gerá-los, acesse o item de menu Ferramentas -> Gerar Código -> Processador de Cópia em Massa. Na caixa de diálogo Selecionar banco de dados, selecione os bancos de dados de origem, mova-os para o lado direito da janela e clique em OK. Após a conclusão da geração, os programas aparecerão no diretório bpreplrepl_mproc.
Configurando processos de replicação no Pro2
A divisão de tabelas em conjuntos servidos por um thread de replicação separado melhora o desempenho e a eficiência do Pro2 Oracle. Por padrão, todas as conexões criadas no mapa de replicação para novas tabelas de replicação estão associadas ao thread número 1. É recomendado separar as tabelas em threads diferentes.
As informações sobre o status dos threads de replicação são exibidas na tela Administração do Pro2 na guia Monitor na seção Status da replicação. Uma descrição detalhada dos valores dos parâmetros pode ser encontrada na documentação do Pro2 (diretório C:Pro2Docs).
Criar e ativar políticas CDC
As políticas são um conjunto de regras para o mecanismo OpenEdge CDC monitorar alterações nas tabelas. No momento em que este artigo foi escrito, o Pro2 suporta apenas políticas do CDC com nível 0, ou seja, apenas os fatos são monitorados registrar alterações.
Para criar uma política de CDC, no painel administrativo, acesse a aba Mapeamento, selecione o banco de dados de origem e clique no botão Adicionar/Remover Políticas. Na janela Selecionar alterações que é aberta, selecione no lado esquerdo e mova para a direita as tabelas para as quais você precisa criar ou excluir uma política de CDC.
Para ativar, abra novamente a aba Mapeamento, selecione o banco de dados de origem e clique no botão (In)Ativar Políticas. Selecione e mova para o lado direito da tabela as políticas que precisam ser ativadas, clique em OK. Depois disso eles são marcados em verde. Usando (In)Ativar Políticas Você também pode desativar as políticas do CDC. Todas as transações são realizadas online.
Após a ativação da política do CDC, as notas sobre os registros modificados são salvas na área de armazenamento "ReplCDCArea" de acordo com o banco de dados de origem. Estas notas serão processadas através de um processo especial CDCBatch, que com base neles criará notas na fila de replicação Pro2 no banco de dados cdc (reposição).
Assim, temos duas filas para replicação. O primeiro estágio é o CDCBatch: do banco de dados de origem, os dados vão primeiro para o banco de dados CDC intermediário. A segunda etapa é quando os dados são transferidos do banco de dados CDC para o Oracle. Esta é uma característica da arquitetura atual e do próprio produto - até agora os desenvolvedores não conseguiram estabelecer a replicação direta.
Sincronização primária
Após habilitar o mecanismo CDC e configurar o servidor de replicação Pro2, precisamos iniciar a sincronização inicial. Comando de sincronização inicial:
/pro2/bprepl/Script/replLoad.sh bisquit nome da tabela
Depois que a sincronização inicial for concluída, os processos de replicação poderão ser iniciados.
Início dos processos de replicação
Para iniciar processos de replicação você precisa executar um script replbatch.sh. Antes de começar, certifique-se de que existam scripts replbatch para todos os threads - replbatch1, replbatch2, etc. Se tudo estiver no lugar, abra a linha de comando (por exemplo, proenv), vá para o diretório /bprepl/scripts e inicie o script. No painel administrativo verificamos se o processo correspondente recebeu o status RUNNING.
Descobertas
Após a implementação, aceleramos bastante o upload de informações para o data warehouse corporativo. Os dados entram automaticamente no Oracle online. Não há necessidade de perder tempo executando consultas demoradas para coletar dados de diferentes sistemas. Além disso, nesta solução o processo de replicação pode comprimir dados, o que também tem um efeito positivo na velocidade. Agora, a reconciliação diária do sistema BISKVIT com outros sistemas começou a levar de 15 a 20 minutos em vez de 2 a 2,5 horas, e uma reconciliação completa levou várias horas em vez de dois dias.
Fonte: habr.com