Discussion :

[escartefigue]

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

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é.
En résumé:
T1 evenements (tout produit)|COL2|COL3|COL4 etc....
T2 evenment (produit X)|numero abonné|COL3

Très rarement valorisé, Est-ce à dire nul, blanc/zéro ou autre valeur constante, ou bien qu'il n'y a pas d'occurrence dans T2 pour ces cas

Pour lever toute ambiguïté (COL1 n'est plus là, ou semble être devenu COL3), ce serait plus simple avec le vrai DDL des 2 tables et de leurs index

[s2rs2]

La colonne COL1 est le numéro d'evenement dans les 2 tables.
La colonne COL2 est le numér od'abonné dans la table T2.


CREATE TABLE T2
(
COL1 CHAR(10) NOT NULL
,COL2 CHAR(15) NOT NULL
,COL3 CHAR(1) NOT NULL
)
IN DATABASE
CCSID EBCDIC
NOT VOLATILE
APPEND NO

---------------------------
CREATE
INDEX XT2
ON T2
(
COL2
,COL1
)
USING STOGROUP XXXX
PRIQTY 3512
SECQTY 292
ERASE NO
FREEPAGE 0
PCTFREE 5
GBPCACHE CHANGED
NOT CLUSTER
BUFFERPOOL BPX
CLOSE NO
COPY YES
PIECESIZE 2G
COMPRESS NO
;


CREATE TABLE T1
(
COL1 CHAR(10) NOT NULL
,COL2 CHAR(15) NOT NULL
,COL3 CHAR(15) NOT NULL
,COL4 CHAR(3) NOT NULL
,COL5 CHAR(17) NOT NULL
,COL6 CHAR(15) NOT NULL
,COL7 CHAR(5) NOT NULL
,COL8 CHAR(8) NOT NULL
,COL9 CHAR(1) NOT NULL
,COL10 CHAR(2) NOT NULL
,COL11 CHAR(1) NOT NULL
,COL12 CHAR(5) NOT NULL
,COL13 CHAR(1) NOT NULL
,COL14 CHAR(8) NOT NULL
,COL15 CHAR(8) NOT NULL
,COL16 CHAR(8) NOT NULL
,COL17 CHAR(8) NOT NULL
,COL18 CHAR(8) NOT NULL
,COL19 CHAR(8) NOT NULL
,COL20 CHAR(2) NOT NULL
,COL21 CHAR(15) NOT NULL
,COL22 CHAR(17) NOT NULL
,COL23 CHAR(8) NOT NULL
,COL24 CHAR(2) NOT NULL
,COL25 CHAR(1) NOT NULL
,COL26 CHAR(80) NOT NULL
,COL27 CHAR(80) NOT NULL
)
IN DATABASE
CCSID EBCDIC
NOT VOLATILE
APPEND NO

CREATE UNIQUE
INDEX XT1
ON T1
(
COL1
)
USING STOGROUP XXXX
PRIQTY 56880
SECQTY 2844
ERASE NO
FREEPAGE 0
PCTFREE 5
GBPCACHE CHANGED
CLUSTER
BUFFERPOOL BPX
CLOSE NO
COPY YES
PIECESIZE 2G
COMPRESS NO
;


La requête:


SELECT A.*
FROM T2 B, T1 A
WHERE A.COL1 = B.COL1
AND B.COL2 = ?
AND A.COL3<> ?
AND A.COL1>= ?
ORDER BY A.COL1;

L'Explain:

QBNO PLNO QBTYP METH TNAM AT MATCH ACCNAM IXONLY PREFETCH
----+---------+---------+---------+---------+---------+---------+------
1 1 SELECT 0 T1 I 1 XT1 N S
1 2 SELECT 1 T2 I 2 XT2 Y

Ce devrait être plus clair à présent


Merci.

[Luc Orient]

Est ce que l'ajout de la clause " OPTIMIZE FOR 1 ROW " ne pourrait pas influencer notre sympathique optimiseur, qui parfois c'est vrai, n'en fait qu'à sa tête ?

[escartefigue]

Bonjour,

C'est plus clair en effet, merci pour ces détails

Du coup, je pense que c'est la clause ORDER BY qui provoque le choix de la table T1 , faites un essai sans ORDER BY pour en avoir le cœur net

De plus, le critère de jointure n'est pas sargable, il faudrait créer un index sur T2.COL1, idéalement T2.COL1 + T2.COL2 pour qu'il soit utilisable comme critère de jointure et de filtrage

Pour faciliter la lecture, il serait préférable de positionner les critères de jointure dans une clause JOIN plutôt que des les confondre avec les critères de filtrage :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
   SELECT T2.COL1
        , T2.COL2
        , [...]
        , T2.COLN
   FROM T2
   INNER JOIN T1
      ON T1.COL1 = T2.COL1
   WHERE T2.COL2 = ? 
     AND T1.COL3<> ? 
     AND T1.COL1>= ? 
   ORDER BY T1.COL1

[s2rs2]

Malheureusement non

Est ce que l'ajout de la clause " OPTIMIZE FOR 1 ROW " ne pourrait pas influencer notre sympathique optimiseur, qui parfois c'est vrai, n'en fait qu'à sa tête ?

[s2rs2]

Bonjour,

J'avais déjà retiré l'order by sans succès.
L'index sur T2.COL1 existe déjà (je ne l'ai pas indiqué car il n'est pas utilisé dans la stratégie).
J'ai ajouté la colonne COL2 à cet index donc COL1|COL2 runstats etc....et toujours la même stratégie...

Comme dit précedemment, mes tests en préproduction avec les données de production ont montré que seul le changement de contenu de la table T1 (à volumétrie quasi identique) ramenait le chemin d'accès vers celui attendu.
C'est le seul enseignement que j'arrive à faire pour l'instant. La répartition du portefeuille que je charge est pratiquement ventilée dans les mêmes proportions niveau numéro d'evenements.
Et la seule retouche de la requête qui fait basculer la startégie vers la bonne est le fait de fixer (en low value ou n'importe quoi d'autre) la clause AND T1.COL1>= ?

Tous les autres changements entrepris (dont certains que vous m'avez tous proposés) ne changent pas la stratégie.

Merci.

Bonjour,

C'est plus clair en effet, merci pour ces détails

Du coup, je pense que c'est la clause ORDER BY qui provoque le choix de la table T1 , faites un essai sans ORDER BY pour en avoir le cœur net

De plus, le critère de jointure n'est pas sargable, il faudrait créer un index sur T2.COL1, idéalement T2.COL1 + T2.COL2 pour qu'il soit utilisable comme critère de jointure et de filtrage

Pour faciliter la lecture, il serait préférable de positionner les critères de jointure dans une clause JOIN plutôt que des les confondre avec les critères de filtrage :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
   SELECT T2.COL1
        , T2.COL2
        , [...]
        , T2.COLN
   FROM T2
   INNER JOIN T1
      ON T1.COL1 = T2.COL1
   WHERE T2.COL2 = ? 
     AND T1.COL3<> ? 
     AND T1.COL1>= ? 
   ORDER BY T1.COL1

[escartefigue]

Sacré casse tête en effet

EDIT : le fait que le remplacement d'une host variable par une constante change la stratégie est forcément significatif. Mais pour autant je ne comprends pas. J'aurai compris si table mal organisée et stratégie tablescan, mais ce n'est pas le cas

Avez vous comparé les stats prod et pré-prod, peut être que vous aurez "une révélation"

[s2rs2]

Sacré casse tête en effet

t
Tout à fait, c'est pourquoi je vous sollicte tous.
Je viens de refaire un test avec un 3eme portefeuille en préproduction qui confirme que le souci est bien lié au contenu de la table T1.
En l'alimetant avec des données issu d'un autre centre, la stratégie bascule sur celle voulue...

[bernard59139]

Bonsoir

Tout vient des FILTRES et comment db2 calcule tout ce bazard.

Dans la dernière requête exposée

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
SELECT A.* 
 FROM T2 B, T1 A 
 WHERE A.COL1 = B.COL1
 AND B.COL2 = ? 
 AND A.COL3<> ? 
 AND A.COL1>= ? 
 ORDER BY A.COL1;

tout est fait pour passer par la table T1 (pas bien) car pas mal de "trucs" sur la table T1 (critères, order by).

A chaque critère de sélection, l'optimizer DB2 leur attribue un "%tage" (de réussite sur le critère de sélection, de cout en nb de lignes, de cout en temps).
Cet optimizer mouline le tout pour choisir le(s) chemin(s) d'accès.

Un chemin d'accès opti (vu de notre point de vue) peut devenir pourri après un truc (reorg/ changement de version db2 ou hard ...).

J'ai déjà été confronté à ce problème, ma correction a été de faire 2 requêtes distinctes (Accès applicatif à T2 puis à T1). Pas terrible mais efficace.

En plus, il ne faut pas oublier que l'optimizer DB2 réécrit les requêtes et, après cette réécriture, choisi son chemin d'accès.
Les tables EXPLAIN donnent pas mal d'indications sur les chemins d'accès (étape par étape de la requête sql).

Il faut les exploiter.

a++

[Luc Orient]

Et à tout hasard ... un truc du style :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
SELECT A.* 
 FROM T1.A
 WHERE A.COL1 IN 
 (SELECT B.COL1 FROM T2 B
   WHERE B.COL2 = ? 
   AND B.COL1>= ?)
 AND A.COL3<> ? 
 ORDER BY A.COL1
 OPTIMIZE FOR 1 ROW ;

[s2rs2]

Les stats sont cohérentes...pas de révélation malheureusement.
Problème intriguant effectivement.

Sacré casse tête en effet

EDIT : le fait que le remplacement d'une host variable par une constante change la stratégie est forcément significatif. Mais pour autant je ne comprends pas. J'aurai compris si table mal organisée et stratégie tablescan, mais ce n'est pas le cas

Avez vous comparé les stats prod et pré-prod, peut être que vous aurez "une révélation"

[s2rs2]

Je testes demain et vous tiens au courant.
Merci.

Et à tout hasard ... un truc du style :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
SELECT A.* 
 FROM T1.A
 WHERE A.COL1 IN 
 (SELECT B.COL1 FROM T2 B
   WHERE B.COL2 = ? 
   AND B.COL1>= ?)
 AND A.COL3<> ? 
 ORDER BY A.COL1
 OPTIMIZE FOR 1 ROW ;

[Luc Orient]

Je testes demain et vous tiens au courant.
Merci.

Il manque peut être un AS TRUC juste après la sous requête ... je ne suis plus très sûr de la syntaxe ...

[s2rs2]

Bonjour,

requête testée.
Chemin d'accès dégradé avec un table scan de T1 (entre autre).
Par contre en plaçant la clause de repositionnement à l'exterieur cela améliore très légerement la stratégie dans la mesure où ce coup-ci l'accès aux T1 et T2 pour jointure sur COL1 se fait dans la même étape, là où actuellement elle se font successivement.
La DSN_STATEMNT_TABLE semble indiquer un coût "global" légèrement infèrieur.

Ceci dit on ne bascule toujours pas sur le chemin d'accès attendu et provoqué par le changement de contenu de la table T1, à savoir l'accès d'abord à T2.

Merci.

Il manque peut être un AS TRUC juste après la sous requête ... je ne suis plus très sûr de la syntaxe ...

[escartefigue]

Je propose d'essayer ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
   SELECT T2.COL1
        , T1.COL2
        , T1.COL3
        , [...]
        , T1.COLN
   FROM T1
   INNER JOIN T2
      ON T2.COL1 = T1.COL1
   WHERE T2.COL2 = ? 
     AND T1.COL3<> ? 
     AND T2.COL1>= ? 
   ORDER BY T2.COL1

[s2rs2]

Bonjour Escartefigue,

ceci a déjà été tenté mais sans résultat.

Merci.

Je propose d'essayer ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
   SELECT T2.COL1
        , T1.COL2
        , T1.COL3
        , [...]
        , T1.COLN
   FROM T1
   INNER JOIN T2
      ON T2.COL1 = T1.COL1
   WHERE T2.COL2 = ? 
     AND T1.COL3<> ? 
     AND T2.COL1>= ? 
   ORDER BY T2.COL1

[s2rs2]

Probleme résolu.
Le souci venait de T2.COL2 pas assez valorisé et pas en sequence par rapport a T2.COL1 donc T1.COL1.
contrairement au poetefeuille chargé en preproduction.
J'ai donc leurré Db2 puis runstats+rebind et tout est rentré dans l'ordre.
Merci a tous.