Partager via

Meilleures pratiques pour les migrations d’Oracle vers Azure Database pour PostgreSQL

Les scénarios suivants décrivent certains des défis potentiels qui ont été rencontrés lors d’une migration d’Oracle vers Azure Postgres. Les solutions recommandées peuvent être utiles pour surmonter ces défis lors de la planification et de l’exécution de vos propres migrations.

Scénario : Deux applications clientes distinctes, à faible latence, à débit élevé, ont été découvertes comme opérant indépendamment sur la même base de données. Chaque application expulsait accidentellement hors des mémoires tampons les requêtes mises en cache de l’autre. La charge partagée et la contention de ressources combinées ont créé une situation où les mémoires tampons partagées de la base de données étaient vidées trop fréquemment, ce qui entraînait une dégradation des performances entre les deux systèmes.

Solution recommandée : Assurez-vous que vos évaluations initiales capturent tous les aspects de votre environnement de plateforme de base de données, y compris les modèles de consommation et d’utilisation des structures de mémoire SGA (Systems Global Area) et PGA (Program Global Area). Sélectionnez la famille de calcul appropriée qui correspond à vos besoins en ressources, et vérifiez que votre capacité planifiée Postgres est ajustée selon les besoins.

Conseil

L’extension pg_buffercache fournit un moyen d’examiner l’utilisation et vous permet d’observer ce qui se passe dans le cache de mémoire tampon partagée en temps réel.

Taux d'accès au cache des tampons

L’examen des ratios d’accès vous permet d’évaluer l’efficacité du cache et de déterminer si la taille de la mémoire tampon partagée est appropriée. Un bon taux d’accès au cache est un signe que la plupart des requêtes de données sont traitées à partir de la mémoire plutôt que du disque, ce qui offre des performances optimales :

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;

Tables et index les plus fréquemment sollicités

L’examen des tables et des index les plus fréquemment sollicités et/ou occupant le plus d’espace dans le cache de mémoire tampon peut aider à identifier les points d’accès mis en cache en mémoire :

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;

Contention du cache de mémoire tampon

Une contention significative dans votre cache de mémoire tampon indique que plusieurs requêtes peuvent être en conflit pour le même espace tampon, ce qui entraîne des goulots d’étranglement des performances. L’examen de l’emplacement et de la fréquence de l’accès à la mémoire tampon peut vous aider à diagnostiquer ces problèmes :

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;

Scénario : Un effort de migration a été lancé entre les mises en production des cycles de publication de la plateforme Postgres, et couvrant ces dernières. Malgré les nouvelles fonctionnalités et améliorations disponibles dans la dernière mise en production, la version sélectionnée au début de la migration est restée inchangée. Des efforts, du temps et des dépenses ultérieurs supplémentaires ont été déployés pour mettre à niveau la version de la base de données Postgres après la migration initiale afin d’obtenir des performances optimales et de nouvelles fonctionnalités.

Solution recommandée : Dans la mesure du possible, hiérarchisez l’adoption de la dernière mise en production de Postgres lors de la migration. Les équipes de développement de la communauté Postgres font tout leur possible pour intégrer un maximum de performances et de stabilité dans chaque nouvelle mise en production, et toute retenue se traduit essentiellement par une mise de côté des performances. En outre, veillez à tirer pleinement parti des nouvelles fonctionnalités Azure. Les nouvelles fonctionnalités d’Azure Postgres incluent le stockage SSDv2, la famille de serveurs la plus récente de l’infrastructure, et des fonctionnalités automatisées d’optimisation des index et de réglage des paramètres de serveur autonome.

Scénario: Les organisations qui migrent vers Postgres pour la première fois peuvent ne pas connaître les meilleures pratiques et approches lors de l’identification des requêtes lentes. Des soins et une attention particulières doivent être exercés lors de l’implémentation de nouveaux types d’index appropriés. Notamment, le moteur de base de données Postgres est conçu pour optimiser les performances des requêtes sans avoir le besoin ou la capacité à spécifier des indicateurs de requête.

Solution recommandée : Les extensions font partie intégrante de ce qui rend Postgres si puissant. Il existe plusieurs extensions qui peuvent fournir des fonctionnalités importantes vous permettant de vous assurer que votre base de données délivre des performances optimales. Voici quelques extensions clés à prendre en compte :

  • auto_explain : journalise automatiquement les plans d’exécution des requêtes qui s’exécutent au-delà d’un seuil défini. Permet aux administrateurs de base de données de diagnostiquer les problèmes de performances et d’optimiser les performances des requêtes sans exécuter manuellement EXPLAIN sur chaque requête.

  • pg_trgm : fournit des fonctions et des opérateurs pour déterminer la similarité des données textuelles par le biais de la mise en correspondance de trigrammes. Cette extension est utile pour les tâches impliquant la recherche de texte, la correspondance approximative, et les requêtes basées sur la similarité. Combinée avec des index GIN ou GIST sur des colonnes de texte, elle offre une amélioration des performances sur les requêtes LIKE et les recherches de similarité.

  • pg_cron : permet la planification et la gestion des tâches périodiques directement dans la base de données. Intègre la planification des travaux de type cron dans Postgres, ce qui permet l’automatisation des tâches de maintenance de routine, du traitement des données, et des opérations répétitives similaires.

Conseil

Si vos opérations de base de données impliquent une quantité importante de création et de suppression répétées d’objets de base de données, les tuples de table système plus anciens pg_catalog augmenteront, entraînant l’apparition de « bloats » de table. pg_catalog étant une table système impliquée dans de nombreuses opérations de base de données, la maintenance non atténuée sur cette table peut entraîner une dégradation des performances dans la base de données. Pour garantir que pg_catalog est correctement tenue à jour et vidée de manière appropriée, vous pouvez configurer une planification pg_cron périodique.

  • pg_hint_plan : Postgres vise à fournir des performances cohérentes et fiables sans intervention manuelle, d’où la décision de conception intentionnelle de ne pas inclure d’indicateurs de requête. Pour certains scénarios où un contrôle spécifique et précis des conceptions de plan de requête est nécessaire, pg_hint_plan permet d’influencer les décisions du planificateur de requêtes à l’aide d’indicateurs incorporés dans des commentaires SQL. Ces conseils permettent aux administrateurs de base de données de guider le planificateur de requêtes pour choisir des plans spécifiques afin d’optimiser les requêtes complexes ou de résoudre les problèmes de performances que le planificateur peut ne pas être en mesure de gérer lui-même.

Remarque

Ces exemples ne font que fournir un aperçu de l’ensemble incroyablement vaste d’extensions disponibles pour votre base de données Postgres. Nous vous encourageons à explorer pleinement ces extensions pour booster votre base de données Postgres. Vous pouvez également envisager la possibilité de créer vos propres extensions, ce qui offre le potentiel d’étendre Postgres au-delà de ses capacités actuelles. L’architecture d’extension puissante et flexible garantit que Postgres sera toujours en mesure de s’adapter et d’évoluer avec les exigences de votre plateforme.

Scénario : Dans certains cas, les stratégies de partition de table héritées ont entraîné la création de milliers de partitions. Bien que cela ait pu être efficace auparavant, ces stratégies peuvent ralentir les performances des requêtes dans Postgres dans certaines circonstances. Dans des instances très spécifiques, le planificateur de requêtes peut ne pas pouvoir déterminer la clé de partition appropriée lors de l’analyse de la requête. Le comportement résultant prolonge la durée de planification, et fait en sorte que la planification de requête dure plus longtemps que l’exécution proprement dite de la requête.

Solution recommandée : Réévaluez la nécessité des stratégies de partitionnement générant un trop grand nombre de partitions. Le moteur de base de données Postgres peut ne plus nécessiter la même segmentation des données et réduire le nombre de partitions peut probablement améliorer les performances. Si un schéma de partitionnement hérité est évalué et qu’il est jugé comme étant requis, envisagez de restructurer votre requête en opérations discrètes pour d’abord identifier et extraire des clés de partition dynamiques, puis utilisez les clés de partition dans vos opérations de requête.

Scénario: Parfois, les dépendances externes et les circonstances environnementales peuvent nécessiter des scénarios de base de données hybrides où les bases de données Oracle et Azure Postgres doivent coexister. Par exemple, il peut y avoir des occasions où des migrations par phases sont nécessaires pour accéder aux données Oracle directement à partir d’Azure Postgres sans surcharger l’importation de données ou modifier des processus ETL complexes. Dans d’autres cas, l’exécution d’une validation parallèle des données en comparant simultanément des jeux de données équivalents dans les environnements Oracle et Azure Postgres peut vous aider à garantir la cohérence et l’intégrité des données pendant et/ou après votre migration.

Solution recommandée : Les extensions FDW (Foreign Data Wrapper) PostgreSQL sont une fonctionnalité Postgres clé qui vous permet de solliciter et de manipuler les données stockées dans des systèmes externes comme si elles résidaient dans la base de données Azure Postgres en mode natif. Les FDW permettent à Azure Postgres de fonctionner en tant que base de données fédérée, ce qui permet l’intégration à n’importe quelle quantité de sources de données externes, y compris les bases de données Oracle. Les FDW créent des définitions de tables étrangères dans votre base de données Postgres, et ces tables étrangères agissent en tant que proxy pour votre source de données externe définie, ce qui permet aux utilisateurs d’interroger ces tables étrangères à l’aide de requêtes SQL régulières. En interne, le moteur Postgres utilise la définition de FDW externe pour communiquer avec et coordonner les données à la demande à partir de la source de données distante.

oracle_fdw : (Foreign Data Wrapper pour Oracle) est une extension Postgres qui vous permet d’accéder aux bases de données Oracle à partir d’Azure Postgres. Lors de la migration d’Oracle vers Azure Postgres, oracle_fdw peut jouer un rôle crucial en fournissant l’accès aux données, la validation des données, la migration incrémentielle, et la synchronisation des données en temps réel. Il est important de garder à l’esprit les considérations clés suivantes lors de l’utilisation de FDW :

  • L’exécution de requêtes via oracle_fdw entraîne une surcharge sous la forme de communications réseau et de négociation d’authentification pendant que les données sont traitées et extraites à partir du serveur Oracle distant.
  • Certains types de données peuvent avoir besoin d’une gestion ou d’une conversion spéciale pour garantir que les types de données sont correctement mappés entre les systèmes.

L’utilisation efficace d’oracle_fdw peut aider à simplifier la transition de la base de données et à garantir l’accessibilité des données en permettant à vos applications et données de rester accessibles tout au long du processus de migration global.

Contenu connexe

  • Last updated on