Performance SQL Server 2000 base 21GO

-----Message d'origine-----
Juste une petite reflexion basée sur mon expérience:

Le fait de mettre NOLOCK sur certaines requetes SELECT

résultats pas si farfelu que ça.

Sur certains serveurs tres solicités, je gere toute la

des NOLOCK: car je me dis qu'une stat a un instant T

meme valeur 10s + tard.

J'ai ainsi récupéré pas mal de ressources, pour des

personne n'est venu me dire que c'était faux.

Le tout est de savoir, sur quelles requetes tu peux te

retourner une valeur non fiable.


Laurent.




"A.B." wrote in message
news:069701c35504$ac3ec1d0$
Salut!
Mon problème est le suivant:
Depuis que base a dépassé les 1,5 Go de données, les
performances se sont dégradés de façons vertigineuses!

Plus le volume devient important et plus les perfs se
dégradent alors que j'ai un bi-pro Xeon avec 4Go Ram
(2*1,5Ghz) Question disque dur pas de soucis.

Après quelques observations, j'ai remarqué que mon server
sql 2000 passe soon temps à demander des locks et
attendre!
Aucune activité disque ou très peu, les CPUs sont entre
10 et 20% d'utilisation.
Pas de problème d'interblocage ni quoi que ce soit
d'autres!
En fait, le problème vient des locks! SS2000 demande en
permanance des locks même quand il fait un select!
En se demande pourquoi?
Ce lockage en permanance provoque des ralentissement au
niveau de mon serveur et du réseau!!
Je sais qu'il y a moyen de désactivé ceci avec
l'instruction NOLOCK mais c'est dangereux car ça ramène
des données fantômes pour reprendre l'expressin de
MikeySoft et en plus que SS2000 fait du split
régulièrement je vous remets pas une couche sur les
perfs!!!! (J'ai placé le fillfactor à 70% et ensuite à 50
et 20! Rien pas de changemens notables!!!! ) !
On a la possiblité de passé par Le READPAST mais il ne me
ramène pas toutes mes données. Cette instruction permet
de ne ramener que les lignes non verrouillées! Et comme
SS2000 lock tout! (Selon MikeySoft SS2000 est
intelligent! Selon le cout des lockages SS2000 lock les
pages et non les lignes quand il y a beaucoup de lignes à
lockées!!! Merci MikeySoft!!! Et excellente stratégie!)
On a la possibilité de changé ça avec Sp_indexOption! ça
permet de lui spécifier le lock par Row et non par page!
Mais SS2000 choisit de lock une table aulieu d'une ligne!
Toujours la même stratégie de MickeySoft!!

- J'ai restructé ma base et transformé tout ça en groupe
de fichiers et fichiers ne dépassant pas 500Mo pour
profiter à fond du multithread (Je sais j'ai essayé
qu'avec un seul fichier mais j'ai des tables qui
atteignent les 6 Go et les 5 millions de Rows!!! C'est
pour ceux qui pourrait me parlait d'un goulot
d'etranglement! Non ce n'est pas ça qui fait attendre mon
serveur) avec des indexes avec un taux de remplissage à
50% il y a un petit net progrès mais mes locks sont
toujours là!
Mes indexes ne sont pas combinés! Car les indexes
combinées ça ralentit pas mal lors de

Non pour la proposition de passer à Oracle! pas pour
l'instant!!! mais j'y pense de plus en plus! ça fera du
dev en plus!!

Quelqu'un à trouver une solution à ce problème!
j'ai vu que sur le net bcp de personne rencontrait le
même problème que moi et il n'ya pas toujours de
solutions!!!

Les gars de Microsoft, serait-il possible de nous sortir
un patch assez rapidement concernant ce problème de lock!
quand la base est petite ce n'est pas perceptible mais
dès qu'elle dépasse les 1,5Go ça devient un enfer!!

* Pour locker les lignes lors d'un select?
* Pourquoi ne pas se contenter d'ignorer les lignes dont
les transactions ne sont pas encore COMMITTED et ramener
tout le reste en ignorant les locks au niveau Row/Page
(Update ou Split de page)?
* Si toutes fois vous, les gars de microsoft, vouliez
observer ce problème sur une base en prod qui augmente
sensiblement tout les mois, je serai ravi de vous
acceuillir sur Paris.
Je suis joingnable au pour plus
d'infos!!

Mais je crois que de faire deplacer les GI JOE serait du
Miracle!!!

