Discussion :

[wear12]

Bonjour à tous,

mon prof avait donner plusieurs définition de l’intégrité en lecture du dml donc à la fin je me suis un peu embrouillé si quelqu'un peut m'aider s'il vous plait, merci


- la première définition qu'il avait donner c'est qu'il n'y a pas d’interaction entre 2 instructions du dml par exemple si un user fait un update et un autre user un select l'user qui a fait le select va agir soit avant que l'update a lieu soit après mais jamais entre.

-la 2 ème définition c'est que le select garantie qu'il ne modifiera pas les donnees c est pourquoi on peut pas appeler une fonction qui modifie les donnes dans un select.


donc voilà j'ai un peu du mal à comprendre est ce que l’intégrité en lecture c'est uniquement pour le select ou pour toutes les instructions du dml?
Si quelqu'un peut me donner une meilleur définition s'il vous plait merci d'avance.

[escartefigue]

- la première définition qu'il avait donner c'est qu'il n'y a pas d’interaction entre 2 instructions du dml par exemple si un user fait un update et un autre user un select l'user qui a fait le select va agir soit avant que l'update a lieu soit après mais jamais entre.

Non, les interactions entre transactions sont liées aux types de verrous, à la taille des verrous et aux commits. Lisez vos cours sur ces sujets pour comprendre leur fonctionnement.

-la 2 ème définition c'est que le select garantie qu'il ne modifiera pas les donnees c est pourquoi on peut pas appeler une fonction qui modifie les donnes dans un select.

Un select ne modifie certes pas les données, mais il pose un verrou en lecture, qui peut provoquer le WAIT d'un thread qui s'exécute en parallèle et souhaite faire une mise à jour de la ligne.

Seuls les verrous en lecture de type "UR " (uncommited read) permettent à une tache concurrente de verrouiller en mise à jour la même ligne.

[skuatamad]

Un select ne modifie certes pas les données, mais il pose un verrou en lecture, qui peut provoquer le WAIT d'un thread qui s'exécute en parallèle et souhaite faire une mise à jour de la ligne.

La gestion des verrous, des transactions et des modes d'isolation est spécifique à chaque SGBD, il est généralement hasardeux de tenter des généralités.
Il y a quand même 2 grandes familles (DB2, Sybase, Sqlserver en mode non snapshot) et les SGBD MVCC, mais chacun avec ses spécificités.

Donc ce fonctionnement est vrai pour DB2 mais pas pour Oracle par exemple.

[escartefigue]

Oracle et les autres SGBD utilisent les mêmes principes : utilisation de verrous plus ou moins larges et plus ou moins restrictifs, qui sont levés lors du commit

La différence est une richesse plus ou moins importante sur les niveaux d'isolation et sur la taille des verrous (ex : pas d'isolation UR ni de verrou page avec Oracle)

[skuatamad]

Oracle et les autres SGBD utilisent les mêmes principes : utilisation de verrous plus ou moins larges et plus ou moins restrictifs, qui sont levés lors du commit

Certes mais ce que je voulais dire c'est que :

Un select ne modifie certes pas les données, mais il pose un verrou en lecture, qui peut provoquer le WAIT d'un thread qui s'exécute en parallèle et souhaite faire une mise à jour de la ligne.

Seuls les verrous en lecture de type "UR " (uncommited read) permettent à une tache concurrente de verrouiller en mise à jour la même ligne.

est probablement une description des verrous de DB2.

Et par exemple la 1ère définition donnée :

- la première définition qu'il avait donner c'est qu'il n'y a pas d’interaction entre 2 instructions du dml par exemple si un user fait un update et un autre user un select l'user qui a fait le select va agir soit avant que l'update a lieu soit après mais jamais entre.

est fausse sur Oracle, même si le "jamais entre" mériterait une description un peu plus précises...

[SQLpro]

La norme SQL impose 4 niveaux d'isolation, permettant de s'affranchir des anomalies transactionnelles...
0 - READ UNCOMMITTED => lecture sale (toutes anomalies possible)
1 - READ COMMITTED => Lecture de données validées (évite les lectures sales)
2 - REPEATABLE READ => Lecture répétables (évite les lectures sales et stabilise la relecture)
3 - SERIALIZABLE => "mise en série des transactions (évite toutes les anomalies donc évite les lectures sales et stabilise la relecture et interdit l'apparition de lignes fantômes)
Le verrouillage n'est que l'application physique au niveau de granularité souhaité de la technique de verrouillage induite par le niveau d’isolation choisit.
L'article sur le sujet est ici : http://sqlpro.developpez.com/isolation-transaction/
Les lectures bloquent les écritures (verrous partagés) et les écritures bloquent tout (verrous exclusif). On parle alors de verrouillage pessimiste, car les verrous doivent être posés AVANT le démarrage de tout traitement et la mise à jour est garantie si tous les verrous nécessaires ont été posés.

Les éditeurs de logiciels ont, pour la plupart, rajouté un niveau d'isolation "hors norme" représenté par le SNAPSHOT.
Ce niveau consiste à copier les données à traiter dans un autre espace de stockage, travailler dessus, et si le traitement propose des modifications de données (INSERT, UPDATE, DELLETE) alors, ces mises à jour sont reportées sur la "vraie" base, si, entre temps, personne n'a modifié le même jeu de données. On parle alors de verrouillage optimiste, car il n'y a pas pose de verrou (en fait si, mais pas de même nature...), les lectures ne bloquent personnes, les écritures ne bloquant qu'au moment du report.
En terme vulgaire c'est appelé MVCC dans PG ou Oracle... Mais le système existe aussi dans SQL Server (niveau d’isolation SNAPSHOT).

Cela dit ce niveau n'a pas que des avantages... Par exemple tout un traitement complexe ayant produit de nombreuses mise à jour et ayant couté cher en terme de ressources peut être au final abandonné au moment du COMMIT (validation) conduisant ainsi à un ROLLBACL forcé alors que l'on a demandé la validation...

Le seul SGBDR connu pour assurer les 4 niveaux de la norme et le SNAPSHOT est SQL Server.

Certains SGBDR ne respecte pas la norme SQL et ne propose que quelques niveaux d'isolation souvent différents de ce que la norme propose car ils mélange le SNAPSHOT et le READ COMMITTED. C'est le cas d'Oracle et de PostGreSQL, l'un ayant bêtement singé l'autre (je ne te dirait pas lequel.... mais c'est facile à deviner).

A +