lenteur insertion en masse

Bonjour,

Petit problème avec une base Oracle 10 (le même traitement sur une base Oracle 8i ne pose pas problème) :
- début transaction (logicielle, via prog Delphi)
- boucle 5000 fois insertion d'1 enreg dans table A
- 1 insertion du genre INSERT INTO B SELECT * FROM A (donc insertion en 1 fois de 5000 enreg.)
- COMMIT (fin transaction)

l'instruction INSERT prend 20 minutes !

Or, lorsque je me pointe sur la base pour tester les tables et d'autres insertions, tout baigne, aucun délai pour faire un insert de 5000 enreg. en une fois, les index sont OK, les Foreign Key aussi, bref ça prend une demi-seconde...

Je ne suis pas un pro d'Oracle, y a-t-il une différence entre 8i et 10 qui justifierait de faire un commit entre les 5000 insertions et l'insertion de 5000 enreg. en une fois ?

Merci pour toute idée !

Citation:

---

Je ne suis pas un pro d'Oracle, y a-t-il une différence entre 8i et 10 qui justifierait de faire un commit entre les 5000 insertions et l'insertion de 5000 enreg. en une fois ?

---

A priori, je dirais non. Les 2 bases sont-elles sur les même serveurs ? Si non, quel est le serveur censé être le plus rapide ? C'est peut-être un problème de charge temporaire sur le serveur qui héberge la base ? C'est peut-être un problème de configuration de la base. Mais sans analyse détaillée, il est impossible de résoudre un problème de performance. Si vous arrivez à reproduire ce problème, il faut analyser ce qui se passe en détail avec un outil comme la trace SQL et TKPROF par exemple.

bonjour,
je dirai que si tu ne risques pas d'exploser ton rollbacksegment, l'insertion des 5000 puis le commit devrait être plus efficace.

ensuite, il faut s'interroger sur les données que tu veux insérer dans la table, sont elles au bout, réparties entre les données déja existantes ? dans ce cas voir le pctfree de la table

vérifie aussi qu'il n'y a pas de trigger ou d'index en plus

c'est un début ...

Fait une trace + tkprof sur ton programme. Une fois j'ai découvert qu'il y avait un select entre 2 insert qui ralentissait l'execution.

merci pour votre aide.

Je vais me renseigner pour Trace et TKProf (mais la base est chez le client et ça me paraît compliqué de leur demander ça...).

Il reste que c'est la même base qui est passée en Oracle 10, donc les données sont les mêmes, la répartition des index est donc aussi la même, etc...

Quand bien même il y aurait des SELECT inopportuns (il n'y en a pas), ils étaient là aussi avant, avec la base Oracle 8i...

Je pencherais plutôt, comme le suggère pifor, d'un problème de configuration de la base, mais lequel ?

Je vais tâcher de mettre la main sur le fichier de config et le poster ici car c'est un peu du chinois pour moi...

Citation:

---

Envoyé par zorino

Quand bien même il y aurait des SELECT inopportuns (il n'y en a pas), ils étaient là aussi avant, avec la base Oracle 8i...

---

Il faut savoir que en 10g, il y a des statistiques automatiques. voir :

Code:

---

SELECT * FROM DBA_SCHEDULER_JOBS;

---

Si sur la 8i tu n'avais pas de stat, c'est le mode rule qui s'applique. Sur la 10g, c'est le mode ALL_ROWS. Dans le cas d'insertion massive, le plan de requête se met vite à déconner car les stats sont trop vieille.

J'ai fait du développement en Delphi quand j'étais jeune et quelque fois les composants delphi font une requête pour vérifier que les données en mémoire sont toujours ok.

Es-tu sûr qu'il y a une seul instruction insert ? Et pas 5000 avec un select entre chaque insert ???

Citation:

---

Envoyé par Débéa

Es-tu sûr qu'il y a une seul instruction insert ? Et pas 5000 avec un select entre chaque insert ???

---

oui, certain.
C'est un INSERT INTO... SELECT ( ), lequel SELECT renvoie les 5000 lignes.

Salut,
est-ce que les contraintes, les indexes, les triggers et tout le toutim sont STRICTEMENT identiques sur les 2 bases ?

imagine un trigger qui serait "after statement" sur la 8i et "for each row" sur la 10 g... bonjour les dégats !

autre chose, est-ce que le contexte opérationnel est le même dans les 2 cas ? je veux dire que les triggers ou les contraintes sont activés (ou désactivés) dans les 2 cas de figures de manière identique ?

et le Select tout seul (tu nous parles d'un insert-select), as-t'il les mêmes perf sur les 2 bases, auquel cas le problème vient bien de l'insertion elle même... ou est-ce que le Select lui-même provoque des performances très différentes ?

quid des statistiques sur les tables... elles sont à jours ? des 2 côtés ?