Quelle est la différence entre la lecture non récupérable et la lecture fantôme ?

Question

Quelle est la différence entre lecture non répétable y lecture fantôme ?

J'ai lu le Article sur l'isolation (systèmes de bases de données) de Wikipedia mais j'ai quelques doutes. Dans l'exemple ci-dessous, que se passera-t-il : le lecture non répétable y lecture fantôme ?

#### Transaction A

SELECT ID, USERNAME, accountno, amount FROM USERS WHERE ID=1

#### SORTIE :

1----MIKE------29019892---------5000

#### Transaction B

UPDATE USERS SET amount=amount+5000 where ID=1 AND accountno=29019892;
COMMIT;

#### Transaction A

SELECT ID, USERNAME, accountno, amount FROM USERS WHERE ID=1

Une autre question se pose : dans l'exemple ci-dessus, quel niveau d'isolation doit-on utiliser ? Et pourquoi ?

Answer 1

Tiré de Wikipédia (qui contient d'excellents exemples détaillés à ce sujet) :

Une lecture non répétable se produit lorsque, au cours d'une transaction, une ligne est récupérée deux fois et que les valeurs de la ligne diffèrent entre les lectures.

y

Une lecture fantôme se produit lorsque, au cours d'une transaction, deux requêtes identiques sont exécutées et que la collection de lignes renvoyée par la seconde requête est différente de la première.

Exemples simples :

• L'utilisateur A exécute deux fois la même requête.
• Entre-temps, l'utilisateur B exécute une transaction et la valide.
• Lecture non répétable : La ligne A que l'utilisateur A a interrogée a une valeur différente la deuxième fois.
• Lecture fantôme : Toutes les lignes de la requête ont la même valeur avant et après, mais des lignes différentes sont sélectionnées (parce que B en a supprimé ou inséré). Exemple : select sum(x) from table; renverra un résultat différent même si aucune des lignes concernées n'a été mise à jour, si des lignes ont été ajoutées ou supprimées.

Dans l'exemple ci-dessus, quel niveau d'isolation doit être utilisé ?

Le niveau d'isolation dont vous avez besoin dépend de votre application. Un "meilleur" niveau d'isolation a un coût élevé (comme la réduction de la concurrence).

Dans votre exemple, vous n'aurez pas de lecture fantôme, car vous ne sélectionnez qu'une seule ligne (identifiée par la clé primaire). Vous pouvez avoir des lectures non répétables, donc si c'est un problème, vous pouvez avoir un niveau d'isolation qui l'empêche. Dans Oracle, la transaction A pourrait également émettre un SELECT FOR UPDATE, la transaction B ne pouvant alors pas modifier la ligne tant que A n'a pas terminé.

Answer 2

J'aime y penser d'une manière simple :

Les lectures non répétables et les lectures fantômes sont liées à des opérations de modification de données provenant d'une transaction différente, qui ont été validées après le début de votre transaction et qui ont ensuite été lues par votre transaction.

Les lectures non répétables ont lieu lorsque votre transaction est validée. MISE À JOUR d'une autre transaction. La même ligne a maintenant des valeurs différentes de celles qu'elle avait au début de votre transaction.

Les lectures fantômes sont similaires, mais lorsqu'il s'agit de lire à partir d'un fichier de données engagé, la lecture fantôme est plus facile. INSERTS et/ou DELETES d'une autre transaction. Il y a de nouvelles lignes ou des lignes qui ont disparu depuis le début de la transaction.

Les lectures salissantes sont similaire aux lectures non répétables et aux lectures fantômes, mais elles concernent la lecture de données non validées et se produisent lorsqu'une UPDATE, INSERT ou DELETE d'une autre transaction est lue, et que l'autre transaction n'a PAS encore validé les données. Il s'agit de la lecture de données "en cours", qui peuvent ne pas être complètes et ne jamais être validées.

Answer 3

En Lecture non répétitive se présente comme suit :

1. Alice et Bob lancent deux transactions dans la base de données.
2. Bob's lit l'enregistrement et la valeur de la colonne titre est Transactions.
3. Alice modifie le titre d'un enregistrement donné en lui donnant la valeur ACID.
4. Alice effectue sa transaction dans la base de données.
5. Si Bob relit l'enregistrement, il observera une version différente de cette ligne du tableau.

En Lecture fantôme L'anomalie peut se produire comme suit :

1. Alice et Bob lancent deux transactions dans la base de données.
2. Bob lit tous les enregistrements post_comment associés à la ligne post dont l'identifiant est 1.
3. Alice ajoute un nouvel enregistrement post_commentaire associé à la ligne post dont l'identifiant est 1.
4. Alice effectue sa transaction dans la base de données.
5. Si Bob relit les enregistrements post_comment dont la valeur de la colonne post_id est égale à 1, il observera une version différente de cet ensemble de résultats.

Ainsi, alors que le Lecture non répétitive s'applique à une seule ligne, le Lecture fantôme concerne une série d'enregistrements qui satisfont aux critères de filtrage d'une requête donnée.

Answer 4

Lire les phénomènes

• Lectures salissantes lecture de données non autorisées provenant d'une autre transaction
• Lectures non répétables : lecture de données COMMITTED à partir d'un UPDATE requête provenant d'une autre transaction
• Le fantôme lit : lecture de données COMMITTED à partir d'un INSERT o DELETE requête provenant d'une autre transaction

Nota : Les déclarations DELETE d'une autre transaction ont également une très faible probabilité de provoquer des lectures non répétables dans certains cas. Cela se produit lorsque l'instruction DELETE supprime malheureusement la même ligne que celle que la transaction en cours interrogeait. Mais il s'agit d'un cas rare, qui a beaucoup moins de chances de se produire dans une base de données dont chaque table contient des millions de lignes. Les tables contenant des données de transaction ont généralement un volume de données élevé dans un environnement de production.

Nous pouvons également observer que, dans la plupart des cas d'utilisation, les mises à jour sont plus fréquentes que les insertions ou les suppressions (dans ce cas, le danger de l'utilisation de lectures non répétables restent seulement - Le fantôme lit ne sont pas possibles dans ces cas-là). C'est pourquoi les mises à jour sont traitées différemment des insertions et suppressions, et l'anomalie qui en résulte est également nommée différemment.