Mais j'aimerais bien savoir comment il ont réussi à faire
fonctionner une base de 1 To alors que dès qu'on dépasse
les 1.5 Ghz les performances chutes!!
(Ne me dite pas les indexes car j'en ai très peu moins de
10 par tables En fait j'ai deux table qui contiennent 12
index et le reste c'est entre 1 et 5 Index par table!!!!)

Vous êtes sûre qu'à la place d'un T c'est pas un G!!!

Bref! Merci au challenger de chez MS ou d'ailleurs qui
pourraient se pencher sur la question!!!!

Alors MS?

Désolé d'avoir trop casser du sucre sur le dos des Dev de
SS2K.
Mais s'apercevoir que SS2K ne gère pas très bien les
locks et les VLDB au bout d'un an de dev! C'est

Mon appli et ma base ont 8 mois de vie et j'en suis déjà
à 21 GO (J'entends déjà des personnes me parlait
d'historisation! Non! Je ne peux même pas le faire! Je ne
peux historiser que les données de plus de 5 ans!!!)

Un grand merci à tout les gens qui pourrait avoir une
idée lumineuse que je n'ai pas testé!!!


AB
Béta Testeur SS2K












.

-----Message d'origine-----
Bonjour,

Comment as tu déterminer que SQL Server passait son

locks et à attendre. SQL Server ne demande pas ¨de locks

choisit de les poser, ce n'est pas lui qui attend ce

(spid), donc, un suivi de sysprocesses et syslockinfo

déterminer quel spid (ou connexion) bloque les autres,

qu'il exécute, si elle génère un ou des scan(s), quel

d'isolation (au cas où ce serait du serializable très

a pas de trigger dont l'exécution est de plus en plus

Cordialement,
LionelP


"A.B." wrote in message
news:069701c35504$ac3ec1d0$
Salut!
Mon problème est le suivant:
Depuis que base a dépassé les 1,5 Go de données, les
performances se sont dégradés de façons vertigineuses!

Plus le volume devient important et plus les perfs se
dégradent alors que j'ai un bi-pro Xeon avec 4Go Ram
(2*1,5Ghz) Question disque dur pas de soucis.

Après quelques observations, j'ai remarqué que mon server
sql 2000 passe soon temps à demander des locks et
attendre!
Aucune activité disque ou très peu, les CPUs sont entre
10 et 20% d'utilisation.
Pas de problème d'interblocage ni quoi que ce soit
d'autres!
En fait, le problème vient des locks! SS2000 demande en
permanance des locks même quand il fait un select!
En se demande pourquoi?
Ce lockage en permanance provoque des ralentissement au
niveau de mon serveur et du réseau!!
Je sais qu'il y a moyen de désactivé ceci avec
l'instruction NOLOCK mais c'est dangereux car ça ramène
des données fantômes pour reprendre l'expressin de
MikeySoft et en plus que SS2000 fait du split
régulièrement je vous remets pas une couche sur les
perfs!!!! (J'ai placé le fillfactor à 70% et ensuite à 50
et 20! Rien pas de changemens notables!!!! ) !
On a la possiblité de passé par Le READPAST mais il ne me
ramène pas toutes mes données. Cette instruction permet
de ne ramener que les lignes non verrouillées! Et comme
SS2000 lock tout! (Selon MikeySoft SS2000 est
intelligent! Selon le cout des lockages SS2000 lock les
pages et non les lignes quand il y a beaucoup de lignes à
lockées!!! Merci MikeySoft!!! Et excellente stratégie!)
On a la possibilité de changé ça avec Sp_indexOption! ça
permet de lui spécifier le lock par Row et non par page!
Mais SS2000 choisit de lock une table aulieu d'une ligne!
Toujours la même stratégie de MickeySoft!!

- J'ai restructé ma base et transformé tout ça en groupe
de fichiers et fichiers ne dépassant pas 500Mo pour
profiter à fond du multithread (Je sais j'ai essayé
qu'avec un seul fichier mais j'ai des tables qui
atteignent les 6 Go et les 5 millions de Rows!!! C'est
pour ceux qui pourrait me parlait d'un goulot
d'etranglement! Non ce n'est pas ça qui fait attendre mon
serveur) avec des indexes avec un taux de remplissage à
50% il y a un petit net progrès mais mes locks sont
toujours là!
Mes indexes ne sont pas combinés! Car les indexes
combinées ça ralentit pas mal lors de

Non pour la proposition de passer à Oracle! pas pour
l'instant!!! mais j'y pense de plus en plus! ça fera du
dev en plus!!

Quelqu'un à trouver une solution à ce problème!
j'ai vu que sur le net bcp de personne rencontrait le
même problème que moi et il n'ya pas toujours de
solutions!!!

Les gars de Microsoft, serait-il possible de nous sortir
un patch assez rapidement concernant ce problème de lock!
quand la base est petite ce n'est pas perceptible mais
dès qu'elle dépasse les 1,5Go ça devient un enfer!!

* Pour locker les lignes lors d'un select?
* Pourquoi ne pas se contenter d'ignorer les lignes dont
les transactions ne sont pas encore COMMITTED et ramener
tout le reste en ignorant les locks au niveau Row/Page
(Update ou Split de page)?
* Si toutes fois vous, les gars de microsoft, vouliez
observer ce problème sur une base en prod qui augmente
sensiblement tout les mois, je serai ravi de vous
acceuillir sur Paris.
Je suis joingnable au pour plus
d'infos!!

Mais je crois que de faire deplacer les GI JOE serait du
Miracle!!!

Mais j'aimerais bien savoir comment il ont réussi à faire
fonctionner une base de 1 To alors que dès qu'on dépasse
les 1.5 Ghz les performances chutes!!
(Ne me dite pas les indexes car j'en ai très peu moins de
10 par tables En fait j'ai deux table qui contiennent 12
index et le reste c'est entre 1 et 5 Index par table!!!!)

Vous êtes sûre qu'à la place d'un T c'est pas un G!!!

Bref! Merci au challenger de chez MS ou d'ailleurs qui
pourraient se pencher sur la question!!!!

Alors MS?

Désolé d'avoir trop casser du sucre sur le dos des Dev de
SS2K.
Mais s'apercevoir que SS2K ne gère pas très bien les
locks et les VLDB au bout d'un an de dev! C'est

Mon appli et ma base ont 8 mois de vie et j'en suis déjà
à 21 GO (J'entends déjà des personnes me parlait
d'historisation! Non! Je ne peux même pas le faire! Je ne
peux historiser que les données de plus de 5 ans!!!)

Un grand merci à tout les gens qui pourrait avoir une
idée lumineuse que je n'ai pas testé!!!


AB
Béta Testeur SS2K











.

-----Message d'origine-----
Bonjour,

Comment as tu déterminer que SQL Server passait son

locks et à attendre. SQL Server ne demande pas ¨de locks

choisit de les poser, ce n'est pas lui qui attend ce

(spid), donc, un suivi de sysprocesses et syslockinfo

déterminer quel spid (ou connexion) bloque les autres,

qu'il exécute, si elle génère un ou des scan(s), quel

d'isolation (au cas où ce serait du serializable très

a pas de trigger dont l'exécution est de plus en plus

Cordialement,
LionelP


"A.B." wrote in message
news:069701c35504$ac3ec1d0$
Salut!
Mon problème est le suivant:
Depuis que base a dépassé les 1,5 Go de données, les
performances se sont dégradés de façons vertigineuses!

Plus le volume devient important et plus les perfs se
dégradent alors que j'ai un bi-pro Xeon avec 4Go Ram
(2*1,5Ghz) Question disque dur pas de soucis.

Après quelques observations, j'ai remarqué que mon server
sql 2000 passe soon temps à demander des locks et
attendre!
Aucune activité disque ou très peu, les CPUs sont entre
10 et 20% d'utilisation.
Pas de problème d'interblocage ni quoi que ce soit
d'autres!
En fait, le problème vient des locks! SS2000 demande en
permanance des locks même quand il fait un select!
En se demande pourquoi?
Ce lockage en permanance provoque des ralentissement au
niveau de mon serveur et du réseau!!
Je sais qu'il y a moyen de désactivé ceci avec
l'instruction NOLOCK mais c'est dangereux car ça ramène
des données fantômes pour reprendre l'expressin de
MikeySoft et en plus que SS2000 fait du split
régulièrement je vous remets pas une couche sur les
perfs!!!! (J'ai placé le fillfactor à 70% et ensuite à 50
et 20! Rien pas de changemens notables!!!! ) !
On a la possiblité de passé par Le READPAST mais il ne me
ramène pas toutes mes données. Cette instruction permet
de ne ramener que les lignes non verrouillées! Et comme
SS2000 lock tout! (Selon MikeySoft SS2000 est
intelligent! Selon le cout des lockages SS2000 lock les
pages et non les lignes quand il y a beaucoup de lignes à
lockées!!! Merci MikeySoft!!! Et excellente stratégie!)
On a la possibilité de changé ça avec Sp_indexOption! ça
permet de lui spécifier le lock par Row et non par page!
Mais SS2000 choisit de lock une table aulieu d'une ligne!
Toujours la même stratégie de MickeySoft!!

- J'ai restructé ma base et transformé tout ça en groupe
de fichiers et fichiers ne dépassant pas 500Mo pour
profiter à fond du multithread (Je sais j'ai essayé
qu'avec un seul fichier mais j'ai des tables qui
atteignent les 6 Go et les 5 millions de Rows!!! C'est
pour ceux qui pourrait me parlait d'un goulot
d'etranglement! Non ce n'est pas ça qui fait attendre mon
serveur) avec des indexes avec un taux de remplissage à
50% il y a un petit net progrès mais mes locks sont
toujours là!
Mes indexes ne sont pas combinés! Car les indexes
combinées ça ralentit pas mal lors de

Non pour la proposition de passer à Oracle! pas pour
l'instant!!! mais j'y pense de plus en plus! ça fera du
dev en plus!!

Quelqu'un à trouver une solution à ce problème!
j'ai vu que sur le net bcp de personne rencontrait le
même problème que moi et il n'ya pas toujours de
solutions!!!

Les gars de Microsoft, serait-il possible de nous sortir
un patch assez rapidement concernant ce problème de lock!
quand la base est petite ce n'est pas perceptible mais
dès qu'elle dépasse les 1,5Go ça devient un enfer!!

* Pour locker les lignes lors d'un select?
* Pourquoi ne pas se contenter d'ignorer les lignes dont
les transactions ne sont pas encore COMMITTED et ramener
tout le reste en ignorant les locks au niveau Row/Page
(Update ou Split de page)?
* Si toutes fois vous, les gars de microsoft, vouliez
observer ce problème sur une base en prod qui augmente
sensiblement tout les mois, je serai ravi de vous
acceuillir sur Paris.
Je suis joingnable au pour plus
d'infos!!

Mais je crois que de faire deplacer les GI JOE serait du
Miracle!!!

Mais j'aimerais bien savoir comment il ont réussi à faire
fonctionner une base de 1 To alors que dès qu'on dépasse
les 1.5 Ghz les performances chutes!!
(Ne me dite pas les indexes car j'en ai très peu moins de
10 par tables En fait j'ai deux table qui contiennent 12
index et le reste c'est entre 1 et 5 Index par table!!!!)

Vous êtes sûre qu'à la place d'un T c'est pas un G!!!

Bref! Merci au challenger de chez MS ou d'ailleurs qui
pourraient se pencher sur la question!!!!

Alors MS?

Désolé d'avoir trop casser du sucre sur le dos des Dev de
SS2K.
Mais s'apercevoir que SS2K ne gère pas très bien les
locks et les VLDB au bout d'un an de dev! C'est

Mon appli et ma base ont 8 mois de vie et j'en suis déjà
à 21 GO (J'entends déjà des personnes me parlait
d'historisation! Non! Je ne peux même pas le faire! Je ne
peux historiser que les données de plus de 5 ans!!!)

Un grand merci à tout les gens qui pourrait avoir une
idée lumineuse que je n'ai pas testé!!!


AB
Béta Testeur SS2K











.

-----Message d'origine-----
Bonjour,

Donc si la requête toute seule est "lente", ce n'est pas

mais purement de temps d'exécution. Il faut arrêter de

locks et plutôt regarder à optimiser la requête. Et

comment ça marche ;).


Cordialement,
LionelP



"A.B." wrote in message
news:09a801c355a9$41f93170$
bonjour,
En utilisant les traces sur les locks on peut voir que
SS2K pour une requete select il demande bcp de lock!
il attend dans le sens ou tant qu'il n'a pas obtenu de
lock et comme il en demande bcp il fait attendre les
autres processus!
Pour chaque processus il demande des locks!
Je sais que SS2k choisit de poser les locks, en fait il
ne choisit pas il lock les lignes ou page ou table selon
la stratégie de MS! même quand c'est un select je trouve
ça lourd!
Je rajoute juste une précision, j'ai omis de vous dire
que j'avais récupéré la requête qui me prends le plus de
temps et je l'ai exécutée via l'analyseur de requete un
soir quand il n'y a plus personnes de connecter! Donc
plus de traffic réseaux, plus de connexions au serveur
NT5 ni à SS2k!
Résultat: aussi lent que si elle était exécuté via
l'appli VB!

Même avec personne de connecter, ça pose problème!

* Pour revenir au niveau de transaction! c'est le niveau
readcommitted celui par defaut de ss2k!
* je n'ai pas de trigger sur aucune de table je trouve ça
pénalisant quand on a une table depassant les 5Millions
de lignes!!

Merci à tous!
AB

-----Message d'origine-----
Bonjour,

Comment as tu déterminer que SQL Server passait son

temps à demander des

locks et à attendre. SQL Server ne demande pas ¨de locks

c'est lui qui

choisit de les poser, ce n'est pas lui qui attend ce

sont les connexions

(spid), donc, un suivi de sysprocesses et syslockinfo

permettra de

déterminer quel spid (ou connexion) bloque les autres,

récupérer la requête

qu'il exécute, si elle génère un ou des scan(s), quel

est le mode

d'isolation (au cas où ce serait du serializable très

pénalisant), s'il n'y

a pas de trigger dont l'exécution est de plus en plus

longue, ...

Cordialement,
LionelP


"A.B." wrote in message
news:069701c35504$ac3ec1d0$
Salut!
Mon problème est le suivant:
Depuis que base a dépassé les 1,5 Go de données, les
performances se sont dégradés de façons vertigineuses!

Plus le volume devient important et plus les perfs se
dégradent alors que j'ai un bi-pro Xeon avec 4Go Ram
(2*1,5Ghz) Question disque dur pas de soucis.

Après quelques observations, j'ai remarqué que mon

sql 2000 passe soon temps à demander des locks et
attendre!
Aucune activité disque ou très peu, les CPUs sont entre
10 et 20% d'utilisation.
Pas de problème d'interblocage ni quoi que ce soit
d'autres!
En fait, le problème vient des locks! SS2000 demande en
permanance des locks même quand il fait un select!
En se demande pourquoi?
Ce lockage en permanance provoque des ralentissement au
niveau de mon serveur et du réseau!!
Je sais qu'il y a moyen de désactivé ceci avec
l'instruction NOLOCK mais c'est dangereux car ça ramène
des données fantômes pour reprendre l'expressin de
MikeySoft et en plus que SS2000 fait du split
régulièrement je vous remets pas une couche sur les
perfs!!!! (J'ai placé le fillfactor à 70% et ensuite à

et 20! Rien pas de changemens notables!!!! ) !
On a la possiblité de passé par Le READPAST mais il ne

ramène pas toutes mes données. Cette instruction permet
de ne ramener que les lignes non verrouillées! Et comme
SS2000 lock tout! (Selon MikeySoft SS2000 est
intelligent! Selon le cout des lockages SS2000 lock les
pages et non les lignes quand il y a beaucoup de lignes

lockées!!! Merci MikeySoft!!! Et excellente stratégie!)
On a la possibilité de changé ça avec Sp_indexOption! ça
permet de lui spécifier le lock par Row et non par page!
Mais SS2000 choisit de lock une table aulieu d'une

Toujours la même stratégie de MickeySoft!!

- J'ai restructé ma base et transformé tout ça en groupe
de fichiers et fichiers ne dépassant pas 500Mo pour
profiter à fond du multithread (Je sais j'ai essayé
qu'avec un seul fichier mais j'ai des tables qui
atteignent les 6 Go et les 5 millions de Rows!!! C'est
pour ceux qui pourrait me parlait d'un goulot
d'etranglement! Non ce n'est pas ça qui fait attendre

serveur) avec des indexes avec un taux de remplissage à
50% il y a un petit net progrès mais mes locks sont
toujours là!
Mes indexes ne sont pas combinés! Car les indexes
combinées ça ralentit pas mal lors de

l'insert/Update!!!!!

Non pour la proposition de passer à Oracle! pas pour
l'instant!!! mais j'y pense de plus en plus! ça fera du
dev en plus!!

Quelqu'un à trouver une solution à ce problème!
j'ai vu que sur le net bcp de personne rencontrait le
même problème que moi et il n'ya pas toujours de
solutions!!!

Les gars de Microsoft, serait-il possible de nous sortir
un patch assez rapidement concernant ce problème de

quand la base est petite ce n'est pas perceptible mais
dès qu'elle dépasse les 1,5Go ça devient un enfer!!

* Pour locker les lignes lors d'un select?
* Pourquoi ne pas se contenter d'ignorer les lignes dont
les transactions ne sont pas encore COMMITTED et ramener
tout le reste en ignorant les locks au niveau Row/Page
(Update ou Split de page)?
* Si toutes fois vous, les gars de microsoft, vouliez
observer ce problème sur une base en prod qui augmente
sensiblement tout les mois, je serai ravi de vous
acceuillir sur Paris.
Je suis joingnable au pour plus
d'infos!!

Mais je crois que de faire deplacer les GI JOE serait du
Miracle!!!

Mais j'aimerais bien savoir comment il ont réussi à

fonctionner une base de 1 To alors que dès qu'on dépasse
les 1.5 Ghz les performances chutes!!
(Ne me dite pas les indexes car j'en ai très peu moins

10 par tables En fait j'ai deux table qui contiennent 12
index et le reste c'est entre 1 et 5 Index par

Vous êtes sûre qu'à la place d'un T c'est pas un G!!!

Bref! Merci au challenger de chez MS ou d'ailleurs qui
pourraient se pencher sur la question!!!!

Alors MS?

Désolé d'avoir trop casser du sucre sur le dos des Dev

SS2K.
Mais s'apercevoir que SS2K ne gère pas très bien les
locks et les VLDB au bout d'un an de dev! C'est

frustrant!

Mon appli et ma base ont 8 mois de vie et j'en suis déjà
à 21 GO (J'entends déjà des personnes me parlait
d'historisation! Non! Je ne peux même pas le faire! Je

peux historiser que les données de plus de 5 ans!!!)

Un grand merci à tout les gens qui pourrait avoir une
idée lumineuse que je n'ai pas testé!!!


AB
Béta Testeur SS2K











.

.

-----Message d'origine-----
Bonjour,

Donc si la requête toute seule est "lente", ce n'est pas

mais purement de temps d'exécution. Il faut arrêter de

locks et plutôt regarder à optimiser la requête. Et

comment ça marche ;).


Cordialement,
LionelP



"A.B." wrote in message
news:09a801c355a9$41f93170$
bonjour,
En utilisant les traces sur les locks on peut voir que
SS2K pour une requete select il demande bcp de lock!
il attend dans le sens ou tant qu'il n'a pas obtenu de
lock et comme il en demande bcp il fait attendre les
autres processus!
Pour chaque processus il demande des locks!
Je sais que SS2k choisit de poser les locks, en fait il
ne choisit pas il lock les lignes ou page ou table selon
la stratégie de MS! même quand c'est un select je trouve
ça lourd!
Je rajoute juste une précision, j'ai omis de vous dire
que j'avais récupéré la requête qui me prends le plus de
temps et je l'ai exécutée via l'analyseur de requete un
soir quand il n'y a plus personnes de connecter! Donc
plus de traffic réseaux, plus de connexions au serveur
NT5 ni à SS2k!
Résultat: aussi lent que si elle était exécuté via
l'appli VB!

Même avec personne de connecter, ça pose problème!

* Pour revenir au niveau de transaction! c'est le niveau
readcommitted celui par defaut de ss2k!
* je n'ai pas de trigger sur aucune de table je trouve ça
pénalisant quand on a une table depassant les 5Millions
de lignes!!

Merci à tous!
AB

-----Message d'origine-----
Bonjour,

Comment as tu déterminer que SQL Server passait son

temps à demander des

locks et à attendre. SQL Server ne demande pas ¨de locks

c'est lui qui

choisit de les poser, ce n'est pas lui qui attend ce

sont les connexions

(spid), donc, un suivi de sysprocesses et syslockinfo

permettra de

déterminer quel spid (ou connexion) bloque les autres,

récupérer la requête

qu'il exécute, si elle génère un ou des scan(s), quel

est le mode

d'isolation (au cas où ce serait du serializable très

pénalisant), s'il n'y

