Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Gros problème de ralentissement d'une serveur SQL 2005

13 réponses
Avatar
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.

Merci de vos conseils
Stéphane

10 réponses

1 2
Avatar
Serguei Tarassov
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 ?


A+
Serguei TARASSOV
MCITP SQL Server Dev/DBA
http://sgbd.arbinada.com
Avatar
Test recherche
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 ?
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

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 ?


A+
Serguei TARASSOV
MCITP SQL Server Dev/DBA
http://sgbd.arbinada.com


Avatar
Serguei Tarassov
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 ?


A+
Serguei TARASSOV
MCITP SQL Server Dev/DBA
http://sgbd.arbinada.com" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">http://sgbd.arbinada.com








--
Сергей Тарасов
www.arbinada.com
369985571

A+
Serguei TARASSOV
MCITP SQL Server Dev/DBA
http://sgbd.arbinada.com" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">http://sgbd.arbinada.com
Avatar
Test recherche
Je n'ai pas d'index sur mes vues, quand j'essaie, cela me dit que la vue
n'appartient pas au shéma.

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é
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 ?


A+
Serguei TARASSOV
MCITP SQL Server Dev/DBA
http://sgbd.arbinada.com" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">http://sgbd.arbinada.com








--
?????? ???????
www.arbinada.com
369985571

A+
Serguei TARASSOV
MCITP SQL Server Dev/DBA
http://sgbd.arbinada.com" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">http://sgbd.arbinada.com


Avatar
Serguei Tarassov
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 ?


A+
Serguei TARASSOV
MCITP SQL Server Dev/DBA
http://sgbd.arbinada.com" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">http://sgbd.arbinada.com








--
?????? ???????
www.arbinada.com
369985571

A+
Serguei TARASSOV
MCITP SQL Server Dev/DBA
http://sgbd.arbinada.com" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">http://sgbd.arbinada.com






Avatar
Test recherche
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 ?


A+
Serguei TARASSOV
MCITP SQL Server Dev/DBA
http://sgbd.arbinada.com" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">http://sgbd.arbinada.com








--
?????? ???????
www.arbinada.com
369985571

A+
Serguei TARASSOV
MCITP SQL Server Dev/DBA
http://sgbd.arbinada.com" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">http://sgbd.arbinada.com








Avatar
Serguei Tarassov
On 28/01/2010 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 ?


Pas nécessairement, cela dépende du niveau d'isolement des transactions
et des verrous dont le nombre peut provoquer l'escalade au niveau de table.



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 ?


A+
Serguei TARASSOV
MCITP SQL Server Dev/DBA
http://sgbd.arbinada.com" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">http://sgbd.arbinada.com" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">http://sgbd.arbinada.com" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">http://sgbd.arbinada.com








--
?????? ???????
www.arbinada.com
369985571

A+
Serguei TARASSOV
MCITP SQL Server Dev/DBA
http://sgbd.arbinada.com" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">http://sgbd.arbinada.com" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">http://sgbd.arbinada.com" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">http://sgbd.arbinada.com














--
Сергей Тарасов
www.arbinada.com
369985571

A+
Serguei TARASSOV
MCITP SQL Server Dev/DBA
http://sgbd.arbinada.com" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">http://sgbd.arbinada.com" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">http://sgbd.arbinada.com" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">http://sgbd.arbinada.com
Avatar
zoltix
On 28 jan, 12:04, "Test recherche" wrote:
En fait, si je comprends bien, une table sur laquelle il y a un verrou ca r
un process insert ou modifie des enregistrements, ne peut pas tre parcour u
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 v ue
>> 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 vu e,
> 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 ne ws:
>> 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 attentivemen t la
>>>> m moire
>>>> vive/cache

>>>>       Je ne sais pas ce qu'est l'isolation snapshot, je vais d onc me
>>>> renseign .

>>>>       Aujourd'hui, toutes les insertions mises jour se font su r 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 possibl e
>>> 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 de s
>>>> 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 e s.

>>> L'utilisation du niveau d'isolation snapshot (introduit en 2005) perm et
>>> 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 20 03
>>>>>> 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 e n
>>>>>> expiration de d lai, alors que la majorit ne font que des op ratio ns
>>>>>> 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 u n
>>>>>> 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 ?

>>>>> A+
>>>>> Serguei TARASSOV
>>>>> MCITP SQL Server Dev/DBA
>>>>>http://sgbd.arbinada.com" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">http://sgbd.arbinada.com

>>> --
>>> ?????? ???????
>>>www.arbinada.com
>>> 369985571

>>> A+
>>> Serguei TARASSOV
>>> MCITP SQL Server Dev/DBA
>>>http://sgbd.arbinada.com" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">http://sgbd.arbinada.com



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
Avatar
Serguei Tarassov
On 29/01/2010 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






Cela dépende du niveau d'isolement des transactions en cours
Voir une petite article avec des exemples
http://sgbd.arbinada.com/node/7" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">http://sgbd.arbinada.com/node/7

Apriori, l'introduction du niveau "snapshot" résoudre ce problème "ad hoc".

A+
Serguei TARASSOV
MCITP SQL Server Dev/DBA
http://sgbd.arbinada.com
Avatar
SQLpro
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-transact" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">http://sqlpro.developpez.com/isolation-transact ion/
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/" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">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 parco uru
> 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 possibl e,
> >> 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 verrouillag e de
> > plusieurs tables, il n'y a pas beaucoup de choses faire de mani re "a d
> > 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 attentivem ent 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 possi ble
> >>> qu'il manque des index et cela produit un "table scan" qui sera blo qu
> >>> par
> >>> les transactions tr s probablement.

> >>>>       Je demande cela car je pense que mes probl mes viennen t 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 fa it
> >>>> 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 fau t
> >>> toujours minimiser le temps de chaque transaction modifi e les donn es.

> >>> L'utilisation du niveau d'isolation snapshot (introduit en 2005) pe rmet
> >>> de
> >>> lire des donn es en tat consistant qui sont en train de modificatio n
> >>> 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 minute s 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 rat ions
> >>>>>> 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 mon t

> >>>>>> 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 es t
> >>>>>> 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 ?

> >>>>> A+
> >>>>> Serguei TARASSOV
> >>>>> MCITP SQL Server Dev/DBA
> >>>>>http://sgbd.arbinada.com" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">http://sgbd.arbinada.com

> >>> --
> >>> ?????? ???????
> >>>www.arbinada.com
> >>> 369985571

> >>> A+
> >>> Serguei TARASSOV
> >>> MCITP SQL Server Dev/DBA
> >>>http://sgbd.arbinada.com" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">http://sgbd.arbinada.com

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


1 2