Packages Oracle

Packages Oracle são componentes fundamentais em muitas aplicações corporativas desenvolvidas sobre Oracle Database. Eles permitem organizar procedures, functions, variáveis, cursores e tipos relacionados dentro de uma estrutura lógica reutilizável. Durante uma migração Oracle para PostgreSQL Enterprise, a análise dos packages é uma das etapas mais importantes para determinar o nível de compatibilidade e o esforço necessário para preservar a lógica de negócio.

No EDB Postgres Advanced Server, a EDB oferece recursos de compatibilidade com packages Oracle. A documentação oficial descreve os built-in packages como parte da estratégia de compatibilidade que permite executar aplicações Oracle com poucas ou nenhuma alteração em determinados cenários. A plataforma também disponibiliza suporte procedural para procedures, functions, triggers e packages. Documentação oficial da EDB.

Essa compatibilidade é especialmente relevante quando uma empresa possui aplicações legadas com milhares de linhas de PL/SQL distribuídas em packages. Em vez de assumir que todo o código precisa ser reescrito, o projeto pode começar com um assessment para identificar quais componentes são compatíveis, quais precisam de ajustes e quais exigem reengenharia.

---

O que são Packages Oracle?

O conceito de Package no Oracle

Um package é uma unidade lógica utilizada para organizar elementos relacionados da aplicação dentro do banco de dados.

Um único package pode reunir:

• Procedures.
• Functions.
• Variáveis.
• Constantes.
• Cursores.
• Tipos definidos pelo usuário.
• Records.
• Rotinas auxiliares.

Essa organização permite que diferentes componentes da aplicação compartilhem uma mesma estrutura lógica.

Package Specification

A specification representa a interface pública do package.

Nela podem ser declaradas procedures, functions, variáveis, tipos e outros elementos que precisam ser acessíveis por outros componentes.

Isso permite separar a interface pública da implementação interna.

Package Body

O package body contém a implementação dos elementos definidos na specification.

Essa separação é importante porque permite esconder detalhes internos da implementação e expor apenas os recursos necessários para a aplicação.

Por que Packages são importantes para aplicações corporativas?

Em sistemas empresariais de longa duração, packages podem concentrar uma quantidade significativa de regras de negócio.

Um sistema financeiro, por exemplo, pode utilizar packages para:

• Processar pagamentos.
• Calcular juros.
• Validar transações.
• Executar fechamentos.
• Gerenciar clientes.
• Processar contratos.
• Controlar auditoria.
• Executar rotinas administrativas.

Por isso, simplesmente migrar tabelas e dados não significa que a aplicação esteja migrada.

O código armazenado no banco precisa fazer parte do assessment.

Packages e migração Oracle para PostgreSQL

Durante uma migração Oracle para PostgreSQL, packages devem ser tratados como componentes de aplicação e não apenas como objetos de banco.

A EDB posiciona o EDB Postgres Advanced Server como uma versão aprimorada do PostgreSQL com compatibilidade integrada para Oracle, incluindo suporte a PL/SQL e packages built-in compatíveis.

---

---

Packages no EDB Postgres Advanced Server

Compatibilidade com Packages Oracle

O EDB Postgres Advanced Server fornece uma camada de compatibilidade Oracle que inclui packages e outros recursos utilizados por aplicações desenvolvidas originalmente para Oracle.

A documentação oficial informa que a compatibilidade do EDB Postgres Advanced Server inclui a linguagem procedural SPL para procedures, functions, triggers e packages, além de packages built-in compatíveis com Oracle.

Isso permite que determinadas aplicações Oracle sejam executadas no ambiente EDB com poucas ou nenhuma alteração, dependendo dos recursos utilizados pela aplicação. A compatibilidade não deve, porém, ser interpretada como equivalência total entre os dois bancos.

Packages compatíveis

A EDB disponibiliza uma lista específica de built-in packages suportados pelo EDB Postgres Advanced Server.

