Comment fonctionnent les curseurs et le fetch ?

Slt les gars,

voilà j'ai certaines questions à propos des curseurs sous oracle.je me lancent donc :

1. quand on ouvre un curseur, est-ce qu'il exécute la commande le définissant et stocke les données quelque part, ou bien exécute-t-il la requête le définissant à chaque Fetch NEXT ?
2. si il les stock bien quelque part, où ? Dans une table temporaire dans le cas de données importantes et en mémoire pour des broutilles ou bien c'est qlq chose d'autres ?!

En fait, mes questions sont destinées à mieux comprendre ce mécanisme. Je vois souvent de la doc sur comment l'utiliser, mais rien sur comment il marche (même dans les bases de données open source).

Merci d'avance pour vos réponses.

Le Concepts Guide donne des éléments à ce sujet. Un curseur n'est qu'un pointeur vers une structure d'exécution interne. En général, le résultat de la requête n'est pas matérialisé dans une table temporaire: chaque instruction FETCH va accéder aux données.

d'abord merci pour ta réponse rapide

Si je comprends bien, la requête SQL encapsulée dans le curseur est effectivement exécutée à chaque FETCH.

J’ai encore une dernière question que j'ai oublié de poster dans mon message précédent.

Supposant qu'on a une requête Q1. quand on la fait passer à la moulinette (EXPLAIN analyze ...) le plan d'exécution retourné indique qu'un index qu'on appellera I1 a bien été utilisé afin d'améliorer le temps de réponse.

Quand j'encapsule cette même requête dans un curseur c1 et le fait passé à la moulinette, il me retourne un autre plan dans lequel il fait un scan séquentiel de la table. Il ne prend plus en compte l'indexe I1. est cette normale ? Un bug ou bien quelque chose m'a échappé ?

J’ai refait le passage à la moulinette plusieurs fois et j'ai toujours les mêmes résultats.

Est-ce exactement la même requête sur les mêmes données avec le même utilisateur Oracle ?
Un paramètre de session est-il différent comme OPTIMIZER_MODE ?
Il faudrait poster le code et les plans d'exécution avec la version exacte d'Oracle.

Citation:

---

Envoyé par subzero82

...
Si je comprends bien, la requête SQL encapsulée dans le curseur est effectivement exécutée à chaque FETCH.
...

---

C'est plutôt inexact! Analyse dans un fichier trace SQL les étapes Parse, Fetch et Exécute.

Citation:

---

Envoyé par subzero82

...
Supposant qu'on a une requête Q1...

Quand j'encapsule cette même requête dans un curseur c1 ...

---

Derrière chaque requête il y a un curseur implicite! Donc il n'a pas de différence conceptuelle entre un requête et une requête "encapsulé dans un curseur".

Citation:

---

Cursors
A cursor is a handle or name for a private SQL area—an area in memory in which a parsed statement and other information for processing the statement are kept.

---

Ok, je vais voire sa de prêt et vous tenir au courant. Il est vrai que j'ai omis de voir le fichier trace.

Je reviens sur les curseurs.

Je me suis amusé à écrire un petit programme en Pro*c dans lequel je me suis amusé à calculer le temps d'exécution d'une requête Q1 et d'un curseur C1 dans la définition est exactement la même.

je me retrouve avec l'équation suivante :

temps d'exécution dans un curseur c1 de Q1 =~ k * temps d'exécution sans curseurs.

où k est le nombre de fetchs effectué dans mon programme ProC

Je suppose que c'est le comportement voulu quand on sait qu'on fait appel à fetch (à partir d'un programme externe du serveur) pour des traitements lourds qui ne tienne pas en mémoire en temps normal.

Je vais continuer mes petites expériences en créant une petite procédure stockée qui encapsulera Q1 et une autre C1 et on verra.

Si mon hypothèse tiens la route et d'après ce que j'ai compris de vos remarques. Le mécanisme Cursor/fetch ne se comporte pas vraiment de la même manière quand se derniers est interne ou externe aux serveurs si je peux m"exprimer ainsi.

J’ai l’impression que tu nage dans la confusion ; c’est quoi un curseur externe et quoi un curseur interne ?
Que est-ce que tu veut dire par

Citation:

---

...
Je suppose que c'est le comportement voulu quand on sait qu'on fait appel à fetch (à partir d'un programme externe du serveur) pour des traitements lourds qui ne tienne pas en mémoire en temps normal.
...

---

Si tu veux qu’on se prononce sur tes tests poste le code (du programme en Pro*C). Si tu veux mesurer des temps d’exécution des requêtes SQL, utilisez la trace SQL.
Et il ne sera pas mal si tu te trouves le temps aussi pour lire Oracle Concepts et Oracle Application Developer’s Guide. Il y a pas mal des explications dedans.