NFE113 - 9 - Gestion Des Transactions

Conception et
Administration des
Bases de Données
Conservatoire National des Arts et
Métiers
Aix-en-Provence
Olivier Michelet
CNAM Aix en Provence -
Conception et Administration des Bases de Données
●
Les systèmes de gestion de bases de données
– Les bases de données, SGBD, Définitions
●
Conception et modélisation des Bases de Données
– La modélisation conceptuelle de données : Le modèle Entité – Association
– La normalisation
– Du modèle conceptuel au modèle relationnel
●
Architecture d’une base de données Relationnelle
– Rappels : Les systèmes de fichiers
– La Structure Physique – La Structure Logique – Le Schéma
●
Architecture d’un SGBDR
– Analyseur syntaxique, Optimiseur de Requêtes, Gestionnaire des Transactions,
Accès Concurrents, Principe de verrouillage des Données, Sécurité / Reprise
●
Mise en œuvre d’une base de données relationnelle
– Algèbre Relationnelle – Opérations Logiques
– Création / Manipulation de Bases de Données
●
Administration / Optimisation / Sécurité / Règles de programmation
●
Approche de la gestion des SI répartis et fédérés
●
Nouvelles technologies et Bases de Données
Olivier Michelet 2
●
Architecture d’un SGBD Relationnel
– Le Gestionnaire de Transactions
Définition :
Une transaction est une séquence d’ordres SQL qui peuvent être considérés comme
des unités de traitement uniques et dans lesquelles chaque modification de donnée
peut être validée ou annulée intégralement.
Olivier Michelet 3
●
Une transaction est une suite d’instructions qui réussissent ou qui échouent en totalité
► il ne peut pas y avoir de réussite partielle
- Si elle réussit, les modifications apportées à la base sont permanentes, et la

transaction est inscrite au journal.
- Si une instruction échoue, toutes les instructions précédentes de la transaction sont
annulées et la base retrouve l’état dans lequel elle était avant la transaction.
Toutes les transactions sont enregistrées dans un fichier nommé le journal des
transactions.
Ce journal permet de restaurer la base de données en cas de panne sur le ou les
fichiers de données. Il sert également à effectuer le retour arrière sur un échec de
transaction.
Il doit être évidemment sauvegardé régulièrement, car pour restaurer complètement
une base, il faut être capable d'appliquer à nouveau toutes les modifications depuis la
dernière sauvegarde.
C’est le rôle du journal des transactions de répertorier toutes ces informations.
Olivier Michelet 4
●
Propriétés ACID des transactions
• Atomicité :
une transaction est une unité d’exécution indivisible
• Cohérence :
respecte les contraintes d ’intégrité
les contraintes de type différé sont vérifiées à la validation
• Isolation :
l’exécution est indépendante de l ’exécution des autres transactions
• Durabilité :
le résultat d ’une transaction validée ne doit pas être perdu
Olivier Michelet 5
●
Olivier Michelet 6
●
La plupart de SGBD offrent 2 niveaux de gestion des transactions:
Auto Commit On:

Chaque ordre SQL est une transaction. Les modifications de données résultant de
chaque ordre sont automatiquement validées.
Auto Commit Off:

Les transactions sont démarrées et finies de manière explicite par le programme. Les
modifications de données ne sont validées que lorsque le programme en donne
l’ordre.
Il existe trois ordres transactionnels :

Start Transaction – Pour démarrer une nouvelle transaction.
Commit – Pour valider les modifications de la transaction courante.
Rollback – Pour annuler toutes les mises à jour de la transaction courante.
Olivier Michelet 7
●
Le mode d’Isolation transactionnelle
L’impact d’une transaction dans une session unique est simple à comprendre.
Cependant, il en va différemment dans le cas de sessions multiples et concurrentes; une

transaction peut avoir un impact d’une session sur une autre.
Olivier Michelet 8
●
Soient les deux transactions ci-dessous :

T1 :
a) x ← lire (X)
b) x ← x-N
c) X ← écrire (x)
T2 :
a) y ← lire(X)
b) y ← y+ M
c) X ← écrire(y)
Si l ’on exécute :
T1a), T1b), T2a), T2b), T1c), T2c),
l ’effet de l ’opération T1b) est perdu.
T1 doit donc travailler en isolation jusqu’à sa terminaison, puis T2 s'exécutera à son tour.
Olivier Michelet 9
●
Trois types d’interactions peuvent survenir :
Dirty Read
Une transaction T1 lit des changements non validés d’une transaction T2.
Si T2 applique une annulation de ces mises à jour, T1 aura utilisé des données
erronées.
Non-Repeatable Read
Une transaction T1 lit une valeur sur rang qui est en cours de modification et validé
par une transaction T2 ultérieurement.
Si T1 lit à nouveau le même rang, le résultat sera différent et paraîtra incohérent.
Phantom
Une transaction T1 lit un ensemble de rangs qui satisfont une condition.
Une seconde transaction T2 effectue des insertions qui satisfont cette condition.
Si T1 effectue la même requête une nouvelle fois, il recevra des rangs fantômes.
Olivier Michelet 10
●
Pour éviter ces phénomènes parasites, 4 niveaux d’isolation sont définis dans SQL:
Read Uncommitted
Niveau minimal d’isolation. Les trois types d'interactions sont possibles.
Read Committed
Les lectures Dirty Read sont évitées. Toutefois les Non-Repeatable Read et Phantom
sont encore possibles.
Repeatable Read
Les Dirty Read and Non-Repeatable Read sont évités mais pas les Phantom.
Serializable
C’est le plus haut niveau d’isolation, aucun des cas présentés ci-dessus n’est
possible.
La commande SET permet de modifier le niveau d’isolation pour la transaction courante:
SET TRANSACTION ISOLATION LEVEL D
Ou pour la session:
SET SESSION TRANSACTION ISOLATION LEVEL D
Olivier Michelet 11
●
– Les Accès Concurrents
Lors de la lecture de données dans une base, le SGBD met en place des « verrous ».
Ce sont des mécanismes qui permettent d’éviter les erreurs de lectures concurrentes.
Il existe deux types de verrou :
Le verrou en Lecture (Read Lock)

