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.