[9i] Migration d'une table volumineuse / performance

**Fiora** · 18/04/2007, 14h59

Bonjour à tous,

Mon DBA est absent et je sais pas quoi faire !!!

Je dois migré une table PAYMENT qui contient plus de 20 millions d'enregistrements depuis une base B1 vers B2 sans aucun traitement intermédiare.

j'utilise un db link, mais je vois que c'est trop long, en plus en cas d'intéromption je dois cleaner et relancer tout

question:
quelle est la meilleur façon d'après votre expérience de migrer une tel table.

- Db link.
- Sql Loader.
- Je suppose aussi Import/export ( mais je sais pas comment le faire).

Merci de me donner votre avis d'expert

**Fiora** · 18/04/2007, 18h03

petite précision:
la table se trouve sur un shema SYSA en première base B1, et sur le shema SYSB dans la deuxième base B2

HELP !!!!!!!!! c'est urgent

**LeoAnderson** · 18/04/2007, 18h51

Si c'est une seule table, vous n'avez guère le choix : export ou copy sous SQL*Plus via dblink

perso, j'opterais plus pour l'export/import car il a l'avantage de scinder les opérations en deux et donc, si ça plante, on ne recommence que la moitié

**pifor** · 19/04/2007, 08h55

L'option SQL*Loader en mode direct peut être intéressante à condition de pouvoir exporter en format texte rapidement la table. Tom Kyte propose un petit programme C dans ce but.

Si les bases utilisant le même OS et la même version d'Oracle, il a y aussi la possibilité (avec les droits DBA) de créer un tablespace spécifique, d'y copier la table avec CREATE TABLE ... AS SELECT ..., et de transporter le tablespace. Pour améliorer les performances, il faudrait essayer de désactiver le mode ARCHIVELOG de la base et/ou de faire l'opération en NOLOGGING (avec sauvegarde de la base avant).

**orafrance** · 19/04/2007, 11h48

Envoyé par LeoAnderson

perso, j'opterais plus pour l'export/import car il a l'avantage de scinder les opérations en deux et donc, si ça plante, on ne recommence que la moitié

pour info, COPY permet de faire des COMMIT intermédiaire et évite de passer un fichier dump qui peut poser des problèmes d'espace disque

**LeoAnderson** · 19/04/2007, 12h08

Envoyé par orafrance

pour info, COPY permet de faire des COMMIT intermédiaire et évite de passer un fichier dump qui peut poser des problèmes d'espace disque

pas d'accord

tu copy avec commit toutes les X lignes.
ta table fait 5000 x lignes (tu auras donc 5000 "lots").

Au bout de 4800 lots, ta session se plante (perte réseau, kill de la session sql*plus, plantage du poste client, ...)
tu fais quoi ??
tu as certes 4800x dans ta base distante, mais tu es quand même obligé de les supprimer puis de relancer ton copy.

**orafrance** · 19/04/2007, 12h09

bah non, pourquoi les supprimer ? Tu insères ce qui manque c'est tout puisque tu peux faire une requête

**LeoAnderson** · 19/04/2007, 12h40

donc tu vas faire un where not in select ou where not exist ?
sur une table énorme, c'est carrément à éviter !

**orafrance** · 19/04/2007, 13h59

Evidemment ça dépend du contexte mais on peut imaginer un INSERT AS SELECT ORDER BY id

si la PK est l'id qui est un NUMBER tu sauras quelle ligne tu as inséré en dernier et tu peux refaire le copy avec id > x.

L'export sur des très gros volumes peux également poser problème et si tu as un plantage en cours de route tu dois tout refaire également

Au fait, Datapump ne remplacerait-il pas COPY ? Un fichier est aussi nécessaire ?

**Fiora** · 19/04/2007, 14h05

Merci pour vos réponses !

Franchement je suis un peu perdu, avec le peu de connaissance que j'ai en base de données
j'ai commencer de voir avec la commande COPY:
COPY {FROM database | TO database | FROM database TO database} {APPEND|CREATE|INSERT|REPLACE} destination_table [(column, column, column, ...)]
USING query

et je vois pas comment faire des commit intermédiares ????

J'ai également lancer l'export, ça fait 18 minute pour exporter la table (20 million d'enregistrement)
mais j'ai un autre problème sur l'import, le tablespace de ma table en B2 semble insuffisant ! et la une autre galère

**orafrance** · 19/04/2007, 14h09

COPYCOMMIT

**Fiora** · 19/04/2007, 14h16

Merci Orafrance

Je vais lancer un test avec un order by PK et un commit intermédiare ....

**Fiora** · 19/04/2007, 15h04

je comprend rien !! j'ai essaie de copier 99999 lignes, comme suit:
sa l'air de bien marcher , mais j'ai rien dans ma table !!

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
SQL> set arraysize 5000
SQL> set copycommit 5000
SQL> COPY FROM sysadm/admb1@b1 -
 TO sysadm/admb2@b2 -
 INSERT SYSB.PAYMENT -
 USING SELECT * FROM  SYSA.PAYMENT where rownum <100000 ORDER BY  INVOICE_NO, CR_TRANS_ID;
 
Array fetch/bind size is 5000. (arraysize is 5000)
Will commit after every 5000 array binds. (copycommit is 5000)
Maximum long size is 80. (long is 80)
   99999 rows selected from sysadm@b1.
   99999 rows inserted into SYSB.PAYMENT.
   99999 rows committed into SYSB.PAYMENT at sysadm@b2.
 
SQL> select count(1) from SYSB.PAYMENT;
 
  COUNT(1)
----------
         0

Quelqu'un a une idée ?

**LeoAnderson** · 19/04/2007, 16h37

Envoyé par orafrance

Au fait, Datapump ne remplacerait-il pas COPY ? Un fichier est aussi nécessaire ?

Si, en 10g, avec datapump on pourrait faire un export/import via dblink. mais pour ça, faut être en 10g !

**Fiora** · 20/04/2007, 14h37

Je ne sais plus quoi faire !!!!!!!

Personne a une ideé sur ma question précédente sur le COPY ?

Sinon, l'export/import prend aussi bcp de temps:

Export: 20 minutes
Import: 5h et toujours en cours !!!!

(sans compter le transfert du dump 3,4 Go)

Y'a t'il d'autres méthodes pour migrer/copier une table volumineuse d'une base a une autre ?

**Yorglaa** · 20/04/2007, 14h54

Salut,
je constate juste un détail :
avec ton COPY, tu te connecte aux 2 bases avec un username SYSADM alors qu'ensuite tu va faire l'insert dans une table située dans le schéma SYSB en sélectionnant les lignes d'une table située das un schéma SYSA.

est-ce que par hasard tu n'aurais pas là un problème de droits que COPY ne te remonterait pas ?

**Fiora** · 20/04/2007, 15h35

Bonne remarque , mais mon user SYSADM a tout les droits sur la table SYSB.PAYMENT

En plus, le resultat du COPY dit:
99999 rows selected FROM sysadm@b1.
99999 rows inserted INTO SYSB.PAYMENT.
99999 rows committed INTO SYSB.PAYMENT at sysadm@b2.

Je trouve ça bizzar !!