Discussion :

[clouddd]

Bonjour,
Je voudrais comprendre comment fonctionne les transactions à travers un petit exemple.

Imaginons une table remplie avec plus 5000 données. Cette table est utilisée en permanence partout dans le monde. Que ce passe t'il lorsque par exemple je veux supprimer le contenu de la table et le remplacer par un autre contenu? Cette modification se fera par avec une transaction mais lors de l'execution de la requête la table est elle toujours disponible. Le script serait tout simplement un delete du contenu suivi d'un ajout (pas qu'un mais 5000).
Durant ce temps d'execution, la table est elle toujours accessible en lecture? lecture/ecriture (même si cela veut dire que les écritures seront écrasés lors de la fin d'execution du script)?

J'ai cherché comment fonctionné une transaction mais sans succès (je pense que le résultat du script est copié dans un cache puis lors du commit alors blocage de la table puis recopie et enfin levé du verrou).
Pouvez vous m'aider?
Merci.

[pulsdrum]

Bonjour,

De base SQL Server est configuré avec un niveau d’isolation « READ COMMITTED » (et « READ_COMMITTED_SNAPSHOT » sur OFF).
Le moteur de base de données utilise donc des verrous partagés pour empêcher d'autres transactions de modifier les lignes alors que la transaction en cours d’exécution.
Plus d’information : ICI

Voici comment fonctionne les Transactions : ICI

++

[SQLpro]

Bonjour,
Je voudrais comprendre comment fonctionne les transactions à travers un petit exemple.

Imaginons une table remplie avec plus 5000 données. Cette table est utilisée en permanence partout dans le monde. Que ce passe t'il lorsque par exemple je veux supprimer le contenu de la table et le remplacer par un autre contenu? Cette modification se fera par avec une transaction mais lors de l'execution de la requête la table est elle toujours disponible. Le script serait tout simplement un delete du contenu suivi d'un ajout (pas qu'un mais 5000).
Durant ce temps d'execution, la table est elle toujours accessible en lecture? lecture/ecriture (même si cela veut dire que les écritures seront écrasés lors de la fin d'execution du script)?

Soit vous procédez en deux instructions SQL :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
DELETE ...
INSERT ...

et donc c'est 2 transactions implicites et entre les deux, les utilisateurs peuvent lire la table vidée.

Soit vous implémentez une transaction :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
BEGIN TRANSACTION
DELETE ...
INSERT ...
COMMIT

et tout dépend du niveau d'isolation...
En niveau READ COMMITTED, pas de différence avec le précédent.
Au niveau SERIALIZABLE les autres utilisateurs n'ont aucun accès à la
table.

J'ai cherché comment fonctionné une transaction mais sans succès (je pense que le résultat du script est copié dans un cache puis lors du commit alors blocage de la table puis recopie et enfin levé du verrou).
Pouvez vous m'aider?
Merci.

A me lire :
les transactions http://sqlpro.developpez.com/cours/sqlaz/techniques/
les niveaux d'isolations : http://sqlpro.developpez.com/isolation-transaction/

A +

[clouddd]

Cool merci pour vos reponses.
Je vais lire tout ca et essayer de comprendre.
Mais d'après ce que vous dites lors de l'execution d'un script la table n'est plus accessible par les autres utilisateurs. C'est bien ca?

[SQLpro]

Cool merci pour vos reponses.
Je vais lire tout ca et essayer de comprendre.
Mais d'après ce que vous dites lors de l'execution d'un script la table n'est plus accessible par les autres utilisateurs. C'est bien ca?

NON !

Tout dépend du niveau d'isolation des transaction et de la granularité des données concernées.

Par exemple si vous faites un DELETE avec une claude WHERE et en mode READ COMMITTED, seule les lignes répondant à la clause WHERE seront inaccessible le temps de la transaction. En mode READ COMMITTED elles seront accessibles entre temps.

A +