Détails de la migration Oracle

Migration d’applications basées sur Oracle vers Postgres

Les faits

  • Oracle Enterprise Edition (EE)/Standard Edition (SE) et Postgres sont des bases de données relationnelles (SGBDR). Pour plus d’informations sur la comparaison Oracle EE par rapport à Postgres, voir le document “SD-Functional equation Oracle EE vs. PostgresPURE” sur notre site.
  • Le langage de description des données (DDL) et le langage de manipulation des données (DML) sont les éléments clefs d’une base de données.
  • La migration peut affecter ou affectera votre architecture de base de données, vos applications tournant sur la base de données et/ou votre pile technologique.
  • Il existe des outils capables de supporter tous types de migrations, mais:
    • certains créent une nouvelle dépendance vis-à-vis d’un fournisseur à travers une couche de compatibilité qui n’est PAS Open Source (eg: EntrepriseDB).
    • certains n’exploitent pas la puissance de Postgres et ne permettent pas l’optimisation des forces de Postgres.
    • certains font seulement une migration partielle et vous laissent dans l’obscurité; ils n’indiquent pas ce qui a été migré/non migré ou changé (ex: Ora2Pg).

Splendid Data, les migrations et les outils

  • Chaque migration est unique, chaque application à des spécifications particulières et chaque client a des exigences qui lui sont propres.
  • Des logiciels d’évaluation permettent l’analyse des instructions Oracle DDL et PL/SQL (DML) stockées dans la base de données.
  • L’outil de conversion est capable d’automatiser (en partie) une migration d’instructions DDL et DML.
  • Côté base de données, nous sommes en mesure de:
    • migrer les instructions Oracle DDL vers Postgres DDL, la plupart du temps de façon automatique (exceptions: tables partitionnées et parfois quelques vues).
    • migrer automatiquement env. 80% des instructions Oracle DML (PL/SQL) vers Postgres DML (PL/pgSQL). Pour plus de détails, veuillez consulter le document “SD-84 Reasons to choose SD for migration Oracle to Postgres” sur notre site.
  • Les outils de migration ne laissent aucune trace (code propriétaire et/ou outillage)… aucune dépendance!

Du point de vue de l’application

  • Dans la plupart des cas, une application s’exécute au-dessus de la base de données. Cette application “utilise et manipule” le contenu de la base de données. Une base de données migrée sans application parallèle N’A AUCUN INTÉRÊT.
  • Front-ends possibles (généralement):
    • Si l’application est basée sur Java, il est normalement facile d’implémenter l’application “en l’état” sur la base de données migrée (DDL/DML).
    • Front-end en .Net: plus ou moins identique à Java, normalement sans grande difficulté.
    • Tous les types de front-end comme Oracle Forms, Oracle ADF, Oracle APEX, UNIFACE, COBOL, etc… doivent être évalués de près pour déterminer la possibilité d’une migration.
    • Si des solutions BI sont déjà en place, la migration dépendra entièrement de la technologie-BI utilisée. Celles-ci doivent également être évaluées.

Avantages de l’approche Splendid Data

  • Une approche transparente…pas de surprises!
  • L’évaluation pour la migration est réalisée par des experts avec une expérience Oracle et Postgres avérée.
  • La migration du code DDL et des données est souvent facile à faire.
  • La migration du code DML (code PL/SQL) stocké dans la base de données Oracle est automatique à 80% env.
  • La sortie (output) converti est formaté en code Postgres natif PL/pgSQL et peut être déployé dans les versions Postgres ciblées (de la v.9.4 à la dernière version).
  • Les outils de migration ne laissent aucune trace, sont 100% Open Source et ne créent pas d’enfermement propriétaire!
  • Permet l’optimisation des capacités de Postgres.
  • Opportunité pour se débarrasser de l’outillage Oracle extrêmement cher (tel que: Oracle RAC, Golden Gate, Data Guard, Weblogic etc…).
  • De l’enfermement propriétaire à la liberté!

Migration réelle – étape 1 Base de données

DDL et données

  • La migration de DDL est généralement facile à réaliser.
  • La migration des données dépend de la qualité des données, mais elle est généralement facile à réaliser.

step1_migration_FR

DML: code PL/SQL → code PL/pgSQL

  • Automatique à env. 80%.
  • Natif → utilisation de Postgres de la meilleure façon possible.
  • Pas de traces.

Migration réelle – étape 2 Middleware

Généralités

  • La migration d’Oracle Weblogic vers une solution middleware Open Source est généralement facile à effectuer.
  • Si une solution middleware Open Source est déjà utilisée → pas de changement nécessaire!
  • Usage spécifique d’ESB, de couche ORM et/ou de Files d’attente de messages (Message Queues) doivent être déterminés et adressés.

step2_migration_FR

Migration réelle – étape 3 Application/Interface Utilisateur (IU)

OLTP Application/IU

  • Java → Java, généralement facile à faire…ajustements de quelques appels de base de données.
  • .Net → .Net, généralement facile à faire…ajustements de quelques appels de base de données.
  • Autres (Oracle Forms, Oracle ADF, Oracle APEX, Uniface, Cobol etc.) … à évaluer.

step3_migration_FR

Rapports

  • Dépend des technologies utilisées (évaluation).

Intégration avec d’autre(s) application(s) IS’n

  • Dépend des technologies utilisées (évaluation).

Batch(es)

  • Dépend des technologies utilisées (évaluation).

BI

  • Dépend des technologies utilisées (évaluation).