Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - Production 64 bits
ALTER SESSION SET ISOLATION_LEVEL = SERIALIZABLE;
Question 1 :
T1 (transaction 1) et T2 (transaction 2)
T1 : sélectionnez * dans tableName où status = 'A';
T2 : insérer dans tableName (id, status) les valeurs (1, 'I');
T2 : validation;
T1 : sélectionnez * dans tableName où status = 'I'; // Pourquoi T1 ne peut pas obtenir l'enregistrement avec le statut que j'ai engagé par T2 ? Est-ce parce que l'instantané créé par T1 et quelle est la portée de cet instantané, la table entière?
Question 2 :
T1 : insérer dans tableName (id, status) les valeurs (1, 'I');
T2 : insérer dans tableName (id, status) les valeurs (1, 'I'); // T2 est bloqué si id est unique. Pourquoi T2 bloqué? Parce que comme je le sais, les deux transactions créent un instantané, même si elles ne se sont pas encore engagées.
Y a-t-il des verrous prendre le participant dans ce scénario? Merci.
3 Réponses :
T1: sélectionnez * dans tableName où status = 'I'; // Pourquoi T1 ne peut pas obtenir l'enregistrement avec le statut que j'ai engagé par T2? Est-ce parce que l'instantané créé par T1 et quelle est la portée de cet instantané, la table entière?
Parce que la transaction SERIALIZE peut voir les données validées avant le début de la transaction ou les modifications apportées par la transaction elle-même. C'est pourquoi T1 ne peut pas voir l'enregistrement I tel qu'il a été inséré après le début de la transaction T1.
Répondant à votre deuxième question,
T2: insérer dans tableName (id, status) les valeurs (1, 'I'); // T2 est bloqué si id est unique. Pourquoi T2 blokced? Comme je l'ai connu, les deux transactions créent un instantané et elles ne se sont même pas encore engagées.
Même si les deux transactions sont SERIALIZE, Oracle maintient l'intégrité et ne permet pas de violer aucune contrainte. Vous ne pouvez donc pas ajouter l'enregistrement I dans votre transaction T2 qui ne viole aucune contrainte.
- Est-ce parce que l'instantané créé par T1
Oui
- et quelle est la portée de cet instantané, de la table entière?
SCN
Question2: Pourquoi T2 blokced?
Parce que vous avez une contrainte de clé unique ou primaire et qu'elle n'est pas différée.
Pourriez-vous me dire la portée de l'instantané dans ce scénario pour T1 en Question1 (semble SCN est un grand concept), merci.
@imp scope - base de données entière :) Toutes vos lectures sont "à partir de scn" de votre SCN de début de votre transaction
Suite à ce que signifie SERIALIZABLE:
SERIALISABLE. Ceci est généralement considéré comme le niveau d'isolation des transactions le plus restrictif, mais il fournit le degré d'isolation le plus élevé. Une transaction SERIALIZABLE fonctionne dans un environnement qui donne l'impression qu'aucun autre utilisateur ne modifie des données dans la base de données. Toute ligne que vous lisez est assurée d'être la même lors d'une relecture, et toute requête que vous exécutez est garantie de renvoyer les mêmes résultats pendant toute la durée d'une transaction.
question 1
Ainsi, dans T1, vous n'obtiendrez aucun changement effectué par T2, car votre niveau de transaction est SÉRIALISABLE. Ce niveau d'isolement garantit que votre requête renverra toujours les mêmes résultats. Les effets secondaires ou les modifications apportées par d'autres transactions ne sont pas visibles pour la requête, quelle que soit la durée de son exécution.
L'isolement sérialisable convient aux environnements:
En ce qui concerne votre deuxième question, la ligne sera verrouillée après l'exécution d'un commit, mais la ligne ne sera pas visible pour T2.
Plus d'informations ici et un bon exemple:
https://docs.oracle.com/cd/E25054_01/server.1111/e25789/consist.htm#BABCJIDI
Section 9.3 Lire les problèmes de cohérence et d'accès sérialisé dans les transactions sérialisables