Discussion :

[punkoff]

Bonjour,


Sur notre base de production nous avons des sorte de "latence" db2 au niveau des fetchs.

Ces latences arrivent d'une manière totalement aléatoire.


Une même requête va passer par exemple (lors de sa première utilisation) en 1sec5 puis si je refais le test 10 min après (pour que l'on est plus le plan d'acces dans le plan cache sqe) elle va prendre par exemple 7sec et quelque.

J'ai pu faire des DBMON pour voir que c'était l'étape du FETCH qui posait problème.


OK, mais je ne sais pas quoi faire avec ceci, ni expliquer pourquoi nous avons de tel comportement.


Y aurai-t-il un outil qui permettrai de voir si à l'instant du fetch nous avons un lock par exemple qui nous bloquerai ?

Auriez-vous d'autre axe de recherche vers lesquels je pourrai me tourner afin de comprendre pourquoi nous avons de tel cas ?

[K2R400]

Questions :

Tes fichiers sont-ils journalisés.
Es-tu sous commitment control ?
>ton curseur est-il déclaré avec WITH NC
> ou set option commit *none

Le fecth en question est-ce au premier fetch ?

[punkoff]

Alors mes fichiers sont journalisés et on dispose de l'option 42.

On est en commited control : uncomited read.

c'est une appli java qui attaque notre bdd, via connection jdbc avec le driver jt400.
(ou via une couche castor .. c'est un peu comme hibernate)


Pour la gestion des curseurs c'est db2 qui gère à sa sauce dans le job QZDASOINIT (pas sur à 100% pour ce point).

J'ai fait mes tests via l'interface sql de iseries afin de passer par les QZDASOINIT.

J'ai 2 DBMON pour la même requête avec le problème, un d'un cas réalisé avec notre appli java et l'autre réalisé avec la requête directement sur l'interface sql.


Dans les 2 cas la requête a été totalement construite (acces plan et odp), et on a un hard close du curseur.

Et c'est effectivement le 1er fetch qui peut être long.
Je suis conscient que la 1ere utilisation de la requete sera plus longue au vu de ce que db2 va faire par contre ce temsp oscille entre 1sec5 et 7sec pour cette requête en question.


Plus globalement on a ce problème sur d'autre requête, et on essai de savoir pourquoi.

[Mercure]

Une même requête va passer par exemple (lors de sa première utilisation) en 1sec5 puis si je refais le test 10 min après (pour que l'on est plus le plan d'acces dans le plan cache sqe) elle va prendre par exemple 7sec et quelque.

Je ne comprends pas la remarque "pour que l'on est [n'ait] plus le plan d'acces dans le plan cache sqe". Peux-tu l'expliquer ?

Même question pour le hard close :

Dans les 2 cas la requête a été totalement construite (acces plan et odp), et on a un hard close du curseur.

Je reprends ci-après pour info ce que j'ai déjà posté sur un autre forum :

Comment fonctionne SQL
La première fois qu'une instruction SQL est exécutée, la totalité de la procédure d'optimisation est mise en oeuvre, c'est à dire
- la récriture de l'instruction SQL,
- le contrôle de tous les index (DDS compris)
- la création des objets temporaires nécessaires pour accomplir la requête (tables de hâchage, listes de RRN, bitmaps, etc),
- la création d'un plan d'accés, qui définit la méthode avec laquelle accéder aux données, quels index utiliser et quels objets temporaires doivent être éventuellement construits,
- la création de l'ODP (Open Data Path).

A la fin de la première exécution de l'instruction SQL, le curseur fait l'objet d'un hard-close et l'ODP est supprimé. Au deuxième passage de la même instruction, le plan d'accés est validé et l'ODP est réouvert. A partir du troisième passage de la même instruction, l'ODP reste ouvert et seules les données sont réactualisées dans l'ODP. Vous pouvez donc constater que l'exécution de la totalité de la procédure d'optimisation prend beaucoup de temps. Souvenez-vous que cette procédure est effectuée pour chaque instruction SQL.

Impact du Close SQL Cursor
Il faut faire la distinction entre "hard close" et "soft close" du curseur.
Lorsque l'instruction "Close curseur" est exécutée, elle n'accomplit qu'un soft close, ce qui veut dire que l'ODP est laissé ouvert et que seules les données sent réactualisées dans cet objet temporaire à l'exécution suivante de cette même instruction.
Lorsqu'un curseur est fermé par un hard close, l'ODP est détruit. Par conséquent, lorsque la même instruction SQL est réexécutée, la totalité de la procédure d'optimisation est de nouveau mise à oeuvre avec tout l'overhead que cela implique.

[punkoff]

Bonjour,


Nous remarquons ce problème lors de la 1ere exécution de la requête.

Par ces 2 remarques je voulais préciser que les 2 tests que j'ai fait avec les dbmon à l'appui l'étaient avec des requêtes qui n'avaient pas encore été exécutée.


Je comprend le mécanisme que vous postez, ce que je ne comprend pas par contre c'est pourquoi lors de la 1ere exécution d'une même requête (création de l'acces plan + création odp) j'ai des temps de réponse qui varie entre 1sec5 à 7sec et des brouettes.

J'aimerai pouvoir expliquer ca.


En mode "croisière" (après plusieurs utilisation de celle-ci), la requête n'est pas lente.


edit :
En regardant les résultats du dbmon (utilisation d'une vue sur les QQQ1000) je peux remarquer que c'est l'étape de 'FETCH' qui est lente.

[punkoff]

Bonjour,


En regardant de plus près les résultat du cache plan sql et plus particulièrement la vue des exécution les plus longues pour une même requête :



Est-ce que page fault ou asynchronous read peuvent avoir des répercutions sur les "fetch" d'une requête sql ?

et si oui comment puis-je les mesurer (en temps d'attente) ?