Implemente esquemas convertidos con la Experiencia de configuración

La experiencia de configuración de conversión de esquema genera automáticamente instrucciones y scripts a medida que finaliza el flujo de trabajo de conversión. Utilice estos archivos para implementar esquemas convertidos en Azure Database for PostgreSQL. La generación de los archivos no implica la implementación de los esquemas en el destino. Revíselos y ejecute el script de PowerShell o Bash generado en su entorno de implementación.

Para obtener instrucciones sobre cómo abrir los archivos de configuración tras una conversión completada, consulte Preparar la implementación con la Experiencia de configuración en el tutorial.

Revise los archivos generados

El directorio de instalación depende del número de esquemas de Oracle que seleccione para la conversión. Use la ruta de acceso aplicable relativa a la raíz del área de trabajo:

Selección del esquema de Oracle Directorio de instalación
Un esquema seleccionado .github\postgres-migrations\<migration-project>\artifacts\oracle\<schema-name>\setup
Varios esquemas seleccionados .github\postgres-migrations\<migration-project>\artifacts\oracle\_migration\setup

Reemplace <migration-project> por el nombre de la carpeta del proyecto de migración, como Mig001. Si selecciona un esquema, reemplace <schema-name> por el nombre de carpeta del esquema de Oracle seleccionado, como HR. Si selecciona varios esquemas, _migration es el nombre de carpeta real, no un marcador de posición.

La ubicación refleja los esquemas de Oracle seleccionados, no el número de esquemas de PostgreSQL incluidos en el paquete. Consulte setup_instructions.md para conocer el ámbito de implementación del paquete.

Archivo o directorio Purpose
setup_instructions.md Requisitos previos específicos de la implementación, comandos, parámetros opcionales y orientación para la resolución de problemas.
setup.ps1 Ejecutor de implementación para Windows PowerShell.
setup.sh Ejecutor de implementación para Bash en Linux o macOS.
sql Comprobaciones de preparación, scripts de extensión, consultas de verificación y manifiestos de apoyo utilizados por los ejecutores.
reports y logs Salidas escritas al ejecutar los scripts de instalación.

Mantenga el directorio de instalación dentro del proyecto de migración completo. Los ejecutores hacen referencia al deploy.sql de la sesión de conversión en el directorio convert del mismo nivel; no basta con copiar únicamente el directorio de configuración.

Revisa las instrucciones generadas y el código SQL de implementación antes de ejecutarlas. Confirme que SQL incluye las correcciones de objetos que quiere implementar. Si transfiere el proyecto a otro entorno, conserve su estructura de directorios y siga los requisitos de gestión de datos de la organización. Elimina las credenciales y otros secretos de los archivos que compartas.

Prepare el destino

Utilice los requisitos de su setup_instructions.md generado, en lugar de copiar los requisitos de otra conversión:

  • Versiones de servidor y cliente. Prepare un servidor flexible de Azure Database for PostgreSQL con la versión de PostgreSQL necesaria. La psql versión principal del cliente debe coincidir con la versión principal del servidor de conversión registrada en el paquete de instalación generado. Instale ese cliente en el equipo que ejecuta el programa de instalación y haga que esté disponible en PATH. El programa de instalación puede crear una base de datos en su servidor, pero no aprovisiona el servidor de Azure.
  • Shell y acceso a archivos. Use PowerShell 5.1 o posterior en Windows, o Bash en Linux o macOS. El ejecutor necesita acceso de escritura a sus directorios logs y reports.
  • Acceso a la red. Permita que el equipo de configuración se conecte al servidor de destino de Azure Database for PostgreSQL y al puerto de PostgreSQL.
  • Extensiones. Revise las extensiones necesarias y añada las extensiones compatibles a la lista de permitidos del servidor de destino de Azure Database for PostgreSQL antes de la implementación. Consulte Permitir extensiones en Azure Database for PostgreSQL.
  • Permisos. Utilice una cuenta con los permisos de base de datos, esquema, creación de objetos e instalación de extensiones especificados en las instrucciones generadas. El modo de nueva base de datos también requiere permiso para crear la base de datos.
  • Autenticación. Use la solicitud de contraseña oculta del script, un archivo de contraseña de PostgreSQL o el proceso aprobado de administración de secretos de su organización. No inserte contraseñas en scripts de despliegue.

Confirme que el cliente está disponible:

psql --version

Las instrucciones generadas reflejan el entorno de conversión, incluidos sus requisitos de extensión y versión de PostgreSQL. Revisa cualquier diferencia en el destino antes de la implementación.

Elija un modo de la base de datos

Ambos runners admiten estos modos:

Mode Behavior
Nueva base de datos Modo predeterminado. Crea una base de datos en el servidor de destino Azure Database for PostgreSQL al implementar. El nombre de la base de datos solicitado no debe existir previamente.
Base de datos existente Usa la base de datos que especifiques. Si los esquemas de destino contienen objetos, el programa de instalación requiere confirmación explícita antes de continuar.

Para una ejecución interactiva, el script solicita valores de host, usuario y base de datos que faltan. Revise el destino mostrado, el modo de base de datos, los esquemas y la operación antes de confirmar.

