Prácticas recomendadas para la conversión de esquemas de Oracle a Azure Database for PostgreSQL (servidor flexible)

En este artículo se proporcionan prácticas recomendadas y recomendaciones para la característica de conversión de esquemas de Oracle a Azure Database for PostgreSQL en Visual Studio Code con Microsoft Foundry. Siga estas instrucciones para obtener resultados confiables y de alta calidad.

Planear la conversión del esquema

Una conversión correcta comienza con el planeamiento. Decida qué convertir, cómo iterar y con qué destino de Azure Database for PostgreSQL se alinea antes de ejecutar la herramienta.

Ámbito de los esquemas de origen

Especifique qué esquemas de aplicación de Oracle desea convertir. El flujo de trabajo de extracción excluye automáticamente el sistema oracle y los esquemas integrados, como SYS, SYSTEM, XDB, MDSYS, CTXSYSy WMSYS.

Alineación de la versión principal de PostgreSQL de destino

Use la misma versión principal de PostgreSQL en la base de datos temporal que en el destino de producción, el servidor flexible de Azure Database for PostgreSQL. La herramienta de conversión emite DDL que tiene como destino una versión principal específica de PostgreSQL. La conversión desde una versión principal y la implementación en otra pueden poner de manifiesto diferencias sintácticas o de funcionalidades durante el proceso de implementación.

Buscar objetos no compatibles con antelación

Revise Oracle para Azure Database for PostgreSQL limitaciones de conversión de esquemas de servidor flexibles antes de empezar. Para cada objeto no admitido, decida con antelación si desea volver a crear la funcionalidad de forma nativa en PostgreSQL, replatarla a un servicio de Azure adecuado o quitarla del ámbito de migración.

Planear la corrección de objetos no admitidos

Para cada objeto no admitido identificado en el paso anterior, registre la opción de corrección elegida antes de ejecutar la conversión. Seguimiento:

• Nombre y tipo del objeto de Oracle.
• La vía elegida: recrear, cambiar de plataforma o descartar.
• El servicio de Azure de destino o el patrón de PostgreSQL, si va a cambiar de plataforma.

Elija dónde ejecutar la conversión.

En el caso de esquemas pequeños, puede ejecutar la conversión desde la estación de trabajo local. Para esquemas más grandes, ejecute Visual Studio Code y la herramienta de conversión de esquemas en una máquina virtual Azure en su lugar.

Una conversión grande se ejecuta durante mucho tiempo y realiza llamadas sostenidas a su origen de Oracle, la base de datos temporal y Microsoft Foundry. La ejecución desde una máquina virtual Azure proporciona lo siguiente:

• Proximidad de red: la máquina virtual se encuentra en la misma región de Azure que el servidor flexible Azure Database for PostgreSQL y el recurso de Microsoft Foundry, lo que reduce la latencia de ida y vuelta en las muchas llamadas que realiza una conversión.
• Sesiones estables y de larga duración: la conversión no se interrumpe por suspensión de estación de trabajo, reinicios, caídas de VPN o tiempos de espera de red corporativos.
• Conectividad privada: puede colocar la máquina virtual en la misma red virtual que el servidor de destino y Microsoft punto de conexión privado de Foundry, por lo que el tráfico no atraviesa la red pública de Internet.
• Recursos predecibles: puede ajustar el tamaño de la CPU, la memoria y el disco para la carga de trabajo de conversión y mantener los artefactos en un disco administrado del que se realiza una copia de seguridad.

Coloque la máquina virtual en la región que hospeda la base de datos temporal y asígnele acceso de red a la base de datos de Oracle de origen. Si usa el modo de cliente grueso, instale Oracle Instant Client en la máquina virtual. Para obtener más información, consulte Modos de conectividad de Oracle.

Preparación del entorno de Oracle de origen

