Bonjour à tous,
 
Je dois faire une étude pour la migration d'une base de données d'Oracle vers MySQL avec des millions d'enregistrement.
 
J'ai déjà fait pour plusieurs Go de données, mais là, je me demande si les outils standards de migration vont tenir le coup ?
 
Je pense faire un web service qui pointe sur oracle et qui va chercher les données, les reformates pour accélérer le processus.
 
Pouvez vous me donner des conseils ?
 
Merci

Bonsoir,
 
Je n'ai jamais fait de migration d'Oracle vers MySql, mais uniquement d'Oracle vers Sql Server ou inversement. Je ne vois pas trop où tu veux en venir avec la méthode du web service ?
Les millions d'enregistrement ne devraient pas trop poser de problème (en tout cas entre Oracle et SQL Server ça se passe bien).Si tu passes par un web service, tu vas ajouter 2 connecteurs de bdd, un programme au milieu pour traiter tes données, et ce sera plus compliqué de faire de l'ensembliste. Avec un outil ou même des SQL Loader, tu traiteras simplement tout ça non ?
 
Bon courage,

 
 
Oui, mais j'ai des tables de 10 millions d'enregistrements minimum, avec une table qui en fait plus de 300 millions du coup je vois mal mon petit logiciel faire ca. avec un web service, c'est plus rapide non ?
 
 
 
Merci de ton retour .

si tu es plus à l'aise avec ton web service vas-y, de tte facon il y a rarement plus rapide que les outils en natif du SGBD

t'as bien raison gustoune, rien de plus efficient que de passer par un webservice pour faire sql vers sql !

xmlerde vaincra !

je pense que c'est une histoire d'affinité, migrer 10 million de lignes c'est pas énorme, si c'est plus rapide pour lui de le faire en webservice et qu'il a le temps pour la migration et la coupure disponible, y'a pas de raison...

Après cela dépend de la largeur d'une ligne pour ces 10 millions.
Autrement il y a la méthode classique d'unload/load, où il faut créer un fichier à partir de la table sous Oracle puis charger par un loader sous MySQL.
A mon avis c'est le plus rapide, mais nécessite un peu de développement.

si tu as une migration  à faire, tu prends une ETL plutot que de le redevelopper à la main
Soit tu te diriges vers des outils libres comme Talend, soit des outils payants ( ici on utilise data intelligency , d'oxio )

des tables de 300 millions de lignes sous mysql?

c'est sûr qu'il faudra un peu benchmarker, après il me semble que mysql intègre maintenant du partionnement, non ?

aucune idée, mais perso j'oserais même pas tenter le coup.

sinon j'ai un outil de conversion fait main, qui fait de la conversion Oracle vers MySQL
100% assembleur, se reposant sur la plus basse couche possible du sgbd (OCI pour Oracle, et natif pour MySQL), interface immonde (2 listboxes qui présentent les 2 bases), mais exécutable de 4936 octets et vitesse moyenne de 80000 lignes/s en fonction du type de données à migrer

edit: il marche plus sous Vista et 7

avec ce genre d'outil tu mets en péril le marché du hardware il est préférable de faire un webservice basé sur hibernate pour relancer le marché des CPU, de la RAM et des disques SSD

faudrait que je reprenne le développement de ce bouzin tiens... déjà le rendre compatible Win 7, et faire une interface utilisable par quelqu'un d'autre que moi même

Mais tu es fou

Un ETL sinon rien, c'est prévu exactement pour ce genre de choses.

Ton webservice, tu vas passer perdre plus de temps à le programmer qu'à migrer tes données.

c'est ce que m'avait dit mon boss de l'époque
déjà il me prenait pour un fou de faire ça chez moi pendant mes lolLoisirs, et en plus quand je lui ai dit le fonctionnement du truc (allocation de la plus grande plage mémoire dispo sur la machine, recopie d'Oracle vers la mémoire, puis de la mémoire vers MySQL après conversion des données via MMX ou SSE si dispo -ce qui permet de traiter 2 voire 4, 8 ou 16 champs dans le même cycle en fonction de la taille des données-, et contrôle final de l'intégrité des données à la FPU), il voulait me faire interner
testé à l'époque sur une table ne contenant que des champs de taille 1 octet (CHAR) : transfert de 3 millions de lignes en 4 secondes

j'avais même fait une version 3DNow! à l'époque, c'était la techno qui avait le vent en poupe

nan, un export/import au format CSV ca marche aussi

a condition de bien pendre en compte les diverses encodages de fichier, et paramètre d'échappement

 
faut faire du Bulk.