Discussion :

[mousquetaires]

Bonsoir à tous,

Mon problème est assez vicieux si je puis dire... J'utilise une base de données DB2 dans laquelle, entre autres, il y a une table qui est sollicitée (très souvent) à chaque échange du CICS. C'est cette table, de service, qui pose problème lorsqu' un nombre important de transactions arrivent simultanément. Un -911 est généré, ce qui plante telle ou telle transaction. J'ai bien pensé utiliser la clause "WITH UR" dans le SELECT, mais j'ai un doute quant à la justesse de cette modification qui d'après moi peu engendrer des disfonctionnements dans la lecture des données.
Quelqu'un peut-il m'indiquer s'il y a d'autres moyens "programme" ou "système" pour régler ce problème.

Par avance merci.

Fabrice

[Christianchristian]

Bonjour,

J'ai trouvé cela sur internet.

In general a -911 means that a deadlock or timeout has occurred while the statement was attempting to obtain a lock on the object that is necessary for an insert to occur. That means that some other process has a lock on the object you need, and DB2 waiting for the lock to be released (wait time determined by a DB2 pram that can be set) and finally gave up waiting and terminated your transaction.

It is possible that another process has a row lock on the table or index that your need, or the other process has a table lock (either taken explicitly or escalated by DB2 from a row lock). Try to find out what other locks are being held on that object.



Je crois que la clause WITH UR ne peut être spécifiée que si la table est en READ ONLY.

je viens de trouver ça également :

WITH UR can be specified only if the result table is read-only.
If isolation-clause is not specified, the default isolation is used with the exception of a default isolation level of uncommitted read. With uncommitted read, the default isolation level of the statement depends on whether the result table is read-only; if the result table is read-only then the default will be UR; if the result table is not read-only then the default will be CS.

Je n'ai malheureusement pas de réponse précise à vous donner.
Si ce n'est déjà fait, peut-être pouvez-vous mener une investigation sur les points suivants ?
Quel genre de table est-ce, quelle est exactement son utilité ? Est-elle conséquente => mise en historique possible d'une partie des lignes ? A-t-elle (beaucooup) de clés secondaires ? Comment est-elle exploitée autrement que durant la session TP ?
Les transactions CICS sont-elles (toutes) montées en pseudo-conversationnel ? Les msies à jours des fichiers et les ordres de "verrouillage et déverrouillage des entités" sont ils, au niveau du code, centralisés et judicieux (pertinents) ?

Si ce n'est pas une table stratégique pour la gestion de l'entreprise, j'ai cru comprendre qu'elle sert de "logging" au TP, elle peut éventuellement être scindée en plusieurs tables (une table par application par exemple), lesquelles pourront toujours être consolidées pour créer une seule table en BATCH en fin de session téléprocessing. Mais cela n'est peut-être pas réaliste et entraînerait certainement des moodifications conséquentes.


Cordialement,

[gregory.broissard]

Bonjour,

Le -911 est un deadlock effectivement sur tes transactions. Les Locks se placant au niveau DB2, je ne vois pas vraiment de solution système pour résoudre ton problème. Peut etre au niveau des KIX mais je suis pas spécialiste du tout.

La clause with UR peut être utilisé sur n'importe quelle type de table (également en RW), c'est le résultat renvoyé qui est RO. Tu ne pourras donc pas modifié le résultat de ta requête.

Le WITH UR permet :
1/ a n'importe quelle ligne de ta sélection d'être lue et/ou modifiée par une autre transaction pendant ta transaction contrairement aux niveaux d'isolation CS, RR, etc...

2/Ta transaction peut lire n'importe quelle ligne même non commitée d'une autre transaction (dirty read)

Je te conseille le lire la doc DB2 IBM sur l'article sur "isolation levels"
http://publib.boulder.ibm.com/infoce...v2r2/index.jsp

Peut etre comme le dit Christian regarder du côté de la structure de la table ou des transactions CICS.

[jab]

