Migração Oracle PL/SQL para PostgreSQL: Conversão, Compatibilidade e Estratégia
Migração Oracle PL/SQL para PostgreSQL
Migração Oracle PL/SQL para PostgreSQL é o processo de analisar, converter, testar e validar código procedural desenvolvido para Oracle Database em uma arquitetura baseada em PostgreSQL ou EDB Postgres. O trabalho não consiste simplesmente em trocar comandos SQL, pois aplicações corporativas podem concentrar regras de negócio em procedures, functions, packages, triggers, cursores, exceções e rotinas PL/SQL fortemente dependentes do Oracle.
Em ambientes Oracle de longa duração, o PL/SQL frequentemente evolui junto com a aplicação e pode conter milhares de linhas de código distribuídas entre diferentes schemas. Por isso, antes da conversão é necessário identificar dependências, classificar o código e determinar quais componentes podem ser convertidos, adaptados, preservados por compatibilidade ou reescritos.
O PostgreSQL possui sua própria linguagem procedural, o PL/pgSQL, documentada oficialmente como uma linguagem procedural carregável utilizada para criar functions e procedures que podem executar operações de banco e lógica procedural. postgresql.org
Já o EDB Postgres Advanced Server oferece recursos de compatibilidade Oracle que podem reduzir o esforço de migração em determinados cenários. enterprisedb.com
Por que migrar PL/SQL exige uma análise específica
Uma migração de banco de dados pode transportar tabelas e dados, mas isso não significa que o código procedural continuará funcionando sem alterações.
Uma aplicação Oracle pode depender de:
- PL/SQL;
- packages;
- procedures;
- functions;
- triggers;
- cursors;
- exceptions;
- collections;
- record types;
- dynamic SQL;
- Oracle built-in packages;
- views de catálogo;
- sequences;
- database links;
- tipos de dados específicos;
- funções SQL específicas do Oracle.
Esses componentes precisam ser analisados antes que a organização defina o esforço, o prazo e a estratégia de migração.
Oracle PL/SQL versus PostgreSQL PL/pgSQL
O PostgreSQL utiliza principalmente PL/pgSQL para programação procedural dentro do banco. Embora PL/pgSQL e PL/SQL compartilhem conceitos importantes, eles não são linguagens idênticas.
Existem conceitos equivalentes, mas a sintaxe, o catálogo, o modelo de objetos, os tipos de dados e diversos recursos de execução apresentam diferenças.
Na prática, a conversão deve analisar:
- declarações;
- variáveis;
- parâmetros;
- blocos;
- condicionais;
- loops;
- cursores;
- tratamento de exceções;
- SQL embutido;
- dynamic SQL;
- retorno de resultados;
- transações;
- dependências entre objetos.
A documentação oficial do PostgreSQL apresenta PL/pgSQL como uma linguagem estruturada em blocos, com declarações, statements, SQL, estruturas de controle, cursores, tratamento de erros e recursos para executar comandos dinamicamente. postgresql.org
Assessment do código PL/SQL
O assessment é a primeira etapa de uma migração PL/SQL bem estruturada.
Inventário dos objetos
- packages;
- package bodies;
- procedures;
- functions;
- triggers;
- types;
- views;
- sequences;
- jobs;
- sinônimos;
- database links.
Inventário das dependências
Cada objeto deve ser relacionado aos demais objetos que utiliza.
Uma procedure pode depender de uma package, que utiliza functions, sequences e tabelas específicas. Sem esse mapa, a conversão pode produzir objetos aparentemente válidos, mas que não funcionam quando executados pela aplicação.
Classificação de complexidade
Uma metodologia prática pode classificar os objetos como:
- baixo esforço de conversão;
- médio esforço de conversão;
- alto esforço de conversão;
- dependência Oracle crítica;
- necessidade de reescrita;
- necessidade de redesign.
Conversão de Procedures Oracle para PostgreSQL
Procedures Oracle precisam ser avaliadas individualmente durante a migração.
Entre os elementos que devem ser analisados estão:
- parâmetros IN;
- parâmetros OUT;
- parâmetros IN OUT;
- tipos de dados;
- variáveis locais;
- cursores;
- SQL executado;
- tratamento de exceções;
- dependências externas;
- controle transacional.
O PostgreSQL possui suporte a procedures e functions, mas o comportamento e o modelo de execução devem ser avaliados de acordo com a implementação original.
Em projetos de migração, não é recomendável considerar uma procedure convertida apenas porque sua definição foi aceita pelo banco. O resultado funcional precisa ser validado por testes.
Conversão de Functions Oracle para PostgreSQL
Functions podem ser utilizadas diretamente em SQL, chamadas por outras funções ou incorporadas em regras de negócio da aplicação.
Durante a conversão devem ser avaliados:
- tipo de retorno;
- parâmetros;
- SQL interno;
- variáveis;
- exceções;
- efeitos colaterais;
- dependências;
- uso em consultas;
- uso em índices ou expressões;
- performance.
Uma function aparentemente simples pode ter impacto significativo caso seja executada milhares de vezes dentro de uma consulta.
Por isso, a conversão sintática deve ser seguida de testes de execução e análise de performance.
Migração de Packages Oracle
Packages estão entre os componentes que podem representar maior esforço em uma migração Oracle PL/SQL.
Um package pode concentrar:
- procedures;
- functions;
- variáveis;
- constantes;
- tipos;
- cursores;
- regras de negócio;
- estado de sessão.
O modelo de packages Oracle não possui equivalência direta em todos os aspectos no PostgreSQL comunitário. Portanto, dependendo da arquitetura de destino, o package pode precisar ser dividido em diferentes objetos ou adaptado para os mecanismos disponíveis.
No EDB Postgres Advanced Server, entretanto, existem recursos específicos de compatibilidade Oracle voltados a facilitar a execução e a migração de determinadas estruturas PL/SQL. ([enterprisedb.com](https://www.enterprisedb.com/docs/edb-postgres-ai/latest/databases/oracle_compatibility/))
A decisão entre aproveitar a compatibilidade ou realizar uma conversão estrutural deve ser tomada com base no assessment.
Conversão de Triggers Oracle
Triggers podem executar regras de negócio automaticamente em resposta a operações realizadas sobre tabelas.
Devem ser analisados:
- BEFORE;
- AFTER;
- INSERT;
- UPDATE;
- DELETE;
- operações por linha;
- operações por statement;
- triggers compostos;
- dependências entre triggers.
O PostgreSQL possui seu próprio modelo de triggers e funções de trigger. A conversão deve respeitar o modelo de execução do PostgreSQL, evitando simplesmente transportar a sintaxe Oracle sem avaliar seu comportamento.
Conversão de cursores
Cursores são frequentemente utilizados em aplicações PL/SQL para processar conjuntos de registros.
A análise deve identificar:
- cursores explícitos;
- cursores implícitos;
- cursor parameters;
- FOR loops;
- FETCH;
- OPEN;
- CLOSE;
- REF CURSOR.
O PostgreSQL também oferece recursos de cursores em PL/pgSQL, porém a forma de declaração, abertura, navegação e retorno pode ser diferente da implementação Oracle. Veja em: postgresql.org
Em determinados casos, uma conversão pode ser simplificada substituindo processamento procedural por SQL set-based, quando isso preservar o comportamento funcional e melhorar a eficiência.
Tratamento de exceções
O tratamento de erros é outro componente que precisa ser convertido cuidadosamente.
O código Oracle pode depender de:
- NO_DATA_FOUND;
- TOO_MANY_ROWS;
- OTHERS;
- SQLCODE;
- SQLERRM;
- exceções customizadas;
- RAISE;
- RAISE_APPLICATION_ERROR.
O PostgreSQL possui seu próprio mecanismo de tratamento de exceções em PL/pgSQL, incluindo blocos EXCEPTION e condições específicas. postgresql.org
Não basta substituir o nome de uma exceção. É necessário verificar se o comportamento observado pela aplicação permanece equivalente.
Conversão de SQL embutido no PL/SQL
Grande parte do esforço pode estar no SQL executado pelo código procedural.
Devem ser avaliados:
- funções Oracle;
- operadores específicos;
- outer joins;
- subqueries;
- MERGE;
- expressões;
- conversões de tipos;
- tratamento de NULL;
- funções de data;
- funções de string;
- agregações;
- SQL dinâmico.
Uma procedure pode possuir sintaxe procedural relativamente simples, mas executar consultas altamente dependentes do Oracle.
Por isso, a conversão do PL/SQL deve ser analisada em conjunto com a página de compatibilidade SQL e com o modelo de dados migrado.
Tipos de dados durante a migração PL/SQL
Os tipos de dados utilizados pelo código procedural precisam ser comparados aos tipos disponíveis no PostgreSQL ou no EDB Postgres.
Entre os pontos de atenção estão:
- NUMBER;
- VARCHAR2;
- CHAR;
- DATE;
- TIMESTAMP;
- CLOB;
- BLOB;
- RAW;
- collections;
- records;
- tipos definidos pelo usuário.
A conversão precisa preservar tanto os valores quanto o comportamento esperado pelas operações realizadas no código.
Alterações aparentemente pequenas nos tipos podem produzir diferenças em comparação, arredondamento, conversão, ordenação ou tratamento de NULL.
Dynamic SQL
Dynamic SQL exige atenção especial porque o código pode montar consultas ou comandos durante a execução.
O assessment deve identificar:
- EXECUTE IMMEDIATE;
- comandos dinamicamente construídos;
- bind variables;
- SQL dinâmico em loops;
- DDL executado dinamicamente;
- procedures chamadas dinamicamente.
O PostgreSQL possui mecanismos próprios para execução dinâmica em PL/pgSQL, documentados oficialmente na seção de comandos SQL dinâmicos.
Além da compatibilidade sintática, devem ser analisados segurança, parametrização e performance.
Packages e recursos Oracle específicos
Algumas aplicações dependem de packages fornecidos pelo próprio Oracle.
Exemplos comuns incluem recursos relacionados a:
- mensageria;
- arquivos;
- agendamento;
- SQL dinâmico;
- sessão;
- estatísticas;
- administração;
- criptografia;
- HTTP;
- XML.
Cada dependência precisa ser classificada como:
- compatível;
- substituível;
- convertível;
- dependente de produto;
- necessária para redesign.
Essa classificação evita que o projeto trate todos os objetos PL/SQL como se possuíssem o mesmo nível de complexidade.
Ferramentas para migração Oracle PL/SQL
Ferramentas de assessment e conversão podem acelerar o projeto, especialmente em ambientes com grande quantidade de objetos.
Dependendo da arquitetura escolhida, podem ser avaliadas:
- EDB Migration Portal;
- EDB Migration Toolkit;
- Ora2Pg;
- ferramentas próprias de análise de código;
- scripts de comparação;
- testes automatizados;
- ferramentas de validação de resultados.
O EDB Migration Portal é direcionado à análise e conversão de schemas Oracle para EDB Postgres e fornece mecanismos para avaliar incompatibilidades e conversões necessárias. enterprisedb.com
Ferramentas devem ser utilizadas como parte da metodologia e não como substitutas do assessment técnico.
Estratégia de conversão automática
Em projetos de grande porte, a conversão automática pode reduzir trabalho manual em componentes com padrões conhecidos.
Entretanto, código convertido automaticamente deve passar por revisão.
O processo recomendado inclui:
- inventário;
- análise;
- conversão automática quando aplicável;
- revisão técnica;
- compilação;
- testes unitários;
- testes integrados;
- validação funcional;
- otimização.
O objetivo não deve ser simplesmente produzir código que compile. O objetivo é produzir código que preserve o comportamento funcional e atenda aos requisitos de performance, segurança e operação.
Testes unitários de PL/SQL migrado
Cada objeto convertido deve possuir uma estratégia de validação proporcional à sua criticidade.
Devem ser testados:
- entradas válidas;
- entradas inválidas;
- valores nulos;
- limites;
- exceções;
- transações;
- resultados;
- efeitos colaterais.
Para funções e procedures críticas, é recomendável comparar resultados entre Oracle e PostgreSQL durante uma fase controlada de validação.
Testes de regressão
Depois da conversão individual, é necessário validar a aplicação como um todo.
Testes de regressão devem verificar se as mudanças no código procedural alteraram:
- processos financeiros;
- regras comerciais;
- cálculos;
- integrações;
- relatórios;
- processamentos batch;
- rotinas de fechamento;
- processos de faturamento;
- rotinas administrativas.
A prioridade deve ser dada aos processos de maior impacto para o negócio.
Performance do PL/pgSQL após a conversão
Uma rotina que apresenta determinado comportamento de performance no Oracle pode apresentar comportamento diferente no PostgreSQL.
Devem ser analisados:
- planos de execução;
- índices;
- estatísticas;
- joins;
- consultas repetitivas;
- loops;
- acesso a grandes volumes;
- locks;
- tempo de execução;
- consumo de CPU;
- IO.
Um dos objetivos da conversão deve ser identificar código procedural que pode ser simplificado por operações SQL orientadas a conjuntos.
Em determinadas situações, substituir loops que processam registros individualmente por operações set-based pode produzir uma arquitetura mais adequada ao PostgreSQL.
Segurança na conversão de PL/SQL
A migração também deve revisar aspectos de segurança existentes no código.
- SQL dinâmico;
- concatenação de parâmetros;
- credenciais;
- privilégios;
- execução com privilégios elevados;
- acesso a objetos;
- funções SECURITY DEFINER;
- auditoria;
- dados sensíveis.
Um código convertido não deve reproduzir automaticamente permissões excessivas existentes no ambiente Oracle.
PostgreSQL ou EDB Postgres para o código Oracle PL/SQL
A decisão sobre PostgreSQL comunitário ou EDB Postgres deve considerar o grau de dependência do código em relação aos recursos Oracle.
PostgreSQL
O PostgreSQL pode ser uma alternativa adequada quando o código pode ser convertido para PL/pgSQL ou quando a organização está preparada para realizar a reescrita necessária.
EDB Postgres Advanced Server
O EDB Postgres Advanced Server deve ser avaliado quando a compatibilidade Oracle pode reduzir significativamente o esforço de conversão.
A documentação da EDB apresenta recursos de compatibilidade para facilitar a migração de aplicações Oracle, incluindo componentes relacionados a PL/SQL e objetos Oracle. enterprisedb.com
O ponto fundamental é evitar decisões baseadas somente no nome do produto. A escolha deve resultar da análise técnica do código, das dependências e dos requisitos operacionais.
Coexistência Oracle e PostgreSQL durante a migração
Projetos grandes podem utilizar uma fase de coexistência para reduzir riscos.
Nessa etapa, Oracle e PostgreSQL podem permanecer disponíveis enquanto os componentes são migrados progressivamente.
A coexistência permite:
- migrar objetos por grupos;
- testar aplicações individualmente;
- comparar resultados;
- corrigir incompatibilidades;
- reduzir o risco de uma mudança única;
- preparar o cutover.
Por outro lado, a coexistência aumenta a complexidade operacional e deve possuir critérios claros para sincronização, validação e encerramento.
Cutover do código PL/SQL
O cutover deve ocorrer somente após a validação dos objetos e das aplicações dependentes.
O processo pode incluir:
- congelamento do código Oracle;
- sincronização final dos dados;
- execução da última conversão;
- validação dos objetos;
- alteração das conexões;
- execução de testes críticos;
- liberação dos usuários;
- monitoramento.
O plano deve estabelecer critérios objetivos de sucesso e procedimentos de rollback.
Plano de rollback
O rollback precisa considerar não apenas o banco, mas também o estado da aplicação.
Devem ser definidos:
- condições para retorno;
- responsáveis pela decisão;
- estado dos dados;
- versão do código;
- configurações de conexão;
- procedimentos de restauração;
- comunicação aos usuários.
Quanto mais crítica a aplicação, maior deve ser a cobertura dos testes do procedimento de retorno.
Metodologia para Migração Oracle PL/SQL para PostgreSQL
Uma metodologia estruturada pode ser organizada da seguinte forma:
- assessment do ambiente Oracle;
- inventário dos objetos PL/SQL;
- mapeamento de dependências;
- classificação de complexidade;
- identificação de incompatibilidades;
- definição do banco de destino;
- conversão do código;
- revisão técnica;
- compilação;
- testes unitários;
- testes integrados;
- testes de regressão;
- testes de performance;
- homologação;
- cutover;
- operação assistida.
Principais riscos da migração Oracle PL/SQL
- subestimar a quantidade de código;
- não mapear dependências;
- converter somente a sintaxe;
- ignorar packages;
- não validar exceptions;
- não testar dynamic SQL;
- ignorar diferenças de tipos;
- não avaliar performance;
- não testar processos críticos;
- transportar privilégios excessivos;
- não possuir rollback;
- modernizar o código sem preservar requisitos funcionais.
Benefícios da migração de PL/SQL para PostgreSQL
Uma migração planejada pode contribuir para reduzir a dependência do Oracle e criar uma base tecnológica mais flexível.
- redução do acoplamento com tecnologias Oracle;
- adoção de PostgreSQL Enterprise;
- possibilidade de utilização de EDB Postgres;
- modernização progressiva do código;
- padronização da arquitetura;
- maior flexibilidade de infraestrutura;
- preparação para ambientes cloud;
- evolução das aplicações legadas.
Os benefícios efetivos dependem do nível de compatibilidade, do esforço de conversão e da arquitetura escolhida para o ambiente de destino.
Quando utilizar compatibilidade Oracle
Em aplicações com grande quantidade de código Oracle, uma estratégia baseada em compatibilidade pode ser considerada para reduzir o impacto inicial da migração.
Isso pode ser especialmente relevante quando:
- há grande volume de PL/SQL;
- existem muitos packages;
- há forte dependência de objetos Oracle;
- a aplicação é crítica;
- o prazo de migração é restrito;
- a organização deseja uma transição gradual.
O uso de compatibilidade não deve impedir a avaliação de longo prazo. Depois da migração, a organização pode decidir quais componentes devem permanecer utilizando recursos de compatibilidade e quais podem ser modernizados gradualmente.
Links Relacionados
- PL/SQL no PostgreSQL
- Migração Oracle para PostgreSQL
- Migração de Aplicações Oracle para PostgreSQL
- Migração Oracle Forms para PostgreSQL
- Packages Oracle
- Procedures Oracle
- Triggers Oracle
- Functions Oracle
- Ferramentas de Migração Oracle para PostgreSQL
- Migração de Dados Oracle para PostgreSQL
- Testes Pós-Migração Oracle para PostgreSQL
- PostgreSQL Enterprise
Recursos Oficiais
- PostgreSQL — PL/pgSQL
- PostgreSQL — Control Structures
- PostgreSQL — Cursors
- PostgreSQL — PL/pgSQL Statements
- PostgreSQL — Executing Dynamic Commands
- EDB — Oracle Compatibility
- EDB — Migration Handbook
- EDB — Migration Tools
- EDB — Migration Portal
- EDB — Migration Toolkit
FAQ — Perguntas Frequentes
É possível migrar Oracle PL/SQL para PostgreSQL?
Sim. O código pode ser convertido para PL/pgSQL ou adaptado utilizando recursos de compatibilidade disponíveis em plataformas como o EDB Postgres Advanced Server. O esforço depende das funcionalidades Oracle utilizadas.
PL/SQL e PL/pgSQL são iguais?
Não. As duas linguagens possuem conceitos semelhantes, mas apresentam diferenças de sintaxe, tipos, funções, objetos, tratamento de erros e recursos específicos.
Todo código PL/SQL precisa ser reescrito?
Não necessariamente. Dependendo do destino e do código utilizado, alguns componentes podem ser convertidos com alterações limitadas, enquanto outros exigem adaptação ou reescrita.
O EDB Postgres Advanced Server facilita a migração de PL/SQL?
Em determinados cenários, sim. O produto possui recursos de compatibilidade Oracle destinados a facilitar a migração de aplicações que utilizam funcionalidades Oracle. A aplicabilidade deve ser verificada durante o assessment.
Packages Oracle podem ser migrados para PostgreSQL?
Podem ser migrados, mas o tratamento depende da arquitetura de destino. No PostgreSQL comunitário, pode ser necessário decompor a estrutura do package em diferentes objetos. No EDB Postgres Advanced Server, recursos de compatibilidade podem facilitar determinados cenários.
Procedures Oracle funcionam diretamente no PostgreSQL?
Não deve ser presumido. A procedure precisa ser analisada e convertida conforme a sintaxe, os tipos, as funções, as exceções e as demais dependências utilizadas.
Functions Oracle precisam ser convertidas?
Sim, quando dependem de recursos específicos do Oracle. Mesmo quando uma function possui estrutura semelhante no PostgreSQL, seu comportamento e suas dependências devem ser validados.
O que acontece com os triggers Oracle?
Os triggers precisam ser adaptados ao modelo de triggers do PostgreSQL ou aos recursos de compatibilidade do ambiente escolhido. A lógica executada pelo trigger deve ser validada funcionalmente.
Como migrar EXECUTE IMMEDIATE?
O SQL dinâmico precisa ser convertido para os mecanismos de execução dinâmica do PostgreSQL ou tratado pelos recursos de compatibilidade disponíveis. Também devem ser avaliadas parametrização, segurança e performance.
É possível automatizar a conversão de PL/SQL?
Parte da conversão pode ser automatizada por ferramentas de assessment e migração. Entretanto, código convertido automaticamente precisa passar por revisão técnica e testes funcionais.
Como testar o PL/SQL convertido?
Devem ser utilizados testes unitários, testes integrados, testes de regressão e validação dos resultados. Para processos críticos, a comparação entre Oracle e PostgreSQL durante uma fase controlada pode ajudar a identificar diferenças.
A migração PL/SQL pode ser feita sem downtime?
Dependendo da arquitetura, do método de migração de dados e dos requisitos da aplicação, é possível reduzir a indisponibilidade. A possibilidade de uma migração sem downtime precisa ser analisada e comprovada durante o planejamento.
Quanto tempo leva uma migração Oracle PL/SQL para PostgreSQL?
Não existe um prazo único. O tempo depende da quantidade de objetos, volume de código, complexidade das dependências, quantidade de aplicações, estratégia de conversão e nível de modernização.
Devo escolher PostgreSQL ou EDB Postgres?
A decisão deve ser baseada no assessment. Ambientes com grande dependência de recursos Oracle podem se beneficiar da avaliação dos recursos de compatibilidade do EDB Postgres Advanced Server, enquanto aplicações com menor acoplamento podem ser candidatas à conversão direta para PostgreSQL.
A conversão do PL/SQL encerra a migração da aplicação?
Não. O código procedural é apenas um dos componentes. Também devem ser validados dados, objetos de banco, aplicações, integrações, relatórios, performance, segurança, alta disponibilidade e procedimentos operacionais.
Conclusão
A Migração Oracle PL/SQL para PostgreSQL deve ser tratada como uma disciplina específica dentro de um projeto maior de modernização e migração de banco de dados.
O principal erro é considerar que converter sintaxe significa concluir a migração. O código precisa ser inventariado, classificado, convertido, revisado, testado e validado dentro do contexto real da aplicação.
O PostgreSQL oferece PL/pgSQL como linguagem procedural nativa, enquanto o EDB Postgres Advanced Server disponibiliza recursos de compatibilidade Oracle que podem reduzir o esforço em determinados ambientes.
A estratégia mais adequada depende da quantidade de código, do nível de dependência Oracle, da criticidade das aplicações e dos objetivos de modernização.
Com assessment adequado, automação onde aplicável, conversão incremental, testes de regressão, validação de performance e plano de rollback, a organização pode reduzir o risco da transição e construir uma base PostgreSQL Enterprise preparada para evolução futura.
Modernize seu Banco de Dados com a Dominus Tech
👉 Planejando uma Migração Oracle para PostgreSQL?
A Dominus Tech é Parceira Gold da EnterpriseDB e apoia empresas em todas as etapas da modernização de bancos de dados Oracle para PostgreSQL. Nossa equipe atua em assessment, planejamento, análise de compatibilidade, arquitetura, migração, otimização de desempenho, alta disponibilidade, observabilidade e suporte especializado para ambientes PostgreSQL Enterprise.
✔ Parceira Gold da EnterpriseDB no Brasil
O planejamento adequado permite transformar uma migração complexa em um projeto estruturado, com riscos identificados, responsabilidades definidas, critérios de sucesso e estratégia de execução. A Dominus Tech pode apoiar sua organização desde a avaliação inicial até a estabilização do ambiente PostgreSQL em produção.
