Melhores práticas para conversão de esquema do Oracle para o servidor flexível do Banco de Dados do Azure para PostgreSQL

Este artigo fornece práticas recomendadas e recomendações para o recurso de conversão de esquema do Oracle no Banco de Dados do Azure para PostgreSQL no Visual Studio Code com o Microsoft Foundry. Siga estas diretrizes para obter resultados confiáveis e de alta qualidade.

Planejar a conversão de esquema

Uma conversão bem-sucedida começa com o planejamento. Decida o que converter, como iterar e com qual destino do Banco de Dados do Azure para PostgreSQL você está alinhado antes de executar a ferramenta.

Defina o escopo dos esquemas de origem

Especifique quais esquemas de aplicativo Oracle você deseja converter. O fluxo de trabalho de extração exclui automaticamente o sistema Oracle e esquemas internos, como SYS, , SYSTEM, XDB, MDSYSe CTXSYSWMSYS.

Alinhar a versão principal do PostgreSQL de destino

Use a mesma versão principal do PostgreSQL no banco de dados de rascunho do servidor flexível do Banco de Dados do Azure para PostgreSQL de destino da produção. A ferramenta de conversão emite DDL que tem como destino uma versão principal específica do PostgreSQL. Conversão em relação a uma versão principal e implantação em outra pode revelar diferenças de sintaxe ou de recurso durante a implantação.

Verificar se há objetos sem suporte com antecedência

Examine o Oracle para Banco de Dados do Azure para PostgreSQL limitações de conversão de esquema de servidor flexível antes de começar. Para cada objeto sem suporte, decida com antecedência se deseja recriar a funcionalidade nativamente no PostgreSQL, replatá-la em um serviço de Azure apropriado ou retirá-la do escopo de migração.

Planeje a remediação de objetos sem suporte

Para cada objeto sem suporte identificado na etapa anterior, registre o caminho de correção escolhido antes de executar a conversão. Acompanhe:

• O nome e o tipo do objeto Oracle.
• O caminho escolhido: recriar, nova plataforma ou descartar.
• O serviço do Azure de destino ou o padrão do PostgreSQL, se você estiver mudando de plataforma.

Escolha onde executar a conversão

Para esquemas pequenos, você pode executar a conversão de sua estação de trabalho local. Para esquemas maiores, execute Visual Studio Code e a ferramenta de conversão de esquema em uma máquina virtual Azure.

Uma conversão grande é executada por muito tempo e faz chamadas sustentadas para sua origem Oracle, o banco de dados zero e Microsoft Foundry. A execução de uma máquina virtual Azure oferece:

• Proximidade de rede: a máquina virtual fica na mesma região Azure que seu servidor flexível Banco de Dados do Azure para PostgreSQL e seu recurso Microsoft Foundry, o que reduz a latência de ida e volta nas muitas chamadas feitas por uma conversão.
• Sessões estáveis e de execução longa: a conversão não é interrompida por suspensão da estação de trabalho, reinicializações, quedas de VPN ou tempos limite de rede corporativa.
• Conectividade privada: você pode colocar a máquina virtual na mesma rede virtual que o servidor de destino e Microsoft ponto de extremidade privado do Foundry, para que o tráfego não percorra a Internet pública.
• Recursos previsíveis: você pode dimensionar cpu, memória e disco para a carga de trabalho de conversão e manter artefatos em um disco gerenciado que você faz backup.

Coloque a máquina virtual na região que hospeda seu banco de dados zero e dê a ela acesso de rede ao banco de dados Oracle de origem. Se você usar o modo de cliente espesso, instale o Oracle Instant Client na máquina virtual. Para obter mais informações, consulte os modos de conectividade oracle.

Preparar o ambiente oracle de origem

Antes de executar uma conversão, prepare o ambiente Oracle de origem. Conceda à ferramenta de conversão os privilégios necessários para ler metadados de esquema e verifique se a capacidade de sessão simultânea é suficiente para que a ferramenta possa extrair um esquema completo e preciso.

Privilégios necessários do Oracle

O usuário de conexão Oracle que a ferramenta de conversão usa precisa de acesso de leitura ao catálogo de metadados do Oracle. A ferramenta lê metadados do esquema a partir das DBA_* exibições de catálogo.

Conceda SELECT_CATALOG_ROLE ou SELECT ANY DICTIONARY para que o usuário possa ler as visualizações DBA_* necessárias. Use acesso com privilégios mínimos de acordo com a política organizacional. O usuário não precisa de privilégios em nenhuma tabela de aplicativos ou para ler dados em nível de linha. A ferramenta nunca consulta dados do aplicativo; ele lê apenas metadados de esquema.

Definir o parâmetro de sessões Oracle

Verifique se o parâmetro Oracle sessions seja maior que 10 para que a ferramenta possa abrir um número suficiente de leituras simultâneas de metadados. Verifique o valor atual com:

SELECT name, value
FROM v$parameter
WHERE name = 'sessions';

Preparar o banco de dados do zero

A ferramenta de conversão de esquema usa um banco de dados temporário no servidor flexível do Banco de Dados do Azure para PostgreSQL para validar os objetos convertidos. Provisione e configure o servidor antes de iniciar uma conversão para que o comportamento de validação corresponda ao destino de produção eventual.

Privilégios necessários do PostgreSQL

O usuário da conexão PostgreSQL que a ferramenta de conversão usa precisa ter privilégios para criar e validar objetos no banco de dados temporário:

• Participação na função azure_pg_admin, que é necessária para criar as extensões das quais a ferramenta depende.
• Privilégios CREATE e USAGE no esquema de rascunho, de maneira que a ferramenta possa criar objetos convertidos para validação.
• Privilégio CONNECT no banco de dados de rascunho.

Escolha um tamanho apropriado para o banco de dados temporário

O banco de dados de rascunho só valida DDL; ele não hospeda a carga de trabalho do aplicativo. Use uma camada de computação que forneça capacidade de conexão estável para a atividade de conversão e validação. Dimensione o banco de dados temporário separadamente do destino de produção e reduza seu tamanho após a conclusão da conversão.

Lista de permissões e instalação de extensões necessárias

A ferramenta de conversão de esquema depende de várias extensões do PostgreSQL. Essas extensões traduzem pacotes internos do Oracle, tipos espaciais, particionamento e pesquisa de texto completo. Eles também permitem a observabilidade no banco de dados de rascunho. Permitir lista e instalar as extensões que o esquema convertido precisa antes da primeira execução de conversão.

A tabela a seguir lista extensões comumente usadas para conversões do Oracle para o Banco de Dados do Azure para PostgreSQL. Inclua os que se aplicam ao esquema de origem e adicione outros que a carga de trabalho requer.

A ferramenta cria plpgsql_check no banco de dados zero automaticamente quando a extensão está na lista de permissões. Permita a lista antes de sua primeira execução para que as rotinas convertidas obtenham validação de corpo inteiro. Se a extensão não estiver disponível, a conversão ainda será bem-sucedida, mas a validação extra será ignorada silenciosamente. plpgsql_check é necessário apenas no banco de dados zero. O esquema convertido não depende dele em tempo de execução.

Adicione dblink somente quando o esquema de origem usar PRAGMA AUTONOMOUS_TRANSACTION. Nesse caso, o código convertido precisa dblink no servidor de destino, não apenas no banco de dados zero.

Etapa 1: Lista de permissões das extensões

No portal do Azure, abra o Servidor Flexível do Banco de Dados do Azure para PostgreSQL que hospeda seu banco de dados temporário. Selecione parâmetros do servidor, pesquise azure.extensionse selecione cada extensão na lista. Salve suas alterações. Extensões como pg_partman, pg_stat_statementse plpgsql_check também exigem entradas em shared_preload_libraries. Essas entradas precisam de uma reinicialização do servidor. Para obter mais informações, consulte Como usar extensões do PostgreSQL.

Etapa 2: Instale as extensões no banco de dados temporário

Conecte-se ao banco de dados de rascunho como um membro da função azure_pg_admin e crie cada extensão:

CREATE EXTENSION IF NOT EXISTS orafce;
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
CREATE EXTENSION IF NOT EXISTS pgcrypto;
CREATE EXTENSION IF NOT EXISTS pg_trgm;
CREATE EXTENSION IF NOT EXISTS postgis;
CREATE EXTENSION IF NOT EXISTS postgis_topology;
CREATE EXTENSION IF NOT EXISTS postgis_tiger_geocoder;
CREATE EXTENSION IF NOT EXISTS pg_partman;
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;
CREATE EXTENSION IF NOT EXISTS plpgsql_check;

Etapa 3: Configurar search_path para compatibilidade do Oracle

orafceinstala pacotes compatíveis com Oracle em esquemas dedicados (oracle, , dbms_*, plv*). utl_file Defina search_path no nível do banco de dados para que esses esquemas, juntamente com os esquemas PostGIS (topology, tiger) estejam disponíveis para todas as conexões. Uma configuração no nível do banco de dados também abrange objetos que não podem qualificar uma referência por conta própria, como exibições, CHECK restrições, padrões de coluna e colunas geradas.

ALTER DATABASE <database_name> SET search_path = public, oracle, topology, tiger,
    dbms_random, dbms_alert, dbms_assert, dbms_output, dbms_pipe,
    dbms_sql, dbms_utility, plvchr, plvdate, plvlex, plvstr,
    plvsubst, plunit, utl_file;

Inclua apenas os esquemas para as extensões que você instalou. Reconecte-se depois de executar essa instrução, pois o novo valor se aplica às sessões que começam após a alteração. Em vez disso, para definir o escopo da configuração para uma única função, use ALTER ROLE <role_name> SET search_path = ....

Configurar a capacidade do Microsoft Foundry

A capacidade do Microsoft Foundry afeta diretamente a confiabilidade da conversão, especialmente para esquemas do Oracle grandes ou complexos. Provisione tokens suficientes por minuto (TPM) e monitore o uso para que as conversões se concluam sem interrupção.

Provisionar tokens suficientes por minuto

• Configure sua implantação do Microsoft Foundry com uma cota de pelo menos 500.000 tokens por minuto (TPM) para um desempenho ideal. Objetos de esquema complexos consomem capacidade de token significativa durante a conversão.
• Monitore o consumo no portal do Microsoft Foundry e aumente o limite se você observar limitação durante uma execução de conversão.

Executar um projeto de cada vez

Execute um único projeto de conversão de esquema de cada vez. Projetos simultâneos competem pela mesma cota do Microsoft Foundry e podem causar limitação, conversões parciais e custos de token inesperados. Processe projetos sequencialmente para manter o comportamento previsível e mais fácil de depurar.

Proteger o fluxo de trabalho de conversão

A ferramenta de conversão é executada localmente em Visual Studio Code e se conecta a três pontos de extremidade: a implantação do Microsoft Foundry, o banco de dados Oracle de origem e o servidor flexível Banco de Dados do Azure para PostgreSQL de destino. Antes de iniciar uma conversão, confirme se o Visual Studio Code consegue acessar os três endpoints a partir da sua estação de trabalho e, em seguida, aplique os controles de segurança corporativos padrão a cada conexão.

Confirmar a conectividade de rede do Visual Studio Code

Verifique se a estação de trabalho na qual o Visual Studio Code está em execução consegue acessar o endpoint do Microsoft Foundry, o banco de dados de origem Oracle e o servidor flexível do Banco de Dados do Azure para PostgreSQL. Se qualquer conexão for bloqueada por um firewall corporativo, VPN ou grupo de segurança de rede, trabalhe com sua equipe de rede para permitir o acesso de saída antes de iniciar uma conversão.

Usar pontos de extremidade privados ou regras de firewall para o destino

Restrinja o acesso à rede ao servidor flexível Banco de Dados do Azure para PostgreSQL. Use pontos de extremidade privados para estações de trabalho integradas à VNet ou configure regras de firewall que só permitem os intervalos de IP usados pela equipe.

Autenticação usando Microsoft Entra ID

Conecte-se ao servidor flexível do Banco de Dados do Azure para PostgreSQL com a autenticação do Microsoft Entra em vez da autenticação por senha. Microsoft Entra autenticação centraliza o controle de acesso, dá suporte a políticas de acesso condicional e produz eventos de entrada auditáveis.

