Ralentissement des requêtes sur la durée

[joelduret]

Bonjour,
Je suis débutant dans l'administration de SQL Server qui est très complet.
J'ai une application qui exécute tout un tas de requêtes SELECT sur SQL Server (environ 4000 par exécution), et qui réitère le processus toutes les 5 minutes... Jusque là tout semble bon.
Au tout début, lors des premières exécutions, la vitesse était carrément bonne (1 à 2 minutes). Mais après avoir laisser tourner le programme pendant quelques jours, le processus a ralenti, et met maintenant beaucoup plus de temps (facilement 2h30 à 3h )...

J'ai fait beaucoup de recherche, et n'es pas encore trouvé de raison à ce ralentissement.
Je me pose la question si SQL Server ne limiterais pas la quantité de donnée renvoyé, ou le nombre de connexions (non simultanées), comme une sorte de bridage à la manière des opérateurs téléphoniques avec le réseau mobile "illimité" qui ralenti si on dépasse le quota...

Pour info, le serveur est un serveur de test Windows 2003, avec SQL Server 2008, qui ne travail que pour mon application.
L'application a été développé sous WinDev 16, et utilise le driver OLEDB pour la connexion.

Aidez moi, je cherche depuis plusieurs jours, et ce forum me semble celui ou les sujets sont le plus proche de mon problème...

[castorameur]

Bonjour,

Si vous n'avez aucune connaissance de l'administration SQl server, je pense que vous allez au devant de nombreux problèmes. Mais peut être s'agit t il de tests personnels et dans ce cas vous aurez la possibilité d'apprendre.

Pour avoir un sql qui fonctionne bien vous devez
- connaître la mémoire alloué
- connaître le système disque

Pour avoir une base qui fonctionne bien vous devez
- faire un plan de maintenant
- savoir ce que font les requêtes (pour optimiser tempdb par exmple)

ce ne sont que quelques pistes, mais dans tous les cas fouillez sur le web pour recueillir de l'essentiel. Par exemple ici http://sqlserver.developpez.com/cours/

a+

[joelduret]

Envoyé par castorameur

Bonjour,
Pour avoir un sql qui fonctionne bien vous devez
- connaître la mémoire alloué
- connaître le système disque

Pour avoir une base qui fonctionne bien vous devez
- faire un plan de maintenant
- savoir ce que font les requêtes (pour optimiser tempdb par exemple)

Merci de la réponse.
Toutefois, il me semble que les performance du serveur ne sont pas à remettre en question vis à vis des tests fait avec d'autres applicatifs.
Je pense que le problème est lié à mon application qui se lance toute les 5 minutes et qui interroge massivement la base (en nombre de requêtes, pas de résultats car environ 20 résultats au maximum)

Mes requêtes font des SELECT simples, aucune procédure stockée ou autre...
Je voudrais surtout comprendre quel mécanisme de SQL Server pourrait éventuellement brider le temps d'exécution après un certain nombre de SELECT...
Ce qui me trouble vraiment c'est qu'au début les temps étaient plus que correct. Pourquoi cette dégradation? L'application est toujours sur le même poste, la structure réseau et la gestion des droits est la même.

Mais si toutefois vous pensez qu'il faille passer par une optimisation de la table temporaire, ainsi que par les différents test que vous avez donné, alors j'irais dans cette direction.
-La taille du cache alloué est à 61.86 d'après cette requête de Nicolas SOUQUET
http://blog.developpez.com/elsuket/p...e-alloue-aux-/

Code :

1
2
3
4
5
6
7
8
9
10
SELECT    CASE 
      WHEN GROUPING(D.name) = 1 THEN 'TOTAL' 
      ELSE D.name  
    END AS database_name 
    , CAST(COUNT_BIG(*) / 128.0 AS decimal(10,2)) AS cached_size_MB 
FROM    sys.dm_os_buffer_descriptors AS OSBD 
INNER JOIN  sys.DATABASES AS D ON OSBD.database_id = D.database_id 
--WHERE    D.name = 'maBD' 
GROUP BY  D.name WITH ROLLUP 
ORDER BY  cached_size_MB DESC

[castorameur]

Mes requêtes font des SELECT simples, aucune procédure stockée ou autre..

Une procédure stockée peut faire des select et envoyer le résultat dans un mail. Il y a des cas où une procédure stockée peut s'exécuter plus vite qu'un "simple" select, mais passons.

Vos données sont elles updatées par d'autres appli ? votre appli est elle seule quand les perfs baissent ? avez vous vous une connaissance des délais d'attente/latch? avec vous des locks ?
bref il y a beaucoup de pistes à explorer

bon courage et bienvenu dans le monde sql server

[SQLpro]

1) le serveur physique (la machine) est-elle virtualisée ?
2) le serveur physique ou virtuel est-il entièrement dédié à SQL Server ou y a t-il d'autres applications dessus comme :
a) client lourd,
b) serveur web
c) antivirus
...
3) quelle est la taille de la base de données ? (EXEC sp_spaceused)
4) quel est la quantité de RAM ?
5) quel OS/version ? (standard, Enterprise...)
6) quelle version de SQL Server (2005, 2008, R2...) Express, Standard, Enterprise ?
7) combien de socket CPU et de coeurs
8) comment on été créé les fichiers de votre base
9) comment sont structurées vos tables (sont-elles obèses ou normalisées...) ?

