Problème performance SQL Server Delphi

Bonjour,

J'ai développé une application de gestion de stock avec Delphi 6. La base de données est sous SQL Serveur. L'ouverture d'un table (TADOTable.Open) qui est lie à une vue (view) de la base de données prend sur le PC de développement (pour un résultat qui retourne 23000 linges) quelques secondes (2-10 seconds) mais sur le Serveur de production plus de 10 minutes.

voici ci-dessous la requête SQL qui générée la vue:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

SELECT dbo.CDM.CBCDM, dbo.PRD.Designation, dbo.CDM.CodePRD, dbo.CDM.CodeInventaire, dbo.CDM.NumSerieCDM, dbo.CLS.LibelleCLS, dbo.CTGR.LibelleCTGR, dbo.CDM.EtatCDM, dbo.CDM.DateR, dbo.DR.PrixAchatHT, dbo.FRS.RS AS RSFRS, dbo.CDM.Observation, dbo.DPT.CodeDPT, dbo.DPT.LibelleDPT, dbo.MGZ.CodeMGZ, dbo.MGZ.LibelleMGZ, dbo.CMPT.LibelleCMPT, dbo.RYN.LibelleRYN, dbo.ETGR.LibelleETGR, dbo.TM.LibelleMVT AS MvtR, dbo.CDM.NumR, TM_1.LibelleMVT AS MvtSRT, dbo.SRT.NumSRT, dbo.SRT.DateSRT, dbo.SRT.LibelleNV, dbo.PRT.RS AS RSPRT, dbo.R.TypeR, dbo.SRT.Agent AS AgentSRT, dbo.R.Agent AS AgentR, dbo.CDM.CDMStatut, dbo.CDM.DatePeremption, dbo.CDM.PrixUnitaireR, dbo.CDM.QuantiteStock, dbo.CDM.QuantiteR FROM dbo.FRS RIGHT OUTER JOIN dbo.DRC INNER JOIN dbo.R INNER JOIN dbo.DR ON dbo.R.NumR = dbo.DR.NumR INNER JOIN dbo.TM ON dbo.R.TypeR = dbo.TM.TM ON dbo.DRC.NumR = dbo.DR.NumR AND dbo.DRC.CodePRD = dbo.DR.CodePRD LEFT OUTER JOIN dbo.PRT ON dbo.R.CodePRT = dbo.PRT.CodePRT ON dbo.FRS.CodeFRS = dbo.R.CodeFRS RIGHT OUTER JOIN dbo.DS INNER JOIN dbo.DSC ON dbo.DS.NumSRT = dbo.DSC.NumSRT AND dbo.DS.CodePRD = dbo.DSC.CodePRD INNER JOIN dbo.SRT ON dbo.DS.NumSRT = dbo.SRT.NumSRT INNER JOIN dbo.TM AS TM_1 ON dbo.SRT.TypeSRT = TM_1.TM RIGHT OUTER JOIN dbo.ETGR RIGHT OUTER JOIN dbo.CDM ON dbo.ETGR.CodeETGR = dbo.CDM.CodeETGR LEFT OUTER JOIN dbo.CLS INNER JOIN dbo.SC ON dbo.CLS.CodeCLS = dbo.SC.CodeCLS INNER JOIN dbo.CTGR ON dbo.CLS.CodeCTGR = dbo.CTGR.CodeCTGR RIGHT OUTER JOIN dbo.PRD ON dbo.SC.CodeSC = dbo.PRD.CodeSC LEFT OUTER JOIN dbo.MRQ ON dbo.PRD.CodeMRQ = dbo.MRQ.CodeMRQ ON dbo.CDM.CodePRD = dbo.PRD.CodePRD ON dbo.DSC.CBCDM = dbo.CDM.CBCDM AND dbo.DSC.NumR = dbo.CDM.NumR ON dbo.DRC.CBCDM = dbo.CDM.CBCDM AND dbo.DRC.NumR = dbo.CDM.NumR LEFT OUTER JOIN dbo.RYN ON dbo.ETGR.CodeRYN = dbo.RYN.CodeRYN LEFT OUTER JOIN dbo.CMPT ON dbo.RYN.CodeCMPT = dbo.CMPT.CodeCMPT LEFT OUTER JOIN dbo.MGZ ON dbo.CMPT.CodeMGZ = dbo.MGZ.CodeMGZ LEFT OUTER JOIN dbo.DPT ON dbo.MGZ.CodeDPT = dbo.DPT.CodeDPT

---

J'ai eu le même problème de lenteur sur un autre PC qui tourne sous Windows7 avec SQL Serveur 2008.

Voici un résume de temps d'exécution de la même requête avec la même quantité de données :