Entre os recursos documentados estão packages relacionados a alertas, filas, agendamento, arquivos, HTTP, locks, LOBs, randomização, utilidades e outras funções utilizadas em aplicações Oracle. A lista e o nível de suporte devem ser verificados de acordo com a versão do EDB Postgres Advanced Server utilizada no projeto.

Exemplos de packages importantes

Alguns packages podem aparecer com frequência em aplicações corporativas.

DBMS_OUTPUT

É utilizado para produzir informações de saída durante a execução de código procedural e pode ser bastante comum em rotinas de desenvolvimento, diagnóstico e processamento.

DBMS_SQL

Está relacionado à execução e manipulação de SQL de forma dinâmica dentro da lógica procedural.

DBMS_SCHEDULER

É utilizado para gerenciamento de tarefas agendadas no ambiente Oracle. Dependências desse tipo precisam ser avaliadas cuidadosamente porque a arquitetura de agendamento do ambiente de destino pode exigir ajustes.

DBMS_JOB

Aplicações legadas podem utilizar DBMS_JOB para execução de tarefas programadas. Durante uma migração, essas dependências devem ser inventariadas e validadas.

UTL_FILE

Aplicações que utilizam operações de arquivos por meio de packages Oracle precisam de atenção especial devido às diferenças de segurança e de acesso ao sistema operacional entre as plataformas.

UTL_HTTP

Rotinas que fazem chamadas HTTP a partir do banco também precisam ser testadas no ambiente de destino, principalmente quando existem regras de segurança, certificados, autenticação ou dependências externas.

Packages próprios da aplicação

Além dos packages fornecidos pelo banco, muitas aplicações possuem packages desenvolvidos internamente.

Esses packages podem representar a maior parte do esforço de migração.

Por isso, o assessment deve separar claramente:

• Packages built-in.
• Packages desenvolvidos pela empresa.
• Packages de terceiros.
• Packages dependentes de funcionalidades específicas do Oracle.

---

Compatibilidade, dependências e riscos

Todo Package Oracle é compatível com PostgreSQL?

Não.

Essa é uma das principais questões que precisam ser esclarecidas em um projeto de migração.

O EDB Postgres Advanced Server oferece ampla compatibilidade Oracle, mas não implementa todas as funcionalidades específicas do Oracle. A própria documentação da EDB ressalta que a compatibilidade cobre muitos dos construtos mais utilizados, mas não todos os recursos Oracle.

Compatibilidade não significa equivalência absoluta

Um package pode existir no ambiente de destino e ainda assim exigir testes específicos.

O comportamento de uma procedure, function ou package pode depender de:

• Tipos de dados.
• Configurações do banco.
• Privilégios.
• Objetos externos.
• Sistema operacional.
• Arquivos.
• Jobs.
• Links entre bancos.
• Bibliotecas externas.
• Drivers.
• Características específicas da aplicação.

Dependências entre Packages

Um dos maiores riscos de uma migração é analisar cada package isoladamente.

Packages frequentemente chamam outros packages, procedures, functions, tabelas, views, sequences e objetos externos.

Portanto, o assessment deve construir um mapa de dependências.

Exemplo de dependência

Um processo de faturamento pode chamar:

• Package de faturamento.
• Package de clientes.
• Package de impostos.
• Package de auditoria.
• Functions de cálculo.
• Triggers de atualização.
• Sequences.
• Tabelas de configuração.

Alterar um componente sem analisar os demais pode gerar falhas que só aparecem durante os testes de integração.

Packages e segurança

Packages também devem ser analisados do ponto de vista de segurança.

É necessário verificar:

• Quem possui permissão de execução.
• Quais objetos são acessados.
• Quais operações podem modificar dados.
• Quais packages acessam recursos externos.
• Quais rotinas manipulam informações sensíveis.
• Quais privilégios são herdados ou necessários.

Essa análise deve fazer parte da arquitetura de segurança do novo ambiente.

Packages e desempenho

Uma conversão sintática bem-sucedida não garante desempenho equivalente.

