Mejores prácticas para migrar de Oracle a Azure Database for PostgreSQL
SE APLICA A: 
Azure Database for PostgreSQL con servidor flexible
En los escenarios siguientes se describen algunos de los posibles desafíos que se han encontrado durante una migración de Oracle a Azure Postgres. Las soluciones recomendadas pueden ser útiles para superar estos desafíos al planear y ejecutar sus propias migraciones.
Escenario: se detectaron dos aplicaciones cliente independientes, de baja latencia y alto rendimiento, que funcionan de forma independiente en la misma base de datos. Cada aplicación estaba aumentando accidentalmente las consultas almacenadas en caché del otro fuera de los búferes. La carga compartida y la contención de recursos combinados crearon una situación en la que los búferes compartidos de la base de datos se vacíaban con demasiada frecuencia, lo que provocaba una degradación del rendimiento en ambos sistemas.
Solución recomendada: asegúrese de que las evaluaciones iniciales capturan TODOS los aspectos del entorno de la plataforma de base de datos, incluidos los patrones de uso y consumo de memoria de los sistemas del área global de sistemas (SGA) y las estructuras de memoria del área global del programa (PGA). Seleccione la familia de proceso adecuada que coincida con los requisitos de los recursos y asegúrese de que la capacidad planeada de Postgres se ajusta según sea necesario.
Sugerencia
La extensión pg_buffercache proporciona un medio para examinar el uso y permite observar lo que sucede en la memoria caché del búfer compartido en tiempo real.
frecuencia de aciertos de caché del búfer
Examinar las relaciones de aciertos permite evaluar la eficacia de la memoria caché y determinar si el tamaño del búfer compartido es adecuado. Una buena proporción de aciertos de caché es un signo de que la mayoría de las solicitudes de datos se sirven desde la memoria en lugar del disco, lo que proporciona un rendimiento óptimo:
SELECT COUNT(*) AS total
, SUM(CASE WHEN isdirty THEN 1 ELSE 0 END) AS dirty -- # of buffers out of sync with disk
, SUM(CASE WHEN isdirty THEN 0 ELSE 1 END) AS clean -- # of buffers in sync with data on disk
FROM pg_buffercache;
Tablas e índices a los que se accede con más frecuencia
Examinar las tablas e índices a las que se accede con más frecuencia o ocupar el espacio más en la memoria caché del búfer puede ayudar a identificar las zonas activas que se almacenan en caché en la memoria:
SELECT b.relfilenode, relname, relblocknumber
, relkind
--r = ordinary table, i = index, S = sequence, t = TOAST table
--, v = view, m = materialized view, c = composite type
--, f = foreign table, p = partitioned table, I = partitioned index
, COUNT(*) AS buffers
FROM pg_buffercache b
JOIN pg_class c ON c.oid = b.relfilenode
GROUP BY b.relfilenode, relname, relblocknumber, relkind
ORDER BY buffers DESC
LIMIT 10;
Contención de caché de búfer
La contención significativa en la memoria grupo de búferes indica que varias consultas podrían estar luchando por el mismo espacio de búfer, lo que conduce a cuellos de botella de rendimiento. Examinar la ubicación y la frecuencia de acceso al búfer puede ayudar a diagnosticar estos problemas:
SELECT c.relname, b.relblocknumber, COUNT(*) AS access_count
FROM pg_buffercache b
JOIN pg_class c ON c.relfilenode = b.relfilenode
GROUP BY c.relname, b.relblocknumber
ORDER BY access_count DESC
LIMIT 10;
Escenario: se inició un esfuerzo de migración entre las versiones y las versiones de expansión de los ciclos de versión de la plataforma Postgres. A pesar de que las nuevas características y mejoras están disponibles en la versión más reciente, la versión seleccionada al principio de la migración no ha cambiado. El esfuerzo, el tiempo y los gastos adicionales posteriores se realizaron para actualizar la versión de la base de datos de Postgres después de la migración inicial para lograr un rendimiento óptimo y nuevas funcionalidades.
Solución recomendada: siempre que sea posible, priorice la adopción de la versión más reciente de Postgres al migrar. Los equipos de desarrollo de la comunidad de Postgres trabajan increíblemente duro para exprimir cada poco de rendimiento y estabilidad en cada nueva versión, y retener básicamente se traduce en dejar el rendimiento en las líneas laterales. Además, aproveche al máximo las nuevas características de Azure. Entre las nuevas características de Azure Postgres se incluyen: almacenamiento SSDv2, la familia de servidores más reciente de infraestructura y funcionalidades automatizadas de optimización de índices y ajuste de parámetros de servidor autónomo.
Escenario: las organizaciones que migran a Postgres por primera vez pueden no estar familiarizadas con las mejores prácticas y enfoques a la hora de identificar consultas de ejecución lenta. Se debe prestar especial atención y atención al implementar correctamente nuevos tipos de índice. En particular, el motor de base de datos de Postgres está diseñado para optimizar el rendimiento de las consultas sin necesidad ni capacidad de especificar sugerencias de consulta.
Solución recomendada: las extensiones son una parte integral de lo que hace que Postgres sea tan eficaz. Hay varias extensiones que pueden proporcionar características importantes que le permiten asegurarse de que la base de datos funciona en un rendimiento máximo. Algunas extensiones clave que se deben tener en cuenta incluyen:
auto_explain: registra automáticamente los planes de ejecución de las consultas que se ejecutan más allá de un umbral establecido. Permite a los administradores de bases de datos diagnosticar problemas de rendimiento y optimizar el rendimiento de las consultas sin ejecutar manualmente EXPLAIN en cada consulta.
pg_trgm: proporciona funciones y operadores para determinar la similitud de los datos basados en texto mediante la coincidencia de trigramas. Esta extensión es útil para las tareas que implican búsqueda de texto, coincidencia aproximada y consultas basadas en similitud. Combinado con índices GIN o GIST en columnas de texto ofrece un rendimiento mejorado en consultas LIKE y búsquedas de similitud.
pg_cron: permite programar y administrar tareas periódicas directamente dentro de la base de datos. Integra la programación de trabajos similares a cron en Postgres, lo que permite la automatización de tareas de mantenimiento rutinarias, el procesamiento de datos y operaciones repetitivas similares.
Sugerencia
Si las operaciones de base de datos implican una cantidad significativa de creación y eliminación repetidas de objetos de base de datos, aumentarán las tuplas de tabla del sistema más antiguas pg_catalog, lo que conduce a la tabla "bloat". Como pg_catalog es una tabla del sistema implicada en muchas operaciones de base de datos, el mantenimiento no asignado en esta tabla puede provocar un rendimiento degradado en toda la base de datos. Se puede asegurar que pg_catalog se mantiene adecuadamente y se vacía apropiadamente configurando una programación periódica de pg_cron.
- pg_hint_plan:el objetivo de Postgres es proporcionar un rendimiento coherente y confiable sin necesidad de intervención manual, lo que da lugar a la decisión intencionada de diseño para no incluir sugerencias de consulta. En algunos escenarios en los que se necesita un control específico y preciso sobre los diseños de planes de consulta, pg_hint_plan proporciona una manera de influir en las decisiones del planificador de consultas mediante sugerencias insertadas en comentarios SQL. Estas sugerencias permiten a los administradores de bases de datos guiar al planificador de consultas en la elección de planes específicos para optimizar consultas complejas o resolver problemas de rendimiento que el planificador no pueda resolver por sí mismo.
Nota:
Estos ejemplos son simplemente rascar la superficie del amplio conjunto de extensiones disponibles para la base de datos Postgres. Le recomendamos que explore completamente estas extensiones para sobrecargar la base de datos de Postgres. Además, puede considerar la posibilidad de crear sus propias extensiones en las que vea el potencial de expandir Postgres más allá de sus funcionalidades actuales. La arquitectura de extensión eficazmente flexible garantiza que Postgres siempre podrá adaptarse y evolucionar con sus requisitos de plataforma.
Escenario: en algunos casos, las estrategias de partición de tabla heredadas han dado lugar a la creación de miles de particiones. Aunque esto puede haber sido efectivo cuando se usó anteriormente, estas estrategias pueden ralentizar el rendimiento de las consultas en Postgres en determinadas circunstancias. En instancias muy específicas, es posible que el planificador de consultas no pueda determinar la clave de partición adecuada al analizar la consulta. El comportamiento resultante genera tiempo de planeación extendido y hace que la planificación de consultas tarde más tiempo que la ejecución real de la consulta.
Solución recomendada: vuelva a evaluar la necesidad de estrategias de creación de particiones que generen un número excesivo de particiones. Es posible que el motor de base de datos de Postgres ya no requiera la misma segmentación de datos y reducir el número de particiones puede mejorar probablemente el rendimiento. Si se evalúa un esquema de partición heredado y se determina que es necesario, considere la posibilidad de reestructurar la consulta en operaciones discretas para identificar y extraer claves de partición dinámicas y, después, usar las claves de partición en las operaciones de consulta.
Escenario: en ocasiones, las dependencias externas y las circunstancias ambientales pueden requerir escenarios de base de datos híbridas en los que las bases de datos de Oracle y Azure Postgres deben coexistir. Por ejemplo, puede haber ocasiones en las que es necesario realizar migraciones por fases para acceder a los datos de Oracle y consultarlos directamente desde Azure Postgres sin la sobrecarga de importar datos o modificar procesos ETL complejos. En otras instancias, realizar la validación de datos paralelos comparando conjuntos de datos equivalentes en entornos de Oracle y Azure Postgres simultáneamente pueden ayudar a garantizar la coherencia e integridad de los datos durante y/o después de la migración.
Solución recomendada: Las extensiones de contenedor de datos externos (FDW) de PostgreSQL son una característica clave de Postgres que le permite acceder a los datos almacenados y manipularlos en sistemas externos como si esos datos residan en la base de datos de Azure Postgres de forma nativa. Los FDW habilitan que Azure Postgres funcione como una base de datos federada, lo que permite la integración con cualquier número de orígenes de datos externos, incluidas las bases de datos de Oracle. Los FDW crean definiciones de tabla externa dentro de la base de datos de Postgres y estas tablas externas actúan como proxy para el origen de datos externos definido, lo que permite a los usuarios consultar estas tablas externas mediante consultas SQL normales. Internamente, el motor de Postgres usa la definición de FDW externa para comunicarse con los datos a petición y coordinarlos desde el origen de datos remoto.
oracle_fdw: (Contenedor de datos externos para Oracle) es una extensión de Postgres que permite acceder a las bases de datos de Oracle desde Azure Postgres. Al migrar de Oracle a Azure Postgres, oracle_fdw puede desempeñar un papel fundamental al proporcionar acceso a datos, validación de datos, migración incremental y sincronización de datos en tiempo real. Es importante tener en cuenta las siguientes consideraciones clave al usar FDW:
- La ejecución de consultas a través de oracle_fdw incurrirá en sobrecarga en forma de comunicaciones de red y negociación de autenticación mientras los datos se procesan y capturan desde el servidor Oracle remoto
- Algunos tipos de datos pueden necesitar un control o conversión especiales para asegurarse de que los tipos de datos se asignan correctamente entre sistemas.
El uso eficaz de oracle_fdw puede ayudar a simplificar la transición de la base de datos y garantizar la accesibilidad de los datos al permitir que las aplicaciones y los datos permanezcan accesibles en todo el proceso de migración general.