Discussion :

[PickEpique]

Je poste ici a cause de la spécificité des CTEs de SQLserver
J'ai quelques problèmes avec la vue suivante

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
41
42
43
44
45
46
47
48
49
50
51
52
53
 
CREATE VIEW [dbo].[V_DEVPART_ALL_DPT1]
AS
WITH Descendants (ID, LVL, NUM)
AS
(
-- Ancre
    SELECT A.DPT_ID, 0 AS LVL, CAST(A.DPT_ORD AS VARCHAR(32)) AS NUM
    FROM T_DEVPART_DPT A 
	WHERE A.DPT_PID IS NULL
    UNION ALL
-- Partie Recursive 
    SELECT B.DPT_ID, P.LVL+1 AS LVL, CAST(P.NUM + '-' + CAST(B.DPT_ORD AS VARCHAR(4)) AS VARCHAR(32)) 
    FROM T_DEVPART_DPT B 
	INNER JOIN Descendants P ON B.DPT_PID = P.ID
)
--Utlisation de la cte
SELECT     
	A.DPT_ID,
	T.LVL AS DPT_LVL,
	T.NUM AS DPT_NUM,
	A.DEV_ID,
	A.DPT_PID,
	A.DPT_ORD,
	A.DPT_STYPE, 
	A.DPT_FAMILLE,
	A.DPT_SFAMILLE,
	A.DPT_REF,
	A.DPT_LIBELLE, 
	A.DPT_QTE,
	A.DPT_UNITP,
	B.UPU_QTE,
	A.DPT_PUA1,
	A.DPT_PUA2,
	A.DPT_PUVHF,
	A.DPT_PUV1,
	A.DPT_PUVF,
	A.DPT_MT_AJUST, 
	A.DPT_NB_HRS_MO,
	A.DPT_MT_MO,
	A.DPT_PUA1 * A.DPT_QTE * (1 / B.UPU_QTE) AS DPT_PTA1,
	A.DPT_PUA2 * A.DPT_QTE * (1 / B.UPU_QTE) AS DPT_PTA2,
	A.DPT_PUVHF * A.DPT_QTE * (1 / B.UPU_QTE) AS DPT_PTVHF,
	A.DPT_PUV1 * A.DPT_QTE * (1 / B.UPU_QTE) AS DPT_PTV1,
	A.DPT_PUVF * A.DPT_QTE * (1 / B.UPU_QTE) AS DPT_PTVF,
	A.DPT_TEXTCOM,
	A.DPT_REF_DEEE,
	A.DPT_CODE_DEEE,
	A.DPT_UNIT_DEEE, 
	A.DPT_MT_DEEE
FROM 
	T_DEVPART_DPT AS A INNER JOIN Descendants AS T ON (A.DPT_ID = T.ID)
		LEFT OUTER JOIN T_UNITPU_UPU AS B ON (A.DPT_UNITP = B.UPU_CODE);

Quand je l'utilise depuis le client ou Management studio avec par exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
SET STATISTICS IO ON
SET STATISTICS TIME ON
select * from V_DEVPART_ALL_DPT1 where DEV_ID = 9470

alors que la plupart du temps j'obtiens - de 400 ms sur 4500 lignes renvoyées, de temps en temps cela monte à plus de 4 secondes
comme si la partie récursive s'executait sur l'ensemble de la table avant
d'etre restreinte par la jointure, je ne sais pas si je me fait bien comprendre,
sinon pourquoi cette différence

[Ptit_Dje]

Salut,

Pourquoi cette différence ?
- Surcharge réseau ?
- Surcharge serveur ?
- Un ptit lock sur la table ?
- Les controlleurs disques trop occupés que pour avoir le temps de te retourner tes data...
- Le cache vient d'être vidé ?
- ...

Est ce que l'execution plan varie entre les fois ou tu as tes données en 400ms et celles ou tu les as en 4 secondes ?

[PickEpique]

