Notion de transaction

Une transaction est un ensemble d'ordres SQL qui ont pour objectifs de faire passer la base de donnes, en une seule tape d'un tat cohrent un autre tat cohrent. La transaction comporte un dbut, une suite d'ordres SQL et une fin. Si la transaction choue les modifications dj effectues sont annules : ROLLBACK. Si l'ensemble des requtes peuvent s'excuter la transaction est valide : COMMIT

Exemple

Transfert bancaire :

dbit du compteA <-> crdit du compteB Begin transaction

compteA = compteA 10 compteB = compteB + 10 Commit

End transaction

Le gestionnaire de transactions

Il doit assurer le contrle des transactions et assure les proprits ACID :

Atomicit : Tout ou rien Cohrence : Satisfaction des contraintes d'intgrit Isolation : Pas d'interfrences entre les transactions Durabilit : Permanence des modifications effectues

L'atomicit

Excution en tout (COMMIT) ou rien (ROLLBACK) La proprit d'atomicit est respecte par le schma d'excution suivant :

Dbut transaction

Action1, action2, action3 ... Si toutes les actions sont correctement excutes Alors Valider la transaction (COMMIT) Sinon Annuler ses effets (ROLLBACK) Fin Si

Fin transaction

La cohrence

La cohrence satisfait les contraintes d'intgrit Une transaction doit faire passe la base d'un tat correct un autre tat correct L'ordre des oprations d'une transaction est important Excuter les oprations dans un autre ordre peut conduire des situations ne vrifiant plus les contraintes d'intgrit

L'isolation

Les transactions ne doivent pas interfrer T1

T2

1 : x <-- lire(X) 2 : x <-- x - N 3 : X<-- ecrire(x)

1 : y <-- lire(X) 2 : y <-- y + M 3 : X<-- ecrire(y)

Si l'ordre des transactions est T11, T12, T21, T22, T13, T23 l'effet de l'opration est perdue

La durabilit

Permanence des modifications effectues Cette permanence doit tre vrifie en cas de panne matrielle ou logicielle Le fait que des modifications de donnes par une transaction ne soit par rpercutes dans la base avant leurs utilisations par une autre transaction peut occasionner des problmes Les fichiers journaux permettent de palier au non respect de cette proprit

Concurrence des transactions

Le SGBD permet plusieurs transactions de s'excuter paralllement Chaque transaction doit avoir l'impression d'tre la seule utiliser la base Le SGBD cherche maximiser le nombre de transactions et minimiser les temps d'excution

Notion d'ordonnancement

Le processeur partage son temps entre les diffrentes transactions Les lectures/critures des diffrentes transactions en cours peuvent tre entrelaces Les oprations de lecture/critures peuvent provoques des interfrences si elles s'intressent aux mmes objets La solution est la srialisabilit : un ordonnancement est correct s'il est quivalent au moins un ordonnancement squentiel des mmes transactions.

Le verrouillage

Une transaction verrouille l'objet obligeant les autres transactions attendre que l'objet se libre L'objet ou granule est l'unit verrouille. Il peut s'agir selon le cas de la base de donnes, d'une relation, d'un tuple ou d'un attribut. Le verrou peut-tre binaire, appos sur un granule, rendant celui-ci accessible ou inaccessible

Le verrouillage (suite)

Le verrou peut-tre de type partag

Share : permet aux autres transactions de lire la donne (select) Exclusive : la transaction dtient le granule pour modifier la donne (update, insert, delete)
Share Exclusive Share Oui Non Exclusive Non Non
Demande d'une transaction

Verrou appos

Verrouillage deux-phases (V2P)

Dans un premier temps la transaction ne peut que verrouiller les donnes dont elle besoin, dans un second temps elle ne peut que les dverrouiller Pour viter la situation d'interblocage, si la transaction n'arrive pas verrouiller l'ensemble des donnes dont elle besoin elle doit les dverrouiller

Mthode d'estampillage

Estampille : identifiant qui dfinit l'ordre des vnements Toute transaction reoit une estampille qui reprsente le moment o elle commence Chaque objet conserve les estampilles read et write de la dernire transaction Une transaction ne peut lire ou crire un objet que si son estampille est suprieure l'estampille correspondante de l'objet

Segments d'annulation

Appels galement rollback segments Contiennent les anciennes valeurs des enregistrements en cours de modification dans la transaction. Ces segments sont utiliss :

Pour assurer une lecture consistante des donnes Pour annuler des transactions En cas de restauration

Les lectures consistantes

L'objectif est de rduire l'attente lors d'accs concurrents. Oracle assure :

Qu'au sein d'un ordre SQL les donnes ne changeront pas Les lectures ne seront pas bloques par des utilisateurs effectuant des modifications Les modifications ne seront pas bloques par utilisateurs effectuant des lectures Un utilisateur ne peut lire les modifications effectues par un autre si elles n'ont pas t valides

Les lectures consistantes (suite)

Oracle conserve toujours les anciennes valeurs et les donnes mises jour. Les anciennes donnes sont copies dans les rollback segments avant que les mises jour ne soient faites dans les segments de donnes. Ce n'est qu'au moment du COMMIT que le rollback segment est libr S'il y a ROLLBACK les informations du segment d'annulation sont copies dans les enregistrements affects

Segment d'annulation (suite)

Un segment d'annulation est partage par un certain nombre de transactions L'entte d'un segment d'annulation contient une table des transactions ayant des entres dans le segment Les critures dans les rollback segments sont galement journaliss (redo logs)

Segment d'annulation (suite)

Un rollback segment est un espace physique contenant des rollback entries Chaque entre contient :

L'identification du fichier de donnes L'identification du bloc contenant les donnes modifies La valeur avant modification de la donne

Les entres correspondant une mme transaction sont chanes entre elles

Types de tables MySQL

MySQL supporte plusieurs moteurs de stockage, qui gre diffrents types de tables. Les moteurs de tables MySQL peuvent tre transactionnels ou non-transactionnels. Lorsque vous crez une table, vous pouvez indiquer MySQL le type de table avec la clause ENGINE
CREATE TABLE t (i INT) ENGINE = INNODB;

Si vous omettez ENGINE, le type de table par dfaut sera utilis. C'est gnralement MyISAM. Cela peut tre chang en modifiant la variable systme table_type.

Moteurs non-transactionnels

Le moteur de tables originel tait ISAM, qui grait des tables non-transactionnelles. Ce moteur a t remplac par le moteur MyISAM Le moteur HEAP propose des tables stockes en mmoire Le moteur MERGE permet le regroupement de tables MyISAM identiques sous la forme d'une seule table

Moteurs transactionnels

Les moteurs InnoDB et BDB grent des tables transactionnelles NDBCluster est le moteur de stockage du cluster MySQL qui implmente des tables rparties sur plusieurs serveurs.

Cration de tables MySQl

MySQL cre toujours un fichier .frm pour stocker le type de la table et les informations de dfinition. Le serveur cre le fichier .frm par dessus le moteur de stockage. Les moteurs peuvent crer des fichiers supplmentaires, en fonction de leurs besoins.

Les avantages des tables transactionnelles

Plus sr. Mme si MySQL crashe ou que vous avez un problme matriel, vous pouvez rcuprer vos donnes, soit par un recouvrement automatique, soit partir d'une sauvegarde combine avec le log des transactions. Vous pouvez combiner plusieurs commandes et les accepter toutes d'un seul coup avec la commande COMMIT. Vous pouvez utiliser ROLLBACK pour ignorer vos modifications (si vous n'tes pas en mode autocommit).

Les avantages des tables transactionnelles (suite)

Si une mise jour choue, tout vos changements seront annuls. (Avec les tables non-transactionnelles tous les changements oprs sont permanents) Gre mieux les accs concurrents si la table reoit simultanment plusieurs lectures.

Avantages des tables non-transactionnelles

Plus rapides Utilisent moins d'espace disque Utilisent moins de mmoire pour excuter les mises jour.

Type de table Sakila

+---------------+--------+ | table_name | engine | +---------------+--------+ | actor | InnoDB | | address | InnoDB | | category | InnoDB | | city | InnoDB | | country | InnoDB | | customer | InnoDB | | employe | InnoDB | | film | InnoDB | | film_actor | InnoDB | | film_category | InnoDB | | film_text | MyISAM | | inventory | InnoDB | | inventory_sav | InnoDB | | language | InnoDB | | payment | InnoDB | | rental | InnoDB | | staff | InnoDB | | store | InnoDB | +---------------+--------+

mysql> select table_name, engine -> from information_schema.tables -> where table_schema='sakila' -> and table_type='base table';

Prsentation des tables innoDB

Gestionnaire de table transactionnelle (compatible ACID), avec validation (commits), annulations (rollback) et capacits de restauration aprs crash. Utilise un verrouillage de lignes, et fournit des lectures cohrentes comme Oracle, sans verrous.