atomicité des transactions et performances du serveur
3 réponses
Eric Belhomme
bonjour,
mon serveur MS SQL Server 2000 souffre de problèmes de performances depuis
quelques temps. En réflechissant à ce qui a bien pu changer (ce serveur est
en production depuis 2003) je me suis apperçu que l'atomicité des
transactions d'insertion avait changé :
Auparavant, l'application métier qui alimentait ce serveur effectuait des
transactions de lots de 3000 documents en moyenne. Cette application a été
réécrite, et effectue maintenant une transaction pour un volume de variant
entre 50000 et 80000 documents !
Questions :
1) cela peut-il expliquer une baisse de performances ? j'ai remarqué que
les journaux de transactions restaient stables en volume (tout de même plus
de 20Go pour les plus grosses) mais peut-être son organisation interne a-t-
elle changée ?
2) si oui, que peut-on optimiser afin d'améliorer la gestion de ces grosses
transactions ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
lionelp
Bonjour,
il y a peut-être eu des modifications sur les tables en plus des batch d'insertion? Sinon on éssaie toujours de trouver un juste milieu dans la taille des batch, pas trop petits, pas trop gros, dans un cas on est lent parce que on traite 1 par 1, dans l'autre cas on sature le journal de transaction en IOs et le résultat fin par être le même.
Les problèmes de contentions: http://www.microsoft.com/technet/prodtechnol/sql/2005/tsprfprb.mspx
une 1ère requête: select top 10 * from sys.dm_os_wait_stats order by wait_time_ms desc
Si PAGEIOLATCH_XX, WRITELOG et IO_COMPLETION sont dans le top 10, c'est de la contention IO.
Cordialement, LionelP "Eric Belhomme" a écrit :
bonjour,
mon serveur MS SQL Server 2000 souffre de problèmes de performances depuis quelques temps. En réflechissant à ce qui a bien pu changer (ce serveur est en production depuis 2003) je me suis apperçu que l'atomicité des transactions d'insertion avait changé :
Auparavant, l'application métier qui alimentait ce serveur effectuait des transactions de lots de 3000 documents en moyenne. Cette application a été réécrite, et effectue maintenant une transaction pour un volume de variant entre 50000 et 80000 documents !
Questions :
1) cela peut-il expliquer une baisse de performances ? j'ai remarqué que les journaux de transactions restaient stables en volume (tout de même plus de 20Go pour les plus grosses) mais peut-être son organisation interne a-t- elle changée ?
2) si oui, que peut-on optimiser afin d'améliorer la gestion de ces grosses transactions ?
merci pour vos avis éclairés ;)
-- Rico
Bonjour,
il y a peut-être eu des modifications sur les tables en plus des batch
d'insertion?
Sinon on éssaie toujours de trouver un juste milieu dans la taille des
batch, pas trop petits, pas trop gros, dans un cas on est lent parce que on
traite 1 par 1, dans l'autre cas on sature le journal de transaction en IOs
et le résultat fin par être le même.
Les problèmes de contentions:
http://www.microsoft.com/technet/prodtechnol/sql/2005/tsprfprb.mspx
une 1ère requête:
select top 10 *
from sys.dm_os_wait_stats
order by wait_time_ms desc
Si PAGEIOLATCH_XX, WRITELOG et IO_COMPLETION sont dans le top 10, c'est de
la contention IO.
Cordialement,
LionelP
"Eric Belhomme" a écrit :
bonjour,
mon serveur MS SQL Server 2000 souffre de problèmes de performances depuis
quelques temps. En réflechissant à ce qui a bien pu changer (ce serveur est
en production depuis 2003) je me suis apperçu que l'atomicité des
transactions d'insertion avait changé :
Auparavant, l'application métier qui alimentait ce serveur effectuait des
transactions de lots de 3000 documents en moyenne. Cette application a été
réécrite, et effectue maintenant une transaction pour un volume de variant
entre 50000 et 80000 documents !
Questions :
1) cela peut-il expliquer une baisse de performances ? j'ai remarqué que
les journaux de transactions restaient stables en volume (tout de même plus
de 20Go pour les plus grosses) mais peut-être son organisation interne a-t-
elle changée ?
2) si oui, que peut-on optimiser afin d'améliorer la gestion de ces grosses
transactions ?
il y a peut-être eu des modifications sur les tables en plus des batch d'insertion? Sinon on éssaie toujours de trouver un juste milieu dans la taille des batch, pas trop petits, pas trop gros, dans un cas on est lent parce que on traite 1 par 1, dans l'autre cas on sature le journal de transaction en IOs et le résultat fin par être le même.
Les problèmes de contentions: http://www.microsoft.com/technet/prodtechnol/sql/2005/tsprfprb.mspx
une 1ère requête: select top 10 * from sys.dm_os_wait_stats order by wait_time_ms desc
Si PAGEIOLATCH_XX, WRITELOG et IO_COMPLETION sont dans le top 10, c'est de la contention IO.
Cordialement, LionelP "Eric Belhomme" a écrit :
bonjour,
mon serveur MS SQL Server 2000 souffre de problèmes de performances depuis quelques temps. En réflechissant à ce qui a bien pu changer (ce serveur est en production depuis 2003) je me suis apperçu que l'atomicité des transactions d'insertion avait changé :
Auparavant, l'application métier qui alimentait ce serveur effectuait des transactions de lots de 3000 documents en moyenne. Cette application a été réécrite, et effectue maintenant une transaction pour un volume de variant entre 50000 et 80000 documents !
Questions :
1) cela peut-il expliquer une baisse de performances ? j'ai remarqué que les journaux de transactions restaient stables en volume (tout de même plus de 20Go pour les plus grosses) mais peut-être son organisation interne a-t- elle changée ?
2) si oui, que peut-on optimiser afin d'améliorer la gestion de ces grosses transactions ?
merci pour vos avis éclairés ;)
-- Rico
Fred BROUARD
plus généralement : 1) fichier de taille fixe bien dimensionnés 2) faire des transactions par lots de 64 Ko
A +
a écrit :
Bonjour,
il y a peut-être eu des modifications sur les tables en plus des batch d'insertion? Sinon on éssaie toujours de trouver un juste milieu dans la taille des batch, pas trop petits, pas trop gros, dans un cas on est lent parce que on traite 1 par 1, dans l'autre cas on sature le journal de transaction en IOs et le résultat fin par être le même.
Les problèmes de contentions: http://www.microsoft.com/technet/prodtechnol/sql/2005/tsprfprb.mspx
une 1ère requête: select top 10 * from sys.dm_os_wait_stats order by wait_time_ms desc
Si PAGEIOLATCH_XX, WRITELOG et IO_COMPLETION sont dans le top 10, c'est de la contention IO.
Cordialement, LionelP "Eric Belhomme" a écrit :
bonjour,
mon serveur MS SQL Server 2000 souffre de problèmes de performances depuis quelques temps. En réflechissant à ce qui a bien pu changer (ce serveur est en production depuis 2003) je me suis apperçu que l'atomicité des transactions d'insertion avait changé :
Auparavant, l'application métier qui alimentait ce serveur effectuait des transactions de lots de 3000 documents en moyenne. Cette application a été réécrite, et effectue maintenant une transaction pour un volume de variant entre 50000 et 80000 documents !
Questions :
1) cela peut-il expliquer une baisse de performances ? j'ai remarqué que les journaux de transactions restaient stables en volume (tout de même plus de 20Go pour les plus grosses) mais peut-être son organisation interne a-t- elle changée ?
2) si oui, que peut-on optimiser afin d'améliorer la gestion de ces grosses transactions ?
merci pour vos avis éclairés ;)
-- Rico
-- 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 ***********************
plus généralement :
1) fichier de taille fixe bien dimensionnés
2) faire des transactions par lots de 64 Ko
A +
lionelp@online.microsoft.com a écrit :
Bonjour,
il y a peut-être eu des modifications sur les tables en plus des batch
d'insertion?
Sinon on éssaie toujours de trouver un juste milieu dans la taille des
batch, pas trop petits, pas trop gros, dans un cas on est lent parce que on
traite 1 par 1, dans l'autre cas on sature le journal de transaction en IOs
et le résultat fin par être le même.
Les problèmes de contentions:
http://www.microsoft.com/technet/prodtechnol/sql/2005/tsprfprb.mspx
une 1ère requête:
select top 10 *
from sys.dm_os_wait_stats
order by wait_time_ms desc
Si PAGEIOLATCH_XX, WRITELOG et IO_COMPLETION sont dans le top 10, c'est de
la contention IO.
Cordialement,
LionelP
"Eric Belhomme" a écrit :
bonjour,
mon serveur MS SQL Server 2000 souffre de problèmes de performances depuis
quelques temps. En réflechissant à ce qui a bien pu changer (ce serveur est
en production depuis 2003) je me suis apperçu que l'atomicité des
transactions d'insertion avait changé :
Auparavant, l'application métier qui alimentait ce serveur effectuait des
transactions de lots de 3000 documents en moyenne. Cette application a été
réécrite, et effectue maintenant une transaction pour un volume de variant
entre 50000 et 80000 documents !
Questions :
1) cela peut-il expliquer une baisse de performances ? j'ai remarqué que
les journaux de transactions restaient stables en volume (tout de même plus
de 20Go pour les plus grosses) mais peut-être son organisation interne a-t-
elle changée ?
2) si oui, que peut-on optimiser afin d'améliorer la gestion de ces grosses
transactions ?
merci pour vos avis éclairés ;)
--
Rico
--
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 ***********************
plus généralement : 1) fichier de taille fixe bien dimensionnés 2) faire des transactions par lots de 64 Ko
A +
a écrit :
Bonjour,
il y a peut-être eu des modifications sur les tables en plus des batch d'insertion? Sinon on éssaie toujours de trouver un juste milieu dans la taille des batch, pas trop petits, pas trop gros, dans un cas on est lent parce que on traite 1 par 1, dans l'autre cas on sature le journal de transaction en IOs et le résultat fin par être le même.
Les problèmes de contentions: http://www.microsoft.com/technet/prodtechnol/sql/2005/tsprfprb.mspx
une 1ère requête: select top 10 * from sys.dm_os_wait_stats order by wait_time_ms desc
Si PAGEIOLATCH_XX, WRITELOG et IO_COMPLETION sont dans le top 10, c'est de la contention IO.
Cordialement, LionelP "Eric Belhomme" a écrit :
bonjour,
mon serveur MS SQL Server 2000 souffre de problèmes de performances depuis quelques temps. En réflechissant à ce qui a bien pu changer (ce serveur est en production depuis 2003) je me suis apperçu que l'atomicité des transactions d'insertion avait changé :
Auparavant, l'application métier qui alimentait ce serveur effectuait des transactions de lots de 3000 documents en moyenne. Cette application a été réécrite, et effectue maintenant une transaction pour un volume de variant entre 50000 et 80000 documents !
Questions :
1) cela peut-il expliquer une baisse de performances ? j'ai remarqué que les journaux de transactions restaient stables en volume (tout de même plus de 20Go pour les plus grosses) mais peut-être son organisation interne a-t- elle changée ?
2) si oui, que peut-on optimiser afin d'améliorer la gestion de ces grosses transactions ?
merci pour vos avis éclairés ;)
-- Rico
-- 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 ***********************
Eric Belhomme
=?Utf-8?B?bGlvbmVscEBvbmxpbmUubWljcm9zb2Z0LmNvbQ==?= wrote in news::
select top 10 * from sys.dm_os_wait_stats order by wait_time_ms desc
merci mais ca ne fonctionne pas avec sql server 2000...
-- Rico
=?Utf-8?B?bGlvbmVscEBvbmxpbmUubWljcm9zb2Z0LmNvbQ==?=
<lionelponlinemicrosoftcom@discussions.microsoft.com> wrote in
news:F5768152-1F11-478F-A35E-B55D1A4FEE6B@microsoft.com:
select top 10 *
from sys.dm_os_wait_stats
order by wait_time_ms desc
merci mais ca ne fonctionne pas avec sql server 2000...