a pas de trigger dont l'exécution est de plus en plus

longue, ...

Cordialement,
LionelP


"A.B." wrote in message
news:069701c35504$ac3ec1d0$
Salut!
Mon problème est le suivant:
Depuis que base a dépassé les 1,5 Go de données, les
performances se sont dégradés de façons vertigineuses!

Plus le volume devient important et plus les perfs se
dégradent alors que j'ai un bi-pro Xeon avec 4Go Ram
(2*1,5Ghz) Question disque dur pas de soucis.

Après quelques observations, j'ai remarqué que mon

sql 2000 passe soon temps à demander des locks et
attendre!
Aucune activité disque ou très peu, les CPUs sont entre
10 et 20% d'utilisation.
Pas de problème d'interblocage ni quoi que ce soit
d'autres!
En fait, le problème vient des locks! SS2000 demande en
permanance des locks même quand il fait un select!
En se demande pourquoi?
Ce lockage en permanance provoque des ralentissement au
niveau de mon serveur et du réseau!!
Je sais qu'il y a moyen de désactivé ceci avec
l'instruction NOLOCK mais c'est dangereux car ça ramène
des données fantômes pour reprendre l'expressin de
MikeySoft et en plus que SS2000 fait du split
régulièrement je vous remets pas une couche sur les
perfs!!!! (J'ai placé le fillfactor à 70% et ensuite à

et 20! Rien pas de changemens notables!!!! ) !
On a la possiblité de passé par Le READPAST mais il ne

