Lenteurs SQL 2000 [Résolu]

[Swampscott]

Bonjour à tous

J'ai un serveur SQL 2000 std ss Windows 2003 std
Je suis bien conscient de la limite mémoire utile SQL à 2 Go.
Mon serveur est de plus en plus lent. La BDD fait 40 Go.
L'organisation disque n'est pas optimale pour l'instant BDD et Logs sur les mêmes disque, TMPDB sur le C.

name minimum maximum config_value run_value
----------------------------------- ----------- ----------- ------------ -----------
affinity mask -2147483648 2147483647 0 0
allow updates 0 1 0 0
awe enabled 0 1 1 1
c2 audit mode 0 1 0 0
cost threshold for parallelism 0 32767 5 5
Cross DB Ownership Chaining 0 1 0 0
cursor threshold -1 2147483647 -1 -1
default full-text language 0 2147483647 1036 1036
default language 0 9999 2 2
fill factor (%) 0 100 0 0
index create memory (KB) 704 2147483647 0 0
lightweight pooling 0 1 0 0
locks 5000 2147483647 0 0
max degree of parallelism 0 32 0 0
max server memory (MB) 4 2147483647 2560 2560
max text repl size (B) 0 2147483647 65536 65536
max worker threads 32 32767 255 255
media retention 0 365 0 0
min memory per query (KB) 512 2147483647 1024 1024
min server memory (MB) 0 2147483647 0 0
nested triggers 0 1 1 1
network packet size (B) 512 32767 4096 4096
open objects 0 2147483647 0 0
priority boost 0 1 1 1
query governor cost limit 0 2147483647 0 0
query wait (s) -1 2147483647 -1 -1
recovery interval (min) 0 32767 0 0
remote access 0 1 1 1
remote login timeout (s) 0 2147483647 20 20
remote proc trans 0 1 0 0
remote query timeout (s) 0 2147483647 600 600
scan for startup procs 0 1 0 0
set working set size 0 1 1 1
show advanced options 0 1 1 1
two digit year cutoff 1753 9999 2049 2049
user connections 0 32767 0 0
user options 0 32767 0 0

Lorsque que la machine est chargée (serveur dédié SQL), le taux de présence dans les tampons descend fréquemment à 75%, la longueur de la file d’attente disque plafonne alors à 100%. Le taux de présence dans le cache des tampons reste toujours à 7%.

Qu'en pensez-vous ? (Il semble que l'application fasse souvent appel aux curseurs).

Merci de vos avis

[mikedavem]

Bonjour,

Vous pouvez nous dire les comptes exacts que vous utilisez et leurs valeurs ?

Merci

++

[Swampscott]

Bonjour

De quel compte s'agit il ? Connexion ?

[mikedavem]

Oups,

De quels compteurs il s'agit ?

++

[Swampscott]

Alors

Long moyenne de la file d'attente du disque (à fond quand le taux de présence dans le cache descend)
Gestionnaire de cache - tx de présence dans le cache (toujours à 7%)
Gestionnaire de tampons - Pages de bases de données (tjs à fond)
Gestionnaire de tampons - Taux de présence dans le cache des tampons (descend très fréquemment à 70-75%)
Temps processeur (quekques pics à 50% voire un peu plus mais pas de quoi foutter un chat)
Transac/seconde (assez dense parfois mais raisonnable)

J'espere que c'est ce que tu attendais

merci

[SQLpro]

Ce chiffrées sont catastrophique. Par exemple le taux de mise en cache dans la mémoire tampon ne devrait pas descendre en dessous de 98%
Sachant que c'est une mesure exponentielle être à 78% signifie une division de la vitesse de traitement de 100 fois !!!

Il est probable que votre base de données soit une catastrophe en terme de modélisation.....
Dans un premier temps, il convient de donner de la RAM au moins 8 Go au serveur.
Dans un second temps il faut auditer la base au niveau structurel et ce qui est requêtés via le profiler pour déterminer sur quoi agir et dans quel ordre.

Question : en dehors de SQL Server, avez vous quoi que ce soit qui tourne à côté (application, serveur web, anti virus....etc) ?
En principe un SGBDR doit IMPÉRATIVEMENT être installé sur un serveur dédié et aucun programme ni service inutile d'aucune sorte ne doit ëtre lancé sur ce serveur.

