Performances Curseur / Complexité requête SQL

Performances Curseur / Complexité requête SQL - SQL/NoSQL - Programmation

Marsh Posté le 06-02-2012 à 16:30:44    

Salut,
 
J'utilise la librairie DBLink de IBM (Ilog).
J'ai deux requêtes SQL de type select dont je parcours le résultat via un curseur, le tout sur une base Oracle 9.
Les deux requêtes fournissent exactement le même résultat (même nombre de colonnes, même nombre de lignes et mêmes valeurs) mais par des tables et jointures différentes.
 
Je suis surpris car le temps de parcours de l'ensemble des lignes du résultat via les deux curseurs est très différent. Avec la requête la plus simple, le temps de parcours est inférieur à la seconde. Avec l'autre requête plus complexe, le temps de parcours s'approche des 10 secondes.
 
Je n'ai jamais pensé que la complexité d'une requête pouvait avoir un impact sur le parcours des lignes qu'elle renvoit via un curseur. En fait j'ai toujours cru que la requête produisait un tableau de valeurs et que le curseur parcourait ce tableau de valeurs. or il semble que ce ne soit pas aussi simple.
Quelqu'un peut-il me le confirmer ?
 
 ;)


---------------
"Comme des pommes d'or sur des ciselures d'argent, Ainsi est une parole dite à propos" (Proverbes de Salomon)
Reply

Marsh Posté le 06-02-2012 à 16:30:44   

Reply

Marsh Posté le 06-02-2012 à 16:49:55    

Les Curseurs c'est le mal.
En fait les boucles en general c'est le mal.
Je dirais meme que tout traitement autre que du retrait de données (sans les formater) c'est le mal.
 
Le mal ca n'a rien a faire dans une query :)
 
Maintenant, il y a problablement moyen de reecrire ton brol sans curseur ni boucle et ca tournera bien plus vite.

Reply

Marsh Posté le 07-02-2012 à 13:54:47    

Oliiii a écrit :

Les Curseurs c'est le mal.
En fait les boucles en general c'est le mal.
Je dirais meme que tout traitement autre que du retrait de données (sans les formater) c'est le mal.
 
Le mal ca n'a rien a faire dans une query :)
 
Maintenant, il y a problablement moyen de reecrire ton brol sans curseur ni boucle et ca tournera bien plus vite.


Le curseur en Oracle ça existe toujours, qu'il soit créé en PL/SQL ou dans ton client Oracle ça revient au même, dès que tu fetch, t'as un curseur. Et les perfs sont sans doute différente car le plan d'execution n'est pas le même.


---------------
| AMD Ryzen 7 7700X 8C/16T @ 4.5-5.4GHz - 64GB DDR5-6000 30-40-40 1T - AMD Radeon RX 7900 XTX 24GB @ 2680MHz/20Gbps |
Reply

Marsh Posté le 07-02-2012 à 14:12:46    

C'est pas parceque ca existe qu'il faut l'utiliser.
Si tu utilises un curseur ca veut dire que tu bosses en row by row au lieu de travailler avec des set.
 
Il n'y a que de tres tres rare cas ou on doit travailler avec un boucle (curseur ou autre) et c'est quasi toujours lié a des processus de maintenance de schema/db fait par des DBA. Tout ce qui est applicatif peut etre fait autrement, plus rapidement.

Reply

Marsh Posté le 07-02-2012 à 17:00:28    

Oliiii a écrit :

C'est pas parceque ca existe qu'il faut l'utiliser.
Si tu utilises un curseur ca veut dire que tu bosses en row by row au lieu de travailler avec des set.
 
Il n'y a que de tres tres rare cas ou on doit travailler avec un boucle (curseur ou autre) et c'est quasi toujours lié a des processus de maintenance de schema/db fait par des DBA. Tout ce qui est applicatif peut etre fait autrement, plus rapidement.


En Oracle un select = un curseur.
 
Si tu déclares un curseur ça ne veux pas dire que tu va forcement fetch en row by row. Tu peux très bien faire du fetch by array en PL/SQL.


---------------
| AMD Ryzen 7 7700X 8C/16T @ 4.5-5.4GHz - 64GB DDR5-6000 30-40-40 1T - AMD Radeon RX 7900 XTX 24GB @ 2680MHz/20Gbps |
Reply

Sujets relatifs:

Leave a Replay

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