Discussion :

[dbaenbois]

Bonjour,

J'ai 2 BDD :
- BDD9i est une 9i
- BDD10g est une 10g
je souhaite inserer des records issus d'une requete de ma BDD9i vers une table de ma BDD10g

Quand je fais un

INSERT INTO matableremote@BDD10g
SELECT t1.champ1,t2.champ1,t3.champ1
FROM matable1 t1, matable2 t2, matable3 t3
avec tout plein de where....

Il met environ 2 minutes pour copier 15 records...
Et il ne me rends jamais la main avec 50000 records.

Si je passe par une table temporaire avec un
create matabletemp as
SELECT t1.champ1,t2.champ1,t3.champ1
FROM matable1 t1, matable2 t2, matable3 t3
avec tout plein de where....

il met 20 secondes pour creer la table de 50000 records
et le
INSERT INTO matableremote@BDD10g
SELECT champ1,champ2,champ3 from matabletemp
met 15 secondes ...

Une idée ???

[remi4444]

oui, il fait des jointures à travers le réseau...

La règle est la suivante:

- quand toutes les tables d'une requête sont issues du même dblink, oracle exécute entièrement sa requête sur le site distant

- quand la requête concerne des tables sur plusieurs db_links différents ou sur un mélange db_link / local, oracle choisi en fonction de critères mystèrieux (enfin pour moi en tout cas)

Quand tu fait un :

Code :

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

1
2
3
insert into table_distante@DLINK 
 select machin, bidule 
from table_locale1, table_locale2 etc...

Il considère qu'il est dans le 2ieme cas donc il peut choisir de faire certaines opérations en local et certaines en distant. tu peux le voir en éditant le plan d'exécution.

Par exemple imagine qu'il doivent faire une jointure par HASH entre 2 accès complets sur 2 tables locale puis insérer le tout sur une table distante. Tu vas t'attendre à ce qu'il fasse sa cuisine en local et qui insère le tout à la fin.... Et bien parfois, il choisi de balancer le contenu complet de tes 2 tables dans ton db_link et faire l'opération de jointure sur la base distante!

Ceci à comme double effet:
- de rendre la procédure tres longue
- de saturer complètement le réseau

Théoriquement, en passant les stats sur les 2 bases, il est censé choisir le bon plan, mais dans la pratique, il se plante trés souvent. C'est pourquoi, il faut éviter de faire des requête avec jointures compliquées (meme avec jointure tout court...). La méthode la plus stable est de faire une vue de manière à ce que ta requête devienne un truc du genre:

Code :

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

1
2
3
4
5
insert into table_distante@DBLING
 select machin, bidule, etc... 
  from vue_locale
 where truc = bazard
  and etc...

[dbaenbois]

Merci pour ta reponse rapide...

Je comprends bien ce que tu dis... seulement meme en passant par une vue le traitement est tout aussi long.

alors que le select * de cette vue est super rapide...

La seule soluce (pour moi...) pour l'instant c'est une table temporaire a defaut de trouver mieux
Je continue a chercher de mon coté...

@+

[remi4444]

meme en passant par une vue le traitement est tout aussi long.

tiens... moi j'avais été confronté au problème en 8i, et cette méthode fonctionnait bien (elle était même préconisée sur le metalink si je me souviens bien...)

Est-ce que tu as essayer d'utiliser le hint /*+ MERGE (la_vue) */ ?

alors que le select * de cette vue est super rapide...

c'est rapide sur l'ensemble ou c'est toad (ou autre outil ne fetchant que le début du curseur) qui te renvoi les premières lignes rapidement ?

[dbaenbois]

... pas mieux avec le hint /*+ MERGE (la_vue) */ (merci quand meme )

J'utilise sqlplus sous linux...
Et quand je dis c'est rapide, l'affichage de mes lignes est instantané....

[remi4444]

pas mieux avec le hint /*+ MERGE (la_vue) */

euh... quand je dit "la_vue" il faut remplacer par le nom ou l'alias de la vue que tu utilises, on est bien d'accord ?

Il faudrait éditer le plan d'exécution pour en avoir le coeur net, il va y avoir l'étiquette "REMOTE" à chaque fois qu'il décide d'envoyer un flux dans le dblink.