Migrer de Oracle à Postgresql

[scheu]

Bonjour

J'ai en tête l'idée de faire un tutoriel sur la migration d'Oracle à Postgresql, axé sur les principales différences entre les 2 SGBDs (commit, fonctions, types de données, comportements à une même syntaxe SQL, ...) , les fonctionnalités à adapter sur Postgresql, les différences de respect de la norme SQL, les principales techniques de migration, etc ...

Cet article se veut technique et non pas politique, le but n'étant pas de dire "Postgresql c'est bien, Oracle c'est pas bien"

Qu'en pensez-vous ?

[SQLpro]

Tu comptes y passer... quatre ans ????

A +

[scheu]

Envoyé par SQLpro

Tu comptes y passer... quatre ans ????

Non pourquoi ?
Les différences ne sont énormes, et c'est une question qu'on peut se poser à juste titre quand dans une boîte on veut migrer sur un SGBD opensource

[djalouk]

Petite relance pour savoir si ce projet de tuto à abouti ?

[scheu]

Toujours dans les cartons faute de temps, néanmoins si tu veux migrer de Oracle à Postgresql je peux t'aider. Que veux-tu savoir ?

[apersonnat]

Bonjour,

Ce post m'interesse particulièrement car je suis en train de préparer une migration Oracle [8i] -> Postgres.

Je pense utiliser l'outil ora2pg, pour les données, pas trop de pb je pense mais pour les procédures, packages, triggers et fonctions il faut faire une revue de code.

Une autre question se pose, j'ai beaucoup de vue matérialisées et je voulais savoir comment se passait la cohabitation Oracle/Postgres.

Si par exemple Postgres doit supporter le snapshot log sur lequel Oracle va venir rafraichir ses données et inversement.

As-tu déjà rencontré ce cas de figure ?

Meric pour ta réponse
Alain

[scheu]

Pour les PL/SQL, il faut bien évidemment les réécrire en PL/PgSQL, la syntaxe est assez similaire mail il faut néanmoins s'y plonger et bien recetter
Pour les rafraichissements Oracle vers Postgresql, j'utilise en ETL externe donc je ne pourrai pas t'aider

Par contre au delà de la migration il y a quelques différences et incompatibilités sur lesquelles il faut faire très attention. Par exemple :
- Postgresql sensible à la casse pour tous les noms d'objets (donc requêtes et scripts sans doute à modifier si les tables sont écrites une fois en majuscule, une fois en minuscule). Le mieux est de choisir une convention : tout en majuscules ou tout en minuscules, sinon on court droit à la catastrophe
- les requêtes à réécrire : fonctions Oracle non standard à réécrire en PL/PgSQL, syntaxe (+) pour jointures ouvertes non supportée par Postgresql, utiliser obligatoirement "as" pour renommer une colonne ou une sous-requête sur Postgresql
- conversions implicites qui ne marchent plus sur Postgresql (toujours caster explicitement)
- le type de données "date" est différent (stocke aussi l'heure sur Oracle, pas sur Postgresql)
- gestion des NULL : NULL = chaîne vide sur Oracle mais pas sur Postgresql donc résultat différent sur filtre "where colonne is null" si la colonne vaut une chaîne vide
- commit implicite sur Postgresql
- pas de synonymes (utiliser à la place des vues affichent le "select *" de la table)
- pas de notion de package sur Postgresql

J'en oublie certainement
N'hésite pas si tu as rencontre d'autres problèmes, le partage d'expériences est toujours enrichissant

[estofilo]

Envoyé par scheu

- Postgresql sensible à la casse pour tous les noms d'objets

Ni plus ni moins qu'Oracle il me semble, c'est-à-dire oui quand il y a des guillemets autour du nom et sinon non.

[apersonnat]

Merci pour toutes ces précisions, je ne manquerais pas de faire un retour d'expérience sur cette migration.

[apersonnat]

Bonjour,

Je suis un peu perplexe quant à l'utilisation en production de Postgres, en effet j'ai posté un SR sur le site Pgfoudry.org .. aucune réponse ..

L'une des problématiques de cette migration réside dans l'utilisation du mécanisme de réplication via db link.

Il existe un module permettant de créer des vues matérialisées ainsi que des snapshots logs compatibles avec Oracle, à condition d'installer le module dbi-link (spécifique pour Oracle).

J’ai installé le module, j'ai réussi à faire une requête distante mais si je relance le serveur Postgres le module devient inopérant .. un peu embêtant .. donc j'ai ouvert un call la semaine dernière et je n'ai aucune réponse.

Je suis d'accord, les licences sont moins onéreuses qu'Oracle mais le service va avec ;-)