Developpement (laptop HP): Windows XP-SP3 + SQL Server 2005 : 2-6 secs
Developpement (laptop HP): Windows XP-SP3 + SQL Server 2008 : 2-6 secs
Teste (laptop Acer): Windows 7 + SQL Server 2008 : plus de 12 minutes
Production (Server HP): Windows 2003 server + SQL Server 2005 : plus de 12 minutes

Je suis vraiment bloqué à cause de ce problème de lenteur :(.

Merci d'avance pour votre aide.

Cdt,
Burkan

Je pense que c'est surtout la requête qui est à revoir complètement.

Ne connaissant pas le modèle de données de ta base je ne peux faire que des remarques :

- Trop de LEFT et RIGHT (sont ils tous obligatoire ?)
- As tu besoin de toute ces tables ? (Ex : DS et DSC ne sont pas appeler dans la partie haute de la requête est ce bien utile de passer par ces deux tables ? ne pourrait on pas faire une jointure avec DR ou DRC directement ?)

Est-ce que toutes les bases de tests sont identiques ?
Surtout sur les Index ?
Ensuite, c'est effectivement une Uzinagaz cette requète, autant de table, autant de champ ?
A quoi cela sert ? Si c'est pour mettre dans une grille, c'est inbuvable, passer 10 colonnes, c'est tué l'utilisateur, mieux vaut lancer une requête pour la grille avec 10 colonnes + PK, puis lors de l'appel d'un formulaire d'édition avancé, lancer quelques requêtes en utilisant les PK pour récupérer les données manquantes !

Cette vue est-elle utiliser massivement pour faire des calculs ?
Perso, j'utilise MySQL 4 et parfois 5 donc je suis pas un habitué des vues mais c'est surtout au CREATE VIEW que cela prend du temps, après, c'est un peu commet lire une table ?
Comment fonctionne SQL Server pour les vues, il relance la requête à chaque lecture ?


je trouve aussi la requête pénible à lire, on ne voit pas les join du 1er coup d'oeil

Code:

---

1 2 3 4 5 6

FROM dbo.FRS RIGHT OUTER JOIN dbo.DRC INNER JOIN dbo.R INNER JOIN dbo.DR ON dbo.R.NumR = dbo.DR.NumR INNER JOIN dbo.TM ON dbo.R.TypeR = dbo.TM.TM ...

---

Pour les Join sans on, je suppose qu'il y a une complétion implicite sur les PK par SQL Server ? comme le NATURAL JOIN ?

Bonjour ShaiLeTroll & Rayek,

L'exécution de la même requête (même base de données) sur les deux systèmes "Windows 7 & Windows 2003 Server" nécessite plus de 12 minutes , alors que sur Windows XP elle termine l'exécution dans moins de 6 secondes.

Pour cette raison que je crois que le problème n'est pas la requête mais mon exécutable. Je note aussi que la requête nécessite moins de 2 seconds avec SQL Server Studio Manager. ce qui peut être confirme que la source du problème est l'application.

Mais la même application tourne sur XP sans aucun problème :(.

Question: est il nécessaire que le système sur le quel Delphi est installé doit être le même que le système où mon future application sera installé pour avoir les meilleures performances de cette dernière?


Merci d'avance pour l'aide

Cdt,
Fouad

Bonjour

afin de lever toute ambiguïté je te propose de faire une simple requête genre

Citation:

---

select * from taTable

---

et de l'exécuter sous tes différents OS, si elle s'exécute dans les mêmes délais alors le problème est dans ta requête sinon dans le système.

Les bases où tu fais tes tests sont elles totalement identique ?
Est ce que les tables ont le même nombre d'enregistrement ?

Tu peux aussi avoir un problème avec l'AntiVirus, avec MySQL5, bcp d'opération passe par une écriture d'un fichier temporaire qui est bloqué par certains AntiVirus
Vu la requête, peut-être que SQL Server est sensible à cela !
Idem avec FireWall ou autres protections ...

Tes essais sont tous lancés en local sur les différentes machines ?
As-tu essayer de lancer depuis un client via le réseau ?

Pour la différence entre ton application et SQL Server Studio Manager, c'est tout à fait normal !
Tu utilise problablement ADO qui est une surcouche par dessus OleDB (si je me trompe pas), le remplissage d'un DataSet est une opération particulièrement longue, Studio Manager lui doit utilisé directement la couche d'accès de SQL Server (soit proprement via OleDB ou plus sauvagement avec le driver sous-jacent), ainsi les couches d'objets étant réduites, cela s'execute plus vite ...

Lorsque j'utilise ADO ou DBExpress+CDS sur MySQL, c'est deux à trois fois plus lent que MyDAC, tout simplement à cause de la gestion de la généricité et de l'empillage de couche logiciel !

d'après ma documentation sur l'interrogation des bases de données distante ou sous réseaux je vous propose les procédures stockées peut être que ca va vous aidé :
http://barlatier.developpez.com/csha...stockee/cours/

Citation:

---

Envoyé par redoran

d'après ma documentation sur l'interrogation des bases de données distante ou sous réseaux je vous propose les procédures stockées peut être que ca va vous aidé :
http://barlatier.developpez.com/csha...stockee/cours/

---

Salut

simple question : quel est le lien entre une requête et une procédure stockée ?
peut-être dans des cas précis une requête peut-être convertie en procédure stockée mais pas une règle générale !
donc, à mon avis, faut pas prendre ça comme habitude.

lire le Pourquoi une procédure stockée ? dans le lien http://barlatier.developpez.com/csha...stockee/cours/ si je ne me trompe pas...

Citation:

---

Alors on revient maintenant sur la question; Pourquoi Utiliser des procédures stockées au lieu des requêtes SQL directement ? La réponse est que T-SQL est le langage natif de SQL Server et les procédures stockées sont exécutées sur le serveur. Une procédure stockée peut scanner des milliers d'enregistrements, effectuer des calculs etc. Si vous effectuez des calculs qui impliquent un grand nombre de lignes, vous pouvez éviter de télécharger trop d'informations vers le client en écrivant une procédure stockée pour effectuer le travail sur le serveur à la place ! Les Procédures Stockées sont exécutées plus rapidement car elles sont compilées et elles n'ont pas besoin de déplacer les données du serveur vers le client.

---

Date de publication : 05/09/2005 Par Nicolas BARLATIER

Citation:

---

Envoyé par redoran

lire le Pourquoi une procédure stockée ? dans le lien http://barlatier.developpez.com/csha...stockee/cours/ si je ne me trompe pas...
Date de publication : 05/09/2005 Par Nicolas BARLATIER

---

Oui mais tu verras avec l'expérience qu'il n'est pas toujours bon d'utiliser des procédures stockées et que parfois il vaut mieux faire les calculs sur le poste client car faire une procédure stockées prendrait trop de ressource sur le serveur et bloquerait les autres utilisateurs.

:koi: je m'incline devant votre réponse vous avez vue juste :zen: merci de m'avoir éclairé

Surtout que le Pré-Requis de départ, c'est la Création d'une Vue !
C'est la création ou l'accès à la Vue qui prend du temps !

Bonjour,

J'ai essai de remplacer la vue par une requête SQL en utilisant TADOQuery, mais la requête prend toujours plus de temps avec Windows 2003.

J'ai remarqué que dans Windows 2003 le CPU est occupé à plus de 97% par SQL Serveur pendant le temps d'exécution de la requête (plus de 12 min).

tj le même problème, la même version de SQL Serveur (Express), le même exécutable & la même base de données (les fichiers sont copies du poste de développement vers me serveur de production) mais je n'arrive pas à expliquer pour quoi le temps d'exécution est beaucoup plus important sur un serveur (Windows 2003) et un poste XP.

Merci d'avance pour l'aide.

Cdt,
Fouad

salut, selon vos messages précédents

Citation:

---

a) Developpement (laptop HP): Windows XP-SP3 + SQL Server 2005 : 2-6 secs
Developpement (laptop HP): Windows XP-SP3 + SQL Server 2008 : 2-6 secs
Teste (laptop Acer): Windows 7 + SQL Server 2008 : plus de 12 minutes
b) Production (Server HP): Windows 2003 server + SQL Server 2005 : plus de 12 minutes

