Fred.M. a écrit :
> Certes, mais je parlais de façon générale avec une configuration à valeur par
> défaut, à savoir avec un niveau d'isolation de la transaction à READ
> COMMITTED.
en read committed la majorité des verrous sont partagés !
A +
>
> Fred.M.
>
> "Fred BROUARD" a écrit :
>
>> Queques petites modifis....
>>
>> Fred.M. a écrit :
>>> Bonjour Patrick,
>>> La réponse est "ça dépend", et les éléments de décision sont les suivants :
>>>
>>> 1.) Par défaut la valeur de l'option de session "SET IMPLICIT_TRANSACTIONS"
>>> est à OFF. Cela induit que toute transaction est par défaut "auto-committée".
>>> Donc toute mise à jour est automatiquement validée.
>>>
>>> 2.) Si en effet tu utilises les transactions :
>>> Une transaction a notamment pour but de garder les données de ta base en un
>>> état cohérent et consistant. Ainsi, si deux opérations sont indissociables
>>> fonctionnellement parlant, elles doivent se situer dans la même transaction.
>>> Ainsi si le system plante en plein milieu du processus, soit tout est validé,
>>> soit rien ne l'est.
>>> Ex : soient 2 opérations pour un archivage, ou l'on historiserait par
>>> exemple des opérations obsolètes dans une table d'archive.
>>> a) insert into Table_Archive select * from Table_Source Where Madate...
>>> b) Delete From Table_Source where Madate....
>>> Si chacune de ces opérations sont dans des transactions différentes (donc si
>>> tu mets un commit après ton "Insert") et que ton serveur plante entre ton a)
>>> et ton b), tes données sont insérées en archive mais pas épurées de ta table;
>>> tu auras donc des données en double. Imagines que ça peut être bien pire si
>>> tu inverses le a) et le b) : tu supprimerais tes données sans les archiver !
>>> Ceci n'est qu'un exemple simple, mais dans cet exemple il convient de mettre
>>> ces opérations dans la même transaction.
>>> CEPENDANT !... Implémenter une transaction implique au niveau du moteur SQL
>>> une génération de verrous exclusifs, qui sont susceptibles de bloquer les
>>> autres sessions le temps de la transaction. Implémenter des transactions trop
>>> longues risquerait donc de ralentir ton application.
>> Ouiet non, cela dépends du niveau d'isolation de la transaction.
>> En particulier au niveau d'isoaltion READ UNCOMMITTED aucun verrou n'est
>> placé, alors qu'au niveau REPEATABLE READ il s'agit de verrous partagés
>> en non exclusifs. Il n'y a guerre qu'au niveau SERIALIZABLE que tout est
>> vérouillé en exclusif.
>>
>> Voir les papiers que j'ai écrit sur le sujet :
>> http://sqlpro.developpez.com/cours/sqlaz/techniques/#L1
>>
>>
>>
>>> CONCLUSION :
>>> - Si des ajouts / suppressions n'ont aucun rapport les uns avec les autres,
>>> alors en effet tu peux commiter après chaque opération.
>>> - Si a contrario fonctionnellement parlant tes opérations de ajouts /
>>> suppressions sont conditionnées entre elles, encapsulent les dans une seule
>>> et même transaction. Et s'il s'avère que cette transaction est relativement
>>> longue, alors essaie de planifier son exécution sur une période creuse (la
>>> nuit en général) pour éviter les locks.
>>>
>>> J'espère avoir été suffisamment clair dans l'ensemble.
>>>
>>> FRED.M.
>>>
>>>
>>> "Patrick" a écrit :
>>>
>>>> Bonjour,
>>>>
>>>> Je fais une succession de mises à jour d'une table qui ajoutent et
>>>> suppriment des enregistrements. J'utilise les transactions.
>>>>
>>>> Est-ce qu'il faut utiliser un "COMMIT" apres chaque mise à jour (ajout ou
>>>> supression) ou bien est-ce qu'on peut faire un seul "COMMIT" à la fin ?
>>>>
>>>> Merci.
>>>>
>>>> --
>>>> Patrick
>> A +
>>
>> --
>> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
>> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
>> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
>> ********************* http://www.datasapiens.com ***********************
>>
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Fred.M. a écrit :
> Certes, mais je parlais de façon générale avec une configuration à valeur par
> défaut, à savoir avec un niveau d'isolation de la transaction à READ
> COMMITTED.
en read committed la majorité des verrous sont partagés !
A +
>
> Fred.M.
>
> "Fred BROUARD" a écrit :
>
>> Queques petites modifis....
>>
>> Fred.M. a écrit :
>>> Bonjour Patrick,
>>> La réponse est "ça dépend", et les éléments de décision sont les suivants :
>>>
>>> 1.) Par défaut la valeur de l'option de session "SET IMPLICIT_TRANSACTIONS"
>>> est à OFF. Cela induit que toute transaction est par défaut "auto-committée".
>>> Donc toute mise à jour est automatiquement validée.
>>>
>>> 2.) Si en effet tu utilises les transactions :
>>> Une transaction a notamment pour but de garder les données de ta base en un
>>> état cohérent et consistant. Ainsi, si deux opérations sont indissociables
>>> fonctionnellement parlant, elles doivent se situer dans la même transaction.
>>> Ainsi si le system plante en plein milieu du processus, soit tout est validé,
>>> soit rien ne l'est.
>>> Ex : soient 2 opérations pour un archivage, ou l'on historiserait par
>>> exemple des opérations obsolètes dans une table d'archive.
>>> a) insert into Table_Archive select * from Table_Source Where Madate...
>>> b) Delete From Table_Source where Madate....
>>> Si chacune de ces opérations sont dans des transactions différentes (donc si
>>> tu mets un commit après ton "Insert") et que ton serveur plante entre ton a)
>>> et ton b), tes données sont insérées en archive mais pas épurées de ta table;
>>> tu auras donc des données en double. Imagines que ça peut être bien pire si
>>> tu inverses le a) et le b) : tu supprimerais tes données sans les archiver !
>>> Ceci n'est qu'un exemple simple, mais dans cet exemple il convient de mettre
>>> ces opérations dans la même transaction.
>>> CEPENDANT !... Implémenter une transaction implique au niveau du moteur SQL
>>> une génération de verrous exclusifs, qui sont susceptibles de bloquer les
>>> autres sessions le temps de la transaction. Implémenter des transactions trop
>>> longues risquerait donc de ralentir ton application.
>> Ouiet non, cela dépends du niveau d'isolation de la transaction.
>> En particulier au niveau d'isoaltion READ UNCOMMITTED aucun verrou n'est
>> placé, alors qu'au niveau REPEATABLE READ il s'agit de verrous partagés
>> en non exclusifs. Il n'y a guerre qu'au niveau SERIALIZABLE que tout est
>> vérouillé en exclusif.
>>
>> Voir les papiers que j'ai écrit sur le sujet :
>> http://sqlpro.developpez.com/cours/sqlaz/techniques/#L1
>>
>>
>>
>>> CONCLUSION :
>>> - Si des ajouts / suppressions n'ont aucun rapport les uns avec les autres,
>>> alors en effet tu peux commiter après chaque opération.
>>> - Si a contrario fonctionnellement parlant tes opérations de ajouts /
>>> suppressions sont conditionnées entre elles, encapsulent les dans une seule
>>> et même transaction. Et s'il s'avère que cette transaction est relativement
>>> longue, alors essaie de planifier son exécution sur une période creuse (la
>>> nuit en général) pour éviter les locks.
>>>
>>> J'espère avoir été suffisamment clair dans l'ensemble.
>>>
>>> FRED.M.
>>>
>>>
>>> "Patrick" a écrit :
>>>
>>>> Bonjour,
>>>>
>>>> Je fais une succession de mises à jour d'une table qui ajoutent et
>>>> suppriment des enregistrements. J'utilise les transactions.
>>>>
>>>> Est-ce qu'il faut utiliser un "COMMIT" apres chaque mise à jour (ajout ou
>>>> supression) ou bien est-ce qu'on peut faire un seul "COMMIT" à la fin ?
>>>>
>>>> Merci.
>>>>
>>>> --
>>>> Patrick
>> A +
>>
>> --
>> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
>> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
>> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
>> ********************* http://www.datasapiens.com ***********************
>>
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Fred.M. a écrit :
> Certes, mais je parlais de façon générale avec une configuration à valeur par
> défaut, à savoir avec un niveau d'isolation de la transaction à READ
> COMMITTED.
en read committed la majorité des verrous sont partagés !
A +
>
> Fred.M.
>
> "Fred BROUARD" a écrit :
>
>> Queques petites modifis....
>>
>> Fred.M. a écrit :
>>> Bonjour Patrick,
>>> La réponse est "ça dépend", et les éléments de décision sont les suivants :
>>>
>>> 1.) Par défaut la valeur de l'option de session "SET IMPLICIT_TRANSACTIONS"
>>> est à OFF. Cela induit que toute transaction est par défaut "auto-committée".
>>> Donc toute mise à jour est automatiquement validée.
>>>
>>> 2.) Si en effet tu utilises les transactions :
>>> Une transaction a notamment pour but de garder les données de ta base en un
>>> état cohérent et consistant. Ainsi, si deux opérations sont indissociables
>>> fonctionnellement parlant, elles doivent se situer dans la même transaction.
>>> Ainsi si le system plante en plein milieu du processus, soit tout est validé,
>>> soit rien ne l'est.
>>> Ex : soient 2 opérations pour un archivage, ou l'on historiserait par
>>> exemple des opérations obsolètes dans une table d'archive.
>>> a) insert into Table_Archive select * from Table_Source Where Madate...
>>> b) Delete From Table_Source where Madate....
>>> Si chacune de ces opérations sont dans des transactions différentes (donc si
>>> tu mets un commit après ton "Insert") et que ton serveur plante entre ton a)
>>> et ton b), tes données sont insérées en archive mais pas épurées de ta table;
>>> tu auras donc des données en double. Imagines que ça peut être bien pire si
>>> tu inverses le a) et le b) : tu supprimerais tes données sans les archiver !
>>> Ceci n'est qu'un exemple simple, mais dans cet exemple il convient de mettre
>>> ces opérations dans la même transaction.
>>> CEPENDANT !... Implémenter une transaction implique au niveau du moteur SQL
>>> une génération de verrous exclusifs, qui sont susceptibles de bloquer les
>>> autres sessions le temps de la transaction. Implémenter des transactions trop
>>> longues risquerait donc de ralentir ton application.
>> Ouiet non, cela dépends du niveau d'isolation de la transaction.
>> En particulier au niveau d'isoaltion READ UNCOMMITTED aucun verrou n'est
>> placé, alors qu'au niveau REPEATABLE READ il s'agit de verrous partagés
>> en non exclusifs. Il n'y a guerre qu'au niveau SERIALIZABLE que tout est
>> vérouillé en exclusif.
>>
>> Voir les papiers que j'ai écrit sur le sujet :
>> http://sqlpro.developpez.com/cours/sqlaz/techniques/#L1
>>
>>
>>
>>> CONCLUSION :
>>> - Si des ajouts / suppressions n'ont aucun rapport les uns avec les autres,
>>> alors en effet tu peux commiter après chaque opération.
>>> - Si a contrario fonctionnellement parlant tes opérations de ajouts /
>>> suppressions sont conditionnées entre elles, encapsulent les dans une seule
>>> et même transaction. Et s'il s'avère que cette transaction est relativement
>>> longue, alors essaie de planifier son exécution sur une période creuse (la
>>> nuit en général) pour éviter les locks.
>>>
>>> J'espère avoir été suffisamment clair dans l'ensemble.
>>>
>>> FRED.M.
>>>
>>>
>>> "Patrick" a écrit :
>>>
>>>> Bonjour,
>>>>
>>>> Je fais une succession de mises à jour d'une table qui ajoutent et
>>>> suppriment des enregistrements. J'utilise les transactions.
>>>>
>>>> Est-ce qu'il faut utiliser un "COMMIT" apres chaque mise à jour (ajout ou
>>>> supression) ou bien est-ce qu'on peut faire un seul "COMMIT" à la fin ?
>>>>
>>>> Merci.
>>>>
>>>> --
>>>> Patrick
>> A +
>>
>> --
>> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
>> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
>> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
>> ********************* http://www.datasapiens.com ***********************
>>
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Alors essaie ceci :
-- Session 1 (SPID 51) Transaction non committée pour simuler une
transaction longue
Begin Tran
Update MaTable
Set Monchamp = 'xxx'
Where MonID = 1
-- Session 2 (SPID 52)
Select * from MaTable Where MonId = 1
==> en attente !!!
Vérification avec un sp_lock 51
- Verrou Mode shared sur la DB (logique)
- Verrous Intend Shared et Intend Exclusive au niveau table
- Verrou Intend Exclusif au niveau page
- Verrou Exclusif au niveau key
Ce test a été fait sous 2005 et est également valable sous 2000.
Fred.M.
"Fred BROUARD" a écrit :Fred.M. a écrit :Certes, mais je parlais de façon générale avec une configuration à valeur par
défaut, à savoir avec un niveau d'isolation de la transaction à READ
COMMITTED.
en read committed la majorité des verrous sont partagés !
A +Fred.M.
"Fred BROUARD" a écrit :Queques petites modifis....
Fred.M. a écrit :Bonjour Patrick,
La réponse est "ça dépend", et les éléments de décision sont les suivants :
1.) Par défaut la valeur de l'option de session "SET IMPLICIT_TRANSACTIONS"
est à OFF. Cela induit que toute transaction est par défaut "auto-committée".
Donc toute mise à jour est automatiquement validée.
2.) Si en effet tu utilises les transactions :
Une transaction a notamment pour but de garder les données de ta base en un
état cohérent et consistant. Ainsi, si deux opérations sont indissociables
fonctionnellement parlant, elles doivent se situer dans la même transaction.
Ainsi si le system plante en plein milieu du processus, soit tout est validé,
soit rien ne l'est.
Ex : soient 2 opérations pour un archivage, ou l'on historiserait par
exemple des opérations obsolètes dans une table d'archive.
a) insert into Table_Archive select * from Table_Source Where Madate...
b) Delete From Table_Source where Madate....
Si chacune de ces opérations sont dans des transactions différentes (donc si
tu mets un commit après ton "Insert") et que ton serveur plante entre ton a)
et ton b), tes données sont insérées en archive mais pas épurées de ta table;
tu auras donc des données en double. Imagines que ça peut être bien pire si
tu inverses le a) et le b) : tu supprimerais tes données sans les archiver !
Ceci n'est qu'un exemple simple, mais dans cet exemple il convient de mettre
ces opérations dans la même transaction.
CEPENDANT !... Implémenter une transaction implique au niveau du moteur SQL
une génération de verrous exclusifs, qui sont susceptibles de bloquer les
autres sessions le temps de la transaction. Implémenter des transactions trop
longues risquerait donc de ralentir ton application.
Ouiet non, cela dépends du niveau d'isolation de la transaction.
En particulier au niveau d'isoaltion READ UNCOMMITTED aucun verrou n'est
placé, alors qu'au niveau REPEATABLE READ il s'agit de verrous partagés
en non exclusifs. Il n'y a guerre qu'au niveau SERIALIZABLE que tout est
vérouillé en exclusif.
Voir les papiers que j'ai écrit sur le sujet :
http://sqlpro.developpez.com/cours/sqlaz/techniques/#L1CONCLUSION :
- Si des ajouts / suppressions n'ont aucun rapport les uns avec les autres,
alors en effet tu peux commiter après chaque opération.
- Si a contrario fonctionnellement parlant tes opérations de ajouts /
suppressions sont conditionnées entre elles, encapsulent les dans une seule
et même transaction. Et s'il s'avère que cette transaction est relativement
longue, alors essaie de planifier son exécution sur une période creuse (la
nuit en général) pour éviter les locks.
J'espère avoir été suffisamment clair dans l'ensemble.
FRED.M.
"Patrick" a écrit :Bonjour,
Je fais une succession de mises à jour d'une table qui ajoutent et
suppriment des enregistrements. J'utilise les transactions.
Est-ce qu'il faut utiliser un "COMMIT" apres chaque mise à jour (ajout ou
supression) ou bien est-ce qu'on peut faire un seul "COMMIT" à la fin ?
Merci.
--
Patrick
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Alors essaie ceci :
-- Session 1 (SPID 51) Transaction non committée pour simuler une
transaction longue
Begin Tran
Update MaTable
Set Monchamp = 'xxx'
Where MonID = 1
-- Session 2 (SPID 52)
Select * from MaTable Where MonId = 1
==> en attente !!!
Vérification avec un sp_lock 51
- Verrou Mode shared sur la DB (logique)
- Verrous Intend Shared et Intend Exclusive au niveau table
- Verrou Intend Exclusif au niveau page
- Verrou Exclusif au niveau key
Ce test a été fait sous 2005 et est également valable sous 2000.
Fred.M.
"Fred BROUARD" a écrit :
Fred.M. a écrit :
Certes, mais je parlais de façon générale avec une configuration à valeur par
défaut, à savoir avec un niveau d'isolation de la transaction à READ
COMMITTED.
en read committed la majorité des verrous sont partagés !
A +
Fred.M.
"Fred BROUARD" a écrit :
Queques petites modifis....
Fred.M. a écrit :
Bonjour Patrick,
La réponse est "ça dépend", et les éléments de décision sont les suivants :
1.) Par défaut la valeur de l'option de session "SET IMPLICIT_TRANSACTIONS"
est à OFF. Cela induit que toute transaction est par défaut "auto-committée".
Donc toute mise à jour est automatiquement validée.
2.) Si en effet tu utilises les transactions :
Une transaction a notamment pour but de garder les données de ta base en un
état cohérent et consistant. Ainsi, si deux opérations sont indissociables
fonctionnellement parlant, elles doivent se situer dans la même transaction.
Ainsi si le system plante en plein milieu du processus, soit tout est validé,
soit rien ne l'est.
Ex : soient 2 opérations pour un archivage, ou l'on historiserait par
exemple des opérations obsolètes dans une table d'archive.
a) insert into Table_Archive select * from Table_Source Where Madate...
b) Delete From Table_Source where Madate....
Si chacune de ces opérations sont dans des transactions différentes (donc si
tu mets un commit après ton "Insert") et que ton serveur plante entre ton a)
et ton b), tes données sont insérées en archive mais pas épurées de ta table;
tu auras donc des données en double. Imagines que ça peut être bien pire si
tu inverses le a) et le b) : tu supprimerais tes données sans les archiver !
Ceci n'est qu'un exemple simple, mais dans cet exemple il convient de mettre
ces opérations dans la même transaction.
CEPENDANT !... Implémenter une transaction implique au niveau du moteur SQL
une génération de verrous exclusifs, qui sont susceptibles de bloquer les
autres sessions le temps de la transaction. Implémenter des transactions trop
longues risquerait donc de ralentir ton application.
Ouiet non, cela dépends du niveau d'isolation de la transaction.
En particulier au niveau d'isoaltion READ UNCOMMITTED aucun verrou n'est
placé, alors qu'au niveau REPEATABLE READ il s'agit de verrous partagés
en non exclusifs. Il n'y a guerre qu'au niveau SERIALIZABLE que tout est
vérouillé en exclusif.
Voir les papiers que j'ai écrit sur le sujet :
http://sqlpro.developpez.com/cours/sqlaz/techniques/#L1
CONCLUSION :
- Si des ajouts / suppressions n'ont aucun rapport les uns avec les autres,
alors en effet tu peux commiter après chaque opération.
- Si a contrario fonctionnellement parlant tes opérations de ajouts /
suppressions sont conditionnées entre elles, encapsulent les dans une seule
et même transaction. Et s'il s'avère que cette transaction est relativement
longue, alors essaie de planifier son exécution sur une période creuse (la
nuit en général) pour éviter les locks.
J'espère avoir été suffisamment clair dans l'ensemble.
FRED.M.
"Patrick" a écrit :
Bonjour,
Je fais une succession de mises à jour d'une table qui ajoutent et
suppriment des enregistrements. J'utilise les transactions.
Est-ce qu'il faut utiliser un "COMMIT" apres chaque mise à jour (ajout ou
supression) ou bien est-ce qu'on peut faire un seul "COMMIT" à la fin ?
Merci.
--
Patrick
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Alors essaie ceci :
-- Session 1 (SPID 51) Transaction non committée pour simuler une
transaction longue
Begin Tran
Update MaTable
Set Monchamp = 'xxx'
Where MonID = 1
-- Session 2 (SPID 52)
Select * from MaTable Where MonId = 1
==> en attente !!!
Vérification avec un sp_lock 51
- Verrou Mode shared sur la DB (logique)
- Verrous Intend Shared et Intend Exclusive au niveau table
- Verrou Intend Exclusif au niveau page
- Verrou Exclusif au niveau key
Ce test a été fait sous 2005 et est également valable sous 2000.
Fred.M.
"Fred BROUARD" a écrit :Fred.M. a écrit :Certes, mais je parlais de façon générale avec une configuration à valeur par
défaut, à savoir avec un niveau d'isolation de la transaction à READ
COMMITTED.
en read committed la majorité des verrous sont partagés !
A +Fred.M.
"Fred BROUARD" a écrit :Queques petites modifis....
Fred.M. a écrit :Bonjour Patrick,
La réponse est "ça dépend", et les éléments de décision sont les suivants :
1.) Par défaut la valeur de l'option de session "SET IMPLICIT_TRANSACTIONS"
est à OFF. Cela induit que toute transaction est par défaut "auto-committée".
Donc toute mise à jour est automatiquement validée.
2.) Si en effet tu utilises les transactions :
Une transaction a notamment pour but de garder les données de ta base en un
état cohérent et consistant. Ainsi, si deux opérations sont indissociables
fonctionnellement parlant, elles doivent se situer dans la même transaction.
Ainsi si le system plante en plein milieu du processus, soit tout est validé,
soit rien ne l'est.
Ex : soient 2 opérations pour un archivage, ou l'on historiserait par
exemple des opérations obsolètes dans une table d'archive.
a) insert into Table_Archive select * from Table_Source Where Madate...
b) Delete From Table_Source where Madate....
Si chacune de ces opérations sont dans des transactions différentes (donc si
tu mets un commit après ton "Insert") et que ton serveur plante entre ton a)
et ton b), tes données sont insérées en archive mais pas épurées de ta table;
tu auras donc des données en double. Imagines que ça peut être bien pire si
tu inverses le a) et le b) : tu supprimerais tes données sans les archiver !
Ceci n'est qu'un exemple simple, mais dans cet exemple il convient de mettre
ces opérations dans la même transaction.
CEPENDANT !... Implémenter une transaction implique au niveau du moteur SQL
une génération de verrous exclusifs, qui sont susceptibles de bloquer les
autres sessions le temps de la transaction. Implémenter des transactions trop
longues risquerait donc de ralentir ton application.
Ouiet non, cela dépends du niveau d'isolation de la transaction.
En particulier au niveau d'isoaltion READ UNCOMMITTED aucun verrou n'est
placé, alors qu'au niveau REPEATABLE READ il s'agit de verrous partagés
en non exclusifs. Il n'y a guerre qu'au niveau SERIALIZABLE que tout est
vérouillé en exclusif.
Voir les papiers que j'ai écrit sur le sujet :
http://sqlpro.developpez.com/cours/sqlaz/techniques/#L1CONCLUSION :
- Si des ajouts / suppressions n'ont aucun rapport les uns avec les autres,
alors en effet tu peux commiter après chaque opération.
- Si a contrario fonctionnellement parlant tes opérations de ajouts /
suppressions sont conditionnées entre elles, encapsulent les dans une seule
et même transaction. Et s'il s'avère que cette transaction est relativement
longue, alors essaie de planifier son exécution sur une période creuse (la
nuit en général) pour éviter les locks.
J'espère avoir été suffisamment clair dans l'ensemble.
FRED.M.
"Patrick" a écrit :Bonjour,
Je fais une succession de mises à jour d'une table qui ajoutent et
suppriment des enregistrements. J'utilise les transactions.
Est-ce qu'il faut utiliser un "COMMIT" apres chaque mise à jour (ajout ou
supression) ou bien est-ce qu'on peut faire un seul "COMMIT" à la fin ?
Merci.
--
Patrick
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
votre exemple est non significatif car on ne vas pas attendre 40 ans
pour faire un update d'une ligne ! et surtout pas gérer des transactions
explicite sur un seul ordre SQL qui passe très bien en auto commit.
La norme SQL considérant même qu'un statement SQL doit être une transaction.
Prenez des exemples un peu plus réaliste comme ceux que j'ai donné dans
mes différents articles !
A +
une transaction est
Fred.M. a écrit :
> Alors essaie ceci :
>
> -- Session 1 (SPID 51) Transaction non committée pour simuler une
> transaction longue
> Begin Tran
> Update MaTable
> Set Monchamp = 'xxx'
> Where MonID = 1
>
> -- Session 2 (SPID 52)
> Select * from MaTable Where MonId = 1
> ==> en attente !!!
>
> Vérification avec un sp_lock 51
> - Verrou Mode shared sur la DB (logique)
> - Verrous Intend Shared et Intend Exclusive au niveau table
> - Verrou Intend Exclusif au niveau page
> - Verrou Exclusif au niveau key
>
> Ce test a été fait sous 2005 et est également valable sous 2000.
>
> Fred.M.
>
> "Fred BROUARD" a écrit :
>
>> Fred.M. a écrit :
>>> Certes, mais je parlais de façon générale avec une configuration à valeur par
>>> défaut, à savoir avec un niveau d'isolation de la transaction à READ
>>> COMMITTED.
>> en read committed la majorité des verrous sont partagés !
>>
>> A +
>>
>>> Fred.M.
>>>
>>> "Fred BROUARD" a écrit :
>>>
>>>> Queques petites modifis....
>>>>
>>>> Fred.M. a écrit :
>>>>> Bonjour Patrick,
>>>>> La réponse est "ça dépend", et les éléments de décision sont les suivants :
>>>>>
>>>>> 1.) Par défaut la valeur de l'option de session "SET IMPLICIT_TRANSACTIONS"
>>>>> est à OFF. Cela induit que toute transaction est par défaut "auto-committée".
>>>>> Donc toute mise à jour est automatiquement validée.
>>>>>
>>>>> 2.) Si en effet tu utilises les transactions :
>>>>> Une transaction a notamment pour but de garder les données de ta base en un
>>>>> état cohérent et consistant. Ainsi, si deux opérations sont indissociables
>>>>> fonctionnellement parlant, elles doivent se situer dans la même transaction.
>>>>> Ainsi si le system plante en plein milieu du processus, soit tout est validé,
>>>>> soit rien ne l'est.
>>>>> Ex : soient 2 opérations pour un archivage, ou l'on historiserait par
>>>>> exemple des opérations obsolètes dans une table d'archive.
>>>>> a) insert into Table_Archive select * from Table_Source Where Madate...
>>>>> b) Delete From Table_Source where Madate....
>>>>> Si chacune de ces opérations sont dans des transactions différentes (donc si
>>>>> tu mets un commit après ton "Insert") et que ton serveur plante entre ton a)
>>>>> et ton b), tes données sont insérées en archive mais pas épurées de ta table;
>>>>> tu auras donc des données en double. Imagines que ça peut être bien pire si
>>>>> tu inverses le a) et le b) : tu supprimerais tes données sans les archiver !
>>>>> Ceci n'est qu'un exemple simple, mais dans cet exemple il convient de mettre
>>>>> ces opérations dans la même transaction.
>>>>> CEPENDANT !... Implémenter une transaction implique au niveau du moteur SQL
>>>>> une génération de verrous exclusifs, qui sont susceptibles de bloquer les
>>>>> autres sessions le temps de la transaction. Implémenter des transactions trop
>>>>> longues risquerait donc de ralentir ton application.
>>>> Ouiet non, cela dépends du niveau d'isolation de la transaction.
>>>> En particulier au niveau d'isoaltion READ UNCOMMITTED aucun verrou n'est
>>>> placé, alors qu'au niveau REPEATABLE READ il s'agit de verrous partagés
>>>> en non exclusifs. Il n'y a guerre qu'au niveau SERIALIZABLE que tout est
>>>> vérouillé en exclusif.
>>>>
>>>> Voir les papiers que j'ai écrit sur le sujet :
>>>> http://sqlpro.developpez.com/cours/sqlaz/techniques/#L1
>>>>
>>>>
>>>>
>>>>> CONCLUSION :
>>>>> - Si des ajouts / suppressions n'ont aucun rapport les uns avec les autres,
>>>>> alors en effet tu peux commiter après chaque opération.
>>>>> - Si a contrario fonctionnellement parlant tes opérations de ajouts /
>>>>> suppressions sont conditionnées entre elles, encapsulent les dans une seule
>>>>> et même transaction. Et s'il s'avère que cette transaction est relativement
>>>>> longue, alors essaie de planifier son exécution sur une période creuse (la
>>>>> nuit en général) pour éviter les locks.
>>>>>
>>>>> J'espère avoir été suffisamment clair dans l'ensemble.
>>>>>
>>>>> FRED.M.
>>>>>
>>>>>
>>>>> "Patrick" a écrit :
>>>>>
>>>>>> Bonjour,
>>>>>>
>>>>>> Je fais une succession de mises à jour d'une table qui ajoutent et
>>>>>> suppriment des enregistrements. J'utilise les transactions.
>>>>>>
>>>>>> Est-ce qu'il faut utiliser un "COMMIT" apres chaque mise à jour (ajout ou
>>>>>> supression) ou bien est-ce qu'on peut faire un seul "COMMIT" à la fin ?
>>>>>>
>>>>>> Merci.
>>>>>>
>>>>>> --
>>>>>> Patrick
>>>> A +
>>>>
>>>> --
>>>> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
>>>> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
>>>> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
>>>> ********************* http://www.datasapiens.com ***********************
>>>>
>>
>> --
>> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
>> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
>> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
>> ********************* http://www.datasapiens.com ***********************
>>
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
votre exemple est non significatif car on ne vas pas attendre 40 ans
pour faire un update d'une ligne ! et surtout pas gérer des transactions
explicite sur un seul ordre SQL qui passe très bien en auto commit.
La norme SQL considérant même qu'un statement SQL doit être une transaction.
Prenez des exemples un peu plus réaliste comme ceux que j'ai donné dans
mes différents articles !
A +
une transaction est
Fred.M. a écrit :
> Alors essaie ceci :
>
> -- Session 1 (SPID 51) Transaction non committée pour simuler une
> transaction longue
> Begin Tran
> Update MaTable
> Set Monchamp = 'xxx'
> Where MonID = 1
>
> -- Session 2 (SPID 52)
> Select * from MaTable Where MonId = 1
> ==> en attente !!!
>
> Vérification avec un sp_lock 51
> - Verrou Mode shared sur la DB (logique)
> - Verrous Intend Shared et Intend Exclusive au niveau table
> - Verrou Intend Exclusif au niveau page
> - Verrou Exclusif au niveau key
>
> Ce test a été fait sous 2005 et est également valable sous 2000.
>
> Fred.M.
>
> "Fred BROUARD" a écrit :
>
>> Fred.M. a écrit :
>>> Certes, mais je parlais de façon générale avec une configuration à valeur par
>>> défaut, à savoir avec un niveau d'isolation de la transaction à READ
>>> COMMITTED.
>> en read committed la majorité des verrous sont partagés !
>>
>> A +
>>
>>> Fred.M.
>>>
>>> "Fred BROUARD" a écrit :
>>>
>>>> Queques petites modifis....
>>>>
>>>> Fred.M. a écrit :
>>>>> Bonjour Patrick,
>>>>> La réponse est "ça dépend", et les éléments de décision sont les suivants :
>>>>>
>>>>> 1.) Par défaut la valeur de l'option de session "SET IMPLICIT_TRANSACTIONS"
>>>>> est à OFF. Cela induit que toute transaction est par défaut "auto-committée".
>>>>> Donc toute mise à jour est automatiquement validée.
>>>>>
>>>>> 2.) Si en effet tu utilises les transactions :
>>>>> Une transaction a notamment pour but de garder les données de ta base en un
>>>>> état cohérent et consistant. Ainsi, si deux opérations sont indissociables
>>>>> fonctionnellement parlant, elles doivent se situer dans la même transaction.
>>>>> Ainsi si le system plante en plein milieu du processus, soit tout est validé,
>>>>> soit rien ne l'est.
>>>>> Ex : soient 2 opérations pour un archivage, ou l'on historiserait par
>>>>> exemple des opérations obsolètes dans une table d'archive.
>>>>> a) insert into Table_Archive select * from Table_Source Where Madate...
>>>>> b) Delete From Table_Source where Madate....
>>>>> Si chacune de ces opérations sont dans des transactions différentes (donc si
>>>>> tu mets un commit après ton "Insert") et que ton serveur plante entre ton a)
>>>>> et ton b), tes données sont insérées en archive mais pas épurées de ta table;
>>>>> tu auras donc des données en double. Imagines que ça peut être bien pire si
>>>>> tu inverses le a) et le b) : tu supprimerais tes données sans les archiver !
>>>>> Ceci n'est qu'un exemple simple, mais dans cet exemple il convient de mettre
>>>>> ces opérations dans la même transaction.
>>>>> CEPENDANT !... Implémenter une transaction implique au niveau du moteur SQL
>>>>> une génération de verrous exclusifs, qui sont susceptibles de bloquer les
>>>>> autres sessions le temps de la transaction. Implémenter des transactions trop
>>>>> longues risquerait donc de ralentir ton application.
>>>> Ouiet non, cela dépends du niveau d'isolation de la transaction.
>>>> En particulier au niveau d'isoaltion READ UNCOMMITTED aucun verrou n'est
>>>> placé, alors qu'au niveau REPEATABLE READ il s'agit de verrous partagés
>>>> en non exclusifs. Il n'y a guerre qu'au niveau SERIALIZABLE que tout est
>>>> vérouillé en exclusif.
>>>>
>>>> Voir les papiers que j'ai écrit sur le sujet :
>>>> http://sqlpro.developpez.com/cours/sqlaz/techniques/#L1
>>>>
>>>>
>>>>
>>>>> CONCLUSION :
>>>>> - Si des ajouts / suppressions n'ont aucun rapport les uns avec les autres,
>>>>> alors en effet tu peux commiter après chaque opération.
>>>>> - Si a contrario fonctionnellement parlant tes opérations de ajouts /
>>>>> suppressions sont conditionnées entre elles, encapsulent les dans une seule
>>>>> et même transaction. Et s'il s'avère que cette transaction est relativement
>>>>> longue, alors essaie de planifier son exécution sur une période creuse (la
>>>>> nuit en général) pour éviter les locks.
>>>>>
>>>>> J'espère avoir été suffisamment clair dans l'ensemble.
>>>>>
>>>>> FRED.M.
>>>>>
>>>>>
>>>>> "Patrick" a écrit :
>>>>>
>>>>>> Bonjour,
>>>>>>
>>>>>> Je fais une succession de mises à jour d'une table qui ajoutent et
>>>>>> suppriment des enregistrements. J'utilise les transactions.
>>>>>>
>>>>>> Est-ce qu'il faut utiliser un "COMMIT" apres chaque mise à jour (ajout ou
>>>>>> supression) ou bien est-ce qu'on peut faire un seul "COMMIT" à la fin ?
>>>>>>
>>>>>> Merci.
>>>>>>
>>>>>> --
>>>>>> Patrick
>>>> A +
>>>>
>>>> --
>>>> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
>>>> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
>>>> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
>>>> ********************* http://www.datasapiens.com ***********************
>>>>
>>
>> --
>> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
>> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
>> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
>> ********************* http://www.datasapiens.com ***********************
>>
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
votre exemple est non significatif car on ne vas pas attendre 40 ans
pour faire un update d'une ligne ! et surtout pas gérer des transactions
explicite sur un seul ordre SQL qui passe très bien en auto commit.
La norme SQL considérant même qu'un statement SQL doit être une transaction.
Prenez des exemples un peu plus réaliste comme ceux que j'ai donné dans
mes différents articles !
A +
une transaction est
Fred.M. a écrit :
> Alors essaie ceci :
>
> -- Session 1 (SPID 51) Transaction non committée pour simuler une
> transaction longue
> Begin Tran
> Update MaTable
> Set Monchamp = 'xxx'
> Where MonID = 1
>
> -- Session 2 (SPID 52)
> Select * from MaTable Where MonId = 1
> ==> en attente !!!
>
> Vérification avec un sp_lock 51
> - Verrou Mode shared sur la DB (logique)
> - Verrous Intend Shared et Intend Exclusive au niveau table
> - Verrou Intend Exclusif au niveau page
> - Verrou Exclusif au niveau key
>
> Ce test a été fait sous 2005 et est également valable sous 2000.
>
> Fred.M.
>
> "Fred BROUARD" a écrit :
>
>> Fred.M. a écrit :
>>> Certes, mais je parlais de façon générale avec une configuration à valeur par
>>> défaut, à savoir avec un niveau d'isolation de la transaction à READ
>>> COMMITTED.
>> en read committed la majorité des verrous sont partagés !
>>
>> A +
>>
>>> Fred.M.
>>>
>>> "Fred BROUARD" a écrit :
>>>
>>>> Queques petites modifis....
>>>>
>>>> Fred.M. a écrit :
>>>>> Bonjour Patrick,
>>>>> La réponse est "ça dépend", et les éléments de décision sont les suivants :
>>>>>
>>>>> 1.) Par défaut la valeur de l'option de session "SET IMPLICIT_TRANSACTIONS"
>>>>> est à OFF. Cela induit que toute transaction est par défaut "auto-committée".
>>>>> Donc toute mise à jour est automatiquement validée.
>>>>>
>>>>> 2.) Si en effet tu utilises les transactions :
>>>>> Une transaction a notamment pour but de garder les données de ta base en un
>>>>> état cohérent et consistant. Ainsi, si deux opérations sont indissociables
>>>>> fonctionnellement parlant, elles doivent se situer dans la même transaction.
>>>>> Ainsi si le system plante en plein milieu du processus, soit tout est validé,
>>>>> soit rien ne l'est.
>>>>> Ex : soient 2 opérations pour un archivage, ou l'on historiserait par
>>>>> exemple des opérations obsolètes dans une table d'archive.
>>>>> a) insert into Table_Archive select * from Table_Source Where Madate...
>>>>> b) Delete From Table_Source where Madate....
>>>>> Si chacune de ces opérations sont dans des transactions différentes (donc si
>>>>> tu mets un commit après ton "Insert") et que ton serveur plante entre ton a)
>>>>> et ton b), tes données sont insérées en archive mais pas épurées de ta table;
>>>>> tu auras donc des données en double. Imagines que ça peut être bien pire si
>>>>> tu inverses le a) et le b) : tu supprimerais tes données sans les archiver !
>>>>> Ceci n'est qu'un exemple simple, mais dans cet exemple il convient de mettre
>>>>> ces opérations dans la même transaction.
>>>>> CEPENDANT !... Implémenter une transaction implique au niveau du moteur SQL
>>>>> une génération de verrous exclusifs, qui sont susceptibles de bloquer les
>>>>> autres sessions le temps de la transaction. Implémenter des transactions trop
>>>>> longues risquerait donc de ralentir ton application.
>>>> Ouiet non, cela dépends du niveau d'isolation de la transaction.
>>>> En particulier au niveau d'isoaltion READ UNCOMMITTED aucun verrou n'est
>>>> placé, alors qu'au niveau REPEATABLE READ il s'agit de verrous partagés
>>>> en non exclusifs. Il n'y a guerre qu'au niveau SERIALIZABLE que tout est
>>>> vérouillé en exclusif.
>>>>
>>>> Voir les papiers que j'ai écrit sur le sujet :
>>>> http://sqlpro.developpez.com/cours/sqlaz/techniques/#L1
>>>>
>>>>
>>>>
>>>>> CONCLUSION :
>>>>> - Si des ajouts / suppressions n'ont aucun rapport les uns avec les autres,
>>>>> alors en effet tu peux commiter après chaque opération.
>>>>> - Si a contrario fonctionnellement parlant tes opérations de ajouts /
>>>>> suppressions sont conditionnées entre elles, encapsulent les dans une seule
>>>>> et même transaction. Et s'il s'avère que cette transaction est relativement
>>>>> longue, alors essaie de planifier son exécution sur une période creuse (la
>>>>> nuit en général) pour éviter les locks.
>>>>>
>>>>> J'espère avoir été suffisamment clair dans l'ensemble.
>>>>>
>>>>> FRED.M.
>>>>>
>>>>>
>>>>> "Patrick" a écrit :
>>>>>
>>>>>> Bonjour,
>>>>>>
>>>>>> Je fais une succession de mises à jour d'une table qui ajoutent et
>>>>>> suppriment des enregistrements. J'utilise les transactions.
>>>>>>
>>>>>> Est-ce qu'il faut utiliser un "COMMIT" apres chaque mise à jour (ajout ou
>>>>>> supression) ou bien est-ce qu'on peut faire un seul "COMMIT" à la fin ?
>>>>>>
>>>>>> Merci.
>>>>>>
>>>>>> --
>>>>>> Patrick
>>>> A +
>>>>
>>>> --
>>>> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
>>>> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
>>>> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
>>>> ********************* http://www.datasapiens.com ***********************
>>>>
>>
>> --
>> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
>> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
>> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
>> ********************* http://www.datasapiens.com ***********************
>>
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Prends le temps de lire ce qu'écrivent le gens de temps en temps, cela
t'évitera à l'avenir de telles grossières erreurs, car au final l'exemple
montre bien que PENDANT UNE TRANSACTION il y a bien génération de verrous
exclusifs.
- Enfin, je terminerai ici mon poste sur cette suite de joute verbale qui
n'a aucun sens et qui ne sert personne si ce n'est ton égo. Je n'ai pour ma
part aucunement besoin d'exhiber mes articles et toutes mes certifs pour me
faire reconnaitre pleinement de mes paires.
Sur ce, fin de mon post.
A bon entendeur...
Prends le temps de lire ce qu'écrivent le gens de temps en temps, cela
t'évitera à l'avenir de telles grossières erreurs, car au final l'exemple
montre bien que PENDANT UNE TRANSACTION il y a bien génération de verrous
exclusifs.
- Enfin, je terminerai ici mon poste sur cette suite de joute verbale qui
n'a aucun sens et qui ne sert personne si ce n'est ton égo. Je n'ai pour ma
part aucunement besoin d'exhiber mes articles et toutes mes certifs pour me
faire reconnaitre pleinement de mes paires.
Sur ce, fin de mon post.
A bon entendeur...
Prends le temps de lire ce qu'écrivent le gens de temps en temps, cela
t'évitera à l'avenir de telles grossières erreurs, car au final l'exemple
montre bien que PENDANT UNE TRANSACTION il y a bien génération de verrous
exclusifs.
- Enfin, je terminerai ici mon poste sur cette suite de joute verbale qui
n'a aucun sens et qui ne sert personne si ce n'est ton égo. Je n'ai pour ma
part aucunement besoin d'exhiber mes articles et toutes mes certifs pour me
faire reconnaitre pleinement de mes paires.
Sur ce, fin de mon post.
A bon entendeur...