Catégorie: Cohérence (consistency)

Cet article est la traduction d'un article de Tom Kyte sur son blog (L'article original en anglais se trouve ici). Lectures cohérentes et multi-versionnage, par Tom Kyte

Il est conseillé lire préalablement les premières partie:

• Ecritures cohérentes, par Tom Kyte (1ère partie)
• Ecritures cohérentes - observation d'un redémarrage (2ème partie)

La première chose qui vient à l'esprit, c'est que le trigger se déclenche deux fois. On avait une table avec une seule ligne, et un trigger BEFORE FOR EACH ROW qui se déclanche pour chaque ligne. Un a fait un update sur une seule ligne et le trigger s'est déclanché deux fois.

Vous devez penser aux conséquentes de cela. Si vous faites dans votre trigger quoi que ce soit qui ne soit pas transactionnel, vous pouvez avoir un problème assez sérieux.

» Lire la suite!

Cet article est la traduction d'un article de Tom Kyte sur son blog (L'article original en anglais se trouve ici).

Il est conseillé lire préalablement la première partie:

• Ecritures cohérentes, par Tom Kyte (1ère partie)

Voir un redémarrage d'une requête update est plus plus facile qu'on ne pense.
En fait, nous allons même en voir un avec une simple table d'une seule ligne.

» Lire la suite!

Cet article est la traduction d'un article de Tom Kyte sur son blog (L'article original en anglais se trouve ici). L'article est en 3 parties (il s'agit ici de la partie 1) et il est extrait de son livre Expert Oracle Database Architecture.


Il peut être utile de (re)lire avant:

• Lectures cohérentes et multi-versionnage, par Tom Kyte
• Statistiques 'db block gets' et 'consistent gets', par Jonathan Lewis

Nous avons étudié précédemment (en français ici) la lecture cohérente: la capacité d'Oracle à utiliser les informations d'undo pour fournir des requêtes non-bloquantes et cohérentes (c'est à dire correctes) pour une lecture. Nous savons que lorsque Oracle lit des blocs pour notre requête, dans le buffer cache, il s'assure que la version du bloc est assez 'vieille' pour que notre requête puisse le voir.

Mais cela soulève la question suivante: Qu'en est-il des écritures/modifications ? Qu'est-ce qui se passe lorsque vous exécutez l'instruction UPDATE suivante: UPDATE T SET X = 2 WHERE Y = 5;
et que, pendant que cette requête est en cours d'exécution, quelqu'un modifie une ligne en faisant passer la valeur de Y de 5 vers 6, et commite cette modification, avant que nôtre requête n'ait lu cette ligne ?

Autrement dit, lorsque votre mise à jour a commencé, certaines lignes ont Y=5. Et comme votre mise à jour fait des lectures cohérentes, elle voit pour cette ligne Y=5, puisque c'est la valeur qu'il y avait au moment où votre update a démarré. Cependant, la valeur actuelle de Y est maintenant 6, et non plus 5, et avant de mettre à jour la valeur de X, Oracle va vérifier si la valeur de Y est toujours 5. Maintenant que doit-il se passer ? Et comment cela impacte les update ?

De toute évidence, nous ne pouvons pas modifier une ancienne version d'un bloc: quand on va modifier une ligne, il faut modifier la version actuelle du bloc. En outre, Oracle ne peut pas simplement ignorer cette ligne, car ce serait une lecture incohérente et imprévisible. Ce que nous allons découvrir, c'est que dans ce cas, Oracle va redémarrer à zéro l'écriture des modification.

» Lire la suite!

Cet article est la traduction d'une réponse Tom Kyte à une question sur les vues cohérentes (L'article original en anglais se trouve ici).

Question:

J'ai lu qu'Oracle garantit une vue cohérente en lecture. Je l'ai lu, mais je n'ai pas l'impression que c'est très clair.
Pouvez-vous expliquer, avec vos mots, ce qu'est une vue cohérente ?

Réponse:

J'ai fais cela dans "Expert One on One Oracle".
J'ai écrit beaucoup là dessus et voici un court extrait (il y a beaucoup plus dans le livre).

Extrait de 'Expert One on One Oracle' de Tomas Kyte - Apress

Multi-Versionnage et Concurrence

Le Multi-versionnage (multiversioning) est un sujet lié au contrôle de concurrence d'accès aux données, car qu'il est à la base de ce mécanisme: Oracle implémente la concurrence d'accès en faisant des lecture multi-versions cohérentes (multi-version read consistent concurrency model). Dans le chapitre suivant 'Ce que vous devez savoir', nous allons parler des aspects techniques de manière plus détaillée, mais dans l'essentiel, il s'agit du mécanisme fourni par Oracle pour:

• faire des lectures cohérentes (Read-consistent queries): les requêtes donnent un résultat cohérent à un instant donné.
• Requêtes non bloquantes (Non-blocking queries): les requêtes en lecture ne sont jamais bloquées par les écritures, contrairement à ce qui se passe avec d'autres SGBD.

» Lire la suite!