Influence du partitionnement sur les temps d'accès

[dr_nilkog]

Bonjour à tous,

Suite à une demande d'étude de la part de mon responsable, je regarde l'influence du partionnement de 5 tables relationnelles (1 table mère et 4 filles) sur les temps de réponse des requêtes accédant à ces tables.
Je suis sur DB2 V9 pour Z/OS.
Nous stockons dans ces tables des données de 3 applications différentes dont les données ne se chevauchent pas. J'ai donc créé dans chaque table 3 partitions avec en valeur de clé le nom de l'application.

Si l'on regarde la documention IBM et autres publications lorsque l'on partitionne table et index c'est comme si on travaillait sur des tables / index plus petits (à condition de mettre la colonne de partition dans les requêtes bien sur), d'où des gains de temps.

Tous mes index sont déclarés en Partionned puisque je n'ai aucun intérêt à chercher des informations sur plusieurs partitions en même temps.

Lorsque je fais une jointure sur ces 5 tables, en mettant bien pour chaque table la valeur de l'application pour qu'il aille directement dans la bonne partition j'ai l'étonnant comportement suivant :
- Avant modification mes explains plans sont tout à fait corrects, toutes mes jointures se font via les index des FK, il y a juste quelques tris (colonne SORT_CJOIN de la PLAN_TABLE à 'Y') et un temps estimé de 64 ms.
- Après modification mes explains sont identiques si ce n'est que tous les tris ont disparus (youpi) et le temps estimé est tombé à 40 ms.

Jusque là tout est cohérent avec ce que j'attendais et plutôt prometteur.

En revanche lorsque je fais mes tests en réél, ce n'est plus du tout la même chose.
Je passe en temps CPU mesuré de 0.80 s à 2.00 s et en élapse de 16 s à 210 s. Et là je ne comprends plus.
Je tiens à dire que les statitistiques ont été calculées (REORG TABLESPACE avec les options index et table) et que le contenu des tables est trictement identique.

Quelqu'un aurait il une piste qui expliquerai ce comportement étrange ?
D'avance merci pour vos contributions.

[pdz74]

Bonjour,

Pas évident de donner des explications juste avec la théorie. Pourrais tu nous faire passer le DDL des tables et la requête concernée.

En théorie, le partitionnement, c'est tout bénef dès que tu es capable de cibler à coup sur, la bonne partition. Par contre, si tu commences à faire des accès multi-partitions, ça peut au contraire dégrader les temps de réponse, le temps pour DB2 d'aller sur chaque partition, donc sur des pages différentes, plutôt que de récupérer des données bien stockées au chaud dans la même page.

Autre point à prendre en compte : acceptes tu dans tes binds le parallélisme (paramètre DEGREE à 1 si pas de parallélisme souhaité, à ANY si parallélisme accepté). Le cas typique de gain avec du parallélisme, c'est justement avec des tables partitionnées.

En attendant de tes nouvelles.

[dr_nilkog]

Pas d'accès multipartition, c'est pourquoi je voulais tester cette solution pour améliorer les temps d'accès.

Pour le parallèlisme en revanche je vais voir.

[bernard59139]

Bonjour
un simple retour d'expérience avec db2 v8.

Le partitionnement par DATA (tout est partitionné, même les index) peut dégrader les perf quand les index sont mal conçus ou mal utilisés.

Si le critère (ou les critères) de partitionnement ne sont pas utilisés dans les requetes, pour 1 clef à aller chercher, DB2 essayera d'aller chercher les données dans chacune des partitions. Et plus il y a de partitions, plus les temps de réponses se dégradent.
Même avec des index de type "UNIQUE".

Ensuite, si les tables sont volumineuses, certains mots-clefs du RUNSTATS peuvent influer grandement les chemins d'accès (KEYCARD, COLGROUP, ..).

a+

[Luc Orient]

Envoyé par dr_nilkog

...

Tous mes index sont déclarés en Partionned puisque je n'ai aucun intérêt à chercher des informations sur plusieurs partitions en même temps.

Lorsque je fais une jointure sur ces 5 tables, en mettant bien pour chaque table la valeur de l'application pour qu'il aille directement dans la bonne partition j'ai l'étonnant comportement suivant :
- Avant modification mes explains plans sont tout à fait corrects, toutes mes jointures se font via les index des FK, il y a juste quelques tris (colonne SORT_CJOIN de la PLAN_TABLE à 'Y') et un temps estimé de 64 ms.
- Après modification mes explains sont identiques si ce n'est que tous les tris ont disparus (youpi) et le temps estimé est tombé à 40 ms.

Hum c'est curieux cette disparition des tris ... on dirait que le chemin d'accès pour réaliser la jointure à changé ... peut être faut-il regarder de ce cotè

Par ailleurs, le jointure dont tu parles, est-elle de type unitaire (profil transactionnel pour faire simple) ou plutôt ensembliste (profil batch) ?