migration de données

TL;DR : Debezium lit les journaux de transactions Oracle via LogMiner, publie chaque modification sous forme d'événement Kafka, et un connecteur JDBC sink applique ces événements à PostgreSQL en temps réel.
Le résultat est un pipeline de réplication transparent et rejouable que vous pouvez exécuter pendant des semaines avant la mise en production — utile pour toute migration d'Oracle vers PostgreSQL qui nécessite un temps d'arrêt nul ou quasi nul.
Ce post présente une configuration fonctionnelle de bout en bout, sur de vrais serveurs Oracle et PostgreSQL, avec un schéma bancaire autonome que vous pouvez copier et reproduire.

Continuer la lecture

Le schéma CO (Customer Orders) d'Oracle est le remplacement moderne de l'ancien schéma OE.

Il est livré avec Oracle 19c, il est activement maintenu et il est construit de la manière dont la plupart des applications Oracle réelles sont construites aujourd'hui : colonnes IDENTITY au lieu de paires séquence-déclencheur, JSON stocké dans des colonnes BLOB, et vues qui utilisent des fonctions SQL spécifiques à Oracle.

J'ai exécuté la migration complète en utilisant ora2pg 25.0 avec Oracle 19c comme source et PostgreSQL 18 comme cible.

Cet article aborde les cinq problèmes qui ont nécessité une intervention manuelle — et pourquoi chacun d'eux apparaîtra dans presque tous les schémas de production que vous migrerez.

Ceci est le troisième article de la série.

Le schéma RH post modèles de déclenchement de séquence couverts, %TYPE paramètres, et le bug de ré-application de la FK.

Le Schéma de publication du SH tables partitionnées couvertes, index bitmap et vues matérialisées.

CO introduit trois nouvelles catégories de problèmes qui n'existent dans aucun des deux.

Continuer la lecture

Étiquette : migration de données

Comment configurer la réplication Oracle en temps réel vers PostgreSQL avec Debezium

Migration Oracle vers Postgres : Problèmes et Corrections du Schéma CO