Informations sur le Dirty Read

[lolobuell]

Bonjour, j'aimerai avoir des informations sur le uncommited read de db2.
Par exemple :
Un premier programme vide une table mais n'a pas encore fait son commit.
Un deuxième programme lit au même moment cette table en dirty read, est-ce qu'il va tomber sur une table vide ou bien sur les données qu'il y avait ?

Sinon, est-ce qu'il y a d'autres niveaux, comme sur oracle ?

Merci d'avance pour vos réponses.

Laurent

[lolobuell]

J'ai trouvé la réponse à ma question :
Certains SGBDs, Oracle en particulier, assurent une lecture consistante des données pendant l'exécution d'un seul ordre SQL ; par exemple, un ordre SELECT ou UPDATE va travailler sur les lignes telles qu'elles étaient au moment du début de l'exécution de la commande, même si entre-temps une autre transaction validée par un COMMIT a modié certaines de ces lignes.
Les SGBDs comme DB2 qui ne conservent pas plusieurs versions des données récemment modiées n'offrent pas cette lecture consistante.

En gros, faut que je passe en oracle ....

[fsmrel]

Quel DB2 utilisez-vous ?

Dans le cas de DB2 for z/OS, ça fait 20 ans que le mécanisme de verrouillage fonctionne de manière efficace. Par exemple, une tâche ayant acquis un verrou de type S (Share) sur une page bloque les tentatives de mise à jour de la part des tâches concurrentes sur cette page. Ceci vaut a fortiori si elle a acquis un verrou de mise à jour (U ou X). Le mécanisme vaut évidemment au niveau du tablespace ou de la ligne, suivant le paramétrage retenu : Je vous engage à ce sujet à consulter la documentation technique et regarder de près le paramètre Locksize de l'instruction Create Tablespace (SQL reference). Vous verrez que le verrouillage peut être défini à plusieurs niveaux.

Et consultez le paramètre Isolation de la Commande Bind (Command reference).

En tout état de cause, si vous utilisez le Uncommitted Read (Bind Package ... Isolation(UR)), sachez que les résultats sont par définition imprévisibles, ce qui n'est pas très scientifique et donc à éviter à tout prix...

[fsmrel]

J’ai constaté qu’après envoi de ma réponse, vous aviez "résolu" votre problème :

Certains SGBDs, Oracle en particulier, assurent une lecture consistante des données pendant l'exécution d'un seul ordre SQL ; par exemple, un ordre SELECT ou UPDATE va travailler sur les lignes telles qu'elles étaient au moment du début de l'exécution de la commande, même si entre-temps une autre transaction validée par un COMMIT a modifié certaines de ces lignes.

Je pose la question :
Au temps t1, la tâche A lit une ligne L de la table T. La colonne Montant vaut 2000.
A t2, la tâche B (vous) lit la même ligne de la table T1. La colonne Montant vaut toujours 2000.
A t3, la tâche t1 ajoute 100 à la colonne Montant de la ligne L qui vaut maintenant 2100.
A t4, la tâche t1 effectue un commit.
A t5, vous ajoutez 50. Montant prend la valeur 2050.
A t6, vous faites un commit.

En théorie, dans un contexte normal, Montant doit avoir pris la valeur 2150. Êtes-vous certain que votre résultat est bien celui-ci ? N’y aurait-il pas une mise à jour dans le dos ? Autrement dit, que vous avez annulé la mise à jour effectuée par A ?

Je n’ai pas vérifié le comportement d’Oracle à ce sujet, donc je me trompe peut-être, mais je vous engage à vérifier de près.