Discussion :

[mb240579]

Bonjour tout le monde,
SVP je suis sur un projet d'optimisation du code PLSQL et j'aimerais bien savoir s'il y a une règle à suivre pour optimiser un curseur.
Merci de votre aide

[McM]

L'optimisation est comme celle d'une requête normale.

Par contre, j'avais lu (il y a quelques années, donc ce n'est peut être plus valable) qu'il valait mieux déclarer le curseur que de le mettre directement dans le FOR r IN ( ...)

Mais moi, je code quasiment toujours dans le FOR r IN (select...), c'est plus simple pour débugger ou lire la procédure sans devoir remonter tout en haut voir la déclaration.

[mnitu]

C’est toujours sympa avec les curseurs en PL/SQL, chacun à ses préférences et de plus la mythologie est pleine des faux bons conseilles. A une époque Oracle (7) disait qu’il était mieux d’utiliser un curseur à la place d’un Select ... Into parce que pour le Select ... Into il y a deux fetch à faire : un pour ramener la valeur et un autre pour tester l’exception TOO_MANY_ROWS. Si c’était seulement ça le souci …

Le For … In est optimisé derrière la scène par Oracle à partir de la 10g pour utiliser array fetching. Oui, mais le curseur explicit donne encore bien plus de contrôle, et donc plus optimale, quand il est utilisé avec le bulk fetching.

Mais, en fait ce qui plombe souvent les perfs sont (en supposant que la requête SQL est optimale) :

• les curseurs qui ramènent des valeurs utilisées tout simplement pour alimenter des autres curseurs qui ramènent des valeurs... c'est-à-dire les jointure en PL/SQL
• le traitement ligne par ligne à la place du traitement par ensemble ou lot

[mb240579]

Merci pour vos suggestions...