Discussion :

[s2rs2]

Bonjour à tous
Nous avons en production une problematique d'application qui tombe en abend en raison d'une requête lancée sur le DB2 mainframe qui ne répond pas en temps voulu car très peu performante.

La situation:

Une table T1 3 millions de lignes avec 20 colonnes toutes valorisees.
Une table T2 2500 lignes avec 5 colonnes toutes valorisees sauf la Col2 qui n'est valorisée que pour 3 occurences.

Requete:

SELECT * FROM T2, T1
WHERE T2.COL2= T1.COL1
AND T2.COL1= 'numero d'abonné'
AND T1.COL2 <> 'm'
AND T1.COL1 > 'numero de contrat' (pour le repositionnement).

Indexs:
XT1 COL1. Cluster.
XT2 COL1 COL2 cluster.

Lors de l'exécution de la requête T2.COL2 est toujours valorisé donc on devrait théoriquement entrer par le numéro d'abonné pour lequel nois avons besoin de vérifier que celui ci est bien connu en base personne.
On devrait donc avoit un accès du genre:

Meth 0 sur T2 via XT2 mc 2
Meth 1 sur T1 via XT1 mc 1

Car on entre par la clé de la plus petite table qui est discriminante.

Mais non c'est quasi l'inverse qui se produit...

Meth 0 sur T1 via XT1 mc 1 sequential prefetch
Meth 1 sur T2 via XT2 mc 1


Runstats et reorg passés.
Résultat la requête est fortement consommatrice et l'application tombe alors en erreur a cause de cela(traces posées qui ont confirmé le diagnostic)


Si l'on force le passage par l'index de T2 voulu la requete fonctionne alors de façon optimale et repond.

Une piste?

Merci.

[Luc Orient]

Bonjour,

1) c'est donc du Batch ?

2) on souhaite gérer un repositionnement ? si oui, pourquoi et comment ?

3) pourquoi ne pas distinguer un curseur "normal" et un curseur "de repositionnement" ?

[s2rs2]

Bonjour
Non il s'agit de TP.
Oui un repositionnement est codé pour ce type de module d'accès aux données de type liste.
Il s'agit ici d'affiches la liste des contrats depuis un écran où le numéro d'abonné est renseigné.

[Luc Orient]

La table T1 est la table des contrats et la table T2 la table des abonnés ?

On cherche à afficher à l'écran la liste des contrats pour un abonné donné ?

[s2rs2]

Oui c'est bien ça.
Un abonné peut avoir "n" contrat.
Vois-tu une piste pouvant expliquer à la stratégie choisie par db2?
Merci.

[bernard59139]

bonjour

une piste

Change "AND T1.COL1 > 'numero de contrat' " en t2.col2.... Ta 1ere condition est "T2.COL2= T1.COL1", ca ne changera rien au résultat .
++

[s2rs2]

Bonjour Bernard
Déjà essayé cela ne change rien au chemin d'accès malheureusement. C'est pourquoi je voudrais savoir la raison de cette stratégie par db2.
Merci.

[Luc Orient]

Quelque chose m'échappe et je vais sans doute dire une bêtise, mais il ne manquerait pas un index dans la table des contrats sur le numéro d'abonné ?

[s2rs2]

Non pas de betise c'est juste ma retranscription qui n'est pas assez claire.
Le numero d'abonné nest pas present en table contrat.
La jointure se fait sur le numero de contrat present en T1 et T2. Le but est de ramener les données liées à tous les contrats de l'abonné (présentes en T1).
Desolé du manque de clarté.

[s2rs2]

Un indice cependant m'oriente vers un comportement lié au données de la table contrat elle meme.
Car en environnement de préproduction si je charge la table avec un portefeuille identique en terme de volumétrie mais provenant d'un autre centre alors le chemin d'accès bascule sur celui attendu donc optimal...
Je regarde la distribution des données et ne voit pas grand chose qui pourrait le justifier.
Pour etre sur que ce phenomene n'est pas lié à la plateforme je charge en préproduction les données de production et là on rebascule bien sur la mauvaise stratégie d'accès. .

[escartefigue]

Bonjour,

