Implantar esquemas convertidos com a Setup Experience

O Schema Conversion Setup Experience gera automaticamente instruções e scripts conforme o fluxo de trabalho de conversão é concluído. Use estes arquivos para implantar esquemas convertidos em Banco de Dados do Azure para PostgreSQL. A geração dos arquivos não implanta os esquemas no destino. Examine-os e execute o script gerado do PowerShell ou do Bash em seu ambiente de implantação.

Para obter instruções sobre como abrir os arquivos de instalação de uma conversão concluída, consulte Preparar a implantação com a Experiência de Instalação no tutorial.

Examinar os arquivos gerados

O diretório de instalação depende de quantos esquemas Oracle você selecionar para conversão. Use o caminho aplicável em relação à raiz do espaço de trabalho:

Seleção de esquema do Oracle Diretório de instalação
Um schema selecionado .github\postgres-migrations\<migration-project>\artifacts\oracle\<schema-name>\setup
Vários schemas selecionados .github\postgres-migrations\<migration-project>\artifacts\oracle\_migration\setup

Substitua <migration-project> pelo nome da pasta do projeto de migração, como Mig001. Se você selecionar um esquema, substitua <schema-name> pelo nome da pasta de esquema Oracle selecionada, como HR. Se você selecionar vários schemas, _migration representa o nome real da pasta, não um espaço reservado.

O local reflete os esquemas Oracle selecionados, não o número de esquemas PostgreSQL incluídos no pacote. Examine setup_instructions.md o escopo de implantação do pacote.

Arquivo ou diretório Purpose
setup_instructions.md Pré-requisitos específicos de implantação, comandos, parâmetros opcionais e diretrizes de solução de problemas.
setup.ps1 Executor de implantação para Windows PowerShell.
setup.sh Executor de implantação para Bash no Linux ou macOS.
sql Suporte a verificações de preparação, scripts de extensão, consultas de verificação e manifestos usados pelos executores.
reports e logs Saídas gravadas quando você executa os scripts de instalação.

Mantenha o diretório de configuração dentro do projeto de migração completo. Os runners fazem referência à sessão de conversão deploy.sql no diretório irmão convert; copiar apenas o diretório de instalação não é suficiente.

Revise as instruções geradas e o SQL de implantação antes de executá-los. Confirme se o SQL inclui as correções de objeto que você pretende implantar. Se você transferir o projeto para outro ambiente, preserve a estrutura de diretórios e siga os requisitos de tratamento de dados da sua organização. Remova credenciais e outros segredos dos arquivos que você compartilha.

Preparar o destino

Use os requisitos no seu setup_instructions.md gerado, em vez de copiar os requisitos de outra conversão:

  • Versões de servidor e cliente. Prepare um Servidor Flexível do Banco de Dados do Azure para PostgreSQL com a versão necessária do PostgreSQL. A versão principal do cliente psql deve coincidir com a versão principal do servidor de conversão registrada no pacote de instalação gerado. Instale esse cliente no computador em que a instalação é executada e disponibilize-o em PATH. A instalação pode criar um banco de dados no servidor, mas não provisiona o servidor Azure.
  • Shell e acesso a arquivos. Use o PowerShell 5.1 ou posterior no Windows ou Bash no Linux ou macOS. O executor precisa de acesso de escrita aos diretórios reports e logs.
  • O acesso à rede. Permita que o computador de configuração se conecte ao servidor de destino do Banco de Dados do Azure para PostgreSQL e à porta do PostgreSQL.
  • Extensões. Examine as extensões necessárias e adicione extensões com suporte à lista de permissões do servidor de destino Banco de Dados do Azure para PostgreSQL antes da implantação. Consulte Permitir extensões no Banco de Dados do Azure para PostgreSQL.
  • Permissões. Use uma conta com as permissões no banco de dados, no esquema, de criação de objetos e de instalação de extensões especificadas nas instruções geradas. O modo de novo banco de dados também requer permissão para criar o banco de dados.
  • Autenticação. Use o prompt oculto de senha do script, um arquivo de senhas do PostgreSQL ou o processo de gerenciamento de segredos aprovado pela sua organização. Não insira senhas em scripts de implantação.

Confirme se o cliente está disponível:

psql --version

As instruções geradas refletem o ambiente de conversão, incluindo seus requisitos de versão e extensão do PostgreSQL. Examine as diferenças no destino antes da implantação.

Escolher um modo de banco de dados

Ambos os executores dão suporte a esses modos:

Mode Behavior
Novo banco de dados O modo padrão. Cria um banco de dados no servidor de destino Banco de Dados do Azure para PostgreSQL quando você implanta. O nome do banco de dados solicitado ainda não deve existir.
Banco de dados existente Usa o banco de dados especificado. Se os esquemas de destino contiverem objetos, a instalação exigirá uma confirmação explícita antes de continuar.

Para uma execução interativa, o script solicita os valores de host, usuário e banco de dados que estiverem faltando. Examine o destino exibido, o modo de banco de dados, os esquemas e a operação antes de confirmar.