Comprueba la preparación sin implementar

Abra un terminal en el directorio de configuración generado. Elija el comando para su sistema operativo y el modo de base de datos previsto:

Modo de base de datos PowerShell de Windows Linux o macOS
Nueva base de datos .\setup.ps1 -ValidateOnly bash setup.sh --validate-only
Base de datos existente .\setup.ps1 -DatabaseMode existing -ValidateOnly bash setup.sh --database-mode existing --validate-only

El modo de solo validación se conecta al servidor y escribe registros e informes locales. No crea la base de datos de destino, ni instala extensiones ni implementa objetos convertidos.

Las comprobaciones de preparación cubren la conectividad, la versión de PostgreSQL, la codificación de base de datos y la configuración regional, los permisos, la ocupación del esquema de destino y la disponibilidad de la extensión. Revise las advertencias, así como los errores bloqueantes.

En el modo de nueva base de datos, la validación usa la base de datos de mantenimiento porque la base de datos de destino aún no existe. Las comprobaciones que requieren la base de datos de destino se marcan como omitidas. Una ejecución de solo validación correcta no es una confirmación de que esas comprobaciones omitidas hayan pasado.

Cuando la validación se complete correctamente, revise validation_report_<timestamp>.md en el reports directorio . Resuelva los problemas notificados antes de la implementación. Si la validación se detiene antes de tiempo, compruebe primero la salida de la consola y, a continuación, cualquier registro o informe que se haya creado.

Implemente los esquemas convertidos

Utiliza el mismo destino y modo de base de datos que has comprobado. Desde el directorio de configuración, ejecuta el comando adecuado sin -ValidateOnly (PowerShell) o --validate-only (Bash):

Modo de base de datos PowerShell de Windows Linux o macOS
Nueva base de datos .\setup.ps1 bash setup.sh
Base de datos existente .\setup.ps1 -DatabaseMode existing bash setup.sh --database-mode existing

El runner prepara la base de datos, comprueba que todo está listo, instala las extensiones admitidas necesarias, ejecuta el SQL de implementación convertido y comprueba los objetos y extensiones resultantes.

Revise el SQL de implementación antes de aprobar un destino no vacío porque puede cambiar los objetos existentes.

Important

Ambos modos de base de datos pueden dejar cambios residuales tras un error. En el modo de nueva base de datos, el programa de instalación crea la base de datos antes de las comprobaciones de preparación de destino, por lo que una comprobación con errores puede dejar esa base de datos en su lugar. Deployment SQL también puede aplicar cambios en transacciones independientes. Revise el estado de destino antes de reintentar; no suponga que un despliegue fallido haya revertido los cambios anteriores.

Se usa setup_instructions.md para los parámetros opcionales de puerto, TLS, configuración regional y automatización. Para una ejecución no interactiva, proporcione los detalles de host, usuario, base de datos y autenticación de antemano. Un destino existente no vacío también requiere confirmación explícita a través de -AllowNonEmptyExisting en Windows o --allow-nonempty-existing en Linux o macOS.

Revisa los resultados de la implementación

Lea los resultados del despliegue antes de continuar con la validación de datos o de aplicaciones. Un estado de conversión por sí solo no confirma el despliegue en este destino.

Directorio Output Qué revisar
reports deployment_report_<timestamp>.md Los totales implementados y no implementados, los resultados de la extensión, los resultados por tipo de objeto y los motivos por los que no se implementaron los objetos.
reports verification_<timestamp>.csv Resultados detallados de la verificación de objetos.
reports extensions_<timestamp>.csv Resultados detallados de la extensión.
reports preflight_<timestamp>.csv Resultados de la comprobación de preparación.
logs setup_<timestamp>.log Mensajes de ejecución y errores.

Las ejecuciones de solo validación generan un informe de validación en lugar de un informe de implementación. Un error anticipado, como un problema de acceso a archivos o de versión de shell, podría dejar solo la salida de la consola.

Utilice el código de salida del ejecutor junto con estas salidas:

Código de salida Meaning
0 La operación solicitada se realizó correctamente. En el caso de solo validación, la validación de la preparación se ha realizado correctamente sin implementación.
1 Error de entrada, del cliente o de cancelación por parte del usuario.
2 Fallo en el paquete de instalación/configuración, la conexión, la base de datos, la comprobación de preparación o la instalación de la extensión.
3 Implementación, verificación, generación de informes o error inesperado del ejecutor.
4 La comprobación identificó objetos o extensiones que no se implementaron.

Continúe con la automatización solo para el código de salida 0. Para cualquier otro código, revise las salidas disponibles y resuelva los problemas notificados antes de continuar.

Validar el esquema implementado

Una configuración correcta no garantiza la equivalencia de comportamiento con Oracle ni la preparación para la producción. Pruebe de forma independiente el control de datos, las dependencias, la lógica de negocios y el comportamiento de la aplicación en el entorno de destino.

Revise los objetos o extensiones que no se implementaron y complete su corrección. Aplique la configuración de seguridad administrada por separado y revoque privilegios de configuración temporales cuando ya no sean necesarios.

Contenido relacionado

  • Se actualizó por última vez el