La donnée verrouillée est bloquée en lecture pour la session courante.
Les autres sessions peuvent lire les données verrouillées mais ne peuvent pas les
modifier.
Ce type de verrou est également appelé verrou « partagé ».
Le verrou en Ecriture (Write Lock)

La donnée verrouillée est bloquée en écriture pour la session courante.
Les autres sessions ne peuvent pas accéder aux données, ni en lecture ni en
écriture.
Ce type de verrou est appelé verrou « exclusif ».
Olivier Michelet 12
●
Il y a trois niveaux de verrou :
Table (Table Lock)

Le verrou est appliqué au niveau de la table. Tous les rangs sont bloqués.
Colonne (Column Lock)

Le verrou est appliqué au niveau de la colonne.
Quelques colonnes d’un rang sont bloquées, les autres colonnes et les autres rangs
sont accessibles.
Rang (Row Lock)

Le verrou est appliqué au niveau du rang. Les autres rangs ne sont pas concernés.
Toutefois, pour accélérer les lectures, le SGBD accède à des pages de données qui
sont de ce fait verrouillées (Verrou sur les pages).
Attention, les pages contiennent de nombreux rangs !!!
L’ordre LOCK TABLES pose un verrou sur une table. Il supprime les autres verrous :
LOCK TABLES nom_table {READ | WRITE}, ...;
L’ordre UNLOCK TABLES enlève tous les verrous précédemment posés :

UNLOCK TABLES
Olivier Michelet 13
●
Compatibilité (O/N)
avec les autres modes
de verrouillage
Mode de verrouillage Commandes SQL RS R S SR X
correspondantes X X
RS : Lignes partagées - Select ...from ... for update
- Lock table ... in row share O O O O N
mode
- Insert into ...
- Update ...
- Delete from ...
RX : Lignes exclusives O O N N N
- Lock table ... in row exclusive
mode
S : Table partagée - Lock table ... in share mode O N O N N
SRX : Partage exclusif - Lock table ... in share O N N N N
de lignes exclusive mode
X : Table exclusive Lock table ... in exclusive N N N N N
mode
Olivier Michelet 14
●
Cas particulier : le Blocage Mortel – ou Dead Lock
Il se produit lorsque deux transactions sont mutuellement en attente de données qui sont
verrouillées de manière exclusive par l’autre transaction.
Le système est alors bloqué jusqu’à ce qu’une des deux transactions soit « tuée ».
Transaction 1 temps Transaction 2
La transaction T1 nécessite de mettre à jour La transaction T2 nécessite de mettre à jour

l’ensemble E2 à l’issue de la MàJ de E1 l’ensemble E1 à l’issue de la MàJ de E2
Lecture E1 Lecture E2
Lecture E2 Lecture E1
Blocage E1 Blocage E2
MàJ E1 MàJ E2
Demande de blocage E2 Demande de blocage E1
Attente de E2 Attente de E1
BLOCAGE
Olivier Michelet 15

NFE113 - 9 - Gestion Des Transactions

Transféré par

Informations du document

Titre original

Copyright

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

NFE113 - 9 - Gestion Des Transactions

Titre original :

Transféré par

Droits d'auteur :

Conception et

- Si elle réussit, les modifications apportées à la base sont permanentes, et la

Propriétés ACID des transactions

La plupart de SGBD offrent 2 niveaux de gestion des transactions:

Auto Commit On:

Auto Commit Off:

Il existe trois ordres transactionnels :

Le mode d’Isolation transactionnelle

Cependant, il en va différemment dans le cas de sessions multiples et concurrentes; une

Soient les deux transactions ci-dessous :

Trois types d’interactions peuvent survenir :

Il existe deux types de verrou :

Le verrou en Lecture (Read Lock)

Le verrou en Ecriture (Write Lock)

Il y a trois niveaux de verrou :

Table (Table Lock)

Colonne (Column Lock)

Rang (Row Lock)

L’ordre UNLOCK TABLES enlève tous les verrous précédemment posés :

Cas particulier : le Blocage Mortel – ou Dead Lock

Transaction 1 temps Transaction 2

La transaction T1 nécessite de mettre à jour La transaction T2 nécessite de mettre à jour

Centres d'intérêt liés

Vous aimerez peut-être aussi