Discussion :

[ludvax]

bonjour a tous,
Problème: La mise à jour de 60 000 lignes met entre 3H et 4H !!!
Objectif: Mettre à jour chaque enregistrement selon des valeurs récupéré par une requête chaque enregistrement.

Au début j'avais crée un curseur constituant ma sélection pour effectué la MAJ de chaque enregistrement dans une boucle.
Résultat éffectué en 3H-4H.

Ce temp d'éxecution étant trop long (vous en conviendrez) ma permis de rechercher une autre solution et j'ai trouvé le paramètre BULK COLLECT.
J'ai donc recommencé ma procédure stockée avec:
- ma sélection renvoyant les différentes valeurs dans des tables (précédemment déclaré) du style:
section DECLARE :

* TYPE MA_TABLE IS TABLE TABLE_EXISTANTE.COLONNE%TYPE
mytab MA_TABLE

section BEGIN :
* SELECT CHAMP1 BULK COLLECT INTO mytab FROM TABLE
WHERE CRITERE...

* FORALL i IN 1..mytab.COUNT
UPDATE TABLEMAJ
SET COLONNE = mytable.colonne
WHERE CONDITION;

COMMIT;

Aussi, le serveur utilisé (en production) est avec la version Oracle 8i mais les résultats sont les même sur le serveur de test (Oracle 10g).

Si vous savez d'où viens le problème !
Parce que là je séche !!!

merci

[SheikYerbouti]

Qu'est-ce qui prend du temps : le select du curseur ou l'update derrière ?

Il y a t-il des triggers sur la table ?

[orafrance]

Faudrait ajouter une LIMIT au BULK... il y a peut-être des contentions en mémoire.

[ludvax]

Je pense que c'est l'update qui est long mais cela est de la pure supposition.

Oui il y a une trigger sur la table lors de l'insertion, mais ma procédure stockée est executer une fois les données insérées.

Dans mes docs oracle je n'ai bien compris l'utilisation de LIMIT.
Peux tu m'expliquer son utilité ?

merci d'avance

[SheikYerbouti]

Cela permet de procéder par "tranches" ou "paquets" afin de ne pas exploser le rollback segment, par example.

[orafrance]

il permet de définir la taille des lots pour faire un traitement par tranche

[SheikYerbouti]

autrement, c'est quoi la condition de l'update ?
Sinon, une technique est de ramener le ROWID dans la table PL/SQL et de l'utiliser dans le FORALL

[ludvax]

Ok je vais testé le paramètre LIMIT !

[SheikYerbouti]

Ok je vais testé le paramètre LIMIT !

Je ne pense pas que ça réduira pas le temps de traitement

[ludvax]

Visiblement !

C'est toujours aussi lent !

Quoi faire ?

[j6m]

tu testes en 10 G pour passer en prod en 8i? tu as raison de ne pas en dire plus il te faut de quoi tester et vérifier sur au moins le m^me OS et le m^me Oracle.

[SheikYerbouti]

ENcore une fois, quelle est la condition de la clause WHERE de l'update ?
est-elle optimisée ? que donne le plan d'exécution sur une seule ligne ?

[ludvax]

la condition de la clause WHERE de l'update est de type entier "IDSEL" (passé en paramètre) et un identifiant "MCU" récupéré par le curseur (ou dans le cas du BULK COLLECT d'un SELECT... cf:plus haut) donc différent pour chaque personne.

Bref, dans ma selection avec en paramètre "IDSEL", je récupère une liste de personne dont je dois mettre à jour un code.
Pour ce faire j'utilise l'identifiant "MCU" en condition de mon update avec également "IDSEL".

Ex:
FORALL i IN tableau.first..tableau.last
UPDATE TABLE SET COLONNE_CODE = tableau(i).CODE
WHERE COLONNE_MCU = tableau(i).MCU
AND COLONNE_IDSEL = IDSEL;

COMMIT;


Comment optimizer dans ce cas ?

PS: Je teste d'abord sur 10g avec SQLDevelopeur "Raptor" et lorsque le temps de traitement sera acceptable je testerai sur le serveur de test en Oracle8i avant de passé cela en prod !!!

[SheikYerbouti]

ces 2 colonnes sont-elle indexées ? si oui, les indexes sont-ils valides ?
quel est le temps d'exécution d'un update passé à la main sur une seule ligne ?

[Drizzt [Drone38]]

Tu es sur que le trigger sur ta table n'est pas activé à chaque update?
J'ai eu un problème de perf il y a peu du meme genre avec une requete qui mettait 6H pour à peu pret le meme nombre d'update et c'était l'activation des triggers qui bouffait la majorité du temps. Meme si les triggers ne faisaient rien.
Maintenant la requete met 2-3min ... (avec accessoirement un index mieux defini qui à divise le temps par deux)

Sinon effectivement regarde si tes 2 colonnes sont bien indexées, et si l'index est bien utilisé lorsque tu fais un update. (sous TOAD par ex, regarde l'explain plan et tu devrais voir apparaitre ton index, si il y a un full table access c'est pas bon).

[ludvax]

Tout d'abord merci a vous, pour vos réponses et remarques qui m'on permis de rechercher où je n'avais pas encore cherché !

Effectivement, j'avais pensé au index que devais être optimiser, j'ai donc crée un index sur deux champ dont la paire est unique.

Cependant, il y avait un type d'index que je ne connaissai pas et qui fût la réponse à ma question j'ai nommé "BITMAP".

J'ai donc crée un index de type BITMAP sur les colonnes dont la paire est unique et je suis passé d'un temp de traitement de 3H-4H à 120 secondes !!!

C ti pa magnifique !


Encore merci pour votre aide