Packages podem executar milhares ou milhões de operações em grandes volumes de dados.

Durante os testes, é necessário avaliar:

• Tempo de execução.
• Consumo de CPU.
• Consumo de memória.
• Leituras de disco.
• Bloqueios.
• Concorrência.
• Planos de execução.
• Quantidade de chamadas.
• Processamento em lote.

Otimização após a migração

Em alguns casos, a melhor estratégia não será reproduzir exatamente a implementação Oracle, mas preservar o comportamento funcional e otimizar a implementação para PostgreSQL Enterprise.

---

---

Como migrar Packages Oracle

Assessment antes da migração

O primeiro passo para migrar Packages Oracle é realizar um inventário completo.

Esse inventário deve responder perguntas como:

• Quantos packages existem?
• Quantas linhas de código existem?
• Quais packages são mais utilizados?
• Quais packages são críticos para o negócio?
• Quais packages dependem de outros objetos?
• Quais packages utilizam recursos Oracle específicos?
• Quais packages utilizam SQL dinâmico?
• Quais packages utilizam arquivos?
• Quais packages utilizam agendamento?
• Quais packages dependem de comunicação externa?

Classificação por esforço

Depois do inventário, os objetos podem ser classificados em grupos.

• Baixo esforço: componentes com alta compatibilidade.
• Esforço moderado: componentes que precisam de ajustes.
• Alto esforço: componentes dependentes de recursos Oracle específicos.
• Reengenharia: componentes que devem ser redesenhados.

Migration Portal

O Migration Portal da EDB é uma ferramenta online destinada à avaliação da compatibilidade de schemas Oracle com o EDB Postgres Advanced Server.

Segundo a documentação da EDB, o serviço analisa DDL Oracle, identifica incompatibilidades e pode aplicar handlers de correção para determinados casos conhecidos. Os resultados podem então ser revisados antes de uma nova avaliação.

Esse processo pode ajudar a transformar a avaliação de compatibilidade em uma atividade mensurável.

O que o assessment deve entregar?

Um assessment profissional deve gerar mais do que uma lista de erros.

O resultado deve permitir responder:

• Quanto código precisa ser convertido?
• Quanto pode ser preservado?
• Quais são os maiores riscos?
• Quais componentes precisam de reengenharia?
• Quais testes serão necessários?
• Qual é o impacto esperado na aplicação?
• Qual estratégia de cutover é mais adequada?

Migration Toolkit

O EDB Migration Toolkit é uma ferramenta de linha de comando voltada para diferentes cenários de migração e pode apoiar a movimentação de dados para PostgreSQL ou EDB Postgres Advanced Server.

É importante diferenciar a migração dos dados da conversão da lógica procedural. O Toolkit pode fazer parte do processo de migração, mas o tratamento dos Packages Oracle exige análise específica de compatibilidade e conversão.

A documentação atual da EDB descreve o Migration Toolkit como uma ferramenta Java para diferentes cenários de migração, incluindo Oracle para EDB Postgres Advanced Server.

Testes pós-migração

Depois da conversão, os packages precisam ser submetidos a testes funcionais, de integração e desempenho.

Testes funcionais

• Entradas válidas.
• Entradas inválidas.
• Tratamento de exceções.
• Resultados esperados.
• Atualizações de dados.
• Rollback.

Testes de integração

• Aplicação.
• Drivers.
• APIs.
• Jobs.
• Outros packages.
• Triggers.
• Serviços externos.

Testes de desempenho

Os testes de desempenho devem utilizar volumes e padrões de concorrência próximos do ambiente real.

Isso é especialmente importante para packages que executam processamento em lote ou são chamados milhares de vezes por aplicações transacionais.

Quando preservar um Package?

A preservação tende a ser interessante quando o package possui lógica de negócio estável, bem testada e compatível com o ambiente de destino.

Quando reescrever um Package?