ramène pas toutes mes données. Cette instruction permet
de ne ramener que les lignes non verrouillées! Et comme
SS2000 lock tout! (Selon MikeySoft SS2000 est
intelligent! Selon le cout des lockages SS2000 lock les
pages et non les lignes quand il y a beaucoup de lignes

lockées!!! Merci MikeySoft!!! Et excellente stratégie!)
On a la possibilité de changé ça avec Sp_indexOption! ça
permet de lui spécifier le lock par Row et non par page!
Mais SS2000 choisit de lock une table aulieu d'une

Toujours la même stratégie de MickeySoft!!

- J'ai restructé ma base et transformé tout ça en groupe
de fichiers et fichiers ne dépassant pas 500Mo pour
profiter à fond du multithread (Je sais j'ai essayé
qu'avec un seul fichier mais j'ai des tables qui
atteignent les 6 Go et les 5 millions de Rows!!! C'est
pour ceux qui pourrait me parlait d'un goulot
d'etranglement! Non ce n'est pas ça qui fait attendre

serveur) avec des indexes avec un taux de remplissage à
50% il y a un petit net progrès mais mes locks sont
toujours là!
Mes indexes ne sont pas combinés! Car les indexes
combinées ça ralentit pas mal lors de

l'insert/Update!!!!!

