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
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
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
Est-ce qu'on peut faire plusieurs ajouts et suppressions avant un "COMMIT"
final et qui englobe le tout ?
Merci.
--
Patrick
"Fred.M." wrote:
> 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.
>
> 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
Est-ce qu'on peut faire plusieurs ajouts et suppressions avant un "COMMIT"
final et qui englobe le tout ?
Merci.
--
Patrick
"Fred.M." wrote:
> 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.
>
> 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
Est-ce qu'on peut faire plusieurs ajouts et suppressions avant un "COMMIT"
final et qui englobe le tout ?
Merci.
--
Patrick
"Fred.M." wrote:
> 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.
>
> 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
Si ta question revient à dire "peut-on imbriquer plusieurs transactions les
unes dans les autres ?", la réponse est oui. J'en reviens tout de même et
dans ce cas à mon "CEPENDANT" de tout à l'heure : gare à la génération de
verrous exclusifs !!
FRED.M.
"Patrick" a écrit :
> Est-ce qu'on peut faire plusieurs ajouts et suppressions avant un "COMMIT"
> final et qui englobe le tout ?
>
> Merci.
>
> --
> Patrick
>
>
> "Fred.M." wrote:
>
> > 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.
> >
> > 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
Si ta question revient à dire "peut-on imbriquer plusieurs transactions les
unes dans les autres ?", la réponse est oui. J'en reviens tout de même et
dans ce cas à mon "CEPENDANT" de tout à l'heure : gare à la génération de
verrous exclusifs !!
FRED.M.
"Patrick" a écrit :
> Est-ce qu'on peut faire plusieurs ajouts et suppressions avant un "COMMIT"
> final et qui englobe le tout ?
>
> Merci.
>
> --
> Patrick
>
>
> "Fred.M." wrote:
>
> > 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.
> >
> > 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
Si ta question revient à dire "peut-on imbriquer plusieurs transactions les
unes dans les autres ?", la réponse est oui. J'en reviens tout de même et
dans ce cas à mon "CEPENDANT" de tout à l'heure : gare à la génération de
verrous exclusifs !!
FRED.M.
"Patrick" a écrit :
> Est-ce qu'on peut faire plusieurs ajouts et suppressions avant un "COMMIT"
> final et qui englobe le tout ?
>
> Merci.
>
> --
> Patrick
>
>
> "Fred.M." wrote:
>
> > 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.
> >
> > 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
Si ta question revient à dire "peut-on imbriquer plusieurs transactions
les
unes dans les autres ?", la réponse est oui. J'en reviens tout de même et
dans ce cas à mon "CEPENDANT" de tout à l'heure : gare à la génération de
verrous exclusifs !!
FRED.M.
"Patrick" a écrit :Est-ce qu'on peut faire plusieurs ajouts et suppressions avant un
"COMMIT"
final et qui englobe le tout ?
Merci.
--
Patrick
"Fred.M." wrote:
> 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.
>
> 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
Si ta question revient à dire "peut-on imbriquer plusieurs transactions
les
unes dans les autres ?", la réponse est oui. J'en reviens tout de même et
dans ce cas à mon "CEPENDANT" de tout à l'heure : gare à la génération de
verrous exclusifs !!
FRED.M.
"Patrick" a écrit :
Est-ce qu'on peut faire plusieurs ajouts et suppressions avant un
"COMMIT"
final et qui englobe le tout ?
Merci.
--
Patrick
"Fred.M." wrote:
> 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.
>
> 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
Si ta question revient à dire "peut-on imbriquer plusieurs transactions
les
unes dans les autres ?", la réponse est oui. J'en reviens tout de même et
dans ce cas à mon "CEPENDANT" de tout à l'heure : gare à la génération de
verrous exclusifs !!
FRED.M.
"Patrick" a écrit :Est-ce qu'on peut faire plusieurs ajouts et suppressions avant un
"COMMIT"
final et qui englobe le tout ?
Merci.
--
Patrick
"Fred.M." wrote:
> 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.
>
> 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
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.
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
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.
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
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.
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
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 ***********************
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 ***********************
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 ***********************
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.
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 ***********************
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.
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 ***********************
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.
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 ***********************
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 ***********************
