Implantar esquemas convertidos na Experiência de Configuração

A Experiência de Configuração de Conversão de Esquema gera automaticamente instruções e scripts à medida que o fluxo de trabalho de conversão termina. Utilize estes ficheiros para implementar esquemas convertidos para o Base de Dados do Azure para PostgreSQL. Gerar os ficheiros não implementa os esquemas no seu destino. Revê-os e executa o script PowerShell ou Bash gerado no seu ambiente de implementação.

Para instruções sobre como abrir os ficheiros de configuração a partir de uma conversão concluída, consulte Preparar a implementação com a Experiência de Configuração no tutorial.

Revise os ficheiros gerados

O diretório de configuração depende de quantos esquemas Oracle selecionas para conversão. Utilize o caminho aplicável relativamente à raiz do espaço de trabalho:

Substitua <migration-project> pelo nome da pasta do projeto de migração, como Mig001. Se selecionar um esquema, substitua <schema-name> pelo nome da pasta de esquema Oracle selecionado, como HR. Se selecionares vários schemas, _migration é o nome real da pasta, não um marcador de posição.

A localização reflete os esquemas Oracle selecionados, não o número de esquemas PostgreSQL incluídos no pacote. Verifique setup_instructions.md o âmbito de implementação do pacote.

Mantém o diretório de configuração dentro do projeto completo de migração. Os runners referenciam o deploy.sql da sessão de conversão no diretório irmão convert; copiar apenas o diretório de configuração não é suficiente.

Revise as instruções geradas e o SQL de implementação antes de os executar. Confirma que o SQL inclui as correções de objetos que pretendes implementar. Se transferir o projeto para outro ambiente, preserve a sua estrutura de diretórios e siga os requisitos de gestão de dados da sua organização. Remova credenciais e outros segredos dos ficheiros que partilha.

Preparar o destino

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

• Versões para servidor e cliente. Prepare um servidor flexível Base de Dados do Azure para PostgreSQL com a versão exigida do PostgreSQL. A psql versão principal do cliente deve corresponder à versão principal do servidor de conversão registada no pacote de configuração gerado. Instala esse cliente no computador que executa a configuração e disponibiliza-o em PATH. O Setup pode criar uma base de dados no seu servidor, mas não provisiona o servidor Azure.
• Acesso a shell e ficheiros. Use PowerShell 5.1 ou posterior no Windows, ou Bash no Linux ou macOS. O runner precisa de acesso de escrita aos seus logs e reports diretórios.
• Acesso à rede. Permita que o computador de configuração se ligue à base de dados Base de Dados do Azure para PostgreSQL, servidor de destino e à porta PostgreSQL.
• Extensões. Revise as extensões necessárias e adicione extensões suportadas à lista de permissões do servidor de destino do Base de Dados do Azure para PostgreSQL antes da implementação. Veja Permitir extensões no Base de Dados do Azure para PostgreSQL.
• Permissões. Use uma conta com as permissões de base de dados, esquema, criação de objetos e instalação de extensão especificadas nas instruções geradas. O modo de nova base de dados também requer permissão para criar a base de dados.
• Authentication. Utilize o prompt de palavra-passe oculta do script, um ficheiro de palavra-passe PostgreSQL ou o processo de gestão de segredos aprovado pela sua organização. Não incorpores palavras-passe nos scripts de implementação.

Confirme que o cliente está disponível:

psql --version

As instruções geradas refletem o ambiente de conversão, incluindo a versão PostgreSQL e os requisitos de extensão. Revise quaisquer diferenças de destino antes da implementação.

Escolha um modo de base de dados

Ambos os runners suportam estes modos:

Para uma execução interativa, o script solicita valores em falta de host, utilizador e base de dados. Revise o destino apresentado, o modo de base de dados, os esquemas e a operação antes de confirmar.

Verificar prontidão sem implementar

Abre um terminal no diretório de configuração gerado. Escolha o comando para o seu sistema operativo e para o modo de base de dados pretendido:

O modo apenas de validação liga-se ao servidor e escreve relatórios e registos locais. Não cria a base de dados de destino, não instala extensões nem implementa objetos convertidos.

As verificações de prontidão abrangem conectividade, versão PostgreSQL, codificação da base de dados e definições locais, permissões, ocupação do esquema alvo e disponibilidade de extensões. Revise avisos e falhas bloqueadoras.

No modo de nova base de dados, a validação utiliza a base de dados de manutenção porque a base de dados de destino ainda não existe. Verificações que exigem a base de dados de destino são marcadas como ignoradas. Uma execução bem-sucedida apenas com validação não é confirmação de que essas verificações ignoradas passaram.

Quando a validação for concluída com sucesso, revise validation_report_<timestamp>.md no reports diretório. Resolver os problemas reportados antes da implementação. Se a validação parar cedo, verifique primeiro a saída da consola, depois qualquer log ou relatório que tenha sido criado.

Implementar os esquemas convertidos

Usa o mesmo destino e modo de base de dados que verificaste. A partir do diretório de configuração, execute o comando apropriado sem -ValidateOnly (PowerShell) ou --validate-only (Bash):

O runner prepara a base de dados, verifica a prontidão, instala as extensões suportadas necessárias, executa o SQL de implementação convertido e verifica os objetos e extensões resultantes.

Revê o SQL de implementação antes de aprovar um destino não vazio porque pode alterar objetos existentes.

Use setup_instructions.md para portas, TLS, localização e parâmetros de automação opcionais. Para uma execução não interativa, forneça previamente os detalhes do host, utilizador, base de dados e autenticação. Um destino existente não vazio também requer reconhecimento explícito através de -AllowNonEmptyExisting no Windows ou de --allow-nonempty-existing no Linux ou macOS.

Analisar os resultados da implantação

Leia os resultados da implementação antes de continuar para a validação de dados ou aplicação. Um estado de conversão por si só não confirma a implantação para este destino.

As execuções apenas de validação produzem um relatório de validação em vez de um relatório de implementação. Uma falha precoce, como um problema de acesso a ficheiros ou de versão shell, pode deixar apenas saída de consola.

Utilize o código de saída do runner juntamente com estas saídas:

Continuar a automatização apenas para o código de saída 0. Para qualquer outro código, reveja as saídas disponíveis e resolva os problemas reportados antes de prosseguir.

Validar o esquema implementado

Uma configuração bem-sucedida não estabelece equivalência comportamental com a Oracle ou a prontidão para produção. Testar de forma independente o tratamento dos dados, dependências, lógica de negócio e comportamento da aplicação no ambiente de destino.

Revê quaisquer objetos ou extensões que não tenham sido implantados e conclua a sua correção. Aplicar uma configuração de segurança gerida separadamente e revogar privilégios temporários de configuração quando deixarem de ser necessários.

Conteúdo relacionado

• Tutorial: Converter esquemas Oracle para Base de Dados do Azure para PostgreSQL
• Revise os objetos convertidos no Conversion Object Explorer
• Consulte o relatório HTML para conversão de esquema Oracle
• Boas práticas para a conversão de esquema da Oracle para Base de Dados do Azure para PostgreSQL