je n'ai pas vérifié tout les points dont tu parle mais à priori
ce n'est pas un des 5 premiers , je suis seul sur un nouveau serveur
Le point sur le plan d'exec il faudrait que je m'y penche, depuis Management studio car je ne sais pas comment faire cela depuis mon appli cliente (Ado + delphi)
En y regardant de plus près la lenteur avec Management studio semble effectivement être réglée en envoyant dans la table des données plus nombreuses (60 000) , bizarement avec juste un set de 5000 lignes j'avais de mauvais résultats
Bon maintenant une autre chose m'étonne si la requête sur la vue me retourne 15 lignes cela fait 353 ms et 3247 lignes = 517 ms pourquoi aussi peu de différence parce que coté client la requète (process complet ) met environ 600 ms et cela fait trop pour un 15 lignes, dans les 2 as j'ai le même plan , mais la sortie avec
SET STATISTICS IO ON
SET STATISTICS TIME ON
me donne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
(3247*ligne(s) affectée(s))
Table 'T_UNITPU_UPU'. Nombre d'analyses 1, lectures logiques 6495, lectures physiques 0, lectures anticipées 0, lectures logiques de données d'objets volumineux 0, lectures physiques de données d'objets volumineux 0, lectures anticipées de données d'objets volumineux 0.
Table 'T_DEVPART_DPT'. Nombre d'analyses 13548, lectures logiques 87828, lectures physiques 0, lectures anticipées 0, lectures logiques de données d'objets volumineux 0, lectures physiques de données d'objets volumineux 0, lectures anticipées de données d'objets volumineux 0.
Table 'Worktable'. Nombre d'analyses 2, lectures logiques 81272, lectures physiques 0, lectures anticipées 0, lectures logiques de données d'objets volumineux 0, lectures physiques de données d'objets volumineux 0, lectures anticipées de données d'objets volumineux 0.
 
SQL Server \endash  Temps d'exécution*:
, Temps UC = 391*ms, temps écoulé = 517*ms.

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
(15*ligne(s) affectée(s))
Table 'T_UNITPU_UPU'. Nombre d'analyses 1, lectures logiques 31, lectures physiques 0, lectures anticipées 0, lectures logiques de données d'objets volumineux 0, lectures physiques de données d'objets volumineux 0, lectures anticipées de données d'objets volumineux 0.
Table 'T_DEVPART_DPT'. Nombre d'analyses 13548, lectures logiques 81364, lectures physiques 0, lectures anticipées 0, lectures logiques de données d'objets volumineux 0, lectures physiques de données d'objets volumineux 0, lectures anticipées de données d'objets volumineux 0.
Table 'Worktable'. Nombre d'analyses 2, lectures logiques 81272, lectures physiques 0, lectures anticipées 0, lectures logiques de données d'objets volumineux 0, lectures physiques de données d'objets volumineux 0, lectures anticipées de données d'objets volumineux 0.
 
SQL Server \endash  Temps d'exécution*:
, Temps UC = 328*ms, temps écoulé = 353*ms.

[SQLpro]

le temps écoulé n'a aucun intérêt car il prend en compte toute ce qui se passe en dehors de SQL Server, par exemple le déclenchement d'un envoi de mail ou le passage de la souris sur l'écran. Seul le temps CPU est intéressant. Mais pas très révélateur car il eput lui aussi différer sensiblement par exemple si le serveur est chargé et décide d'interrompre le processus (time sharing) donc il y aura aussi les temps de chargement/déchargement... Le plus intéressant est d'abord le nombre de pages de données scrutées.

SET STATISTICS IO ON

A +

[PickEpique]

Bonjour

Ce nombre de page scrutées, s'agit il du nombre de lecture logique; ce qui m'étonne dans mon cas c'est qu'il est pratiquement le même sur la table T_DEVPART_DPT, que la requète sur la vue ramène 15 ou 3200 lignes, ce qui me fait penser que ma condition
WHERE DEV_ID = NUM_devis1 (16 lignes)
WHERE DEV_ID = NUM_devis2 (3200 lignes)
n'agit pas sur le travail total de ma requète
Je ne connait pas le fonctionnement interne du SGBD mais il semble normal de penser que le travail total est nettement inférieur avec 15 lignes