[SQL Server] Requete SQL lente

Version imprimable

Bonjour,

Je développe en VB .net, a l'aide de la technologie windows Forms, sur le SGBD SQL Server.
J'ai récemment fais l’acquisition d'un serveur dédié hébergé chez OVH.

En local, tous se déroulais parfaitement, les traitements étaient rapide (jamais plus de 5sec).

Seulement, depuis que le logiciel va chercher les informations sur le serveur, certaines requêtes durent plus d'une minute, ce qui n'est pas tolérable. J'ai donc commencer a optimiser mes requêtes. Et c'est alors que j'ai compris la vraie nature du problème.
Une requête simple s’exécute rapidement, a quasiment la même vitesse qu'en local. Le problème provient de l’exécution de double requete, je m'explique :
Code:

1 2 3 4 objDR = requeteSELECT("SELECT * FROM TbAtt WHERE FinW<='" & dateJusque & "'" objDR.read wsExcel.Cells(14 + compteur, 2) = objDR.Item(17) wsExcel.Cells(14 + compteur, 3) = RequeteINFOAlt1("CodeAtt", "TbCodeAtt", "IDCodeAtt", objDR.Item(5))
La première ligne, provenant de la première requête, s’exécute sans problème.
La seconde quant à elle, prend plus de 5 sec à s’exécuter, sachant que ce code est contenu dans une boucle while, les temps de réponses atteignent vite la minute.

Concernant l'optimisation de cette requête, j'ai tout bonnement supprimé la seconde, j'ai rentré le contenu de la table dans un tableau, et ainsi j'ai pu retrouver un temps d’exécution correct.

Sauf que, entrer toute les donné dans un tableau n'est pas toujours possible. Une table fais 36k ligne, bien qu'elle ne soit pas excessivement lourde, la traiter par le code me semble assez conséquent !

J'ai eu dans l’après midi un technicien d'OVH qui m'as proposer 2 choses :
- Optimiser mes requêtes SQL, ce que j'avais commencer a faire, mais qu'il semble compliquer a réaliser sans perdre d'info, ou sans perdre de rapidité.
- Éventuellement configurer SQL Server pour ce genre de traitement.

Etant assez novice dans la configuration d'un serveur, je n'y avais absolument pas touché. Mais je me demande si je n'aurais pas du...
Ce qui me surprend le plus dans cette histoire, c'est qu'en local avant, même sur une machine vraiment peu puissante, les traitement étaient très rapide. Pensant que le souci venais de notre ADSL, j'ai fais un speedTest, et j'ai obtenu un résultat de 10Mbps, pas de souci donc, et le serveur est lui aussi correctement desservi (fibre).
Je fais donc appel aux habitué de ce SGBD, si il y a une solution miracle par la configuration, ou si il n'y a pas de secret et qu'il faut minimiser les traitements au maximum.

Merci a vous !

14/05/2014, 12h32
DotNetMatt
L'optimisation de requêtes SQL n'est pas une science exacte, il existe autant de solutions possibles qu'il existe de requêtes, c'est-à-dire une infinité ;)

Tu peux déjà vérifier de ton côté :
- La présence d'un index sur la colonne FinW dans la table TbAtt. S'il n'y en a pas, il faut en mettre un.
- Utilise une requête paramétrée (tuto ou faq) afin de figer le plan d'exécution et obtenir des performances plus stables.
Peux-tu également préciser ce que tu fais dans la méthode Read ?
14/05/2014, 14h32
Ninpa
Bonjour,

Citation:

La présence d'un index sur la colonne FinW dans la table TbAtt. S'il n'y en a pas, il faut en mettre un.

Je ne comprend pas très bien ce que tu nomme un index sur ce champs. Le champs FinW est un champs Date, pour moi lui coller un index implique d'exporter les données dans une autre table, et de l’identifier avec l'index. Sauf que ce champs est un champs date et différents pour quasiment chaque ligne de la base. Es ce bien ce dont tu parle ?

Citation:

Utilise une requête paramétrée (tuto ou faq) afin de figer le plan d'exécution et obtenir des performances plus stables.

Je suis en train de m'y mettre, merci pour les liens.

Citation:

Peux-tu également préciser ce que tu fais dans la méthode Read ?

ObjDR est un objet de type System.Data.SqlClient.SqlDataReader, la méthode read permet de passer a la ligne suivante du tableau. Classiquement :
Code:

1 2 3 4 5 6 objDR = Requete objDR.read textbox1.text = objDR.item(0) while objDR.read textbox1.text = textbox1.text & vbnewline & objDR.item(0) end while
Merci pour ta réponse. Je vais faire des tests avec les requête paramétrer (qui m'ont quand même l'air un peu plus complexe qu'une requête bidon !), et de voir si je gagne du temps.
14/05/2014, 14h56
DotNetMatt

Citation:

Envoyé par Ninpa

Je ne comprend pas très bien ce que tu nomme un index sur ce champs. Le champs FinW est un champs Date, pour moi lui coller un index implique d'exporter les données dans une autre table, et de l’identifier avec l'index. Sauf que ce champs est un champs date et différents pour quasiment chaque ligne de la base. Es ce bien ce dont tu parle ?

Non pas du tout. Un index peut être assimilé à un annuaire téléphonique : pour chercher un numéro de téléphone associé à un nom de famille, tu n'es pas obligé de parcourir tout l'annuaire, tu peux directement aller à la première lettre du nom de famille, puis fouiller par ordre alphabétique. Cela va donc beaucoup plus vite que si tu devais parcourir tout l'annuaire à la recherche de l'information qui t'intéresse.

Dans ton cas c'est pareil : tu cherches une date précise (le nom de famille) parmi tous les enregistrements contenus dans la table (l'annuaire).

Donc sans index sur la colonne, le SGBDR va devoir parcourir tous les enregistrements (ce qui s'appelle un Full Scan), puis filter pour ne remonter que les lignes correspondant à la date recherchée.
Avec un index, le SGBDR va consulter l'annuaire et il saura précisément où chercher.

Voilà pour te donner une image de ce qu'est un index. Je te laisse le soin de te documenter : Indexer avec SQL-Server... oui mais quoi ? ou encore : CREATE INDEX (Transact-SQL).

En tout cas, pas besoin de créer une nouvelle table, l'index s'applique sur une (ou plusieurs colonnes) dans une table donnée. Le contenu de l'index est stocké au niveau du disque dur.

En tout cas ça peut permettre de booster les requêtes de manière significative.
14/05/2014, 15h34
Ninpa

Merci encore a toi pour toutes tes réponses très précises, je devrais m'en sortir maintenant !