Discussion :

[fdraven]

Système : Oracle 8.1.7 sur windows xp

Machine : Pentium 4 3.40 Ghz avec un disque dur de 160 Go

Contexte : Après le test d'une application sur un jeu d'essai d'enregistrements assez réduit (50k lignes), je suis passé à un test avec un nombre d'enregistrements plus conséquent ( 1M de lignes).

Problème :

Code :

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

INSERT INTO TABLE1 (Champ1....Champ17) SELECT Champ1...Champ17 FROM TABLE2;

résultat :

Code :

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

1
2
3
948404 ligne(s) créée(s).
 
Ecoulé : 00 :05 :302.95

Est-ce normal que la requête d'insertion mette 5 minutes alors qu'il n'y a aucun index sur les 2 tables et aucune jointure pour seulement 1M de lignes ?
Que faut-il changer pour améliorer la performance de la requête ? Quand j'ai regardé la consommation du cpu, je ne suis qu'à 10% d'utilisation comment passer à 100% de consommation ?

Merci d'avance de vos réponses.

[zekey]

Tu commit tout les combien ?

[fdraven]

Je lance l'instruction commit à la fin de l'insertion.

[zekey]

aaaaaaarrrrgg
pas bon ca (enfin ca dépend) sous quelle DB ?
essaye un commit à 10000

[fdraven]

Comment tu spécifies en sql de faire un commit tous les 10 000 ?

pas bon ca (enfin ca dépend) sous quelle DB ?

Système : Oracle 8.1.7 sur windows xp

[zekey]

Tu spécifie pas tu fais un curseur et tu loop dedans
ou alors tu un insert avec rownum.

[scornille]

Ce qui ralentit ta requete c'est le suivi de la transaction ... Si tu fais un commit ou un rollback par la suite ...
Si dans tous les cas tu ne fais qu'un commit et que tu ne risque pas de plantages tu peux préciser NOLOGGING en fin de ton ordre : aucun suivi ne sera effectué. Ce n'est pas le plus beau mais surement le plus efficace.

Code :

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

INSERT INTO TABLE1 (Champ1....Champ17) SELECT Champ1...Champ17 FROM TABLE2 NOLOGGING;

[SheikYerbouti]

Je ne pense pas que le commit intermédiaire change quoi que ce soit. Le Commit en lui-même n'est pas long par rapport au Rollback.

Le Commit intermédiare sert surtout à ne pas exploser le rollback segment.

[lalystar]

Tu peux essayer de passer la table finale en nologging :

Code :

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

1
2
3
4
 
alter table TABLE1 nologging;
 
INSERT /*+ append */ INTO TABLE1 (Champ1....Champ17) SELECT Champ1...Champ17 FROM TABLE2;

Ca générera nettement moins de redo, mais ca peut faire hérisser ton DBA... a voir car la modif ne sera pas réflétée dans les redo et ca peut poser des problemes dans le cas de backup à chaud ou de standby databases.


Laly.

[aline]

Tu peux essayer de passer la table finale en nologging :

Code :

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

1
2
3
4
 
alter table TABLE1 nologging;
 
INSERT /*+ append */ INTO TABLE1 (Champ1....Champ17) SELECT Champ1...Champ17 FROM TABLE2;

Ca générera nettement moins de redo, mais ca peut faire hérisser ton DBA... a voir car la modif ne sera pas réflétée dans les redo et ca peut poser des problemes dans le cas de backup à chaud ou de standby databases.


Laly.

Cela peux faire hérisser les DBAs mais pas les DBAtes!
Mais bases de prod sont en FORCE LOGGING. Alors, mes developpeurs, ils font ce qu'ils veulent!


Sinon, plus sérieusement, ama le problème ne vient pas du cpu. Peux être les I/O?

Peux tu faire un tkprof de ta requête pour que l'on voie ou est le problème?

[lalystar]

Question bete : y a t il des triggers sur la table dans lequel on insère ?


Laly.

[fdraven]

En effet, j'ai un trigger sur la table d'insertion qui permet de gérer une séquence à chaque nouvelle ligne insérée. Tu penses que la lenteur vient du trigger ? Existe-t-il une méthode plus rapide que la gestion d'une séquence dans un trigger pour un numéro auto ?

Merci d'avance de vos réponses.

[PpPool]

En effet, j'ai un trigger sur la table d'insertion qui permet de gérer une séquence à chaque nouvelle ligne insérée. Tu penses que la lenteur vient du trigger ? Existe-t-il une méthode plus rapide que la gestion d'une séquence dans un trigger pour un numéro auto ?

Merci d'avance de vos réponses.

Code :

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

1
2
 
INSERT INTO ma_table(col1, col2, ...) VALUES (ma_seq.nextval,....);

quel est l'intéret du trigger ?

[aline]

oui,

tu peux faire

Code :

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

1
2
 
INSERT INTO TABLE1 (MA_SEQUENCE, Champ1....Champ17) SELECT Ma_SEQUENCE.NEXTVAL,Champ1...Champ17 FROM TABLE2;

Cela améliore les perfs mais ,d'expérience, c'est négligeable.

[LeoAnderson]

En effet, j'ai un trigger sur la table d'insertion qui permet de gérer une séquence à chaque nouvelle ligne insérée. Tu penses que la lenteur vient du trigger ? Existe-t-il une méthode plus rapide que la gestion d'une séquence dans un trigger pour un numéro auto ?

Merci d'avance de vos réponses.

Code :

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

1
2
 
INSERT INTO ma_table(col1, col2, ...) VALUES (ma_seq.nextval,....);

quel est l'intéret du trigger ?

L'intérêt est d'être sûr que la séquence soit appellé, et ce, quelque soit la façon dont sont réalisées les insertions !!!

[fdraven]

Grâce à vos conseils, je viens de diviser le temps par 2.

Code :

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

1
2
3
948404 ligne(s) créée(s).
 
Ecoulé : 00 :02 :35.21

Si j'ai bien compris comment fonctionner les séquences, est-ce que ça ne serait pas plus rapide de gérer le numéro auto avec une variable directement en pl/sql pour éviter le temps d'accès et de mise à jour d'une séquence à chaque enregistrement ?

Merci d'avance de vos réponses.