Antes de ejecutar una conversión, prepare el entorno de Oracle de origen. Conceda a la herramienta de conversión los privilegios que necesita para leer los metadatos del esquema y compruebe que la capacidad de sesión simultánea es suficiente para que la herramienta pueda extraer un esquema completo y preciso.

Privilegios de Oracle necesarios

El usuario de conexión de Oracle que usa la herramienta de conversión necesita acceso de lectura al catálogo de metadatos de Oracle. La herramienta lee los metadatos del esquema de las vistas de catálogo de DBA_*.

Otorgue o bien SELECT_CATALOG_ROLE o SELECT ANY DICTIONARY para que el usuario pueda leer las vistas DBA_* requeridas. Use el acceso con privilegios mínimos según la directiva de la organización. El usuario no necesita privilegios en ninguna tabla de aplicación ni leer datos de nivel de fila. La herramienta nunca consulta los datos de la aplicación; solo lee los metadatos del esquema.

Establezca el parámetro de sesiones de Oracle

Asegúrese de que el parámetro Oracle sessions sea mayor que 10 para que la herramienta pueda abrir suficientes lecturas simultáneas de metadatos. Compruebe el valor actual con:

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

Preparación de la base de datos temporal

La herramienta de conversión de esquemas usa una base de datos auxiliar en un servidor flexible de Azure Database for PostgreSQL para validar los objetos convertidos. Aprovisione y configure el servidor antes de iniciar una conversión para que el comportamiento de validación coincida con el destino de producción final.

Privilegios de PostgreSQL necesarios

El usuario de conexión de PostgreSQL que la herramienta de conversión usa necesita privilegios para crear y validar objetos en la base de datos temporal:

• La pertenencia al rol azure_pg_admin, que se requiere para crear las extensiones de las que depende la herramienta.
• Privilegios CREATE y USAGE en el esquema temporal, por lo que la herramienta puede crear objetos convertidos para la validación.
• Privilegio CONNECT en la base de datos de pruebas.

Elija un tamaño adecuado para la base de datos temporal

La base de datos de pruebas solo valida DDL; no hospeda la carga de trabajo de la aplicación. Use un nivel de proceso que proporcione capacidad de conexión estable para la actividad de conversión y validación. Dimensione la base de datos temporal de forma independiente del destino de producción y reduzca su tamaño una vez completada la conversión.

Lista de permitidos e instalación de extensiones necesarias

La herramienta de conversión de esquemas depende de varias extensiones de PostgreSQL. Estas extensiones traducen paquetes integrados de Oracle, tipos espaciales, particiones y búsqueda de texto completo. También habilitan la observabilidad en la base de datos temporal. Allowlist e instale las extensiones que necesita el esquema convertido antes de la primera ejecución de conversión.

En la tabla siguiente se enumeran las extensiones más utilizadas para las conversiones de Oracle a Azure Database for PostgreSQL. Incluya los que se aplican al esquema de origen y agregue cualquier otro que requiera la carga de trabajo.

La herramienta crea plpgsql_check automáticamente en la base de datos temporal cuando la extensión está en la lista de permitidos. Allowlist it before your first run so converted routines get full body validation. Si la extensión no está disponible, la conversión sigue funcionando correctamente, pero la validación adicional se omite silenciosamente. plpgsql_check solo se requiere en la base de datos temporal. El esquema convertido no depende de él en tiempo de ejecución.

Agregue dblink solo cuando el esquema de origen use PRAGMA AUTONOMOUS_TRANSACTION. En ese caso, el código convertido necesita dblink en el servidor de destino, no solo la base de datos temporal.

Paso 1: Lista de permitidos de las extensiones

En el portal de Azure, abra el servidor flexible de Azure Database for PostgreSQL que aloja la base de datos de prueba. Seleccione Parámetros del servidor, busque azure.extensionsy seleccione cada extensión de la lista. Guarde los cambios. Las extensiones como pg_partman, pg_stat_statementsy plpgsql_check también requieren entradas en shared_preload_libraries. Estas entradas necesitan un reinicio del servidor. Para obtener más información, consulte Uso de extensiones de PostgreSQL.

