OK merci pour l'explication.
Comment faire un table scan, il y a une commande spéciale ?
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
OK merci pour l'explication.
Comment faire un table scan, il y a une commande spéciale ?
Il n'y a pas de commande spéciale.
- soit tu effaces l'index (DROP)
- soit tu changes le SQL. Il y a des trucs
Mais n'oublie pas que tu as 250M de lignes et que l'ORDER BY conssomera des ressources.
Sur cette table et pour la requête bien sûr, affiche :Envoyé par sam01
STMT_TYPE
COST_CATEGORY
PROCMS
PROCSU
TOTAL_COST
Puis, refais ton EXPLAIN en enlevant l'ORDER BY et ré-affiche la PLAN_TABLE et la DSN_STATEMNT_TABLE.
Le risque existe aussi que la requête "explose" la base de tri de DB2 ... Mais bon, ça dépend de la taille de la ligne de la table et aussi de la taille de la dite base ...
Voici le résultat de la DSN_STATEMNT_TABLE :
La colonne TOTAL_COST n'existe pas.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7QUERYNO COST_CATEGORY PROCMS PROCSU 99999 A 13988168 582840320 STMT_TYPE COST_CATEGORY SELECT A
je refait un EXPLAIN et j'envoie les résultats
Voici pour la PLAN_TABLE
et pour la DSN_STATEMNT_TABLE
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17PLANNO METHOD 1 0 TABNO ACCESSTYPE MATCHCOLS 1 R 0 INDEXONLY SORTN_UNIQ SORTN_JOIN SORTN_ORDERBY N N N N TSLOCKMODE TIMESTAMP IS 2011092110142250 PREFETCH COLUMN_FN_EVAL MIXOPSEQ S 0
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7QUERYNO STMT_TYPE COST_CATEGORY PROCMS PROCSU 88888 SELECT A 13596520 566521600 STMT_ENCODE E
Le voilà ton "TABLE SPACE SCAN" :
ACCESSTYPE=R
Par contre, je suis surpris par la faible différence PROCMS / PROCSU entre les deux variantes ...
DB2 a l'air d'estimer que l'accès direct à la table est presque aussi coûteux que l'accès via l'index au moins en coùt CPU ...
OK,
pour résumé un peu le tout,
que dois-je en conclure ?
J'aimerais voir ce que donne unload DB2 de la table.
Est-il possible de simuler un Unload afin de voir le temps que ça va prendre et l'espace disque que ça va occuper ?
Passer par un fastunload ne serait-il pas mieux ?
DB2 estime que tes 2 requetes sont équivalentes et consomatrices car les chiffres (PROCSU et PROCMS) ne font pas apparaitre de grosses différences.
Et amha, ces chiffres sont assez grands.
Ca ne veut pas dire que la durée "réelle" sera identique, surtout si les stats du catalog ne sont pas à jour (eq ne reflètent pas la réalité).
Tu peux simuler un UNLOAD, avec SAMPLE 0 LIMIT 0 dans dans la sysin.
tu récupères le LRECL du sysrec (qui devrait être vide) et tu multiplies par le nombre de records de la table pour obtenir une taille en octet.
je met en fichier join une requete de base sur la plan_table que j'utilise souvent. Elle n'est pas parfaite, seulement utile.
a+
Bonjour bernard59139 et merci pour tes réponses.
En ce qui concerne l'unload avec les options que tu me donne, est-ce rapide ?
Ca consomme beaucoup ? E est-ce que ce type d'unload pose des locks sur la table ?
La table fait quand même 570 Millions de ligne (aurais-tu un exemple d'un tel unload ?)
Merci encore pour ton aide.
Il me semble qu'avec cette commande :
toutes les lignes de la table sont lues...
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
ca dépend de la version de db2. En v7, oui, v8 et plus, non.
Si tu penses pouvoir passer par un utilitaire (IBM ou autre), c'est que le programme en cause ne fait pas grand chose d'autre que de lire la table, ce qui serait qiand même un peu surprenant non ?
Ben mon but est de transformer le programme afin qu'il lise le fichier unloadé et non la table.
Ca éviterait au moins le select * de 570 Millions au sein du programme.
Surtout que (là vous n'allez pas me croire !!!) dans le job en question ,il y a un deuxième programme, tout de suite après qui relie à nouveau la table 570 Millions de lignes... Du jamais vu !!!
Quand on fait relever ça, on me dit :
Attention, il ne faut surtout pas toucher à de programme qui ont 20 ans d'âge, ça peut me f... la grouille (Je vous jure que ce n'est pas une blague!)
Quand je vous disais que c'est dur de faire des perf là où je suis...
Désolé Luc Orient, en relisant les posts, je me rend compte que je n'ai pas répondu à ta question. Il faut me le dire, ça ne va pas me vexer
Ben au fait si, le programme ne fait que lire la table... Il récupère des zones (colonnes),les accumule et les écrit des des fichiers de sorties.
j'ai vu pire...Surtout que (là vous n'allez pas me croire !!!) dans le job en question ,il y a un deuxième programme, tout de suite après qui relie à nouveau la table 570 Millions de lignes... Du jamais vu !!!
Depuis tous les post du tu as fait sur le sujet, à vue de nez, je pense que comprendre ce que font les programmes est essentiel, prog principal et sous-prog. Il peut être efficace de fusionner les 2 requêtes 1 seule.
Il faut aussi enquêter du coté des DATA comme tu le pressens. peut-être que la table a besoin d'une épuration.
A vue de nez, je ne pense pas qu'il soit rentable de remplacer simplement ton SQL de départ par un UNLOAD + modif de prog.
Bonjour bernard59139 et merci de me donner ton point de vue.
le souci, c'est que dans notre société, ce n'est pas facile des informations fonctionnelles pour diverse raisons.. (je ne m'étenderai pas la dessus).
Je vais donc faire des propositions (dont celle de l'unload) en croisant pur qu'en face, ils réagissent.
Rebonjour à tous,
je fais toujours des tests de performance et j'aimerais connaître la signification des colonnes :
PROCMS PROCSU
dans la DSN_STATEMNT_TABLE
Voici les données sans la clause WHERE :
PROCMS PROCSU
13988168 582840320
et voici les résultat avec la clause WHERE :
PROCMS PROCSU
1046748 43614512
J'ai l'impression que la différence est significative...
Il s'agit du coût estimé de la requête en millisecondes. Ci-joint définition IBM :
PROCMS : The estimated processor cost, in milliseconds, for the SQL statement. The estimate is rounded up to the next integer value. The maximum value for this cost is 2147483647 milliseconds, which is equivalent to approximately 24.8 days. If the estimated value exceeds this maximum, the maximum value is reported.
PROCSU : The estimated processor cost, in service units, for the SQL statement. The estimate is rounded up to the next integer value. The maximum value for this cost is 2147483647 service units. If the estimated value exceeds this maximum, the maximum value is reported
Pour ton cas, cela signifie sans clause where : environ 4 heures et 162 heures. Avec clause where : 17 minutes et 12 heures. Ca m'étonnerait que ces chiffres reflètent la réalité. 162 heures....
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