A +

[iberserk]

Je suppose que votre traitement fais des mise à jour update sur des tables...
Il y a de bonnes chances pour que la dégradation viennent de l'augmentation du volume(et donc l'apparition d'index manquants) ou d'index non à jour.

reconstruisez vous vos indexes régulièrement?

[iberserk]

SQL Server (environ 4000 par exécution)

A mon avis votre traitement est complètement à revoir.... je suppute des boucles à gogo en lieu et place de bonnes requêtes ensemblistes...


Peut on voir tout ca?

[joelduret]

Envoyé par castorameur

Une procédure stockée peut faire des select et envoyer le résultat dans un mail. Il y a des cas où une procédure stockée peut s'exécuter plus vite qu'un "simple" select, mais passons.

Merci pour l'information... Je voulais juste délimiter mon champ d'action

Vos données sont elles updatées par d'autres appli ?

Non, pas durant mes tests, mais théoriquement elles le seront. Vous pensiez aux verrous?

votre appli est elle seule quand les perfs baissent ?

Oui, il n'y a que mon appli qui tourne, mais le ralentissement est progressif et continu. (une fois ralenti, l'application ne récupère jamais la vitesse d'origine)

avez vous vous une connaissance des délais d'attente/latch?

Non, comment puis-je les voirs? A l'aide des analyse des requêtes?

Code :

1
2
3
4
5
SET STATISTICS IO ON
SET STATISTICS TIME ON
-- Ma requête ici
SET STATISTICS TIME OFF
SET STATISTICS IO OFF

avec vous des locks ?

Non, je ne crois pas. J'avais trouvé une requête permettant de lister les processus en cours, avec les éventuelles blocage, mais le champ blk est à 0 partout.

bienvenu dans le monde sql server

Merci!

Envoyé par SQLpro

1) le serveur physique (la machine) est-elle virtualisée ?
2) le serveur physique ou virtuel est-il entièrement dédié à SQL Server ou y a t-il d'autres applications dessus comme :
a) client lourd,
b) serveur web
c) antivirus
...
3) quelle est la taille de la base de données ? (EXEC sp_spaceused)
4) quel est la quantité de RAM ?
5) quel OS/version ? (standard, Enterprise...)
6) quelle version de SQL Server (2005, 2008, R2...) Express, Standard, Enterprise ?
7) combien de socket CPU et de coeurs
8) comment on été créé les fichiers de votre base
9) comment sont structurées vos tables (sont-elles obèses ou normalisées...) ?

1) Non
2)Oui (sauf un Antivirus car c'est du Windows )
3)
4)1Go
5)Windows XP Pro 2002 SP3 (je croyais que c'était un 2003 serveur...)
6)2008 (Standard ou Entreprise)
...Je ne connais pas les autres réponses.

Envoyé par ibersec

A mon avis votre traitement est complètement à revoir.... je suppute des boucles à gogo en lieu et place de bonnes requêtes ensemblistes...


Peut on voir tout ca?
Je suppose que votre traitement fais des mise à jour update sur des tables...
Il y a de bonnes chances pour que la dégradation viennent de l'augmentation du volume(et donc l'apparition d'index manquants) ou d'index non à jour.

Aucune modification ne sont faite sur cette base.
Je récupère depuis SQL Server et je met sur MySQL
Oui, il y a des boucles "à gogo" dans le programme, mais parce qu'il y a beaucoup de recherche d'existence dans SQL Server d'UN enregistrement précis.
En gros, je récupère une liste d'enregistrements sur MySQL,
puis pour chacun d'entre eux, je vais voir si il existe sur SQL Server. Je récupère d'autres info sur SQL server, puis je met à jour MySQL.

En espérant être compréhensible. Merci à vous de vos réponse.

[iberserk]

Ne pouvez vous pas récupérer un ensemble de ligne via SQL SERVER plutot de que boucler sur des select unitaire?

[SQLpro]

Plus vous lirez de lignes unitaires, plus vous encombrerez le système jusqu'à le tuer. Un SGBDR est fait pour faire des requêtes ensemblistes, c'est à dire portant simultanément sur toute les lignes par des requêtes SQL et non en lisant une ligne à la fois.

Si vous utilisez une voiture pour des déplacements limités à 2 ou 3 mètres dans une grande ville (avec le stationnement qui va avec), ne vous étonnez pas que le vélo ou la marche à pied soit plus rapide !

A +

[castorameur]

Si vous utilisez une voiture pour des déplacements limités à 2 ou 3 mètres dans une grande ville (avec le stationnement qui va avec), ne vous étonnez pas que le vélo ou la marche à pied soit plus rapide !

j'adore la comparaison

[mikedavem]

2)Oui (sauf un Antivirus car c'est du Windows )

Bon ce n'est pas pour lancer un débat ici mais sur Linux ou Unix il y a également des virus qui trainent même si on peut les compter sur les doigts de la main par rapport à Windows

Ceci dit est ce que votre antivirus est paramétré pour exclure l'activité engendré par SQL Server ?

++