[Oracle] Optimisation des paramètres Oracle, update de masse

Optimisation des paramètres Oracle, update de masse [Oracle] - SQL/NoSQL - Programmation

Marsh Posté le 26-08-2002 à 17:31:35    

Voilà j'ai une procedure stockee qui met à jour plusieurs centaines d'enregistrements et elle met environ 5 minutes a s'executer pour mettre à jour 200 enreg (et j'en ai 200 000...) .
 
Dans la proc stock, il y a un select et un update et tout ca en boucle sur le nb d'enreg a mettre a jour.
 
y a t-il des parametres sur Oracle a verifier ou a changer pour ameliorer tout ca ?
 
Merci encore !! :)
 

Reply

Marsh Posté le 26-08-2002 à 17:31:35   

Reply

Marsh Posté le 26-08-2002 à 17:34:51    

A mon avis, c'est les requêtes qu'il faut optimiser, pas Oracle (bien que tu puisse désactiver les tests de cohérence des données par exemple - sur les FK par exemple -)
 
Tu peux poster ta procédure ?

Reply

Marsh Posté le 26-08-2002 à 18:03:46    

Voila la proc:
 
 
Select des enreg. dans un curseur
 
Parcours du curseur:
select pour trouver une valeur qui va servir a l'update dans une autre table (dans le where j'ai 30 champs environ )
si pas trouvé cherche dans une autre table  
 
puis update suivant le cas (en utilisant les cles primaires cette fois)
 
fin
 
Merci pour ton aide !
 

Reply

Marsh Posté le 26-08-2002 à 18:12:01    

Chui d'accord avec MagicBuzz : faut plutôt optimiser tes requêtes (du genre, pas trop de jointures ou utiliser des vues), les paramêtres Oracle n'ont pas grand' chose à voir la dedans, si ce n'est éventuellement le segment de rollback,  et encore, je n'en suis franchement pas sûr.

Reply

Marsh Posté le 26-08-2002 à 18:19:52    

pas de jointure, le select est fait dans une seule (gde) table

Reply

Marsh Posté le 26-08-2002 à 20:28:52    

Ouais nan, mais à la base, faudrait la requête (réellement)
 
A moins que tu ne puisses pas car confidentiel ;)
 
Grossomodo, je pense à ce genre de requête :
 

Code :
  1. UPDATE TaTable, TaDeuxièmeTable SET TaTable.ChampAMettreAJour = TaDeuxièmeTable.LeChampQuiContientLaNouvelleValeur
  2. WHERE [TesConditions]


 
En effet, il va tout faire en une seule fois, ce qui sera ENORMEMENT plus rapide.
 
Parceque 200 000 lignes c'est "tout petit" pour Oracle, donc c'est très étonnant que ça ramme autant. (ou alors tu bosses avec un très vieux serveur complètement surmené ;))

Reply

Marsh Posté le 27-08-2002 à 09:49:00    

Il y a un truc à vérifier en cas de problème de performance, c'est si tu as bien posé des index sur les champs utilisés dans le select.
 
Ne pas oublier dans lancer un Analyze Table après une création d'index, Oracle ne les prenant pas en compte automatiquement.

Reply

Marsh Posté le 27-08-2002 à 10:49:44    

irulan a écrit a écrit :

Il y a un truc à vérifier en cas de problème de performance, c'est si tu as bien posé des index sur les champs utilisés dans le select.
 
Ne pas oublier dans lancer un Analyze Table après une création d'index, Oracle ne les prenant pas en compte automatiquement.




Indexer aussi les champs updatés s'ils ont des contraintes d'unicités par exemple.

Reply

Marsh Posté le 27-08-2002 à 11:34:33    

irulan a écrit a écrit :

Il y a un truc à vérifier en cas de problème de performance, c'est si tu as bien posé des index sur les champs utilisés dans le select.
 
Ne pas oublier dans lancer un Analyze Table après une création d'index, Oracle ne les prenant pas en compte automatiquement.




Tiens t'es toujours sur ce forum maintenant que tu t'es exiler au lointain ?

Reply

Marsh Posté le 27-08-2002 à 13:32:08    

tomlameche > Ben oui, c'est moderne où je suis, on a une connexion au net... ;)


Message édité par irulan le 27-08-2002 à 13:33:08
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed