Estudo de caso de uma migração de Oracle para PostgreSQL em ambiente de alta disponibilidade.Durante o projeto foram avaliadas diversas formas de realizar a migração, devido a complexidade e volumetria do ambiente, a ferramenta escolhida foi o Ora2Pg, esta palestra tem como objetivo demonstrar como realizar uma migração não só de um banco de dados, mas de toda uma cultura que se forma dentro de uma organização
Palestra apresentada no PGBR 2015 em Porto Alegre - RS
http://pgbr.postgresql.org.br/2015/
Demonstração no youtube: https://youtu.be/-DF5FT__OKw
CASE: O PostgreSQL em BI: Milhares de operações diárias consolidadas em "near...
Migração de Oracle para PostgreSQL - Indo além do SGBD
1. Migração de Oracle para
PostgreSQL - Indo além do
SGBD
Este trabalho está licenciado com uma Licença
Creative Commons - Atribuição-NãoComercial 4.0 Internacional.
2. Cenário
● Sistema Jurídico Web – (Aproximadamente
100 mil clientes)
● Base de dados - Oracle 11g RAC 2 nós
(Aproximadamente 1 TB de dados)
● Sistema auxiliares e satélites já utilizando
PostgreSQL
(Necessidade de comunicação entre bases
– Realizado via aplicação - php)
3. Principais Motivos
● Custo de licenciamento
● Integração entre sistemas internos
ineficiente (Bases distintas)
● Gargalos de performance (Modelagem)
4. Desafios da Migração
● Janela para execução mínima
Projeto – Abril – Dez 2014
Migração – Janela de Final de Dezembro < 48H
● Reescrita de SQL (Nenhum framework, SQL direto
no código fonte - PHP e ASP)
● Comportamento da aplicação e demais
integrações deveriam ser transparentes
● Alguns sistemas não tinham mais o código fonte
(.NET)
● Problemas graves de modelagem
5. Ambiente
● DBA não participava do desenho e construção
● Aplicações sem documentação e controle e
versão
● Modelagem desenvolvida no decorrer da
codificação pelo próprio desenvolvedor
● Receio de utilizar soluções implementadas no
banco de dados
● Retrabalho
6. Ferramenta escolhida
ora2pg – Ferramenta livre que simplifica o
processo de migração, desenvolvido desde
2001 por Gilles Darold.
http://ora2pg.darold.net/
7. Motivos da escolha:
● Quantidade de schemas (owner) e tabelas
para migrar
● Desempenho (Multiprocessamento)
● Migração de diversos objetos de forma
transparente (Views, Procedures,
Functions, Packages, Sequences, Triggers
entre outros)
● Possibilidade de realizar ajustes durante a
migração (Alteração de nomes de campos,
tipos de dados, reordenar posicionamento
entre outros)
8. Problemas na migração
● Tipos Number sem definição de tamanho
(Numeric/Bigint/Integer)
● Tabelas sem PK mas com UK
● Tabelas sem PK, UK e/ou relacionamento,
mas que tinham um campo “Codigo” como
sendo o primeiro (Esquecimento do
Dev/DBA ?)
● Dados duplicados (Tabela Cidade: Cod 1 =
Viamão e POA)
9. Estratégia – Projeto
● Extração de estrutura do Oracle e
importação no PostgreSQL (Mapeamento
de erros encontrados – PL_Ajusta)
● Liberação do banco de teste para a equipe
realizar as mudanças no SQL (Início de
uma mudança na cultura da empresa,
orientação para escrita correta de SQL,GIT,
Redmine)
● Testes de cargas e métricas de tempo e
CPU (Até então via output do ora2pg)
10. Novos problemas
● Migração via arquivo de saída do ora2gp
ficou inviável
● Tempo de ajuste dos dados após a
migração (Vacuum, Analyze, criação de
índice)
● Janela comprometida, alto risco caso o
processo falhasse em algum ponto
11. Estratégia de guerra
● Migração direta para o PostgreSQL através
do ora2pg
● Criação de um conjunto scripts que
monitorava a migração
● Cada schema importado com sucesso
dispara os seus respectivos ajustes
(Criação de índice, constraints etc)
● Redução de janela de tempo e possibilidade
de agir em caso de falha.
12. Resumo da Migração
● 1 TB de dados (600 GB somente do
sistema jurídico)
● 2186 tabelas
● 23 schemas (owners)
● 54 funções (PL/pgSQL)
● 41 triggers
● 13 horas e 48 minutos !
13. Cenário após migração!
● PostgreSQL atende todos os sistemas,
ambiente atual conta com replicação nativa
e pgBouncer como pool de conexões
● Nenhum problema de performance
● Integrações com outros sistemas via FDW
● Utilização de novas funções como o uso de
JSON para realização de auditoria e
pesquisa em formulários dinâmicos
14. Indo além do SGBD?
● Menor distância entre DBA e DEV
● Perda do “medo” do banco
● Novas funcionalidades não precisam de
novas licenças
● “Isso você resolve fora do banco” por “Isso
você pode resolver no banco”
● “Dá pra fazer isso no Postgres?!”