Migration de Mysql à Oracle

Version imprimable

28/12/2006, 18h06
RR instinct

Migration de Mysql à Oracle

Bonjour,

Je dois migrer d'une base de données Mysql à une base Oracle et je rencontre pas mal de problèmes dont un en particulier :

J'utilisais, dans la version mysql, la commande load data local infile...

Ce qui me permettait, à partir d'un PC client, de charger des informations préalablement insérée dans un fichier sur ce PC client.

Or j'ai bien peur que ca ne soit pas possible avec Oracle d'après ce que j'ai trouvé sur le net. C'est cela ?

Je précise que le client, à part les driver JDBC (donc un fichier .jar), n'a rien d'installer sur sa machine pour communiquer avec la base distante.

Avez vous une idée de comment je peux faire s'il vous plait ?

Merci d'avance.
28/12/2006, 22h37
nuke_y

Bah tout en java ça doit être possible. Tu faisais comment avec mysql ? C'était un programme particulier en java qui ouvrait le fichier et appelait la commande load data local infile ? Tu risques effectivement de devoir ré-écrire une partie du code de la fonction toi même sous Oracle.
29/12/2006, 09h00
RR instinct

bah en fait je faisait une requete "load data local infile 'C:/fichier.txt' into table t_table"

ce qui chargeait automatiquement le fichier sur le serveur et inserait les infos dans la base.

A la base, c'était pour gagner du temps et éviter de faire x requêtes, mais je vois mal comment faire sur oracle, sachant qu'on utilise juste les drivers JDBC. (j'ai lu qu'on pouvait le faire avec sql*loader mais on ne doit pas faire d'installation sur le PC client).

Est-ce possible ?
29/12/2006, 09h27
pifor

Je pense que la seule solution avec un outil Oracle et sans programmation pour charger des données dans une base depuis une machine client est bien d'utiliser SQL*Loader.

Si le fichier peut être transféré sur le serveur qui héberge la base, alors vous pouvez forcément utiliser SQL*Loader, ou coder le chargement en PL/SQL avec le package UTL_FILE ou encore créer une table externe.
29/12/2006, 09h49
nuke_y

Comme je le disais, tu risques de devoir ré-écrire une partie du code toi-même. Par exemple écrire une fonction java qui va ouvrir ton fichier et envoyer le contenu à une fonction Oracle que tu auras programmé et qui saura quoi en faire, ou alors écrire une fonction java qui va ouvrir ton fichier et qui insérera son contenu dans Oracle.

Bref rien d'évident et de natif, à mon avis. Evidemment si tu avais un moyen simple d'envoyer les fichiers de ton poste client sur un répertoire du serveur, SQL*Loader aurait été utilisable.
29/12/2006, 10h17
RR instinct

il se pourrait que j'en trouve un (j'utilise déjà une fonction similaire qui me permet de transmettre un fichier via un serveur web...)

je vais voir comment je peux faire. Merci pour vos réponses.
29/12/2006, 10h28
remi4444