Il y a également un coût de traitement supplémentaire associé à la gestion des INSERT-DELETE, au lieu de la simple gestion des UPDATES.

Avantages des différents les niveaux d'isolement

• READ_UNCOMMITTED n'empêche rien. C'est l'isolement zéro niveau d'isolement
• READ_COMMITTED n'en empêche qu'une seule, c'est-à-dire que Dirty lit
• REPEATABLE_READ permet d'éviter deux anomalies : Les lectures sales et les les lectures non répétables
• SERIALIZABLE permet d'éviter ces trois anomalies : Les lectures parasites, les lectures non répétables et les lectures fantômes.

Dans ce cas, pourquoi ne pas simplement définir la transaction SERIALISABLE à tout moment ? La réponse à la question précédente est la suivante : le paramètre SERIALIZABLE rend les transactions très difficiles à gérer. lent ce que nous ne voulons pas non plus.

En fait, la consommation de temps de transaction se fait au rythme suivant :

SERIALISABLE > LECTURE_RÉPÉTABLE > READ_COMMITTED > READ_UNCOMMITTED

Le paramètre READ_UNCOMMITTED est donc le paramètre le plus rapide .

Résumé

En fait, nous devons analyser le cas d'utilisation et décider d'une niveau d'isolement afin d'optimiser le temps de transaction et de prévenir la plupart des anomalies.

Notez que les bases de données peuvent avoir un paramètre REPEATABLE_READ par défaut. Les administrateurs et les architectes peuvent avoir une affinité pour choisir ce paramètre par défaut, afin d'améliorer les performances de la plateforme.

Answer 5

Il existe une différence dans la mise en œuvre de ces deux types de niveaux d'isolement.
Pour la "lecture non répétable", le verrouillage des lignes est nécessaire.
Pour la "lecture fantôme"，scoped-locking est nécessaire, même un table-locking.
Nous pouvons mettre en œuvre ces deux niveaux en utilisant verrouillage biphasé protocole.