PARTIE 1: TRANSACTION ET ORDRE CREATE TABLE ET DROP TABLE
1. Créer la table transa
2. Considérons les ordres CREATE et DROP. La création et la suppression d'une table sont- elles
transactionnelles ? Pour vérifier cela, avec vos deux connexions, tentez de créer la table
"transa" dans une transaction, et de vérifier dans l'autre session si vous la voyez .
Session1 :
Session 2 :
3. Que constatez-vous ?
Je constate que MySQL exécute immédiatement les commandes DDL (comme CREATE TABLE),
en dehors du contrôle transactionnel.
Donc même sans COMMIT, la table est déjà visible dans l’autre session.
4. Exécutez la même tentative avec un DROP.
Session 1 :
Session 2 :
5. Conclusion
En MySQL, les commandes DDL (CREATE, DROP, ALTER...) sont automatiquement validées.
Elles ne sont pas annulables via ROLLBACK.
PARTIE 2 : ATOMICITE D’UNE TRANSACTION COURANTE
6. Insérez trois ou quatre lignes dans la table transa et les voir,;
7. Modifiez une ligne, en supprimer une autre, enfin annuler les mises à jour venant d’être
effectuées (en écrivant « ROLLBACK ; »).
8. Vérifier le contenu de le contenu de la table et sa structure.
9. Conclusion
Toutes les modifications sont annulées
10. Insérer à nouveau trois ou quatre lignes, les modifier et les détruire partiellement, puis
valider (en écrivant « COMMIT ; ») ces mises à jour,
11. Faites maintenant un ROLLBACK. Que s’est-il passé ?
Le roolback ne fait rien car le commit a déjà validé les changements
12. Maintenant détruire les données de votre table et valider.
13. Insérer à nouveau dans votre table vide trois ou quatre lignes et clore la transaction par un
EXIT.
14. Reconnectez vous à SQL. Que s’est-il passé ? Expliquez
Les données saisies sont présentes car EXIT exécute un COMMIT implicite.
15. Dans votre table, insérez à nouveau deux ou trois lignes dans la table et fermez brutalement
votre session.
16. Reconnectez vous à SQL. Les données saisies ont-elles été préservées ? Expliquez!
Les données insérer avant la fermeture ne sont pas là
17. Insérer à nouveau deux ou trois lignes dans la table, puis ajouter une nouvelle colonne à la
table et essayer d’annuler les dernières insertions puis faites un DESC de la table. Conclusion.
Les modifications DDL ne sont pas annulées par un roolback .
18. Videz votre table par un delete.
PARTIE 3 : ATOMICITE D’UNE TRANSACTION COURANTE ET SAVEPOINT
19. Insérez trois ou quatre lignes dans la table transa et les voir,
20. Insérez deux ou trois lignes puis faites une sauvegarde partielle de la transaction (SAVEPOINT)
21. Insérez deux ou trois lignes puis faites une sauvegarde partielle de la transaction (SAVEPOINT)
22. Faites un ROLLBACK puis vérifiez le contenu votre table. Conclusion?
Toutes les lignes sont annulées.
23. Insérez deux ou trois lignes puis faites une sauvegarde partielle de la transaction (SAVEPOINT)
24. Insérez deux ou trois lignes puis faites une sauvegarde partielle de la transaction (SAVEPOINT)
25. Faites un COMMIT puis vérifiez le contenu votre table. Conclusion?
26. Videz votre table par un delete.
27. Insérez deux ou trois lignes puis faites une sauvegarde partielle de la transaction (SAVEPOINT)
28. Insérez deux ou trois lignes puis faites une sauvegarde partielle de la transaction (SAVEPOINT)
29. Faites une annulation partielle de la transaction (ROLLBACK TO …)
30. Vérifier le contenu de la table par un SELECT.
31. Faites un COMMIT. Et vérifiez le contenu de la table. Conclusion?
La première savepoint a été concervé et la deuxième a été supprimé
PARTIE 4 : TRANSACTION ET ORDRE DDL
32. Videz votre table par un delete.
33. Insérez deux ou trois lignes.
34. Faites un ALTER TABLE (par exemple, modification du schéma logique en général).
35. Faites un DESC de la table
36. Vérifiez le contenu de la table. Que constatez-vous? Conclusion??
Il y a une nouvelle colonne mais les données insérer sont toujours là.