Personnellement, je trouve que c'est pénible de devoir gérer des fichiers sur le serveur, car il y a une foule de nouveaux cas d'erreurs à traiter (problèmes de droits, problèmes réseaux etc...). Si le volume n'est pas tres important, alors tu peux toi meme générer une boucle d'insert en faisant tres attention à 2 choses:
- ne pas ouvrir/fermer la connexion à chaque occurence de boucle (si si j'ai vu des progiciels qui faisaient ça! :aie: )
- utiliser les variable bind (requetes préparées avec "prepareStatement" avec les "?" dedans)

Si vraiment tu as des gros problèmes de performances (mais quand meme ça m'etonnerait) tu peux envisager des solutions plus brutales comme le chargement du fichier en 1 seul coup dans un CLOB et traiter apres par des procédures stockées.
29/12/2006, 15h07
RR instinct

Citation:

Envoyé par remi4444

Personnellement, je trouve que c'est pénible de devoir gérer des fichiers sur le serveur, car il y a une foule de nouveaux cas d'erreurs à traiter (problèmes de droits, problèmes réseaux etc...). Si le volume n'est pas tres important, alors tu peux toi meme générer une boucle d'insert en faisant tres attention à 2 choses:
- ne pas ouvrir/fermer la connexion à chaque occurence de boucle (si si j'ai vu des progiciels qui faisaient ça! :aie: )
- utiliser les variable bind (requetes préparées avec "prepareStatement" avec les "?" dedans)

Si vraiment tu as des gros problèmes de performances (mais quand meme ça m'etonnerait) tu peux envisager des solutions plus brutales comme le chargement du fichier en 1 seul coup dans un CLOB et traiter apres par des procédures stockées.

Je ne ferme jamais la connexion, je le devrais ? (je l'ouvre au chargement du logiciel et j'utilise toujours la même jusqu'à la fermeture).

Les variables bind c'est des requêtes parametrées en fait ? Quand j'ai récuperé les sources du logiciel ce n'était pas fait... il faudrait que j'y pense, est-ce que ca influe vraiment sur les performances ?

A savoir, je peux inserer jusqu'à, 3000 enregistrements d'un seul coup (au max. sinon c'est entre 50 et 500 en moyenne), contenu dans un seul fichier, c'est pour cela que cette solution a été choisie.

Le problème est que en local, sur un serveur mysql, ca allait mais dès qu'on passait sur un serveur mysql distant... j'ose même pas en parler...

La solution brutale pourrait être une solution mais ca me fait modifier beaucoup de choses pour une version oracle et en maintenance par la suite ... c'est pas l'idéal :/

Je dit pas trop de bêtises ?
29/12/2006, 15h54
remi4444

Citation:

Envoyé par RR instinct

Je ne ferme jamais la connexion, je le devrais ? (je l'ouvre au chargement du logiciel et j'utilise toujours la même jusqu'à la fermeture).

ben reste comme ça justement, c'est très bien!

Citation:

Envoyé par RR instinct

Les variables bind c'est des requêtes parametrées en fait ? Quand j'ai récuperé les sources du logiciel ce n'était pas fait... il faudrait que j'y pense, est-ce que ca influe vraiment sur les performances ?

Oui ça influe ennormément quand y'a une baterie de petites requêtes répétées très vite. Il faut comprendre que Oracle va prendre un temps fixe à parser la requête, calculer le plan d'execution etc... lorsque tu utilises les requêtes paramétrées, ce temps est économisé car il va directement chercher dans son cache mémoire et ne refait pas ce travail. Ce temps est tout petit, donc sur des grosses requêtes espacées ça n'a aucune importance, mais sur des petites requêtes rapprochées ça devient très significatif. De plus, oracle met dans son cache-sql les requêtes la première fois qu'il les voit passer. Du coup, si tu ne paramètres pas tes requêtes, tu crées une nouvelle requête à chaque fois, et donc oracle gaspille sa mémoire à mettre des trucs qu'il ne réutilisera jamais.

Oki.

Sinon j'ai essayé de prendre en main le sql*loader d'oracle, je n'arrive pas à inclure un champ selon la valeur d'une séquence dans le fichier de contrôle :

Code:

1
2
3
4
5
6
 
LOAD DATA INFILE 'c:\activite.txt'
INTO TABLE T_ACTIVITE 
FIELDS TERMINATED BY ';'
(CLE_ACTIVITE "GEN_T_CONDUCTEUR.nextval", CLE_CHAUFFEUR,CLE_TYPE_ACTIV,HEURE_DEBUT,
HEURE_FIN,DUREE_EN_MINUTE,ANNEE_ACTIVITE)

et mon activite.txt :

Code:

1
2
3
4
5
6
 
1;4;0;53;53;2006-12-01
1;1;53;60;7;2006-12-01
1;4;60;64;4;2006-12-01
1;1;64;72;8;2006-12-01
1;4;72;191;119;2006-12-01

Lorsque je l'execute avec sqlldr j'obtiens le log suivant :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
 
SQL*Loader: Release 10.1.0.2.0 - Production on Ven. Déc. 29 16:54:04 2006
 
Copyright (c) 1982, 2004, Oracle.  All rights reserved.
 
Control File:   c:\control.txt
Data File:      c:\activite.txt
  Bad File:     c:\bad.txt
  Discard File:  none specified
 
 (Allow all discards)
 
Number to load: ALL
Number to skip: 0
Errors allowed: 0
Bind array:     64 rows, maximum of 256000 bytes
Continuation:    none specified
Path used:      Conventional
 
Table T_ACTIVITE, loaded from every logical record.
Insert option in effect for this table: INSERT
 
   Column Name                  Position   Len  Term Encl Datatype
------------------------------ ---------- ----- ---- ---- ---------------------
CLE_ACTIVITE                        FIRST     *   ;       CHARACTER            
    SQL string for column : "GEN_T_CONDUCTEUR.nextval"
CLE_CHAUFFEUR                        NEXT     *   ;       CHARACTER            
CLE_TYPE_ACTIV                       NEXT     *   ;       CHARACTER            
HEURE_DEBUT                          NEXT     *   ;       CHARACTER            
HEURE_FIN                            NEXT     *   ;       CHARACTER            
DUREE_EN_MINUTE                      NEXT     *   ;       CHARACTER            
ANNEE_ACTIVITE                       NEXT     *   ;       CHARACTER            
 
Record 1: Rejected - Error on table T_ACTIVITE, column ANNEE_ACTIVITE.
Column not found before end of logical record (use TRAILING NULLCOLS)
 
MAXIMUM ERROR COUNT EXCEEDED - Above statistics reflect partial run.
 
Table T_ACTIVITE:
  0 Rows successfully loaded.
  1 Row not loaded due to data errors.
  0 Rows not loaded because all WHEN clauses were failed.
  0 Rows not loaded because all fields were null.
 
 
Space allocated for bind array:                 115584 bytes(64 rows)
Read   buffer bytes: 1048576
 
Total logical records skipped:          0
Total logical records read:             1
Total logical records rejected:         1
Total logical records discarded:        0
 
Run began on Ven. Déc.  29 16:54:04 2006
Run ended on Ven. Déc.  29 16:54:06 2006
 
Elapsed time was:     00:00:01.71
CPU time was:         00:00:00.52

Quelqu'un a une idée d'ou cela peut provenir ?

31/12/2006, 16h58
Marc Musette

c'est normal : tu veux remplir une table comprenant 7 colonnes et tu n'en fournis que six

je sais que la première tu veux la générer automatiquement mais dans ce cas tu dois utiliser le keyword SEQUENCE

je n'ai pas d'exemple sous la main mais fait une recherche dans la doc (Utilities Guide) à "Using SQL*Loader to Generate Data for Input."

bonne chance et bon réveillon (attention trop d'oracle nuit à la santé ;)