Gros problème de ralentissement d'une serveur SQL 2005
13 réponses
Test recherche
Bonjour
Je dispose d'un serveur SQL 2005 x 64 (9.0.4207) sur un windows 2003 serveur
x64. 2 processeurs avec 4 cores chacun soit 8 cores au total, 2.93Ghz, 12 Go
de ram.
Tous les jours un traitement spécifique est lancé par une application, ce
traitement lance une procédure stockée qui dure environ 2 minutes 30 à 3
minutes.
Ce traitement à pour effet de ralentir considérablement toutes les autres
applications connecter à la base de données et de les faire tomber en
expiration de délai, alors que la majorité ne font que des opérations de
lecture.
Lors de ce traitement, j'ai un core qui est presque à 100 % mais globalement
le temps d'occupation cpu est à 20 %
Les disques ne travaillent pas plus que ça et les différents compteurs de
l'observateur de performance, mais à part le temps CPU qui est monté à 20%,
les autres n'ont pas bougés.
Aucun autre gros traitement n'est lancé en parallèle.
En revanche ce problème est présent depuis que le serveur SQL est passé de
2000 à 2005.
Je ne comprends pas comment 1 procédure stockée peut mettre à plat un
serveur qui à l'observateur de perf et au gestionnaire des taches n'est pas
plus affecté que ça.
Avec une peu de retard car en déplacement, je vous remercie tous pour ces précisions Très cordialement Stéphane
"SQLpro" a écrit dans le message de news:
Effectivement et comme vous le dit Serguei, le mieux serait d'utiliser le bon niveau d'isolation des transactions et notamment le niveau SNAPSHOT que vous devez préalablement autoriser. Voir l'article que j'ai écrit à ce sujet : http://sqlpro.developpez.com/isolation-transaction/ En sus, l'indexation est très importante. En effet en l'absence d'index les lignes sont parcourues par balayage ce qui multiplie par un facteur très important les traitement, donc les délais et pour finir la durée du verrouillage, donc les blocages et par là même la contention. Ne pas avoir peur d'indexer. Si 15 index sont nécessaires sur la même table et que chacun apporte un gain de 100 sur des requêtes très différente, alors c'est autant de temps de gagné pour faire les mises à jour. Lisez l'article que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/quoi-indexer/ En sus, vous pouvez utiliser la DMV sys.dm_db_missing_index_details qui vous conseille sur les index manquants (attention : soyez circonspect : mutualisez les résultats de cette demande !).
A +
Frédéric BROUARD, Spécialiste modélisation, bases de données, optimisation, langage SQL. Le site sur le langage SQL et les S.G.B.D. relationnels : http://sqlpro.developpez.com/ Expert SQL Server http://www.sqlspot.com : audit, optimisation, tuning, formation * * * * * Enseignant au CNAM PACA et à l'ISEN à Toulon * * * * *
On 29 jan, 08:39, zoltix wrote:
On 28 jan, 12:04, "Test recherche" wrote:
> En fait, si je comprends bien, une table sur laquelle il y a un verrou > car > un process insert ou modifie des enregistrements, ne peut pas tre > parcouru > par un select ?
> Cordialement > St phane
> "Serguei Tarassov" a crit dans le message de news: > 4b616dc9$0$965$
> > On 28/01/2010 11:41, Test recherche wrote: > >> Je n'ai pas d'index sur mes vues, quand j'essaie, cela me dit que la > >> vue > >> n'appartient pas au sh ma. > > C'est normal car l'indexation des vues c'est pas si simple... > > J'ai voulu dire plut t au sujet des index de tables au-dessous de la > > vue, > > ce sera un bonne id e de voir les plans d' xecution sur les vues.
> >> Je sais bien que les transactions doivent tre le plus courte > >> possible, > >> mais > >> notament dans ce traitement ce n'est pas le cas > >> car si une erreur se produit, tout doit tre annul > > D'accord. > > Si ta traitement donne l'impact significatif au niveau de verrouillage > > de > > plusieurs tables, il n'y a pas beaucoup de choses faire de mani re "ad > > hoc" sauf peut tre l'introduction d'isolement "snapshot".
> >> Cordialement > >> St phane
> >> "Serguei Tarassov" a crit dans le message de > >> news: > >> 4b616142$0$925$ > >>> On 28/01/2010 10:40, Test recherche wrote: > >>>> Bonjour et merci de tes conseils, > >>>> non je n'ai pas mis jour la statistique et donc pas de > >>>> sp_recompile > >>>> pour les tables > >>>> Je vais v rifi mes index. > >>>> lors du prochain traitement je surveillerai attentivement la > >>>> m moire > >>>> vive/cache
> >>>> Je ne sais pas ce qu'est l'isolation snapshot, je vais donc me > >>>> renseign .
> >>>> Aujourd'hui, toutes les insertions mises jour se font sur les > >>>> tables > >>>> et les s lection sur des vues. Est ce une bonne solution ? > >>> Oui, c'est une solution "standard". > >>> Par contre, si t'a grosses volumes ins rer voir aussi la possibilit > >>> de > >>> copie en bloc (bulk). > >>> D'autre part, vois les plans d'ex cution sur tes vues, il est > >>> possible > >>> qu'il manque des index et cela produit un "table scan" qui sera > >>> bloqu > >>> par > >>> les transactions tr s probablement.
> >>>> Je demande cela car je pense que mes probl mes viennent des > >>>> verrous, > >>>> ce > >>>> matin j'ai constat un verrou sur une table mis par une proc dure > >>>> stock e > >>>> (pas de transaction) > >>>> qui fait quelques selects pour r cup rer des infos, met jour un > >>>> enregistrements et je ne sais pas pourquoi, cette proc dure qui > >>>> fait > >>>> presque > >>>> rien a dur e une eternit > >>>> et cela fait tomber en expiration de d lai ceux qui voulais faire > >>>> des > >>>> select sur cette m me table
> >>> Le pb de verrouillage existe toujours en OLTP voila pourquoi il faut > >>> toujours minimiser le temps de chaque transaction modifi e les donn > >>> es.
> >>> L'utilisation du niveau d'isolation snapshot (introduit en 2005) > >>> permet > >>> de > >>> lire des donn es en tat consistant qui sont en train de modification > >>> par > >>> une autre transaction. > >>> C'est une solution "standard" pour les rapports, par exemple.
> >>>> Merci
> >>>> "Serguei Tarassov" a crit dans le message de > >>>> news: > >>>> 4b615255$0$963$ > >>>>> On 28/01/2010 09:39, Test recherche wrote: > >>>>>> Bonjour > >>>>>> Je dispose d'un serveur SQL 2005 x 64 (9.0.4207) sur un windows > >>>>>> 2003 > >>>>>> serveur > >>>>>> x64. 2 processeurs avec 4 cores chacun soit 8 cores au total, > >>>>>> 2.93Ghz, > >>>>>> 12 > >>>>>> Go > >>>>>> de ram. > >>>>>> Tous les jours un traitement sp cifique est lanc par une > >>>>>> application, > >>>>>> ce > >>>>>> traitement lance une proc dure stock e qui dure environ 2 minutes > >>>>>> 30
> >>>>>> 3 > >>>>>> minutes.
> >>>>>> Ce traitement pour effet de ralentir consid rablement toutes les > >>>>>> autres > >>>>>> applications connecter la base de donn es et de les faire tomber > >>>>>> en > >>>>>> expiration de d lai, alors que la majorit ne font que des op > >>>>>> rations > >>>>>> de > >>>>>> lecture.
> >>>>>> Lors de ce traitement, j'ai un core qui est presque 100 % mais > >>>>>> globalement > >>>>>> le temps d'occupation cpu est 20 % > >>>>>> Les disques ne travaillent pas plus que a et les diff rents > >>>>>> compteurs > >>>>>> de > >>>>>> l'observateur de performance, mais part le temps CPU qui est mont
> >>>>>> 20%, > >>>>>> les autres n'ont pas boug s.
> >>>>>> Aucun autre gros traitement n'est lanc en parall le.
> >>>>>> En revanche ce probl me est pr sent depuis que le serveur SQL est > >>>>>> pass > >>>>>> de > >>>>>> 2000 2005.
> >>>>>> Je ne comprends pas comment 1 proc dure stock e peut mettre plat > >>>>>> un > >>>>>> serveur qui l'observateur de perf et au gestionnaire des taches > >>>>>> n'est > >>>>>> pas > >>>>>> plus affect que a.
> >>>>>> Merci de vos conseils > >>>>>> St phane
> >>>>> St phane,
> >>>>> As-tu mis jour la statistique apr s avoir migr de 2000 2005 ? > >>>>> Voir UPDATE STATISTICS et sp_recompile pour toutes les tables.
> >>>>> D'autre part, es-tu s re que ta proc stock e utilise un bon plan > >>>>> d'ex cution ? Les indexs, sont ils suffisante ?
> >>>>> As-tu surveill l'utilisation de la m moire vive/cache ?
> >>>>> Vu que les autres processus ne font que la lecture, pense-tu > >>>>> d'utiliser > >>>>> l'isolation snapshot ?
lors de de update ou insert , il y'a un lock, soit au niveau de la page ou niveau de la row. Et si par hasard une requête essaye de lire en même temps...... Elle se met en attente, jusqu'au moment ou la transaction est finie. Mais dans un select il y a moyen que ce ne soit pas bloquant( voir la doc pour les conséquences).
--Au debut SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
--Code du select
--a la fin SET TRANSACTION ISOLATION LEVEL READ COMMITTED
Avec une peu de retard car en déplacement, je vous remercie tous pour ces
précisions
Très cordialement
Stéphane
"SQLpro" <brouardf@club-internet.fr> a écrit dans le message de news:
ab1e9944-0884-4401-b01b-035456ead8f7@e37g2000yqn.googlegroups.com...
Effectivement et comme vous le dit Serguei, le mieux serait d'utiliser
le bon niveau d'isolation des transactions et notamment le niveau
SNAPSHOT que vous devez préalablement autoriser. Voir l'article que
j'ai écrit à ce sujet : http://sqlpro.developpez.com/isolation-transaction/
En sus, l'indexation est très importante. En effet en l'absence
d'index les lignes sont parcourues par balayage ce qui multiplie par
un facteur très important les traitement, donc les délais et pour
finir la durée du verrouillage, donc les blocages et par là même la
contention. Ne pas avoir peur d'indexer. Si 15 index sont nécessaires
sur la même table et que chacun apporte un gain de 100 sur des
requêtes très différente, alors c'est autant de temps de gagné pour
faire les mises à jour.
Lisez l'article que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/cours/quoi-indexer/
En sus, vous pouvez utiliser la DMV sys.dm_db_missing_index_details
qui vous conseille sur les index manquants (attention : soyez
circonspect : mutualisez les résultats de cette demande !).
A +
Frédéric BROUARD, Spécialiste modélisation, bases de données,
optimisation, langage SQL.
Le site sur le langage SQL et les S.G.B.D. relationnels :
http://sqlpro.developpez.com/
Expert SQL Server http://www.sqlspot.com : audit, optimisation,
tuning, formation
* * * * * Enseignant au CNAM PACA et à l'ISEN à Toulon * * * * *
On 29 jan, 08:39, zoltix <zol...@gmail.com> wrote:
On 28 jan, 12:04, "Test recherche" <T...@Test.fr> wrote:
> En fait, si je comprends bien, une table sur laquelle il y a un verrou
> car
> un process insert ou modifie des enregistrements, ne peut pas tre
> parcouru
> par un select ?
> Cordialement
> St phane
> "Serguei Tarassov" <se...@arbinada.com> a crit dans le message de news:
> 4b616dc9$0$965$ba4ac...@news.orange.fr...
> > On 28/01/2010 11:41, Test recherche wrote:
> >> Je n'ai pas d'index sur mes vues, quand j'essaie, cela me dit que la
> >> vue
> >> n'appartient pas au sh ma.
> > C'est normal car l'indexation des vues c'est pas si simple...
> > J'ai voulu dire plut t au sujet des index de tables au-dessous de la
> > vue,
> > ce sera un bonne id e de voir les plans d' xecution sur les vues.
> >> Je sais bien que les transactions doivent tre le plus courte
> >> possible,
> >> mais
> >> notament dans ce traitement ce n'est pas le cas
> >> car si une erreur se produit, tout doit tre annul
> > D'accord.
> > Si ta traitement donne l'impact significatif au niveau de verrouillage
> > de
> > plusieurs tables, il n'y a pas beaucoup de choses faire de mani re "ad
> > hoc" sauf peut tre l'introduction d'isolement "snapshot".
> >> Cordialement
> >> St phane
> >> "Serguei Tarassov"<se...@arbinada.com> a crit dans le message de
> >> news:
> >> 4b616142$0$925$ba4ac...@news.orange.fr...
> >>> On 28/01/2010 10:40, Test recherche wrote:
> >>>> Bonjour et merci de tes conseils,
> >>>> non je n'ai pas mis jour la statistique et donc pas de
> >>>> sp_recompile
> >>>> pour les tables
> >>>> Je vais v rifi mes index.
> >>>> lors du prochain traitement je surveillerai attentivement la
> >>>> m moire
> >>>> vive/cache
> >>>> Je ne sais pas ce qu'est l'isolation snapshot, je vais donc me
> >>>> renseign .
> >>>> Aujourd'hui, toutes les insertions mises jour se font sur les
> >>>> tables
> >>>> et les s lection sur des vues. Est ce une bonne solution ?
> >>> Oui, c'est une solution "standard".
> >>> Par contre, si t'a grosses volumes ins rer voir aussi la possibilit
> >>> de
> >>> copie en bloc (bulk).
> >>> D'autre part, vois les plans d'ex cution sur tes vues, il est
> >>> possible
> >>> qu'il manque des index et cela produit un "table scan" qui sera
> >>> bloqu
> >>> par
> >>> les transactions tr s probablement.
> >>>> Je demande cela car je pense que mes probl mes viennent des
> >>>> verrous,
> >>>> ce
> >>>> matin j'ai constat un verrou sur une table mis par une proc dure
> >>>> stock e
> >>>> (pas de transaction)
> >>>> qui fait quelques selects pour r cup rer des infos, met jour un
> >>>> enregistrements et je ne sais pas pourquoi, cette proc dure qui
> >>>> fait
> >>>> presque
> >>>> rien a dur e une eternit
> >>>> et cela fait tomber en expiration de d lai ceux qui voulais faire
> >>>> des
> >>>> select sur cette m me table
> >>> Le pb de verrouillage existe toujours en OLTP voila pourquoi il faut
> >>> toujours minimiser le temps de chaque transaction modifi e les donn
> >>> es.
> >>> L'utilisation du niveau d'isolation snapshot (introduit en 2005)
> >>> permet
> >>> de
> >>> lire des donn es en tat consistant qui sont en train de modification
> >>> par
> >>> une autre transaction.
> >>> C'est une solution "standard" pour les rapports, par exemple.
> >>>> Merci
> >>>> "Serguei Tarassov"<se...@arbinada.com> a crit dans le message de
> >>>> news:
> >>>> 4b615255$0$963$ba4ac...@news.orange.fr...
> >>>>> On 28/01/2010 09:39, Test recherche wrote:
> >>>>>> Bonjour
> >>>>>> Je dispose d'un serveur SQL 2005 x 64 (9.0.4207) sur un windows
> >>>>>> 2003
> >>>>>> serveur
> >>>>>> x64. 2 processeurs avec 4 cores chacun soit 8 cores au total,
> >>>>>> 2.93Ghz,
> >>>>>> 12
> >>>>>> Go
> >>>>>> de ram.
> >>>>>> Tous les jours un traitement sp cifique est lanc par une
> >>>>>> application,
> >>>>>> ce
> >>>>>> traitement lance une proc dure stock e qui dure environ 2 minutes
> >>>>>> 30
> >>>>>> 3
> >>>>>> minutes.
> >>>>>> Ce traitement pour effet de ralentir consid rablement toutes les
> >>>>>> autres
> >>>>>> applications connecter la base de donn es et de les faire tomber
> >>>>>> en
> >>>>>> expiration de d lai, alors que la majorit ne font que des op
> >>>>>> rations
> >>>>>> de
> >>>>>> lecture.
> >>>>>> Lors de ce traitement, j'ai un core qui est presque 100 % mais
> >>>>>> globalement
> >>>>>> le temps d'occupation cpu est 20 %
> >>>>>> Les disques ne travaillent pas plus que a et les diff rents
> >>>>>> compteurs
> >>>>>> de
> >>>>>> l'observateur de performance, mais part le temps CPU qui est mont
> >>>>>> 20%,
> >>>>>> les autres n'ont pas boug s.
> >>>>>> Aucun autre gros traitement n'est lanc en parall le.
> >>>>>> En revanche ce probl me est pr sent depuis que le serveur SQL est
> >>>>>> pass
> >>>>>> de
> >>>>>> 2000 2005.
> >>>>>> Je ne comprends pas comment 1 proc dure stock e peut mettre plat
> >>>>>> un
> >>>>>> serveur qui l'observateur de perf et au gestionnaire des taches
> >>>>>> n'est
> >>>>>> pas
> >>>>>> plus affect que a.
> >>>>>> Merci de vos conseils
> >>>>>> St phane
> >>>>> St phane,
> >>>>> As-tu mis jour la statistique apr s avoir migr de 2000 2005 ?
> >>>>> Voir UPDATE STATISTICS et sp_recompile pour toutes les tables.
> >>>>> D'autre part, es-tu s re que ta proc stock e utilise un bon plan
> >>>>> d'ex cution ? Les indexs, sont ils suffisante ?
> >>>>> As-tu surveill l'utilisation de la m moire vive/cache ?
> >>>>> Vu que les autres processus ne font que la lecture, pense-tu
> >>>>> d'utiliser
> >>>>> l'isolation snapshot ?
lors de de update ou insert , il y'a un lock, soit au niveau de la
page ou niveau de la row. Et si par hasard une requête essaye de
lire en même temps...... Elle se met en attente, jusqu'au moment ou la
transaction est finie.
Mais dans un select il y a moyen que ce ne soit pas bloquant( voir la
doc pour les conséquences).
--Au debut
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
--Code du select
--a la fin
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
Avec une peu de retard car en déplacement, je vous remercie tous pour ces précisions Très cordialement Stéphane
"SQLpro" a écrit dans le message de news:
Effectivement et comme vous le dit Serguei, le mieux serait d'utiliser le bon niveau d'isolation des transactions et notamment le niveau SNAPSHOT que vous devez préalablement autoriser. Voir l'article que j'ai écrit à ce sujet : http://sqlpro.developpez.com/isolation-transaction/ En sus, l'indexation est très importante. En effet en l'absence d'index les lignes sont parcourues par balayage ce qui multiplie par un facteur très important les traitement, donc les délais et pour finir la durée du verrouillage, donc les blocages et par là même la contention. Ne pas avoir peur d'indexer. Si 15 index sont nécessaires sur la même table et que chacun apporte un gain de 100 sur des requêtes très différente, alors c'est autant de temps de gagné pour faire les mises à jour. Lisez l'article que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/quoi-indexer/ En sus, vous pouvez utiliser la DMV sys.dm_db_missing_index_details qui vous conseille sur les index manquants (attention : soyez circonspect : mutualisez les résultats de cette demande !).
A +
Frédéric BROUARD, Spécialiste modélisation, bases de données, optimisation, langage SQL. Le site sur le langage SQL et les S.G.B.D. relationnels : http://sqlpro.developpez.com/ Expert SQL Server http://www.sqlspot.com : audit, optimisation, tuning, formation * * * * * Enseignant au CNAM PACA et à l'ISEN à Toulon * * * * *
On 29 jan, 08:39, zoltix wrote:
On 28 jan, 12:04, "Test recherche" wrote:
> En fait, si je comprends bien, une table sur laquelle il y a un verrou > car > un process insert ou modifie des enregistrements, ne peut pas tre > parcouru > par un select ?
> Cordialement > St phane
> "Serguei Tarassov" a crit dans le message de news: > 4b616dc9$0$965$
> > On 28/01/2010 11:41, Test recherche wrote: > >> Je n'ai pas d'index sur mes vues, quand j'essaie, cela me dit que la > >> vue > >> n'appartient pas au sh ma. > > C'est normal car l'indexation des vues c'est pas si simple... > > J'ai voulu dire plut t au sujet des index de tables au-dessous de la > > vue, > > ce sera un bonne id e de voir les plans d' xecution sur les vues.
> >> Je sais bien que les transactions doivent tre le plus courte > >> possible, > >> mais > >> notament dans ce traitement ce n'est pas le cas > >> car si une erreur se produit, tout doit tre annul > > D'accord. > > Si ta traitement donne l'impact significatif au niveau de verrouillage > > de > > plusieurs tables, il n'y a pas beaucoup de choses faire de mani re "ad > > hoc" sauf peut tre l'introduction d'isolement "snapshot".
> >> Cordialement > >> St phane
> >> "Serguei Tarassov" a crit dans le message de > >> news: > >> 4b616142$0$925$ > >>> On 28/01/2010 10:40, Test recherche wrote: > >>>> Bonjour et merci de tes conseils, > >>>> non je n'ai pas mis jour la statistique et donc pas de > >>>> sp_recompile > >>>> pour les tables > >>>> Je vais v rifi mes index. > >>>> lors du prochain traitement je surveillerai attentivement la > >>>> m moire > >>>> vive/cache
> >>>> Je ne sais pas ce qu'est l'isolation snapshot, je vais donc me > >>>> renseign .
> >>>> Aujourd'hui, toutes les insertions mises jour se font sur les > >>>> tables > >>>> et les s lection sur des vues. Est ce une bonne solution ? > >>> Oui, c'est une solution "standard". > >>> Par contre, si t'a grosses volumes ins rer voir aussi la possibilit > >>> de > >>> copie en bloc (bulk). > >>> D'autre part, vois les plans d'ex cution sur tes vues, il est > >>> possible > >>> qu'il manque des index et cela produit un "table scan" qui sera > >>> bloqu > >>> par > >>> les transactions tr s probablement.
> >>>> Je demande cela car je pense que mes probl mes viennent des > >>>> verrous, > >>>> ce > >>>> matin j'ai constat un verrou sur une table mis par une proc dure > >>>> stock e > >>>> (pas de transaction) > >>>> qui fait quelques selects pour r cup rer des infos, met jour un > >>>> enregistrements et je ne sais pas pourquoi, cette proc dure qui > >>>> fait > >>>> presque > >>>> rien a dur e une eternit > >>>> et cela fait tomber en expiration de d lai ceux qui voulais faire > >>>> des > >>>> select sur cette m me table
> >>> Le pb de verrouillage existe toujours en OLTP voila pourquoi il faut > >>> toujours minimiser le temps de chaque transaction modifi e les donn > >>> es.
> >>> L'utilisation du niveau d'isolation snapshot (introduit en 2005) > >>> permet > >>> de > >>> lire des donn es en tat consistant qui sont en train de modification > >>> par > >>> une autre transaction. > >>> C'est une solution "standard" pour les rapports, par exemple.
> >>>> Merci
> >>>> "Serguei Tarassov" a crit dans le message de > >>>> news: > >>>> 4b615255$0$963$ > >>>>> On 28/01/2010 09:39, Test recherche wrote: > >>>>>> Bonjour > >>>>>> Je dispose d'un serveur SQL 2005 x 64 (9.0.4207) sur un windows > >>>>>> 2003 > >>>>>> serveur > >>>>>> x64. 2 processeurs avec 4 cores chacun soit 8 cores au total, > >>>>>> 2.93Ghz, > >>>>>> 12 > >>>>>> Go > >>>>>> de ram. > >>>>>> Tous les jours un traitement sp cifique est lanc par une > >>>>>> application, > >>>>>> ce > >>>>>> traitement lance une proc dure stock e qui dure environ 2 minutes > >>>>>> 30
> >>>>>> 3 > >>>>>> minutes.
> >>>>>> Ce traitement pour effet de ralentir consid rablement toutes les > >>>>>> autres > >>>>>> applications connecter la base de donn es et de les faire tomber > >>>>>> en > >>>>>> expiration de d lai, alors que la majorit ne font que des op > >>>>>> rations > >>>>>> de > >>>>>> lecture.
> >>>>>> Lors de ce traitement, j'ai un core qui est presque 100 % mais > >>>>>> globalement > >>>>>> le temps d'occupation cpu est 20 % > >>>>>> Les disques ne travaillent pas plus que a et les diff rents > >>>>>> compteurs > >>>>>> de > >>>>>> l'observateur de performance, mais part le temps CPU qui est mont
> >>>>>> 20%, > >>>>>> les autres n'ont pas boug s.
> >>>>>> Aucun autre gros traitement n'est lanc en parall le.
> >>>>>> En revanche ce probl me est pr sent depuis que le serveur SQL est > >>>>>> pass > >>>>>> de > >>>>>> 2000 2005.
> >>>>>> Je ne comprends pas comment 1 proc dure stock e peut mettre plat > >>>>>> un > >>>>>> serveur qui l'observateur de perf et au gestionnaire des taches > >>>>>> n'est > >>>>>> pas > >>>>>> plus affect que a.
> >>>>>> Merci de vos conseils > >>>>>> St phane
> >>>>> St phane,
> >>>>> As-tu mis jour la statistique apr s avoir migr de 2000 2005 ? > >>>>> Voir UPDATE STATISTICS et sp_recompile pour toutes les tables.
> >>>>> D'autre part, es-tu s re que ta proc stock e utilise un bon plan > >>>>> d'ex cution ? Les indexs, sont ils suffisante ?
> >>>>> As-tu surveill l'utilisation de la m moire vive/cache ?
> >>>>> Vu que les autres processus ne font que la lecture, pense-tu > >>>>> d'utiliser > >>>>> l'isolation snapshot ?
lors de de update ou insert , il y'a un lock, soit au niveau de la page ou niveau de la row. Et si par hasard une requête essaye de lire en même temps...... Elle se met en attente, jusqu'au moment ou la transaction est finie. Mais dans un select il y a moyen que ce ne soit pas bloquant( voir la doc pour les conséquences).
--Au debut SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
--Code du select
--a la fin SET TRANSACTION ISOLATION LEVEL READ COMMITTED
zoltix
SQLpro > Soyez circonspect : mutualisez les résultats de cette demande !).
Je ne comprends pas bien la phrases ?
SQLpro > Soyez circonspect : mutualisez les résultats de cette
demande !).
SQLpro > Soyez circonspect : mutualisez les résultats de cette demande !).
Je ne comprends pas bien la phrases ?
Fred BROUARD
zoltix a écrit :
SQLpro > Soyez circonspect : mutualisez les résultats de cette demande !).
Je ne comprends pas bien la phrases ?
le moteur conseille des index sur la même table comme :
colonnes A, B, C A, C A, B C, B C, B, A
Mais : 1) C, B est inclus dans C, B, A 2) A, B est inclus dans A, B, C 3) A, C offre peut d'intérêt si vous faites A, B, C Conclusions : En implémetant les index C, B, A et A, B, C vous avez presque tous les cas de figure !
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 Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies *********************** http://www.sqlspot.com *************************
zoltix a écrit :
SQLpro > Soyez circonspect : mutualisez les résultats de cette
demande !).
Je ne comprends pas bien la phrases ?
le moteur conseille des index sur la même table comme :
colonnes
A, B, C
A, C
A, B
C, B
C, B, A
Mais :
1) C, B est inclus dans C, B, A
2) A, B est inclus dans A, B, C
3) A, C offre peut d'intérêt si vous faites A, B, C
Conclusions :
En implémetant les index
C, B, A et A, B, C vous avez presque tous les cas de figure !
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
SQLpro > Soyez circonspect : mutualisez les résultats de cette demande !).
Je ne comprends pas bien la phrases ?
le moteur conseille des index sur la même table comme :
colonnes A, B, C A, C A, B C, B C, B, A
Mais : 1) C, B est inclus dans C, B, A 2) A, B est inclus dans A, B, C 3) A, C offre peut d'intérêt si vous faites A, B, C Conclusions : En implémetant les index C, B, A et A, B, C vous avez presque tous les cas de figure !
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 Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies *********************** http://www.sqlspot.com *************************