Gerenciar credenciais com segurança

Não insira credenciais Oracle ou PostgreSQL em texto sem formatação e não as confirme no controle do código-fonte. Armazene-os no Azure Key Vault ou no gerenciador de segredos da sua organização e referencie-os na configuração de conexão da ferramenta de conversão em Visual Studio Code no momento da conexão.

Validar o esquema convertido

A conversão automatizada acelera a migração, mas a validação manual é essencial para detectar diferenças semânticas, comportamentos específicos da plataforma e casos de borda que a IA ou as ferramentas podem perder. O relatório de conversão de esquema sinaliza objetos que a ferramenta extraiu, mas não conseguiu converter totalmente como tarefas de revisão. Trabalhe nessas tarefas primeiro e identifique objetos complexos que foram convertidos de maneira limpa.

Para obter detalhes sobre os artefatos que a ferramenta produz e a ordem de revisão recomendada, consulte os relatórios de conversão de esquema do Oracle para Banco de Dados do Azure para PostgreSQL servidor flexível.

Validar objetos de código complexos

Valide manualmente os seguintes objetos de código Oracle complexos após a conversão:

• Procedimentos armazenados: examine a lógica do procedimento convertido, o tratamento de parâmetros e o gerenciamento de exceções.
• Pacotes: validar a estrutura do pacote e a resolução de dependência em relação aos esquemas do PostgreSQL.
• Funções: verificar tipos de retorno, mapeamentos de parâmetro e precisão da lógica de negócios.

Fluxo de trabalho de validação

1. Resolva todas as tarefas de revisão no relatório de conversão do esquema, opcionalmente com a ajuda do modo de agente do GitHub Copilot.
2. Examine cada objeto complexo convertido pela IA, mesmo quando nenhuma tarefa de revisão foi criada.
3. Execute procedimentos e funções convertidos no banco de dados temporário com dados de teste representativos.
4. Confirme se a lógica de negócios e os conjuntos de resultados correspondem à origem Oracle antes de promover o esquema para o ambiente de produção.

Executar novamente e iterar

Uma execução de conversão é repetível. Execute novamente a conversão sempre que as entradas forem alteradas para que o relatório e o DDL gerado reflitam o estado atual.

Quando executar novamente uma conversão

Execute a conversão novamente quando:

• Ajuste o banco de dados temporário de destino. Por exemplo, você permite listar uma extensão ausente, instalar uma nova extensão ou corrigir search_path.
• Ajuste o lado da origem no Oracle. Por exemplo, você coloca um esquema adicional no escopo, descarta um objeto de problema ou corrige a corrupção de metadados em um objeto de origem.
• Ajustar a capacidade do Microsoft Foundry. Por exemplo, você aumentará a cota do TPM depois de observar a limitação na execução anterior.

Compare o novo relatório de conversão com o anterior para confirmar que a alteração teve o efeito pretendido e detectar quaisquer efeitos colaterais não intencionais em objetos que não fazem parte da alteração.

Reter artefatos de conversão

Salve a pasta DDL do PostgreSQL gerada juntamente com todos os relatórios produzidos pela ferramenta de conversão como o artefato de auditoria para o projeto de migração. Esses artefatos são úteis para:

• Revisões de conformidade e auditoria.
• Comparações de diferenças com reconversões futuras.
• Transferência de conhecimento para operações ou equipes de aplicativos.

Armazene os artefatos no sistema de gerenciamento de documentos ou controle do código-fonte da sua equipe.

Conteúdo relacionado

• O que é o Oracle para Banco de Dados do Azure para PostgreSQL conversão de esquema de servidor flexível?
• Tutorial: Oracle para Banco de Dados do Azure para PostgreSQL conversão de esquema de servidor flexível
• Examinar tarefas e pastas de saída do Oracle para Banco de Dados do Azure para PostgreSQL conversão de esquema de servidor flexível
• Oracle para Banco de Dados do Azure para PostgreSQL limitações de conversão de esquema de servidor flexível