Si vos index sont créés
- sont ils discriminants (nombre de valeurs distinctes), pour les colonnes alimentées dans la requête
- les réorg sont elles faites (tant qu'à faire )
- vos stats sont elles à jour
- les packages ont ils été rebindés

Et aussi : remplacez le select * par une liste des colonnes utiles au traitement, un select * est dangereux car sensible au DDL et dégrade les perfs en transportant des données inutiles (à minima, les critères de jointure que vous avez 2 fois)

[escartefigue]

Non pas de betise c'est juste ma retranscription qui n'est pas assez claire.
Le numero d'abonné nest pas present en table contrat.
La jointure se fait sur le numero de contrat present en T1 et T2. Le but est de ramener les données liées à tous les contrats de l'abonné (présentes en T1).
Desolé du manque de clarté.

En relisant les différentes réponses, celle-ci m'interpelle
Comment le n° de contrat peut il etre présent dans la table des abonnés, puisque vous mentionnez plus haut qu'un abonné peut avoir plusieurs contrats ?
Ou alors, la table T2 que vous mentionnez comme une table des abonnés est en faite une table issue de la relation entre abonné et contrat

Si le schéma relationnel est bien
T2 (abonné) 0,n ----- 1,1 T1 (contrat)
C'est à dire les règles de gestion suivantes
1 abonné peut avoir plusieurs contrats
1 contrat appartient à un et un seul abonné

Alors on devrait avoir
- aucune FK issue de contrat dans la table abonné
- la PK abonné présente dans contrat en tant que FK, et, de préférence, avec une contrainte de type référence de contrat.FK vers abonné.PK

[s2rs2]

Bonjour,

affirmatif pour toutes les questions ci dessous.

Et la valorisation des colonnes en lieu et place du select * ne résoud pas le problème.

Merci.

Bonjour,

Si vos index sont créés
- sont ils discriminants (nombre de valeurs distinctes), pour les colonnes alimentées dans la requête
- les réorg sont elles faites (tant qu'à faire )
- vos stats sont elles à jour
- les packages ont ils été rebindés

Et aussi : remplacez le select * par une liste des colonnes utiles au traitement, un select * est dangereux car sensible au DDL et dégrade les perfs en transportant des données inutiles (à minima, les critères de jointure que vous avez 2 fois)

[escartefigue]

Bonjour,

affirmatif pour toutes les questions ci dessous.

Et la valorisation des colonnes en lieu et place du select * ne résoud pas le problème.

Merci.

D'accord, au moins ça c'est fait
La valorisation des colonnes à la place du select * n'est pas tant pour les perfs, bien que ce soit non négligeable surtout en cas de tables obèses (ce n'est pas le cas ici), que aussi et surtout pour la stabilité du résultat.
D'ailleurs, de nombreux sites de production interdisent les select * pour ces raisons
Ce qui m'inquiète le plus c'est les questions de mon post suivant sur les FK

[s2rs2]

Un abonné peut avoir plusieurs contrats effectivement.
Dans la table abonnés le couple abonné/contrat est unique. On peut donc avoir plusieurs fois le même abonné mais pour des contrats différents.
Les règles de gestions que vous citez sont correctes.
L'intégrité pour ces objets n'est pas gérée par DB2 mais de manière applicative.

Même si l'architecture peut paraitre "bancale" le but de mon post est surtout d'essayer de comprendre la stratégie adoptée par DB2 qui n'est vraiement pas celle attendue pourtant sur une requête peu complexe.
Le tout étant visiblement lié au contenu (cf mes tests avec un autre portefeuille à volumétrie équivalente).
J'opterais éventuellement pour la ventilation des numéro de contrats mais rien ne saute aux yeux...

Merci.

En relisant les différentes réponses, celle-ci m'interpelle
Comment le n° de contrat peut il etre présent dans la table des abonnés, puisque vous mentionnez plus haut qu'un abonné peut avoir plusieurs contrats ?
Ou alors, la table T2 que vous mentionnez comme une table des abonnés est en faite une table issue de la relation entre abonné et contrat

Si le schéma relationnel est bien
T2 (abonné) 0,n ----- 1,1 T1 (contrat)
C'est à dire les règles de gestion suivantes
1 abonné peut avoir plusieurs contrats
1 contrat appartient à un et un seul abonné

Alors on devrait avoir
- aucune FK issue de contrat dans la table abonné
- la PK abonné présente dans contrat en tant que FK, et, de préférence, avec une contrainte de type référence de contrat.FK vers abonné.PK

[escartefigue]

D'accord, en ce cas, la table T2 est bien une table issue de la relation entre abonnés et contrats
Mais du coup, comment peut il n'y avoir que 2500 rows dans T2 alors qu'il y a 3 000 000 de contrats dans T1
Ca sous entend que la quasi totalité des contrats ne fait référence à aucun abonné

Ces questions sur le modèle peuvent vous sembler en marge du sujet, mais j'avoue avoir du mal à raisonner sur la requête sans comprendre comment ces 2 tables s'articulent

[escartefigue]

Sinon avez vous vérifié que le format des host variables, en particulier celle du n° d'abonné, était bien identique à celui du DDL (même type et même longueur).
Ca pourrait expliquer

[s2rs2]

aucun souci, ceci est une retranscription peut être un peu légère. Afi nde mieux comprendre on pourra parler d'évenement plutot que de contrat.

La table T2 est donc la table concernant un certain type de produit(peu developpé).
Dans cette table on trouvera donc les évenements liés à ce type de produit ainsi que le numéro d'abonné à ce produit.
On va alors aller en table T1 rechercher tous les evenements générés pour un numéro d'abonné bien précis via la jointure entre numéro d'evenementT2 et numéro d'evenement T1.
Un abonné de ce type de produit pouvant donc générer n evenements en T1.
Avec la particularité que le numéro d'abonné de ce type d'evenement n'est que très rarement valorisé en table T2 car c'est un critère de recherche qui appelle à être abandonné.
Et c'est d'ailleurs pour cela que les abends de ce type dans l'application n'arrivent que quelques fois sur une journée(pour plusieurs milliers de recherche).

En résumé:

T1 evenements (tout produit)|COL2|COL3|COL4 etc....
T2 evenment (produit X)|numero abonné|COL3



Merci.

D'accord, en ce cas, la table T2 est bien une table issue de la relation entre abonnés et contrats
Mais du coup, comment peut il n'y avoir que 2500 rows dans T2 alors qu'il y a 3 000 000 de contrats dans T1
Ca sous entend que la quasi totalité des contrats ne fait référence à aucun abonné

Ces questions sur le modèle peuvent vous sembler en marge du sujet, mais j'avoue avoir du mal à raisonner sur la requête sans comprendre comment ces 2 tables s'articulent

[s2rs2]

Oui le format de la donnée en entrée est le bon.

Sinon avez vous vérifié que le format des host variables, en particulier celle du n° d'abonné, était bien identique à celui du DDL (même type et même longueur).
Ca pourrait expliquer

[s2rs2]

Autre précision:

Si dans l'explain on valorise la clause de repositionnement AND T1.COL1 > low value (ou 0 ou autre) alors le chemin d'accès bascule sur celui attendu...