A suivre ..

[NouveauMigrateur]

Bonjour,

Donc je suis dans le même cas que certains d'entre vous, à savoir migrer d'oracle 9.I vers Postgresql 8.3.
Première question quel est l'outil de migration qui vous paraît le plus approprier, j'ai appris que ora2PG est pas mal mais je voudrais savoir si c'est le cas ou y a il d'autre plus performant.

2ème question (la plus importante) connaissez vous tuto sinon pourriez vous me diriger vers des bonnes adresse qui traitent ce sujet

Enfin quelles sont les étapes à suivre

Merci infiniment de vos réponses

[apersonnat]

Bonjour,

Quelques news sur le projet de migration Oracle -> Postgres, je suis allé au PGDays au début du mois de novembre assister [entre autre] à une conférence dont le thème était
'Retour d'expérience sur une migration Oracle 9i => Postgres 8.3'

Le cdp à choisi d'utiliser l'outil ora2pg (je l'avait déjà testé avec succès) en revanche il n'y avait pas de réplication domage ...

Il n'y avait pas non plus de procédures, fonctions, triggers uniquement des données.

Donc pour répondre à la question, oui l'outil le plus approprié est à mon sens ora2pg.

Pas besoin réellement de tuto, il y a un readme très bien documenté dans le package ora2pg.

Cdt,
Alain

[younesss]

Bonjour,
Je dois préparer un projet de migration entre une base de données Oracle et une base de données PostgreSQL.
J'ai entendu parler de l'outil ora2pg mais, quand je le télécharge, il y a juste un paquet winrar.
Quelqu'un peut-il m'aider et me dire comment je peux télécharger ora2pg et l'utiliser ?
Merci d'avance.

[punkoff]

Ben winrar c'est un format compressé, donc télécharger le logiciel winrar pour le décompresser.


Courage, vous en aurez besoin...

[Jc-balt]

Bonjour,

Pour vos besoins, on peut aussi utiliser un outil d'ETL. Par rapport au début de la discussion -2009- c'est vrai que ces outils ont évolué. Et sont plus facile à prendre en main. Avec quelque chose comme Talend, aujourd'hui, la prise en main est relativement aisée (faut pas etre un cador de l'ETL, quoi ) et permet d'operer la migration. Il y a pas mal de connecteurs: Oracle et Postgresql doivent etre supportés. En éspérant avoir pu vous aider!

Bien cordialement,
JCB.

[cal123]

bonjour,

je travaille en ce moment sur une base Oracle et je commence regarder les différences pour voir si c'est compatible avec un autre système de base de données.
je vois pas mal de notion d'instance dans la doc de ce projet. Une Instance semble appartenir à un utilisateur et semble regrouper plusieurs bases de données physiques (enfin dans mon cas) un peu comme une métabase.

pas de notion de package sur Postgresql

quand on parle de package, c'est la même chose que la notion d'instance telle que je l'ai comprise?
Si non est ce quelqu'un pourrait m'expliquer de quoi il s'agit ?

merci.

[scheu]

Sur Oracle, un package peut contenir plusieurs fonctions et/ou procédures, et on les appelle par "nom_schema"."nom_package"."nom_fonction"

Sur Postgresql, les packages n'existent pas, il faut directement créer des fonctions et/ou procédures mais on ne peut pas les grouper en packages

Cela n'est pas gênant en soi, on peut toujours appeler ces fonctions par "nom_schema"."nom_fonction". C'est juste que parfois quand on doit développer plusieurs procédures et/ou fonctions qui concernent le même traitement, on préfère les regrouper en package pour des questions de lisibilité


Concernant la notion d'instance, sur Oracle chaque "base" a sa propre instance (= ses propres processeurs, ses propres zones mémoires, ses propres paramètres").

Alors que sur Postgresql, toutes les bases deune même installation ( = d'une même version installée) partagent les mêmes zones mémoire, les mêmes processeurs SGBD, les mêmes journaux de transaction (WAL), les mêmes paramètres d'instance
Ainsi, les bases sont moins indépendantes les unes des autres sous Postgresql, même si rien ne t'empêche de "surcharger" certains paramètres base par base, ou d'avoir une installation de Postgresql par base (en jouant sur les variables d'environnement, le PATH, ...) mais c'est plus compliqué