Discussion :

[oradevb]

Bonjour,

je propose de réfléchir aux différentes façons d'optimiser un traitement oracle,

Le cas est simple :
Pour chaque occurrence d'une table "A", j'ai un traitement à effectuer qui met à jour de nouvelles colonnes sur chaque ligne correspondante.
Le problème est la forte volumétrie de la table qui risque de faire durer les temps de traitement s'il est séquentiel (parcours d'un curseur basé sur un select)

Je pense partitionner cette table en N partitions
puis de lancer simultanément N sessions oracle afin que chaque session travaille sur une partition différente

qu'en pensez-vous?

[NGasparotto]

Difficile a dire, en tout cas, travailler explicitement sur les partitions de table est plutot une fausse bonne idee.
Au moins pour deux raisons : un, c'est bypasser l'optimizeur Oracle, et deux, c'est pas souple.
Si tu as la licence EE + partitioning (option additionnelle) alors pourquoi pas sur des tres gros volume, mais ensuite profiter du parallelisme qu'Oracle est capable de faire tres bien tout seul, et pas travailler explicitement sur les partitions.

Nicolas.

[oradevb]

Merci pour ta réponse Nicolas.
Tu penses que la meilleur solution est donc de laisser faire Oracle.
Le sgbd est-il capable de parralelliser tout seul ce type de traitement?

Lecture d'un curseur basé sur un select (full table)
pour chaque occurrence
1) appel à une procédure de mise à jour des colonnes concernées
2) commit

[NGasparotto]

...Lecture d'un curseur basé sur un select (full table)
pour chaque occurrence
1) appel à une procédure de mise à jour des colonnes concernées
2) commit

C'est typiquement le type d'algo que j'eviterai pour des raisons de perf. Je prefere de loin une et une seule requete dont Oracle pourra eventuellement paralleliser l'execution sur les differentes partitions le cas echeant.
Je ne comprends pas le besoin de faire un appel a une proc pour chaque ligne d'un curseur (et de plus un commit a chaque modif !!), c'est tres couteux, Oracle n'y pourra pas grand chose, et du fait d'un algo... heu disons... pas bien choisi, tu es en train de monter une usine a gaz pour contourner ce mauvais choix.
Mais biensur, plus de details de ta part pourrait nous eclaircir sur tes intentions exactes.

Nicolas.

[oradevb]

comme la volumétrie est importante, je me suis dit qu'il valait mieux essayer de tracer un peu le traitement (pour certaines lignes il y aura des anomalies car impossibilité de valoriser les zones, exemple : informations manquantes ou erronées), gérer des flag pour permettre en cas d'incident de ne traiter uniquement ce qui n'a pas encore été fait et ne pas recommencer tout depuis le début.

d'où le fait de commiter à chaque ligne

ta solution d'update global est interessante, encore faut-il pouvoir le faire au vue des règles de gestions et contrôles, mais toujours pour des raisons de volumétrie, ne va t il pas y avoir de pb au niveau du tablespace temporaire etc.. si pas de commit intermédiaire ?

[NGasparotto]

Committer a chaque ligne est encore pire, tu vas corrompre le UNDO tablespace est risque d'obtenir l'erreur ORA-1555.
Ensuite, en fonction de ta version d'Oracle, que l'on ne connait pas, tu as des fonctions telles que DBMS_ERRLOG qui creent une table de log pour loguer les lignes provoquant des erreurs.
Mais la, on ne parle que de theorie pure, ou presque dans le vide puisque on ne connait pas les details de ta proc et contraintes.

Nicolas.

[oradevb]

Merci pour ta réactivité.

voici la version:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

voici des explications concernant le traitement de chaque ligne pour valoriser les nouvelles colonnes:
1) recherche de données supplémentaire dans une autre table
2) transformation de champs existants
3) calcul complexe impossible à faire à partir d'un simple update (a priori, est-il possible à ce sujet d'appeler directement une fonction dans un select?)
4) concaténation du calcul précédent avec d'autres zones

[NGasparotto]

Je ne dis pas forcement que c'est possible de faire via une requete, une etude un peu plus approffondie est necessaire, en tous les cas, voici mes reponses aux questions :

1) recherche de données supplémentaire dans une autre table

Jointure ?

2) transformation de champs existants

Transformation ? Ca veut dire quoi exactement ?

3) calcul complexe impossible à faire à partir d'un simple update (a priori, est-il possible à ce sujet d'appeler directement une fonction dans un select?)

Oui, appeler une fonction depuis un select est tout a fait possible.

4) concaténation du calcul précédent avec d'autres zones

Par requete, fonction analytique ?

Nicolas.

[mnitu]

Si vraiment le calcul est complexe et l'update ne corresponde pas l'idée est d'utiliser une fonction pipelined pour générer les nouvelles données à partir des anciens et de transformer le traitement en

Code :

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

1
2
 
create table … as select from table(fonction_pipelined)

Cette solution permet de garder le parallélisme du traitement mais il faut aussi vérifier que assez des ressources sont disponible pour traiter en parallèle.

[oradevb]

je vous trouve très intéressant
il faut que je mette en pratique les différentes possibilités
avec un échantillon de données conséquent
et que je compare les temps de traitements