Paso 2: Instalar las extensiones en la base de datos temporal

Conéctese a la base de datos auxiliar como miembro del rol azure_pg_admin y cree cada extensión:

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;

Paso 3: Configuración de search_path para la compatibilidad de Oracle

orafce instala paquetes compatibles con Oracle en esquemas dedicados (oracle, dbms_*, plv*, utl_file). Establezca search_path en el nivel de base de datos para que esos esquemas, junto con los esquemas PostGIS (topology, tiger) estén disponibles para cada conexión. Una configuración de nivel de base de datos también abarca objetos que no pueden calificar una referencia a sí mismos, como vistas, CHECK restricciones, valores predeterminados de columna y columnas generadas.

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;

Incluya solo los esquemas de las extensiones que instaló. Vuelva a conectarse después de ejecutar esta instrucción, ya que el nuevo valor se aplica a las sesiones que se inician después del cambio. Para definir el ámbito de la configuración en un solo rol, use ALTER ROLE <role_name> SET search_path = ....

Configuración de la capacidad de Microsoft Foundry

La capacidad de Microsoft Foundry afecta directamente a la fiabilidad de la conversión, especialmente en el caso de esquemas grandes o complejos de Oracle. Aprovisione tokens suficientes por minuto (TPM) y supervise el uso, por lo que las conversiones se completan sin interrupciones.

Aprovisionar tokens suficientes por minuto

• Configure la implementación de Microsoft Foundry con una cuota de al menos 500 000 tokens por minuto (TPM) para obtener un rendimiento óptimo. Los objetos de esquema complejos consumen una capacidad significativa del token durante la conversión.
• Supervise el consumo desde el portal de Microsoft Foundry y aumente el límite si observa limitación de velocidad durante una ejecución de conversión.

Ejecución de un proyecto a la vez

Ejecute un solo proyecto de conversión de esquema a la vez. Los proyectos simultáneos compiten por la misma cuota de Microsoft Foundry y pueden provocar limitaciones, conversiones parciales y costos de token inesperados. Procese los proyectos secuencialmente para mantener el comportamiento predecible y más fácil de depurar.

Protección del flujo de trabajo de conversión

La herramienta de conversión se ejecuta localmente en Visual Studio Code y se conecta a tres puntos de conexión: la implementación de Microsoft Foundry, la base de datos de Oracle de origen y el servidor flexible de destino Azure Database for PostgreSQL. Antes de iniciar una conversión, confirme que Visual Studio Code puede llegar a los tres puntos de conexión de la estación de trabajo y, a continuación, aplique controles de seguridad empresariales estándar a cada conexión.

Confirmación de la conectividad de red desde Visual Studio Code

Compruebe que la estación de trabajo que ejecuta Visual Studio Code pueda llegar al punto de conexión de Microsoft Foundry, a la base de datos de origen de Oracle y al servidor flexible de Azure Database for PostgreSQL. Si un grupo de seguridad de red, VPN o firewall corporativo bloquea alguna conexión, trabaje con el equipo de red para permitir el acceso saliente antes de iniciar una conversión.

Uso de puntos de conexión privados o reglas de firewall para el destino

Restrinja el acceso de red al servidor flexible Azure Database for PostgreSQL. Use puntos de conexión privados para estaciones de trabajo integradas con red virtual o configure reglas de firewall que permitan solo los intervalos IP que usa el equipo.

Uso de la autenticación de Microsoft Entra ID

Conéctese a Azure Database for PostgreSQL - Servidor flexible con autenticación de Microsoft Entra en lugar de usar la autenticación mediante contraseña. Microsoft Entra autenticación centraliza el control de acceso, admite directivas de acceso condicional y genera eventos de inicio de sesión auditables.

Administración de credenciales de forma segura

No inserte credenciales de Oracle ni PostgreSQL en texto sin formato y no las confirme en el control de código fuente. Guárdelos en Azure Key Vault o en el administrador de secretos de su organización, y haga referencia a ellos desde la configuración de conexión de la herramienta de conversión en Visual Studio Code al conectarse.

Validación del esquema convertido

La conversión automatizada acelera la migración, pero la validación manual es esencial para detectar diferencias semánticas, comportamientos específicos de la plataforma y casos perimetrales que la inteligencia artificial o las herramientas podrían perder. El informe de conversión de esquema marca los objetos que extrajo la herramienta, pero no pudo convertir completamente como tareas de revisión. Realice primero estas tareas y haga una comprobación puntual de los objetos complejos que se convirtieron correctamente.

Para obtener más información sobre los artefactos que genera la herramienta y el orden de revisión recomendado, consulte Informes de conversión de esquemas para Oracle a Azure Database for PostgreSQL servidor flexible.

Validar objetos de código complejos

Valide manualmente los siguientes objetos de código complejos de Oracle después de la conversión:

• Procedimientos almacenados: revise la lógica del procedimiento convertido, el control de parámetros y la administración de excepciones.
• Paquetes: valide la estructura de paquetes y la resolución de dependencias en los esquemas de PostgreSQL.
• Funciones: compruebe los tipos de valor devuelto, las asignaciones de parámetros y la precisión de la lógica de negocios.

Flujo de trabajo de validación

1. Resuelva todas las tareas de revisión en el informe de conversión de esquemas, opcionalmente con la ayuda del modo agente de GitHub Copilot.
2. Revise todos los objetos complejos convertidos por IA, incluso cuando no se creó ninguna tarea de revisión.
3. Ejecute procedimientos convertidos y funciones en la base de datos temporal con datos de prueba representativos.
4. Confirme que la lógica de negocios y los conjuntos de resultados coinciden con el origen de Oracle antes de promover el esquema a producción.

Volver a ejecutar e iterar

Se puede repetir una ejecución de conversión. Vuelva a ejecutar la conversión cada vez que cambien las entradas para que el informe y el DDL generado reflejen el estado actual.

Cuándo volver a ejecutar una conversión

Vuelva a ejecutar la conversión cuando:

• Ajustar la base de datos provisional de destino. Por ejemplo, permite incluir una extensión que falta, instalar una nueva extensión o corregir search_path.
• Ajustar el lado de origen de Oracle. Por ejemplo, puede incluir un esquema adicional en el ámbito, quitar un objeto de problema o corregir los daños en los metadatos en un objeto de origen.
• Ajustar la capacidad de Microsoft Foundry. Por ejemplo, aumentas la cuota de TPM después de observar una limitación de velocidad en la ejecución anterior.

Compara las diferencias entre el nuevo informe de conversión y el anterior para confirmar que el cambio ha tenido el efecto previsto y detectar cualquier efecto secundario no deseado en objetos que no formen parte del cambio.

Conservar artefactos de conversión

Guarde la carpeta DDL de PostgreSQL generada junto con todos los informes generados por la herramienta de conversión como artefacto de auditoría para el proyecto de migración. Estos artefactos son útiles para:

• Revisiones de cumplimiento y auditoría.
• Comparaciones de diferencias frente a reconversiones futuras.
• Transferencia de conocimiento a operaciones o equipos de aplicaciones.

Almacene los artefactos en el sistema de control de código fuente o de administración de documentos del equipo.

Contenido relacionado

• ¿Qué es Oracle para Azure Database for PostgreSQL conversión de esquema de servidor flexible?
• Tutorial: Conversión de esquemas de servidor flexible de Oracle para Azure Database for PostgreSQL
• Revisión de tareas y carpetas de salida para que Oracle Azure Database for PostgreSQL conversión de esquema de servidor flexible
• Limitaciones de conversión de esquemas de servidor flexibles de Oracle para Azure Database for PostgreSQL