Lisez les articles que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/optimisation/

A +

[mikedavem]

Effectivement comme le dit SQLPro les valeurs sont inquietantes ...

Vous avez tres probablement un manque de memoire (mais de toute facon vous etes limite avec SQL Server 2000 Std et vous aurez probablement a mettre a jour votre edition ...) et tres certainement des problemes au niveau de vos requetes / et ou de votre modele.

La repartition de vos fichiers de bases n'arrange en rien vos problemes.

Je pense que dans un premier temps que votre architecture est a revoir ... plus vous avancerez dans le temps plus vous aurez des problemes. Dans un deuxieme temps il faudra tres certainement auditer votre base comme le suggere SQLPro.

++

[Swampscott]

Merci à tous

Je me doutais d'un manque cruel de mémoire sur cette machine mais à ce point ....

L'organisation disque est effectivement très mauvaise. Tmpdb sur C, log et base sur D. Disques à 10k tours.

Quant au soft : apparemment rcours massif aux curseurs, et plusieurs jointures externes
Mais je n'y peux pas grand chose : erp francais acquis il y a quelques années par sage. J'ai tenté une création d'index qui n'a rien donnée en terme de performance (pas étonnant de toute façon si la machine est à la peine)

J'ai désactivé l'antivirus tout au moins sur toutes les partie concernées par sql.

Rien d'autre ne tourne sur la machine si ce n'est l'apache nécessaire au logiciel.

Je pense que le besoin avait été sus-estimé à l'origine. De plus, je viens de voir que sur les 40Go de la base, 13Go sont occupés par une seule table qui grossit très vite. Je vais également voir l'utilité des données qu'elle contient et les possiblités de purge.

A+

[Swampscott]

Une dernière question : La taille d'une table ne peut elle pas pénaliser l'ensemble ?

Merci d'avance

[SQLpro]

Envoyé par Swampscott

Merci à tous

Je me doutais d'un manque cruel de mémoire sur cette machine mais à ce point ....

L'idéal serait de migrer en version 2008 et en conservant votre base en mode de rétro compatibilité 2000. De ce fait vous pourriez mettre 8 à 16 Go de RAM sans problème. Voyez aussi à passer au 64 bits

L'organisation disque est effectivement très mauvaise. Tmpdb sur C, log et base sur D. Disques à 10k tours.

si elle est effectivement mauvaise, elle n'est pas catastrophique probablement. En revanche, voyez à définir des "storages" (fichiers et groupes de fichiers) qui soient largement dimensionnés. Pour ce faire lisez l'article que j'ai écrit : http://blog.developpez.com/sqlpro/p5...fichiers-et-t/

Quant au soft : apparemment rcours massif aux curseurs, et plusieurs jointures externes
Mais je n'y peux pas grand chose : erp francais acquis il y a quelques années par sage. J'ai tenté une création d'index qui n'a rien donnée en terme de performance (pas étonnant de toute façon si la machine est à la peine)

Il ne faut pas lésiner sur l'indexation. La plupart du temps les gens sont frileux sur l'indexation. Si 10 index sont nécessaires sur certaines tables alors, placez les !

J'ai désactivé l'antivirus tout au moins sur toutes les partie concernées par sql.

Rien d'autre ne tourne sur la machine si ce n'est l'apache nécessaire au logiciel.

RIEN, absolument rien ne doit tourner en dehors de SQL Server sur cette machine. Donc, certainement pas Apache !!!! Déplacez le sur un serveur annexe.

Je pense que le besoin avait été sus-estimé à l'origine. De plus, je viens de voir que sur les 40Go de la base, 13Go sont occupés par une seule table qui grossit très vite. Je vais également voir l'utilité des données qu'elle contient et les possiblités de purge.

A+

13 Go pour une table, c'est grand mais pas affolant. Si elle est bien organisée et notamment bien indexées, ce n'est pas moins rapide qu'une petite table. Il n'y a que si elle dépasse la capacité d'un disque qu'il convient de se poser la question, pas exemple du partitionnement !

A +

[Swampscott]

Merci beaucoup pour toutes ces précieuses infos.