Non pour la proposition de passer à Oracle! pas pour
l'instant!!! mais j'y pense de plus en plus! ça fera du
dev en plus!!

Quelqu'un à trouver une solution à ce problème!
j'ai vu que sur le net bcp de personne rencontrait le
même problème que moi et il n'ya pas toujours de
solutions!!!

Les gars de Microsoft, serait-il possible de nous sortir
un patch assez rapidement concernant ce problème de

quand la base est petite ce n'est pas perceptible mais
dès qu'elle dépasse les 1,5Go ça devient un enfer!!

* Pour locker les lignes lors d'un select?
* Pourquoi ne pas se contenter d'ignorer les lignes dont
les transactions ne sont pas encore COMMITTED et ramener
tout le reste en ignorant les locks au niveau Row/Page
(Update ou Split de page)?
* Si toutes fois vous, les gars de microsoft, vouliez
observer ce problème sur une base en prod qui augmente
sensiblement tout les mois, je serai ravi de vous
acceuillir sur Paris.
Je suis joingnable au pour plus
d'infos!!

Mais je crois que de faire deplacer les GI JOE serait du
Miracle!!!

Mais j'aimerais bien savoir comment il ont réussi à

fonctionner une base de 1 To alors que dès qu'on dépasse
les 1.5 Ghz les performances chutes!!
(Ne me dite pas les indexes car j'en ai très peu moins

10 par tables En fait j'ai deux table qui contiennent 12
index et le reste c'est entre 1 et 5 Index par

Vous êtes sûre qu'à la place d'un T c'est pas un G!!!

Bref! Merci au challenger de chez MS ou d'ailleurs qui
pourraient se pencher sur la question!!!!

Alors MS?

Désolé d'avoir trop casser du sucre sur le dos des Dev

SS2K.
Mais s'apercevoir que SS2K ne gère pas très bien les
locks et les VLDB au bout d'un an de dev! C'est

frustrant!

Mon appli et ma base ont 8 mois de vie et j'en suis déjà
à 21 GO (J'entends déjà des personnes me parlait
d'historisation! Non! Je ne peux même pas le faire! Je

peux historiser que les données de plus de 5 ans!!!)

Un grand merci à tout les gens qui pourrait avoir une
idée lumineuse que je n'ai pas testé!!!


AB
Béta Testeur SS2K











.

.

-----Message d'origine-----
Bonjour,

Donc si la requête toute seule est "lente", ce n'est pas

mais purement de temps d'exécution. Il faut arrêter de

locks et plutôt regarder à optimiser la requête. Et

comment ça marche ;).


Cordialement,
LionelP



"A.B." wrote in message
news:09a801c355a9$41f93170$
bonjour,
En utilisant les traces sur les locks on peut voir que
SS2K pour une requete select il demande bcp de lock!
il attend dans le sens ou tant qu'il n'a pas obtenu de
lock et comme il en demande bcp il fait attendre les
autres processus!
Pour chaque processus il demande des locks!
Je sais que SS2k choisit de poser les locks, en fait il
ne choisit pas il lock les lignes ou page ou table selon
la stratégie de MS! même quand c'est un select je trouve
ça lourd!
Je rajoute juste une précision, j'ai omis de vous dire
que j'avais récupéré la requête qui me prends le plus de
temps et je l'ai exécutée via l'analyseur de requete un
soir quand il n'y a plus personnes de connecter! Donc
plus de traffic réseaux, plus de connexions au serveur
NT5 ni à SS2k!
Résultat: aussi lent que si elle était exécuté via
l'appli VB!

Même avec personne de connecter, ça pose problème!

* Pour revenir au niveau de transaction! c'est le niveau
readcommitted celui par defaut de ss2k!
* je n'ai pas de trigger sur aucune de table je trouve ça
pénalisant quand on a une table depassant les 5Millions
de lignes!!

Merci à tous!
AB

-----Message d'origine-----
Bonjour,

Comment as tu déterminer que SQL Server passait son

temps à demander des

locks et à attendre. SQL Server ne demande pas ¨de locks

c'est lui qui

choisit de les poser, ce n'est pas lui qui attend ce

sont les connexions

(spid), donc, un suivi de sysprocesses et syslockinfo

permettra de

déterminer quel spid (ou connexion) bloque les autres,

récupérer la requête

qu'il exécute, si elle génère un ou des scan(s), quel

est le mode

d'isolation (au cas où ce serait du serializable très

pénalisant), s'il n'y

a pas de trigger dont l'exécution est de plus en plus

longue, ...

Cordialement,
LionelP


"A.B." wrote in message
news:069701c35504$ac3ec1d0$
Salut!
Mon problème est le suivant:
Depuis que base a dépassé les 1,5 Go de données, les
performances se sont dégradés de façons vertigineuses!

Plus le volume devient important et plus les perfs se
dégradent alors que j'ai un bi-pro Xeon avec 4Go Ram
(2*1,5Ghz) Question disque dur pas de soucis.

Après quelques observations, j'ai remarqué que mon

sql 2000 passe soon temps à demander des locks et
attendre!
Aucune activité disque ou très peu, les CPUs sont entre
10 et 20% d'utilisation.
Pas de problème d'interblocage ni quoi que ce soit
d'autres!
En fait, le problème vient des locks! SS2000 demande en
permanance des locks même quand il fait un select!
En se demande pourquoi?
Ce lockage en permanance provoque des ralentissement au
niveau de mon serveur et du réseau!!
Je sais qu'il y a moyen de désactivé ceci avec
l'instruction NOLOCK mais c'est dangereux car ça ramène
des données fantômes pour reprendre l'expressin de
MikeySoft et en plus que SS2000 fait du split
régulièrement je vous remets pas une couche sur les
perfs!!!! (J'ai placé le fillfactor à 70% et ensuite à

et 20! Rien pas de changemens notables!!!! ) !
On a la possiblité de passé par Le READPAST mais il ne

ramène pas toutes mes données. Cette instruction permet
de ne ramener que les lignes non verrouillées! Et comme
SS2000 lock tout! (Selon MikeySoft SS2000 est
intelligent! Selon le cout des lockages SS2000 lock les
pages et non les lignes quand il y a beaucoup de lignes

lockées!!! Merci MikeySoft!!! Et excellente stratégie!)
On a la possibilité de changé ça avec Sp_indexOption! ça
permet de lui spécifier le lock par Row et non par page!
Mais SS2000 choisit de lock une table aulieu d'une

Toujours la même stratégie de MickeySoft!!

- J'ai restructé ma base et transformé tout ça en groupe
de fichiers et fichiers ne dépassant pas 500Mo pour
profiter à fond du multithread (Je sais j'ai essayé
qu'avec un seul fichier mais j'ai des tables qui
atteignent les 6 Go et les 5 millions de Rows!!! C'est
pour ceux qui pourrait me parlait d'un goulot
d'etranglement! Non ce n'est pas ça qui fait attendre

serveur) avec des indexes avec un taux de remplissage à
50% il y a un petit net progrès mais mes locks sont
toujours là!
Mes indexes ne sont pas combinés! Car les indexes
combinées ça ralentit pas mal lors de

l'insert/Update!!!!!

Non pour la proposition de passer à Oracle! pas pour
l'instant!!! mais j'y pense de plus en plus! ça fera du
dev en plus!!

Quelqu'un à trouver une solution à ce problème!
j'ai vu que sur le net bcp de personne rencontrait le
même problème que moi et il n'ya pas toujours de
solutions!!!

Les gars de Microsoft, serait-il possible de nous sortir
un patch assez rapidement concernant ce problème de

quand la base est petite ce n'est pas perceptible mais
dès qu'elle dépasse les 1,5Go ça devient un enfer!!

* Pour locker les lignes lors d'un select?
* Pourquoi ne pas se contenter d'ignorer les lignes dont
les transactions ne sont pas encore COMMITTED et ramener
tout le reste en ignorant les locks au niveau Row/Page
(Update ou Split de page)?
* Si toutes fois vous, les gars de microsoft, vouliez
observer ce problème sur une base en prod qui augmente
sensiblement tout les mois, je serai ravi de vous
acceuillir sur Paris.
Je suis joingnable au pour plus
d'infos!!

Mais je crois que de faire deplacer les GI JOE serait du
Miracle!!!

Mais j'aimerais bien savoir comment il ont réussi à

fonctionner une base de 1 To alors que dès qu'on dépasse
les 1.5 Ghz les performances chutes!!
(Ne me dite pas les indexes car j'en ai très peu moins

10 par tables En fait j'ai deux table qui contiennent 12
index et le reste c'est entre 1 et 5 Index par

Vous êtes sûre qu'à la place d'un T c'est pas un G!!!

Bref! Merci au challenger de chez MS ou d'ailleurs qui
pourraient se pencher sur la question!!!!

Alors MS?

Désolé d'avoir trop casser du sucre sur le dos des Dev

SS2K.
Mais s'apercevoir que SS2K ne gère pas très bien les
locks et les VLDB au bout d'un an de dev! C'est

frustrant!

Mon appli et ma base ont 8 mois de vie et j'en suis déjà
à 21 GO (J'entends déjà des personnes me parlait
d'historisation! Non! Je ne peux même pas le faire! Je

peux historiser que les données de plus de 5 ans!!!)

Un grand merci à tout les gens qui pourrait avoir une
idée lumineuse que je n'ai pas testé!!!


AB
Béta Testeur SS2K











.

.

-----Message d'origine-----
Bonjour,

jointures externes ==> table scan, le volume parcourru

miracle
insert qui dure des dizaines de secondes (insert d'une

développer) ==>table fragmentée?==>pas d'index cluster?
il faut des index cluster

ce que je ferai:
S'il y a des stats auto sur les tables, les supprimer

set statistics io on
go
exec du select
==> voir s'il y a des lectures logiques et physiques,

là où il y a bcp d'IO

set showplan_all on
go
exec select
==> cardinalitées et coûts estimés

set statistics profile on
go
exec select
==> cardinalmitées et coûts réels

Tu peux alors comparer avec l'estimation pour voirsi les

obsolètes, ou si certaines estimations sont fausses.


la jointure je la réécrierais comme ça pour plus de

avoir une joiture externe du mauvais côté) et plus juste:
R_DIFFUSEUR DI
INNER JOIN D_SEQUENCE_DIFFUSION SQ
ON DI.pk_Id_Diffuseur = SQ.fk_Id_Diffuseur

INNER JOIN D_OEUVRE OE
ON SQ.fk_oeuvre_diffuseur = OE.pk_oeuvre

INNER JOIN D_TITRE TI
ON SQ.fk_Index_titre = TI.pk_Index_Titre

RIGHT OUTER JOIN L_AYANT_DROIT LAD
ON LAD.pk_oeuvre = OE.pk_oeuvre

INNER JOIN D_AYANT_DROIT AD
ON LAD.pk_ayant_droit = AD.pk_ayant_droit

LEFT OUTER JOIN D_AYANT_DROIT_DOUBLEUR AYDD
ON AYDD.pk_ayant_droit_doubleur = AD.pk_ayant_droit


Cordialement,
LionelP



"A.B." wrote in message
news:0a4401c35678$0c5299b0$
Bonjour,
tout d'abord! Merci de me répondre.
C'est l'exécutiond ela requête qui est lente du aux
problèmes que j'exposais!
La requte on ne peut l'optimiser à moins de denormaliser!
Il y a 7 tables dans ma requete, Dont 4 volumineuses.
une table de reference des diffuseurs DI = 350
une table des sequence de diffusions SQ = 5531441
Une des oeuvres OE= 6816776
une des titres TI= 6714485
une des doubleurs AYDD= 0
une des ayant droits AD= 8974815
et pour finir la liste des ayant droit pour une oeuvre
LAD = 8974809
voila ma jointure sans les with(nolock) et sans les
with index ()
********************************************************
R_DIFFUSEUR DI
INNER JOIN D_SEQUENCE_DIFFUSION SQ
INNER JOIN D_OEUVRE OE ON SQ.fk_oeuvre_diffuseur =
OE.pk_oeuvre
INNER JOIN D_TITRE TI
ON SQ.fk_Index_titre = TI.pk_Index_Titre ON
DI.pk_Id_Diffuseur = SQ.fk_Id_Diffuseur
LEFT OUTER JOIN
D_AYANT_DROIT_DOUBLEUR AYDD RIGHT OUTER JOIN
D_AYANT_DROIT AD INNER JOIN
L_AYANT_DROIT LAD ON AD.pk_ayant_droit =
LAD.pk_ayant_droit
ON AYDD.pk_ayant_droit_doubleur = AD.pk_ayant_droit ON
OE.pk_oeuvre = LAD.pk_oeuvre!
********************************************************

J'ai des problèmes de lenteurs même quand je fais un
pauvre insert dans ces tables!
ça peut aller de 30s à 2 voire 5 min.
J'ai pensé aux index mais je ne peux pas les supprimer
j'en ai besion!
On a d'un côté une oeuvre (D_OEUVRE)qui peut avoir 1 à X
titres (D_TITRE)
Chaque oeuvre appartient de 1 à Y auteurs (L_AYANT_DROIT
et D_AYANT_DROIT) il peut y avoir des doubleur mais cette
table pour l'instant est vide. Normalement elle ne
contient que le numéro de l'ayant droit de la table
D_AYANT_DROIT si doubleur il y a(L_AYANT_DROIT_DOUBLEUR).
cette oeuvre est diffusés sur une chaine exemple (France
2 (R_DIFFUSEUR)) et ceci constitue une diffusion à une
date présice et une heure précise. On appelle ça une
sequence de diffusion (D_SEQUENCE_DIFFUSION).
Image les chaines Hertziennes + cables+ satellites+
radios...
ça en fait du volume à traiter!
poue revenir à ma requete!
les utilisateurs font un filtre sur une période date et
sur un diffuseur! (Exemple Diffuseur FRANCE 2 periode
01/01/2002 à 15/01/2002! qui ramenent un milliers de
lignes! (En moyenne 3 à 4 milles lignes)!!

le volume à recupérer n'est pas enorme!
Si tu as ou vous avez des pistes d'optimisations je suis
preneurs!!

Merci d'avance!
AB

-----Message d'origine-----
Bonjour,

Donc si la requête toute seule est "lente", ce n'est pas

un problème de lock

mais purement de temps d'exécution. Il faut arrêter de

se focaliser sur les

locks et plutôt regarder à optimiser la requête. Et

merci de m'expliquer

comment ça marche ;).


Cordialement,
LionelP



"A.B." wrote in message
news:09a801c355a9$41f93170$
bonjour,
En utilisant les traces sur les locks on peut voir que
SS2K pour une requete select il demande bcp de lock!
il attend dans le sens ou tant qu'il n'a pas obtenu de
lock et comme il en demande bcp il fait attendre les
autres processus!
Pour chaque processus il demande des locks!
Je sais que SS2k choisit de poser les locks, en fait il
ne choisit pas il lock les lignes ou page ou table selon
la stratégie de MS! même quand c'est un select je trouve
ça lourd!
Je rajoute juste une précision, j'ai omis de vous dire
que j'avais récupéré la requête qui me prends le plus de
temps et je l'ai exécutée via l'analyseur de requete un
soir quand il n'y a plus personnes de connecter! Donc
plus de traffic réseaux, plus de connexions au serveur
NT5 ni à SS2k!
Résultat: aussi lent que si elle était exécuté via
l'appli VB!

Même avec personne de connecter, ça pose problème!

* Pour revenir au niveau de transaction! c'est le niveau
readcommitted celui par defaut de ss2k!
* je n'ai pas de trigger sur aucune de table je trouve

pénalisant quand on a une table depassant les 5Millions
de lignes!!

Merci à tous!
AB

-----Message d'origine-----
Bonjour,

Comment as tu déterminer que SQL Server passait son

temps à demander des

locks et à attendre. SQL Server ne demande pas ¨de

c'est lui qui

choisit de les poser, ce n'est pas lui qui attend ce

sont les connexions

(spid), donc, un suivi de sysprocesses et syslockinfo

permettra de

déterminer quel spid (ou connexion) bloque les autres,

récupérer la requête

qu'il exécute, si elle génère un ou des scan(s), quel

est le mode

d'isolation (au cas où ce serait du serializable très

pénalisant), s'il n'y

a pas de trigger dont l'exécution est de plus en plus

longue, ...

Cordialement,
LionelP


"A.B." wrote in message
news:069701c35504$ac3ec1d0$
Salut!
Mon problème est le suivant:
Depuis que base a dépassé les 1,5 Go de données, les
performances se sont dégradés de façons vertigineuses!

Plus le volume devient important et plus les perfs se
dégradent alors que j'ai un bi-pro Xeon avec 4Go Ram
(2*1,5Ghz) Question disque dur pas de soucis.

Après quelques observations, j'ai remarqué que mon

server

sql 2000 passe soon temps à demander des locks et
attendre!
Aucune activité disque ou très peu, les CPUs sont entre
10 et 20% d'utilisation.
Pas de problème d'interblocage ni quoi que ce soit
d'autres!
En fait, le problème vient des locks! SS2000 demande en
permanance des locks même quand il fait un select!
En se demande pourquoi?
Ce lockage en permanance provoque des ralentissement au
niveau de mon serveur et du réseau!!
Je sais qu'il y a moyen de désactivé ceci avec
l'instruction NOLOCK mais c'est dangereux car ça ramène
des données fantômes pour reprendre l'expressin de
MikeySoft et en plus que SS2000 fait du split
régulièrement je vous remets pas une couche sur les
perfs!!!! (J'ai placé le fillfactor à 70% et ensuite à

50

et 20! Rien pas de changemens notables!!!! ) !
On a la possiblité de passé par Le READPAST mais il ne

me

ramène pas toutes mes données. Cette instruction permet
de ne ramener que les lignes non verrouillées! Et comme
SS2000 lock tout! (Selon MikeySoft SS2000 est
intelligent! Selon le cout des lockages SS2000 lock les
pages et non les lignes quand il y a beaucoup de lignes

à

lockées!!! Merci MikeySoft!!! Et excellente stratégie!)
On a la possibilité de changé ça avec Sp_indexOption!

permet de lui spécifier le lock par Row et non par

Mais SS2000 choisit de lock une table aulieu d'une

ligne!

Toujours la même stratégie de MickeySoft!!

- J'ai restructé ma base et transformé tout ça en

de fichiers et fichiers ne dépassant pas 500Mo pour
profiter à fond du multithread (Je sais j'ai essayé
qu'avec un seul fichier mais j'ai des tables qui
atteignent les 6 Go et les 5 millions de Rows!!! C'est
pour ceux qui pourrait me parlait d'un goulot
d'etranglement! Non ce n'est pas ça qui fait attendre

mon

serveur) avec des indexes avec un taux de remplissage à
50% il y a un petit net progrès mais mes locks sont
toujours là!
Mes indexes ne sont pas combinés! Car les indexes
combinées ça ralentit pas mal lors de

l'insert/Update!!!!!

Non pour la proposition de passer à Oracle! pas pour
l'instant!!! mais j'y pense de plus en plus! ça fera du
dev en plus!!

Quelqu'un à trouver une solution à ce problème!
j'ai vu que sur le net bcp de personne rencontrait le
même problème que moi et il n'ya pas toujours de
solutions!!!

Les gars de Microsoft, serait-il possible de nous

un patch assez rapidement concernant ce problème de

lock!

quand la base est petite ce n'est pas perceptible mais
dès qu'elle dépasse les 1,5Go ça devient un enfer!!

* Pour locker les lignes lors d'un select?
* Pourquoi ne pas se contenter d'ignorer les lignes

les transactions ne sont pas encore COMMITTED et

tout le reste en ignorant les locks au niveau Row/Page
(Update ou Split de page)?
* Si toutes fois vous, les gars de microsoft, vouliez
observer ce problème sur une base en prod qui augmente
sensiblement tout les mois, je serai ravi de vous
acceuillir sur Paris.
Je suis joingnable au pour plus
d'infos!!

Mais je crois que de faire deplacer les GI JOE serait