Problème performances SQL Serveur

Bonjour,

combien de temps pour une connection via isqlw?
combien de temps pour l'exécution sp_MShasdbaccess via isqlw?
combien de mémoire physique dispo (task manager->performance->physical
memory available) reste-t-il?

Cordialement,
LionelP
PS: isqlw : analyseur de requête
"Armand Frigo" wrote:

Bonjour,
J'ai l'impression d'avoir tout essayé mais rien ne résoud mon problème de
performances serveur.
Les performances des bases de données en prod sont normales (heureusement!),
mon problème vient du temps d'exécution de procédures stockées système
telles
que Master.dbo.sp_MShasdbaccess. Cette dernière met 7 secondes à retourner
son résultat alors que sur les autres serveurs SQL (sur d'autres machines
pourtant moins performantes et beaucoup plus chargées (exemple 60 BDD pour
4Go de données) ont un temps de réponse inférieur à 1 seconde.) J'ai des
temps d'attente aussi hallucinants lorsque je veux éditer les propriétés
d'un utilisateur (190s) ou faire quelque modif sur des données de management
du serveur. Et pendant ces requêtes, les accès disques sont importants
(recherche d'index d'après le suiveur de perfs systèmes windows), et
Enterprise manager ne répond plus. Ces temps sont aussi valables sur
d'autres postes, quelle que soit la charge du serveur.
Le serveur est installé sur un bi-processeurs P3 700Mhz avec 512Mo RAM. Il
héberge une douzaine de BDD dont 1 seule en PROD qui fait 70 Mo. Au total il
doit y avoir 800Mo de BDD sur ce serveur, donc rien de bien méchant et il
n'y a pas plus de 15 utilisateurs conectés en simultané.
J'ai déjà utilisé les wizard de tuning sur toutes les bases. J'ai recyclé
les logs du serveur. Les tailles des BDD Master et Msdb sont raisonnables...
Quelqu'un a-t-il une idée de ce qui pourrait rendre ces procédures si
longues?

Merci d'avance
Armand Frigo

depuis quel outil lance tu sp_MShasdbaccess et coetera ?
En particulier s'agit-il d'une exécution via Query Analyser ou Entreprise
Manager sur le PC qui exploite la base ?

Si tel est le cas, ce peut être parfaitement normal !

A +

Armand Frigo a écrit:

Bonjour,
J'ai l'impression d'avoir tout essayé mais rien ne résoud mon problème de
performances serveur.
Les performances des bases de données en prod sont normales (heureusement!),
mon problème vient du temps d'exécution de procédures stockées système
telles
que Master.dbo.sp_MShasdbaccess. Cette dernière met 7 secondes à retourner
son résultat alors que sur les autres serveurs SQL (sur d'autres machines
pourtant moins performantes et beaucoup plus chargées (exemple 60 BDD pour
4Go de données) ont un temps de réponse inférieur à 1 seconde.) J'ai des
temps d'attente aussi hallucinants lorsque je veux éditer les propriétés
d'un utilisateur (190s) ou faire quelque modif sur des données de management
du serveur. Et pendant ces requêtes, les accès disques sont importants
(recherche d'index d'après le suiveur de perfs systèmes windows), et
Enterprise manager ne répond plus. Ces temps sont aussi valables sur
d'autres postes, quelle que soit la charge du serveur.
Le serveur est installé sur un bi-processeurs P3 700Mhz avec 512Mo RAM. Il
héberge une douzaine de BDD dont 1 seule en PROD qui fait 70 Mo. Au total il
doit y avoir 800Mo de BDD sur ce serveur, donc rien de bien méchant et il
n'y a pas plus de 15 utilisateurs conectés en simultané.
J'ai déjà utilisé les wizard de tuning sur toutes les bases. J'ai recyclé
les logs du serveur. Les tailles des BDD Master et Msdb sont raisonnables...
Quelqu'un a-t-il une idée de ce qui pourrait rendre ces procédures si
longues?

Merci d'avance
Armand Frigo

--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************

tout à fait normal : SQL Server est conçu pour utiliser TOUTE LA MEMOIRE du
serveur et par conséquent il ne laisse RIEN aux autres applications.

