Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
COUNT APRES UN SELECT DB2
Bonjour,
J'ai une requête de select, je veux compter le nombre de ligne retournées sans utilisé un count.
Y aurait-il un moyen d'obtenir le nombre de ligne dans un programme (comme avec sqlca.sqlerrd[2] ) pour obtenir le nombre de ligne sélectionnées.
Ou dans une même requête obtenir les données et le nombre de lignes totales ?
Merci.
Quelle version ? Quelle plate-forme ?
Tu dis que tu veux l'obtenir dans un programme comme un sqlca.sqlerrd[2]. Pourquoi ne l'utilises-tu pas ?
Je ne connais pas la version de mon os pour l'instant.Envoyé par K2R400
Il semble que sur ma version MVS, sur les update et delete la valeur de sqlca.sqlerrd[2] est modifié sur le select elle est vide je crois ou à -1;
Je lance des requete SQL à partir d'un service CICS en langage C.
Bonjour,
Pour répondre à ton besoin, tu peux te servir des scrollables curseurs. Ce type de curseur te permet de te ballader dans tous les sens dans ton curseur au lieu de lire ton curseur ligne après ligne de manière standard. Le besoin fonctionnel est très limité... Ceci dit, avec les options qui vont bien, cela signifie que DB2 stocke automatiquement le résultat du curseur dans sa database de travail, il connait donc le nombre de ligne ramené dès l'OPEN.
Les actions à faire :
1/ Déclarer le curseur ainsi
DECLARE Nom_curseur INSENSITIVE SCROLL CURSOR FOR SELECT ...
2/ Après l'OPEN Nom_curseur, faire un FETCH ABSOLUTE +1000000 pour se positionner en fin de curseur (le +1000000, c'est aléatoire, mettre une valeur qui ne sera jamais atteinte pour être certain de se retrouver en fin de curseur).
3/ Après ce FETCH ABSOLUTE, la zone SQLERRD(2) contient le nombre de lignes du curseur.
4/ Se repositionner au début du curseur et faire ensuite une lecture standard ligne après ligne.
Cela répond bien au besoin et ça coute moins cher, en terme de perfs, que de faire un SELECT COUNT(*) puis le curseur standard.
Sauf erreur de ma part, si tu es en V8, il te faudra déclarer une database temporaire pour pouvoir te servir des scrollables curseurs. Si tu es en V9, ce n'est plus nécessaire.
Bonne utilisation et à ta disposition.
Mais, pour connaître le nombre de ligne retournées par une SELECT, ne peut-on donc pas utiliser
juste après l'open ?
Code : Sélectionner tout - Visualiser dans une fenêtre à part Exec sql GET DIAGNOSTICS :rcount = DB2_NUMBER_ROWS
Le nombre de lignes sélectionnées est renvoyé dans la variable rcount avec cette fonction SQL. On éviterait ainsi le fetch.
Pb : si pas de tri dans le curseur, DB2 ne fait rien au moment de l'OPEN et la lecture des lignes se fait pendant les fetchs. Donc, tu n'as pas le nbre de lignes à l'OPEN.
C'est pour cette raison que nous nous sommes servis d'un scrollable cursor quand nous avons eu le même besoin : avec un scrollable cursor, on est certain que DB2 fait tout le boulot au moment de l'OPEN.
C'est d'ailleurs la seule permission d'utilisation d'un scrollable cursor dans ma société, car si on commence à s'amuser avec ces trucs avec l'option sensitive, bonjour la complèxité des traitements et les performances...
Merci pour votre réponse tres pertinente.
En effet, je ne pouvais pas utiliser de count(*) car ma base de donnée contient 200 millions d'enregistrement.
Le Fetch c'est la bonne solution pour ne pas ralentir les traitements.
Bonjour,
Je ne comprends pas la pertinence de cette réponse.
Pour se baser en fin d'un curseur, on est obligé d'exécuter la requête non ?
Qui plus est, sur une clause select complexe les résultats ramenés pour faire ce genre de count est plus couteux en ressource comparé à un count(*).
J'ai du louper une étape dans la démarche mais je ne sais pas laquelle :p
Là, tu m'étonnes ! Dans la mesure où le curseur est ouvert en mode INSENSITIVE, le GET DIAGNOSTICS formulé comme affiché dans mon post précédent devrait bien renvoyer les nombre de lignes à lire.
Mercure,
en INSENSITIVE c'est forcé qu'il y ait le Nbr de lignes derrière un GET DIAGNOSTIC car avec un curseur INSENSITIVE la totale des données sont dupliquées lors d'un OPEN. Ce n'est pas le cas d'un curseur ASENSITIVE ou SENSITIVE. Maintenant avec des curseurs de type SCROLLABLE, attention aux performances, c'est déconseillé.
Punkoff,
tu as tout juste et tes remarques sont pertinentes.
Clodo13,
Je te conseille plutôt de créer un EVI (index de type bitmap/vecteur) sur les colonnes de ta clause WHERE et de faire un SELECT COUNT(*). La réponse devrait être instantannée.
Mais AMHA ce SCROLL ne sert à rien et NO SCROLL est sauf erreur pris par défaut dans la clause DECLARE CURSOR.
GET DIAGNOSTICS renverra bien le nombre de lignes sélectionnées dans la mesure où le curseur est ouvert en mode INSENSITIVE, qu'il soit "scrollable" ou pas.
+1 pour l'EVI mais je crois que pas possible sous z/OS, je veux dire que je n'en suis pas sûr.
Exact. La notion de curseur SCROLLable ne sera pas necessaire ici . Un curseur INSENSITIVE (qui est par nature en lecteur seule) est un moyen d'isoler les données sans gérer la notion de transaction.Mais AMHA ce SCROLL ne sert à rien et NO SCROLL est sauf erreur pris par défaut dans la clause DECLARE CURSOR.
GET DIAGNOSTICS renverra bien le nombre de lignes sélectionnées dans la mesure où le curseur est ouvert en mode INSENSITIVE, qu'il soit "scrollable" ou pas.
+1 pour l'EVI mais je crois que pas possible sous z/OS, je veux dire que je n'en suis pas sûr.
Ce genre de curseur peut être assez pénalisant côté perfs, toutes les données sont dupliquées au moment de l'OPEN d'où la connaissance exacte du nombre de lignes concernées dès l'OPEN avec un GET_DIAGNOSTIC.
Pour les autres types de curseurs (ASENSITIVE ou SENSITIVE), le GET_DIAGNOSTIC ne renverra qu'un nombre approximatif de lignes. Cette information est fournie par le "statistic manager" (appelé par lui même par l'optimiseur) qui peut s'appuyer sur des EVIs, de l'échantillonage d'index b-tree, des statistiques de colonnes voire des prédicats tout fait (Exemple : avec un WHERE A=1 --> 10% de lignes estimées, WHERE A>=1 --> 33% des lignes etc...) en l'absence d'index ou de statistiques.
Pour conclure, plusieurs moyens pour obtenir le nombre de lignes concernées par la requête avec des temps de réponse plus ou moins bons :
- Le count(*)
- Curseur INSENSITIVE avec GET_DIAGNOSTIC après l'OPEN
- Curseur SCROLLABLE avec un FETCH RELATIVE maximal suivi d'un GET_DIAGNOSTIC
Il va sans dire qu'avec un bon index (de type EVI), seule la première solution offrira les meilleurs temps de réponse quelque soit le nombre de lignes concernées.
Pour les deux autres solutions, il vaut mieux espérer que le nombre de lignes à compter est faible afin d'obtenir des temps de réponse acceptables.
Attention à la plateforme ... En DB2 z/OS un index de type EVI ça n'existe pas ...
Merci Luc pour la confirmation sur la faisabilité EVI sous z/OS dont je doutais.
Dommageet au temps pour moi
J'ai compté le nombre de ligne au moment du fetch pour ne pas exécuter une commande de count ou de diagnostic.Dommage
C'est la meilleure solution qui me permet de remonter le données et de compter le nombre d'occurences.
Voila.
clodo13,
Pour mon information, je serais tout de même curieux de savoir si le GET DIAGNOSTICS te donne les mêmes résultats car avec GET DIAGNOSTICS on évite de fetcher toutes les lignes sélectionnées par SELECT pour faire un simple comptage.
Peux-tu l'essayer et nous dire, please ?
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager