Forums, scripts, cours, services pour webmaster, manuels (PHP, MySQL, HTML...) en français !
PHP / MySql
Recherche
 
ManuelPHP.com
Transférer une base de données InnoDB vers une autre machine
<<<
Modèle transactionnel de InnoDB Implémentation du multi-versionnage
>>>

7.5 Tables InnoDB
7 Types de tables MySQL
 Manuel de Référence MySQL 4.1 : Version Française

Présentation des tables InnoDB
Options de démarrage InnoDB
Créer des bases InnoDB
Créer des tables InnoDB
Ajouter et retirer des données et des logs InnoDB
Sauver et restaurer une base InnoDB
Transférer une base de données InnoDB vers une autre machine
->Modèle transactionnel de InnoDB
Implémentation du multi-versionnage
Structures de tables et d'index
Gestion de l'espace fichiers et des entrées/sorties disque
Gestion des erreurs
Restrictions sur les tables InnoDB
Historique de l'évolution InnoDB
Informations de contact InnoDB

7.5.8 Modèle transactionnel de InnoDB

Le modèle transactionnel d'InnoDB a pour but de combiner les avantages des bases de données multi-version aux verrouillages traditionnels en deux phases. InnoDB fait un verrouillage de ligne, et exécute les requêtes par défaut avec des lectures cohérentes non bloquante, de la même façon qu'Oracle. Les verrous InnoDB sont stockés de manière efficace, pour que l'escalade de transaction ne soit pas nécessaire : typiquement, plusieurs utilisateurs sont autorisés à verrouiller toutes les lignes dans une base, ou un sous ensemble aléatoire de ligne, sans que InnoDB ne soit à court de mémoire.

Avec InnoDB, toutes les activités des utilisateurs sont placées dans des transactions. Si le mode de validation automatique de MySQL est utilisé, chaque requête SQL représente une transaction. MySQL démarre toujours une nouvelle connexion avec de mode activé.

Si le mode de validation automatique est désactivé, avec la commande SET AUTOCOMMIT = 0 , alors nous considérons que l'utilisateur a toujours une transaction ouverte. Si il utilise les commandes COMMIT ou ROLLBACK , cela va terminer la transaction courante, et en démarrer une nouvelle. Les deux commandes vont libérer les verrous posés durant la transaction courante. Une validation COMMIT signifie que les modifications faites durant la transaction sont rendus permanents, et accessibles aux autres utilisateurs. Une annulation ROLLBACK , d'un autre coté, annule toutes les modifications faites durant la transaction.

Si la connexion est en mode AUTOCOMMIT = 1 , alors l'utilisateur peut réaliser une transaction à requêtes multiples en commençant par la commande BEGIN et en terminant la transaction par COMMIT ou ROLLBACK .

En termes de niveau d'isolations de transaction SQL-1992, le mode par défaut d'InnoDB est REPEATABLE READ . Depuis la version 4.0.5, InnoDB offre 4 niveaux d'isolation de transaction différents, tels que décrits dans le standard SQL 1992. Vous pouvez choisir le niveau d'isolation par défaut du serveur [mysqld] dans le fichier de configuration my.cnf :

transaction-isolation = {READ-UNCOMMITTED | READ-COMMITTED
                         | REPEATABLE-READ | SERIALIZABLE}
Un utilisateur peut modifier le niveau d'isolation d'une transaction ou des nouvelles connexions avec la commande suivante :

SET [SESSION | GLOBAL] TRANSACTION ISOLATION LEVEL
                       {READ UNCOMMITTED | READ COMMITTED
                        | REPEATABLE READ | SERIALIZABLE}
Notez qu'il n'y a pas de tirets dans les noms de niveaux de la syntaxe SQL. Si vous spécifiez le mot réservé GLOBAL dans la commande ci-dessus, cela va configurer les valeurs pour les nouvelles connexions, mais ne modifiera pas les valeurs des connexions déjà ouvertes. Tout utilisateur est libre de changer le niveau d'isolation de sa session, même durant la transaction. Dans les versions inférieure à 3.23.50, SET TRANSACTION n'avait aucun effet sur les tables InnoDB. Dans les versions inférieures à 4.0.5, seuls REPEATABLE READ et SERIALIZABLE étaient disponibles.

Vous pouvez connaître les valeurs de niveaux d'isolations global et courant avec la commande :


SELECT @@global.tx_isolation;
SELECT @@tx_isolation;
Durant le verrouillage de ligne, InnoDB utilise le verrouillage de clé suivante. Cela signifie qu'en plus des lignes de l'index, InnoDB verrouille aussi l'espace 'avant' un index, pour éviter les insertions d'un autre utilisateur. Un verrou de ligne suivante signifie le verrouillage de l'index et de l'intervalle entre cet index et le précédent. Un verrouillage d'espacement indique un verrouillage de l'espace entre deux index.

Voici une description plus détaillée des différents niveaux d'isolation des transactions de InnoDB :

  • READ UNCOMMITTED , qui est aussi appelé la 'lecture incohérente' : les commandes SELECT non bloquantes sont exécutées sans vérifier la présence de versions antérieures de la ligne : par conséquent, ces lectures ne sont pas cohérentes avec ce niveau d'isolation. Sinon, ce niveau fonctionne exactement comme READ COMMITTED .
  • READ COMMITTED Le niveau d'isolation qui se rapproche de celui d'Oracle. TOutes les commandes SELECT ... FOR UPDATE et SELECT ... LOCK IN SHARE MODE ne verrouille que les lignes d'index, et non pas les espaces qui les précèdent, et de cette manière, ils autorisent les insertions entre deux lignes verrouillées. Les commandes UPDATE et DELETE qui utilisent un index unique avec une condition de recherche, ne vont verrouiller que les index trouvés, et non pas les espaces précédent ces verrous. Mais avec les commandes UPDATE et DELETE en mode intervalle, InnoDB va poser des verrous de clé suivante, ou verrous d'espacement, et bloquer les insertions d'autres utilisateurs dans ces espaces. Ceci est nécessaire pour éviter la présence de lignes 'fantômes', qui sont néfastes pour la réplication. Les lectures cohérentes fonctionnent comme sous Oracle : chaque lecture cohérente, même durant une transaction, fixe et lit une version récente de données.
  • REPEATABLE READ est le niveau d'isolation par défaut d'InnoDB. SELECT ... FOR UPDATE , SELECT ... LOCK IN SHARE MODE , UPDATE , et DELETE qui utilisent un index unique comme condition de recherche, ne vont verrouiller que la ligne d'index trouvée, et non pas l'espace qui la prépare. Sinon, ces opérations vont employer le verrouillage de clés suivante, pour bloquer les insertions parasites. En lectures cohérentes il y a une différence importante avec le niveau d'isolation précédent : avec ce niveau, toutes les lectures faites dans une même transaction sont faîtes avec la version établit lors de la première lecture. Cette convention signifie que si vous faites plusieurs lectures SELECT dans une même transaction, ces SELECT seront cohérents entre eux.
  • SERIALIZABLE Ce niveau ressemble au précédent, mais toutes les lectures SELECT s sont implicitement converties en SELECT ... LOCK IN SHARE MODE .

Sommaire :

<< Modèle transactionnel de InnoDB >>
Transférer une base de données InnoDB vers une autre machine Tables InnoDB Implémentation du multi-versionnage





Google

Services webmasters

Les manuels
 

ManuelPHP.com © 2003-2012 Tigersun - Crédits
Webmaster Site Internet - Télécharger des Logiciels - Programme TV - Entraide Informatique - Agence de Communication
2017-12-12