Extrait d'un ouvrage en préparation :

"
Un SGBDR ne fonctionne correctement que sur une machine qui lui est dédiée et
sur laquelle il est le seul programme à travailler en continu. Tout autre
solution d'exploitation est à proscrire.

Toute installation de logiciel supplémentaire en fonctionnement permanent
(serveur de messagerie, serveur de page web, serveur d'objet...) dégrade
sensiblement les performances d'un SGBDR.
[...]
De plus, les SGBDR étant les programmes les plus consommateurs de ressources,
ils sont programmés pour consommer si le besoin s'en fait sentir, toutes les
ressources dont ils ont besoin, sauf limitation expresse en provenance de l'OS.

En particulier SQL Server est un serveur orienté "serveur d'application" est
n'est donc pas franchement compatible avec un serveur orienté "serveur de
fichiers" comme c'est le cas de IIS / ASP.
De plus SQL Server est paramétré pour prendre toute les ressources de mémoire
vive (RAM) sans se préoccuper des autres applications. Seul l'OS peut lui
demander de restituer de la mémoire vive. On parle alors de "stress" du système.
On peut néanmoins limiter la mémoire utilisable par SQL Server.
sp_configure, max server memory (MB)
"

Il est donc logique que Query Analyser et Entreprise Manager qui sont des
applications clientes deviennent très lentes si elles sont lancés sur le serveur.
La solution est de ne jamais travailler directement sur le serveur.
Utiliser un poste qui y accède via le réseau.

A +

Fred BROUARD a écrit:

depuis quel outil lance tu sp_MShasdbaccess et coetera ?
En particulier s'agit-il d'une exécution via Query Analyser ou
Entreprise Manager sur le PC qui exploite la base ?

Si tel est le cas, ce peut être parfaitement normal !

A +

Armand Frigo a écrit:

Bonjour,
J'ai l'impression d'avoir tout essayé mais rien ne résoud mon problème de
performances serveur.
Les performances des bases de données en prod sont normales
(heureusement!),
mon problème vient du temps d'exécution de procédures stockées système
telles
que Master.dbo.sp_MShasdbaccess. Cette dernière met 7 secondes à
retourner
son résultat alors que sur les autres serveurs SQL (sur d'autres machines
pourtant moins performantes et beaucoup plus chargées (exemple 60 BDD
pour
4Go de données) ont un temps de réponse inférieur à 1 seconde.) J'ai des
temps d'attente aussi hallucinants lorsque je veux éditer les propriétés
d'un utilisateur (190s) ou faire quelque modif sur des données de
management
du serveur. Et pendant ces requêtes, les accès disques sont importants
(recherche d'index d'après le suiveur de perfs systèmes windows), et
Enterprise manager ne répond plus. Ces temps sont aussi valables sur
d'autres postes, quelle que soit la charge du serveur.
Le serveur est installé sur un bi-processeurs P3 700Mhz avec 512Mo
RAM. Il
héberge une douzaine de BDD dont 1 seule en PROD qui fait 70 Mo. Au
total il
doit y avoir 800Mo de BDD sur ce serveur, donc rien de bien méchant et il
n'y a pas plus de 15 utilisateurs conectés en simultané.
J'ai déjà utilisé les wizard de tuning sur toutes les bases. J'ai recyclé
les logs du serveur. Les tailles des BDD Master et Msdb sont
raisonnables...
Quelqu'un a-t-il une idée de ce qui pourrait rendre ces procédures si
longues?

Merci d'avance
Armand Frigo

--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************

Bonjour,
SQL Query Analyser et Enterprise Manager sont utilisés sur un autre poste
que le serveur SQL server.

combien de temps pour une connection via isqlw?
-> Le temps du dbo.sp_MShasdbaccess (le reste est instantané), soit :
6373 ms + quelques ms
combien de temps pour l'exécution sp_MShasdbaccess via isqlw?
-> 6500 ms, 6453 ms, 6360 ms... c'est assez stable et indépendant de la
charge du serveur.
combien de mémoire physique dispo (task manager->performance->physical
-> 79Mo libre sur 512.

Merci
Armand


"lionelp@online.microsoft.com"
<lionelponlinemicrosoftcom@discussions.microsoft.com> wrote in message
news:A07FF9CF-E681-49C2-B2BF-49984F8E0EA9@microsoft.com...

Bonjour,

combien de temps pour une connection via isqlw?
combien de temps pour l'exécution sp_MShasdbaccess via isqlw?
combien de mémoire physique dispo (task manager->performance->physical
memory available) reste-t-il?

Cordialement,
LionelP
PS: isqlw : analyseur de requête
"Armand Frigo" wrote:

> Bonjour,
> J'ai l'impression d'avoir tout essayé mais rien ne résoud mon problème

de

> performances serveur.
> Les performances des bases de données en prod sont normales

(heureusement!),

> mon problème vient du temps d'exécution de procédures stockées système
> telles
> que Master.dbo.sp_MShasdbaccess. Cette dernière met 7 secondes à

retourner

> son résultat alors que sur les autres serveurs SQL (sur d'autres

machines

> pourtant moins performantes et beaucoup plus chargées (exemple 60 BDD

pour

> 4Go de données) ont un temps de réponse inférieur à 1 seconde.) J'ai des
> temps d'attente aussi hallucinants lorsque je veux éditer les propriétés
> d'un utilisateur (190s) ou faire quelque modif sur des données de

management

> du serveur. Et pendant ces requêtes, les accès disques sont importants
> (recherche d'index d'après le suiveur de perfs systèmes windows), et
> Enterprise manager ne répond plus. Ces temps sont aussi valables sur
> d'autres postes, quelle que soit la charge du serveur.
> Le serveur est installé sur un bi-processeurs P3 700Mhz avec 512Mo RAM.

Il

> héberge une douzaine de BDD dont 1 seule en PROD qui fait 70 Mo. Au

total il

> doit y avoir 800Mo de BDD sur ce serveur, donc rien de bien méchant et

il

> n'y a pas plus de 15 utilisateurs conectés en simultané.
> J'ai déjà utilisé les wizard de tuning sur toutes les bases. J'ai

recyclé

> les logs du serveur. Les tailles des BDD Master et Msdb sont

raisonnables...

> Quelqu'un a-t-il une idée de ce qui pourrait rendre ces procédures si
> longues?
>
> Merci d'avance
> Armand Frigo
>
>
>
>

Bonjour,

Le reste est instantané veut dire que la connexion est instantanée ou
qu'elle met 6.5s?
Si en local sur le serveur le même test avec isqlw renvoie les mêmes
résultats alors le problème est bien côté serveur sinon c'est côté client.

Si le problème est côté serveur il faut alors voir éalement sa charge CPU,
si ces latences surviennent dès que le serveur a démarré sans connexion
aucune, ...


Cordialement,
LionelP


"Armand Frigo" wrote:

Bonjour,
SQL Query Analyser et Enterprise Manager sont utilisés sur un autre poste
que le serveur SQL server.

combien de temps pour une connection via isqlw?
-> Le temps du dbo.sp_MShasdbaccess (le reste est instantané), soit :
6373 ms + quelques ms
combien de temps pour l'exécution sp_MShasdbaccess via isqlw?
-> 6500 ms, 6453 ms, 6360 ms... c'est assez stable et indépendant de la
charge du serveur.
combien de mémoire physique dispo (task manager->performance->physical
-> 79Mo libre sur 512.

Merci
Armand


"lionelp@online.microsoft.com"
<lionelponlinemicrosoftcom@discussions.microsoft.com> wrote in message
news:A07FF9CF-E681-49C2-B2BF-49984F8E0EA9@microsoft.com...
> Bonjour,
>
> combien de temps pour une connection via isqlw?
> combien de temps pour l'exécution sp_MShasdbaccess via isqlw?
> combien de mémoire physique dispo (task manager->performance->physical
> memory available) reste-t-il?
>
> Cordialement,
> LionelP
> PS: isqlw : analyseur de requête
> "Armand Frigo" wrote:
>
> > Bonjour,
> > J'ai l'impression d'avoir tout essayé mais rien ne résoud mon problème
de
> > performances serveur.
> > Les performances des bases de données en prod sont normales
(heureusement!),
> > mon problème vient du temps d'exécution de procédures stockées système
> > telles
> > que Master.dbo.sp_MShasdbaccess. Cette dernière met 7 secondes à
retourner
> > son résultat alors que sur les autres serveurs SQL (sur d'autres
machines
> > pourtant moins performantes et beaucoup plus chargées (exemple 60 BDD
pour
> > 4Go de données) ont un temps de réponse inférieur à 1 seconde.) J'ai des
> > temps d'attente aussi hallucinants lorsque je veux éditer les propriétés
> > d'un utilisateur (190s) ou faire quelque modif sur des données de
management
> > du serveur. Et pendant ces requêtes, les accès disques sont importants
> > (recherche d'index d'après le suiveur de perfs systèmes windows), et
> > Enterprise manager ne répond plus. Ces temps sont aussi valables sur
> > d'autres postes, quelle que soit la charge du serveur.
> > Le serveur est installé sur un bi-processeurs P3 700Mhz avec 512Mo RAM.
Il
> > héberge une douzaine de BDD dont 1 seule en PROD qui fait 70 Mo. Au
total il
> > doit y avoir 800Mo de BDD sur ce serveur, donc rien de bien méchant et
il
> > n'y a pas plus de 15 utilisateurs conectés en simultané.
> > J'ai déjà utilisé les wizard de tuning sur toutes les bases. J'ai
recyclé
> > les logs du serveur. Les tailles des BDD Master et Msdb sont
raisonnables...
> > Quelqu'un a-t-il une idée de ce qui pourrait rendre ces procédures si
> > longues?
> >
> > Merci d'avance
> > Armand Frigo
> >
> >
> >
> >

SQL Query Analyser s'ouvre instantanément en grisé (tous les contrôles sont
indisponibles), puis Query Analyser est dispo après envriron 6,5 secondes
d'attente, lorsque tous les contrôles sont chargés. (liste déroulante des
BDD et object browser).
Le résultat est le même sur le serveur. Evolution du CPU lorsque je lance
Query Analyser sur le serveur :
14% au démarrage pendant moins d'une seconde
3% pendant 5-6 secondes
44% pendant 1/2 seconde.
0% Query Analyser est dispo.

Il s'agit d'un serveur de production, je ne peux pas déconnecter les
utilisateurs sans fermer l'application Web et envoyer un mail, ce dont je
préfèrerai me passer. Pour l'instant je privilégie les actions incognito,
d'autant que les perfs en prod sont très correctes.

Une idée de l'origine de mon problème?

Merci

Armand



"lionelp@online.microsoft.com"
<lionelponlinemicrosoftcom@discussions.microsoft.com> wrote in message
news:68951A2A-9B1D-4013-AF27-98D3ABC06662@microsoft.com...

Bonjour,

Le reste est instantané veut dire que la connexion est instantanée ou
qu'elle met 6.5s?
Si en local sur le serveur le même test avec isqlw renvoie les mêmes
résultats alors le problème est bien côté serveur sinon c'est côté client.

Si le problème est côté serveur il faut alors voir éalement sa charge CPU,
si ces latences surviennent dès que le serveur a démarré sans connexion
aucune, ...


Cordialement,
LionelP


"Armand Frigo" wrote:

> Bonjour,
> SQL Query Analyser et Enterprise Manager sont utilisés sur un autre

poste

> que le serveur SQL server.
>
> combien de temps pour une connection via isqlw?
> -> Le temps du dbo.sp_MShasdbaccess (le reste est instantané), soit

:

> 6373 ms + quelques ms
> combien de temps pour l'exécution sp_MShasdbaccess via isqlw?
> -> 6500 ms, 6453 ms, 6360 ms... c'est assez stable et indépendant de

la

> charge du serveur.
> combien de mémoire physique dispo (task manager->performance->physical
> -> 79Mo libre sur 512.
>
> Merci
> Armand
>
>
> "lionelp@online.microsoft.com"
> <lionelponlinemicrosoftcom@discussions.microsoft.com> wrote in message
> news:A07FF9CF-E681-49C2-B2BF-49984F8E0EA9@microsoft.com...
> > Bonjour,
> >
> > combien de temps pour une connection via isqlw?
> > combien de temps pour l'exécution sp_MShasdbaccess via isqlw?
> > combien de mémoire physique dispo (task manager->performance->physical
> > memory available) reste-t-il?
> >
> > Cordialement,
> > LionelP
> > PS: isqlw : analyseur de requête
> > "Armand Frigo" wrote:
> >
> > > Bonjour,
> > > J'ai l'impression d'avoir tout essayé mais rien ne résoud mon

problème

> de
> > > performances serveur.
> > > Les performances des bases de données en prod sont normales
> (heureusement!),
> > > mon problème vient du temps d'exécution de procédures stockées

système

> > > telles
> > > que Master.dbo.sp_MShasdbaccess. Cette dernière met 7 secondes à
> retourner
> > > son résultat alors que sur les autres serveurs SQL (sur d'autres
> machines
> > > pourtant moins performantes et beaucoup plus chargées (exemple 60

BDD

> pour
> > > 4Go de données) ont un temps de réponse inférieur à 1 seconde.) J'ai

des

> > > temps d'attente aussi hallucinants lorsque je veux éditer les

propriétés

> > > d'un utilisateur (190s) ou faire quelque modif sur des données de
> management
> > > du serveur. Et pendant ces requêtes, les accès disques sont

importants

> > > (recherche d'index d'après le suiveur de perfs systèmes windows), et
> > > Enterprise manager ne répond plus. Ces temps sont aussi valables sur
> > > d'autres postes, quelle que soit la charge du serveur.
> > > Le serveur est installé sur un bi-processeurs P3 700Mhz avec 512Mo

RAM.

> Il
> > > héberge une douzaine de BDD dont 1 seule en PROD qui fait 70 Mo. Au
> total il
> > > doit y avoir 800Mo de BDD sur ce serveur, donc rien de bien méchant

et

> il
> > > n'y a pas plus de 15 utilisateurs conectés en simultané.
> > > J'ai déjà utilisé les wizard de tuning sur toutes les bases. J'ai
> recyclé
> > > les logs du serveur. Les tailles des BDD Master et Msdb sont
> raisonnables...
> > > Quelqu'un a-t-il une idée de ce qui pourrait rendre ces procédures

si

> > > longues?
> > >
> > > Merci d'avance
> > > Armand Frigo
> > >
> > >
> > >
> > >
>
>
>

Bonjour,

Tu peux éventuellement vérifier que tous les utilisateurs de tes bases sont
bien référencés dans master..syslogins.

use [mabase]
select * from sysusers where issqlrole=0 and sid not in (select sid from
master..syslogins)

Cordialement,
Philippe


"Armand Frigo" <afrigo@netsize.com> a écrit dans le message de
news:euvAmbetEHA.636@TK2MSFTNGP09.phx.gbl...

SQL Query Analyser s'ouvre instantanément en grisé (tous les contrôles

sont

indisponibles), puis Query Analyser est dispo après envriron 6,5 secondes
d'attente, lorsque tous les contrôles sont chargés. (liste déroulante des
BDD et object browser).
Le résultat est le même sur le serveur. Evolution du CPU lorsque je lance
Query Analyser sur le serveur :
14% au démarrage pendant moins d'une seconde
3% pendant 5-6 secondes
44% pendant 1/2 seconde.
0% Query Analyser est dispo.

Il s'agit d'un serveur de production, je ne peux pas déconnecter les
utilisateurs sans fermer l'application Web et envoyer un mail, ce dont je
préfèrerai me passer. Pour l'instant je privilégie les actions incognito,
d'autant que les perfs en prod sont très correctes.

Une idée de l'origine de mon problème?

Merci

Armand



"lionelp@online.microsoft.com"
<lionelponlinemicrosoftcom@discussions.microsoft.com> wrote in message
news:68951A2A-9B1D-4013-AF27-98D3ABC06662@microsoft.com...
> Bonjour,
>
> Le reste est instantané veut dire que la connexion est instantanée ou
> qu'elle met 6.5s?
> Si en local sur le serveur le même test avec isqlw renvoie les mêmes
> résultats alors le problème est bien côté serveur sinon c'est côté

client.

>
> Si le problème est côté serveur il faut alors voir éalement sa charge

CPU,

> si ces latences surviennent dès que le serveur a démarré sans connexion
> aucune, ...
>
>
> Cordialement,
> LionelP
>
>
> "Armand Frigo" wrote:
>
> > Bonjour,
> > SQL Query Analyser et Enterprise Manager sont utilisés sur un autre
poste
> > que le serveur SQL server.
> >
> > combien de temps pour une connection via isqlw?
> > -> Le temps du dbo.sp_MShasdbaccess (le reste est instantané),

soit

:
> > 6373 ms + quelques ms
> > combien de temps pour l'exécution sp_MShasdbaccess via isqlw?
> > -> 6500 ms, 6453 ms, 6360 ms... c'est assez stable et indépendant

de

la
> > charge du serveur.
> > combien de mémoire physique dispo (task manager->performance->physical
> > -> 79Mo libre sur 512.
> >
> > Merci
> > Armand
> >
> >
> > "lionelp@online.microsoft.com"
> > <lionelponlinemicrosoftcom@discussions.microsoft.com> wrote in message
> > news:A07FF9CF-E681-49C2-B2BF-49984F8E0EA9@microsoft.com...
> > > Bonjour,
> > >
> > > combien de temps pour une connection via isqlw?
> > > combien de temps pour l'exécution sp_MShasdbaccess via isqlw?
> > > combien de mémoire physique dispo (task

manager->performance->physical

> > > memory available) reste-t-il?
> > >
> > > Cordialement,
> > > LionelP
> > > PS: isqlw : analyseur de requête
> > > "Armand Frigo" wrote:
> > >
> > > > Bonjour,
> > > > J'ai l'impression d'avoir tout essayé mais rien ne résoud mon
problème
> > de
> > > > performances serveur.
> > > > Les performances des bases de données en prod sont normales
> > (heureusement!),
> > > > mon problème vient du temps d'exécution de procédures stockées
système
> > > > telles
> > > > que Master.dbo.sp_MShasdbaccess. Cette dernière met 7 secondes à
> > retourner
> > > > son résultat alors que sur les autres serveurs SQL (sur d'autres
> > machines
> > > > pourtant moins performantes et beaucoup plus chargées (exemple 60
BDD
> > pour
> > > > 4Go de données) ont un temps de réponse inférieur à 1 seconde.)

J'ai

des
> > > > temps d'attente aussi hallucinants lorsque je veux éditer les
propriétés
> > > > d'un utilisateur (190s) ou faire quelque modif sur des données de
> > management
> > > > du serveur. Et pendant ces requêtes, les accès disques sont
importants
> > > > (recherche d'index d'après le suiveur de perfs systèmes windows),

et

> > > > Enterprise manager ne répond plus. Ces temps sont aussi valables

sur

> > > > d'autres postes, quelle que soit la charge du serveur.
> > > > Le serveur est installé sur un bi-processeurs P3 700Mhz avec 512Mo
RAM.
> > Il
> > > > héberge une douzaine de BDD dont 1 seule en PROD qui fait 70 Mo.

Au

> > total il
> > > > doit y avoir 800Mo de BDD sur ce serveur, donc rien de bien

méchant

et
> > il
> > > > n'y a pas plus de 15 utilisateurs conectés en simultané.
> > > > J'ai déjà utilisé les wizard de tuning sur toutes les bases. J'ai
> > recyclé
> > > > les logs du serveur. Les tailles des BDD Master et Msdb sont
> > raisonnables...
> > > > Quelqu'un a-t-il une idée de ce qui pourrait rendre ces procédures
si
> > > > longues?
> > > >
> > > > Merci d'avance
> > > > Armand Frigo
> > > >
> > > >
> > > >
> > > >
> >
> >
> >