---

la comparaison permet de constater que:
1) dans A et B que le système utilisé joue un rôle dans le résultat ( toujours selon vos résultats...).
2) voir coté matériels du serveur sinon changer la machine et voir le résultat.
3) s'agit-il d'une version originale ou autre , généralement les problèmes vient avec les versions cracké.
4) coté requêtes :
c'est à revoir je crois qu'elle n'est pas optimisé.
y'a beaucoup de champs ( est ce que c'est utile à affichés tous ces champs....)
coté jointures là .... :koi: je pense qu'il faut revoir ( structure...) .

en résumé je croit qu'il faut passé par le soft après voir avec le hard ( déduit de vos résultats...)
j'espére que j'ai pu apporté quelques :idea:

Bonjour redoran,

Finalement j'ai peut amélioré la vitesse de traitement en utilisant des composants DBexpress.

voir le sujet:
http://www.developpez.net/forums/d96...i/#post5411399

concernant l'optimisation de la requête, je crois qu'elle est assez optimisée, la solution sert à gérer le stock, les entrées/sorties et l'inventaire avec des produit composés (3 niveau). Notre client demande cette vue où il peut voir voir tout le détail d'un article sur une seule fenêtre (peut que je peut utilisé des sous requêtes).

Merci encore une fois pour l'aide.

Cdt,
Fouad