Discussion :

[nuke_y]

Bonjour j'ai un comportement qui m'étonne (mais qui est peut-être normal) dans ma base.

Je suis en train de faire tourner un traitement mensuel qui delete puis insère OU update des lignes en masse dans une table. Cad qu'il essaye d'updater, et si le nombre de lignes mises à jour = 0, il insère.

Je manipule environ 300 000 lignes, et dans le cas actuel j'efface environ 300 000 lignes (les anciennes), j'insère 300 000 lignes (les nouvelles) et n'en update aucune (car aucune des nouvelles lignes n'existe dans les anciennes non effacées).

Je génère les inserts un par un et je commit tous les 10 000 inserts.

Ce qui m'étonne c'est que sous OEM, il m'affiche dans les opérations longues des sort Output assez longs (genre 6/7 mn).

Le plan d'exécution ne me parle que d'un INSERT STATEMENT avec un coût de 364, 398 855 lignes et 21 033 Ko.

Je n'avais jamais regardé de près ces traitements là, et je trouvais normal qu'il passe 20mn à insérer 300 000 lignes mais d'un seul coup je me pose un peu des questions...

Pour info la table dans laquelle il insère a environ 400 000 lignes (il en reste toujours un peu des fois précédentes en gros).

Il y a :
1 PK sur 4 champs
7 index (pour clés étrangères d'autres tables référençant celle là).
Pas de trigger

Si vous pouvez m'éclairer un peu (déjà savoir si c'est normal ou pas). Merci

[nuke_y]

Hum j'ai ptet compris.

Il fait la requête de sélection des données sources. Puis dès les premières données il commence l'update/insert dans la cible. Mais pendant ce temps il continue à ramener des données. Ce qui fait que je ne vois que l'INSERT dans le plan d'exécution mais l'opération de sort output que je vois est celle de la requête de sélection des données sources.

C'est ça ?

[orafrance]

je ne sais pas ce qui se passe mais j'espère que tu utilises le BULK COLLECT pour faire ça

[nuke_y]

Non pas du tout.

On peut utiliser le bulk collect dans un cas pareil ? Je pensais que c'était pour une série d'insertion en masse ? Moi j'ai besoin de savoir si l'update a eu lieu ou pas, si l'insertion s'est bien passée, etc.

Je suis obligé de travailler ligne par ligne.

[orafrance]

Ha oui... tu as raison... mais tu pourrais t'en sortir en remplaçant tout ça par un MERGE

[nuke_y]

Oui c'est vrai MAIS ça c'est le code généré par un ETL qui ne connaît pas les merge (compatibilité multi-SGBD oblige).

Bon sinon ça semble cohérent ce que j'ai dit dans mon 2e post ?