Verificar a preparação sem implantar

Abra um terminal no diretório de instalação gerado. Escolha o comando para o seu sistema operacional e o modo de banco de dados pretendido:

Modo de banco de dados Windows PowerShell Linux ou macOS
Novo banco de dados .\setup.ps1 -ValidateOnly bash setup.sh --validate-only
Banco de dados existente .\setup.ps1 -DatabaseMode existing -ValidateOnly bash setup.sh --database-mode existing --validate-only

O modo somente validação se conecta ao servidor e grava relatórios e logs locais. Não cria o banco de dados de destino, instala extensões ou implanta objetos convertidos.

As verificações de preparação abrangem conectividade, versão do PostgreSQL, codificação de banco de dados e configurações de localidade, permissões, ocupação de esquema de destino e disponibilidade de extensão. Examine os avisos, bem como as falhas de bloqueio.

No modo de novo banco de dados, a validação usa o banco de dados de manutenção porque o banco de dados de destino ainda não existe. As verificações que exigem o banco de dados de destino são marcadas como ignoradas. Uma execução somente de validação bem-sucedida não é a confirmação de que essas verificações ignoradas foram aprovadas.

Quando a validação for concluída com êxito, examine validation_report_<timestamp>.md no reports diretório. Resolva problemas relatados antes da implantação. Se a validação for interrompida antecipadamente, verifique primeiro a saída do console e, em seguida, qualquer log ou relatório que tenha sido criado.

Implantar os esquemas convertidos

Use o mesmo destino e modo de banco de dados que você verificou. No diretório de configuração, execute o comando apropriado sem -ValidateOnly (PowerShell) ou --validate-only (Bash):

Modo de base de dados Windows PowerShell Linux ou macOS
Novo banco de dados .\setup.ps1 bash setup.sh
Banco de dados existente .\setup.ps1 -DatabaseMode existing bash setup.sh --database-mode existing

O executor prepara o banco de dados, verifica a preparação, instala as extensões necessárias com suporte, executa o SQL de implantação convertida e verifica os objetos e extensões resultantes.

Examine o SQL de implantação antes de aprovar um destino não vazio porque ele pode alterar objetos existentes.

Important

Ambos os modos de banco de dados podem deixar as alterações para trás após uma falha. No modo de novo banco de dados, a instalação cria o banco de dados antes das verificações de preparação de destino, de modo que uma verificação com falha pode deixar esse banco de dados em vigor. O SQL de implantação pode também aplicar alterações em transações separadas. Verifique o estado de destino antes de tentar novamente; não suponha que uma implantação com falha reverteu as alterações anteriores.

Use setup_instructions.md para parâmetros opcionais de porta, TLS, localidade e automação. Para uma execução não interativa, forneça os detalhes do host, do usuário, do banco de dados e da autenticação com antecedência. Um destino existente não vazio também requer confirmação explícita por meio de -AllowNonEmptyExisting no Windows ou de --allow-nonempty-existing no Linux ou macOS.

Revisar os resultados da publicação

Leia os resultados da implantação antes de continuar com a validação de dados ou aplicativo. Um status de conversão sozinho não confirma a implantação para esse destino.

Diretório Saída O que revisar
reports deployment_report_<timestamp>.md Totais de implantados e não implantados, resultados da extensão, resultados por tipo de objeto e motivos pelos quais os objetos não foram implantados.
reports verification_<timestamp>.csv Resultados detalhados de verificação de objeto.
reports extensions_<timestamp>.csv Resultados detalhados da extensão.
reports preflight_<timestamp>.csv Resultados da verificação de prontidão.
logs setup_<timestamp>.log Mensagens de execução e erros.

As execuções somente de validação geram um relatório de validação em vez de um relatório de implantação. Uma falha inicial, como um problema de acesso a arquivos ou de versão do shell, pode deixar apenas a saída do console.

Use o código de saída do executor junto com estas saídas:

Código de saída Meaning
0 A operação solicitada foi bem-sucedida. No modo somente validação, a validação de prontidão foi bem-sucedida sem implantação.
1 Erro de entrada, de cliente ou de cancelamento pelo usuário.
2 Falha no pacote de instalação/configuração, na conexão, no banco de dados, na verificação de prontidão ou na instalação de extensão.
3 Implantação, verificação, geração de relatórios ou erro inesperado do executor.
4 A verificação identificou objetos ou extensões que não foram implantados.

Continue a automação somente para o código de saída 0. Para qualquer outro código, examine as saídas disponíveis e resolva os problemas relatados antes de prosseguir.

Validar o esquema implementado

Uma configuração bem-sucedida não garante equivalência comportamental em relação ao Oracle nem prontidão para produção. Teste independentemente o tratamento de dados, as dependências, a lógica de negócios e o comportamento do aplicativo no ambiente de destino.

Examine todos os objetos ou extensões que não foram implantados e conclua sua correção. Aplique uma configuração de segurança gerenciada separadamente e revogue os privilégios temporários de configuração quando não forem mais necessários.

Conteúdo relacionado

  • Última atualização em