Vous n'êtes pas identifié(e).
Bonjour,
Je suis à la recherche de la méthodologie la plus adaptée pour migrer la base de données d'un client de 3,2 To.
Je suppose qu'il y a des outils performants surtout pour migrer la partie data avec un minimum d'interruption de service pour le client.
Merci de vos retours et de votre aide.
Hors ligne
Il n'y a pas tellement d'alternative. Vous pouvez utiliser ora2pg pour le schéma et les données, en parallélisé. Ou en ETL pour uniquement les données. Perso, je ferais plutôt confiance à ora2pg.
Guillaume.
Hors ligne
Bonjour,
Les 2 solutions de Gleu peuvent être envisager si vous maîtrisez votre appli et votre modèle de données :
- ora2pg pour le DDL et le gros des données
- puis un ETL pour le delta des données avant la bascule vers PostgreSQL.
sinon tout avec ora2pg ça devrait le faire.
Cordialement,
Sébastien.
Hors ligne
Merci messieurs.
Si je comprends bien vos réponses, ça veut dire qu'il faut bien maîtriser l'application et le modèle de données (ça me paraît difficilement jouable) pour pousser les données non seulement sur le SI actuel (oracle) mais aussi sur la base de données cible.
Et donc on prend un ETL pour le delta des données restantes avant bascule.
Et si on prend ora2pg, on va se retrouver avec une indisponibilité (je suppose) plus élevée le temps de transfert des données "vivantes".
On peut se dire de basculer l'ensemble des données de correspondance (ou mortes) avant la bascule.
C'est cvomme ça que vous voyez les choses ?
Hors ligne
pour moi c'est le cas.
Cordialement,
Sébastien.
Hors ligne
Bonjour,
Ora2Pg fait principalement de la migration de données "oneshot" ce qui effectivement nécessite une interruption de l'application. En terme de vitesse de migration de données, Ora2Pg n'a rien a envier aux meilleurs ETL, c'est une question de nombre de CPU à disposition. Mais en ce qui concerne la possibilité de faire de l'incrémental, les ETL ont plus d'une longueur d'avance. Cependant il existe une fonctionnalité dans Ora2Pg permettant de faire de l'incrémental. Elle est encore en développement mais elle ne demande qu'à être finalisée. Cette fonctionnalité développée par Sebastian Albert peut être activée grâce à la directive de configuration DATADIFF, reportez vous à la documentation pour plus de détail. Personnellement je ne l'ai pas encore vraiment utilisée car l'interruption de service peut être minimisée par d'autres moyens, notamment le chargement à posteriori des données "non vivantes" (avec la directive de configuration WHERE vous pouvez appliquez un filtre aux données à migrer).
Sinon pour être plus précis, au niveau de l'interruption de service, ce qui pose problème c'est la migration des données BLOB. Pour les autres en général c'est extrêmement rapide en fonction du nombre de CPU à disposition. Les BLOBs doivent être transformé en BYTEA il faut pour cela encoder ces données et c'est ce qui prend du temps. Pour vous donner un ordre d'idée, la dernière migration que j'ai faite avait 240 GB sur une table avec des BLOB et il a fallu 16h00 avec des VM de 4 CPU et 8Go de RAM des deux cotés (serveur Oracle et serveur PG). Bien sur en dehors du hardware, tout dépend aussi de la taille des BLOBs, plus ils sont volumineux plus ils prennent des ressources à la conversion. Là c'est la première fois que je constate une telle lenteur, je pense que les VM n'y sont pas pour rien, surtout coté Oracle. A tel point que j'ai rajouté des options à la commande ora2pg permettant de visualiser à quelle vitesse Oracle est capable d'envoyer les données pour tenter de disculper Ora2Pg:
commit 955592221f6cdc649711b7bb5c982b140eaf5df1
Author: Gilles Darold <gilles@darold.net>
Date: Fri Sep 7 17:52:03 2018 +0200
Add two new command line options:
--oracle_speed : use to know at which full speed Oracle is able to send
data. No data will be processed and nothing written.
--ora2pg_speed : use to know at which full speed Ora2Pg is able to send
transformed data. Nothing will be written.
they are used to be able to see at what speed Oracle is sending data and
at what speed Ora2Pg is processing the data without reaching disk or
direct import into PostgreSQL. Use it for debuging purpose.Pour faire avancer les choses, si vous souhaitez mettre en œuvre le DATADIFF sur Ora2Pg je me ferai un plaisir de vous assister et de corriger/améliorer dès que possible la fonctionnalité en fonction de vos retours. Pour cela il faut reporter vos problématique sur github où à l'adresse ora2pg@darold.net. Sur github merci de le faire en anglais pour que tout le monde en profite, sur l'adresse email officiel peu importe mais c'est probablement plus compréhensible en français.
--
Gilles Darold
http://www.ora2pg.com/
Hors ligne