Artigo no estilo Mentoring
Com toda a interatividade dos dias de hoje, conceitos para bancos de dados como alta disponibilidade e escalabilidade são quase uma prerrogativa para sistemas críticos. Migrações, failover e qualquer manobra que altere uma fonte de dados desses sistemas deve ser feita com o mínimo de downtime, ou seja, essas mudanças devem ser imperceptíveis para o usuário.
Replicações de dados têm sido muito utilizadas nos últimos anos para esse e outros propósitos. Essas replicações são nada mais que envios de dados e/ou estruturas de dados alterados de um servidor para o outro. Hoje os principais fornecedores de SGBDs já possuem ferramentas próprias para uma replicação homogênea. O maior problema reside ainda nas replicações heterogêneas. Para isso é necessária uma ferramenta capaz de executar replicações de um banco para um SGBD de outro fornecedor, para um mesmo SGBD de versão diferente, para uma plataforma diferente ou sistema operacional diferente. Um uso muito comum é possibilitar uma migração ou atualização com um tempo de parada muito pequeno, pois não existe um procedimento de backup/restore que não exija a parada do banco para garantir a integridade e coesão de dados. No caso de uma replicação nesse sentido, existe apenas o tempo de parada da aplicação e o apontamento para o novo servidor.
Veja um exemplo clássico de migração de dados que causa bastante dor de cabeça: imagine que, visando um melhor atendimento ao cliente, uma empresa de varejo decida trocar seu sistema do SAC por outro que utiliza não só um SGDB diferente, mas também uma estrutura de dados diferente. Além de todo um trabalho de mapeamento dos tipos de dados e campos diferentes de um sistema para o outro, ainda existiria o problema do tempo de indisponibilidade do sistema que pode ser grande dependendo do tamanho da base de dados. Esse tempo de indisponibilidade pode representar um risco e até mesmo comprometer o ROI (retorno de investimento) planejado.
Neste artigo iremos abordar uma solução Oracle para situações como essas: o Oracle GoldenGate. Com o GoldenGate podemos extrair e replicar dados sobre uma variedade de topologias, bem como também trocar e manipular dados em nível transacional entre uma variedade de SGBDs.
Adicionalmente, ele oferece suporte para um número variado de requisitos de negócios como:
· Integração de dados e consolidação;
· Migrações e/ou atualizações;
· Escalabilidade e alta disponibilidade;
· Sistemas de suporte a decisões e data warehouse (ler BOX 1).
BOX 1. Data warehouse
Data warehouse são repositórios responsáveis por armazenar uma grande quantidade de dados que serão utilizados para geração de relatórios, análise de históricos e suporte à tomada de decisão.
Na Figura 1, os componentes que formam a arquitetura do Oracle GoldenGate são apresentados. Para realizar a extração dos dados, tem-se o processo Extract. Ele recupera as informações armazenadas nos redo logs do Oracle ou nos transactions logs do SQL Server (ler BOX 2) e os armazena em arquivos trail. Já o Data Pump é uma variação do processo de Extract, cuja finalidade é enviar os dados extraídos para o servidor de destino. Para receber os dados originados do Extract, o servidor de destino utiliza o processo Replicat ou Collector. O Manager é o processo responsável por controlar o funcionamento do GoldenGate e faz uso de checkpoints para identificar os dados que já foram efetivados no servidor de destino e, dessa forma, manter a integridade das informações.
Figura 1. Arquitetura da Replicação de Dados
BOX 2. Redo Logs e Transactions Logs
Ambos são uma estrutura física pertencente ao banco de dados e têm como principal função tornar possível refazer uma determinada transação em caso de falha. Para isso, eles mantêm informações sobre as transações submetidas ao banco e a imagem do banco anterior à efetivação da transação. Caso ocorra um problema no processo, o SGBD retorna o banco para seu estado anterior ao da execução da transação mantendo-o, dessa forma, íntegro.
Implementando o Oracle GoldenGate
Iremos agora migrar um sistema do SQL Server 2012 para o Oracle 12c, mas vamos incrementar um pouco ...