Si je comprend bien, tu ne fis jamauis que des ajouts dans ta table donc UR pourrais être une solution. Toutefois je ne vois pas comment il peut y avoir un problème de lock alors que jamais tu n'utilise le même record.

[gregory.broissard]

par défaut, il me semble que les transactions KIX utilisent l'option CS pour leurs transactions interdisant l'acces sur les données utilisées aux autres pendant l'ensemble de la transaction...

De plus, alors là , il faudrait que je regarde la doc mais les verrous ne se font pas forcément au niveau ligne mais peuvent être positionnés sur la page complète.

[Christianchristian]

Bonjour,

Les mots suivants "If isolation-clause" ont "sauté" du texte de mon précédent message. Désolé, c'est pas moi c'est le copier/coller.


Cordialement,

[ruthene]

Quel est l'ordre passé par tes transactions CICS ? Combien il y a t-il d'enregistrement dans ta table ?

Une première solution est peut-être de passer en locksize row, sinon tu peux essayer en augmentant le pctfree.

[Luc Orient]

Déjà faudrait voir par un outil d'analyse de trace (DB2 PM par exemple) si c'est un DEADLOCK ou un TIMEOUT (c'est pas la même chose bien sûr !) et voir quels sont les processus (PLANS) et ressources (TABLES) en cause ...

Le DIRTY READ (ISOLATION UR) est à manier avec prudence car si il peut résoudre un problème technique ponctuel précis, il peut engendrer de redoutables soucis fonctionnels (mise à jour incohérente, perte de mise à jour etc) ...

[mousquetaires]

Merci pour votre aide, mais je crois que le problème est plus complexe. Je vais préciser la problématique :
Cette fameuse table qui pose problème fait partie d'une application qui a été mal conçue. En fait cette table sert à bloquer des accès sur des données en mise à jour à partie d'une clé. En théorie elle doit être vide car chaque transaction bloque une donnée en écrivant une ligne et en la supprimant en fin d'échange.
Le problème se trouve à priori dans la multitude d'accès en un temps réduit.
Est-ce un problème d'index ? faut-il revoir la déclaration de la table ?
Cette table n'a pas d'index secondaire.

Avez-vous d'autres idées ????

[Luc Orient]

Merci pour votre aide, mais je crois que le problème est plus complexe. Je vais préciser la problématique :
Cette fameuse table qui pose problème fait partie d'une application qui a été mal conçue. En fait cette table sert à bloquer des accès sur des données en mise à jour à partie d'une clé. En théorie elle doit être vide car chaque transaction bloque une donnée en écrivant une ligne et en la supprimant en fin d'échange ...

Il y a une seule lignes pour toutes les transactions ? plusieurs ?

A mon avis il serait plus judicieux de bloquer les transactions avec une lecture exclusive (SELECT ... FOR UPDATE OF) ou même une mise à jour (UPDATE) sur une ligne de même clé et ceci en tout début de transaction ...

Comment peut-on bloquer en écrivant une ligne ? Je ne comprends pas ...

[mousquetaires]

Chaque transaction, avant de mettre à jour les données d'une autre table va ecrire une ligne avec un identifiant correspondant à la donnée à mettre à jour. Cela se comporte comme avec un controle de time-stamp.

[Luc Orient]

Chaque transaction, avant de mettre à jour les données d'une autre table va ecrire une ligne avec un identifiant correspondant à la donnée à mettre à jour. Cela se comporte comme avec un controle de time-stamp.

C'est toujours pas très clair pour moi ...
Qu'appelez-vous un contrôle de Timestamp ?

[Christianchristian]

Bonsoir,

Si j'ai bien compris cette table permet aux transactions CICS, de gérer les accès concurrents susceptibles de survenir sur une même entité fonctionnelle ?
Par exemple : deux utilisateurs d'un service commercial se proposant par erreur de modifier au même moment l'en-tête d'une même commande. Si ce type de situation est mal gérée (ou pas gérée) c'est la dernière personne qui valide son travail qui mettra effectivement à jour l'entité "en-tête de commande".
Vous mentionnez :
"va ecrire une ligne avec un identifiant correspondant à la donnée à mettre à jour".
hypothèse :
Dans ce cas ce type de contrôle doit être effectué au niveau de la donnée, c'est-à-dire au niveau (applicatif) le plus bas.
Ce qui revient à dire que, pour rester cohérente, une même transaction CICS de mise à jour va devoir insérer temporairement (le temps que dure l'intervention de l'utilisateur qui utilise la fonction applicative CICS) dans la table de service autant de lignes que de données à modifier. En fin d'intervention de l'utilisateur ces lignes sont supprimées de la table de service. J'ai entendu parler de quelque chose de semblable dans une banque, c'était "à la mode" par un moment ça s'imposait rarement !.
Cela sous entend, en extrapolant ce scénario, qu'un grand nombre de lignes peuvent être insérées ou effaçées au même moment dans la table en question, par n transactions de mise à jour s'exécutant en "parallèle". Cela semble cadrer avec ce que vous mentionnez :
"Le problème se trouve à priori dans la multitude d'accès en un temps réduit".
De plus, la taille de la clef primaire doit être assez importante :
- identifiant de l'entité fonctionnelle concernée par la mise à jour.
- identifiant de la donnée concernée par la mise à jour.
- .....................

Si cette hypothèse est juste, je ne vois pas grand chose à faire d'autre que scinder la table et/ou retoucher les applications concernées.

Cordialement,

[ruthene]

C'est toujours pas très clair pour moi ...
Qu'appelez-vous un contrôle de Timestamp ?

Pour moi non plus, c'est toujours pas clair. Tu peux avoir plusieurs lignes simultanément dans ta table ?

[jab]

Si cette hypothèse est juste, je ne vois pas grand chose à faire d'autre que scinder la table et/ou retoucher les applications concernées.

Cordialement,

Je le crains.

[Luc Orient]

Bonsoir,

Si j'ai bien compris cette table permet aux transactions CICS, de gérer les accès concurrents susceptibles de survenir sur une même entité fonctionnelle ?
Par exemple : deux utilisateurs d'un service commercial se proposant par erreur de modifier au même moment l'en-tête d'une même commande. Si ce type de situation est mal gérée (ou pas gérée) c'est la dernière personne qui valide son travail qui mettra effectivement à jour l'entité "en-tête de commande".
...

C'est exactement ce que sait faire un SGBD digne de ce nom et en particulier DB2 for z/OS.

Le problème risque de se compliquer si on veut gérer les mises à jour concurrentes entre l'affichage sur l'écran et le retour sur le serveur central ...

Est-ce le cas ici ?

[mousquetaires]

Merci à vous tous pour votre aide...

Après avoir testé le SELECT contenant le WITH UR, qui empêche d'avoir le fameux -911, nous allons supprimer purement et simplement cette table de service qui nous pose problème. Sa création a été une hérésie car elle ne sert à rien sinon qu'à poser des problèmes. Il est plus simple et plus sûr de garantir la l' la cohérence d'une mise à jour par le controle du time-stamp fournit par DB2.

F.B

[Christianchristian]

Bonsoir,

.............. si on veut gérer les mises à jour concurrentes entre l'affichage sur l'écran et le retour sur le serveur central ...

C'est préférable et recommandé, je pense,

Cordialement,

[Christianchristian]

Bonsoir,

........................ Il est plus simple et plus sûr de garantir la cohérence d'une mise à jour par le controle du time-stamp fournit par DB2.
F.B

Pouvez-vous préciser en quoi consiste le contrôle du time-stamp ? J'ai cherché sur internet et dans mes docs, je n'ai rien trouvé.

Cordialement,

[ruthene]

Moi non plus je ne saisi pas ce dont tu parle par contrôle du timestamp ?

La cohérence de tes données sera garantie si tu utilises des SELECT ... FOR UPDATE OF suivi d'un UPDATE.