A reescrita pode ser recomendada quando o componente possui forte dependência de funcionalidades exclusivas do Oracle, arquitetura antiga, baixa qualidade de código ou necessidade de modernização independente da migração.

O objetivo deve ser reduzir risco e preservar o valor da aplicação, e não simplesmente converter código por conversão.

---

---

FAQ — Perguntas Frequentes

O que são Packages Oracle?

Packages Oracle são estruturas que agrupam procedures, functions, variáveis, cursores, tipos e outras rotinas relacionadas em uma unidade lógica. São amplamente utilizados para organizar e encapsular lógica de negócio no banco de dados.

É possível migrar Packages Oracle para PostgreSQL?

Sim, dependendo dos recursos utilizados. O EDB Postgres Advanced Server oferece compatibilidade Oracle que inclui packages, PL/SQL e diversos packages built-in. Entretanto, cada aplicação precisa passar por uma análise de compatibilidade e testes.

Todos os Packages Oracle são compatíveis com EDB Postgres?

Não. A EDB oferece ampla compatibilidade, mas não implementa todas as funcionalidades específicas do Oracle. O nível de compatibilidade deve ser avaliado por versão e por recurso utilizado pela aplicação.

Qual a diferença entre Package Specification e Package Body?

A Package Specification define a interface pública do package, enquanto o Package Body contém a implementação. Essa separação permite expor somente os componentes necessários e manter detalhes internos da implementação.

O EDB Postgres Advanced Server possui packages compatíveis com Oracle?

Sim. A EDB fornece uma coleção de built-in packages destinados à compatibilidade com aplicações Oracle. A lista oficial deve ser consultada de acordo com a versão do EDB Postgres Advanced Server utilizada.

É necessário reescrever todos os Packages Oracle?

Não necessariamente. Uma das vantagens da abordagem de compatibilidade do EDB Postgres Advanced Server é reduzir a quantidade de código que precisa ser convertido. O resultado depende do nível de utilização de recursos Oracle específicos e da compatibilidade de cada componente.

Como descobrir quais Packages Oracle precisam ser alterados?

O projeto deve começar com um assessment do schema e do código procedural, identificando packages, dependências, recursos Oracle utilizados e incompatibilidades. O Migration Portal da EDB pode apoiar a avaliação de compatibilidade de schemas Oracle.

Packages Oracle podem afetar o desempenho após a migração?

Sim. Mesmo quando um package é funcionalmente compatível, seu desempenho precisa ser validado no ambiente de destino. Volume de dados, concorrência, consultas internas, bloqueios e planos de execução podem produzir resultados diferentes.

Packages Oracle devem ser testados depois da migração?

Sim. Os testes devem validar comportamento funcional, tratamento de exceções, integração com a aplicação, concorrência, processamento de grandes volumes e desempenho.

Quando vale a pena reescrever um Package Oracle?

A reescrita pode ser considerada quando o package depende fortemente de funcionalidades exclusivas do Oracle, possui problemas de manutenção ou quando a organização deseja aproveitar a migração para modernizar a arquitetura da aplicação.

---

Links Relacionados, Recursos Oficiais e SEO

Links Relacionados

• Compatibilidade Oracle PostgreSQL
• PL/SQL no PostgreSQL
• PostgreSQL Compatível com Oracle
• Migração Oracle para PostgreSQL
• EnterpriseDB
• EDB Postgres Advanced Server
• EDB Migration Toolkit
• PostgreSQL Enterprise
• PostgreSQL para Empresas
• PostgreSQL vs EDB Postgres
• PostgreSQL Community vs EnterpriseDB
• EDB Replication Server
• EDB Failover Manager
• EDB Backup and Recovery
• EDB Control Center
• EDB Kubernetes
• EDB Distributed

Recursos Oficiais

• EDB — Built-in Packages
• EDB — Database Compatibility for Oracle Developers
• EDB — EDB Postgres Advanced Server Reference
• EDB — Oracle Migration Handbook
• EDB — Capabilities for the Migration Journey
• EDB — Migration Documentation