Discussion :

[Shuret]

J'ai un problème de performances anormales sous SQL Server 2000.

Voici la config : serveur bi-proc Xeon, 2 Go de RAM, HDD RAID 5 Ultra 320, sous Windows 2000 Server SP4/SQL Server 2000 dernier SP (le 3 ?).

J'ai des requêtes agrégeantes qui mettent beaucoup trop de temps : 40 minutes au lieu de 2 minutes maxi (voire 40 sec mini) sur un serveur identique. Ce dernier est presque identique : même modèle, seulement 1 Go de RAM, même OS, même SQL Server, dump de la base du serveur d'origine (donc ça ne vient pas des indexes).

Quand on lance une telle requête sur le serveur qui met 40 min, ça rame de partout : les procs sont utilisés à presque 100%, la RAM monte énormément (même après reboot, SQL Server prend 40 Mo, elle monte à plus de 1,5 Go) et il est inutilisable, pas réactif. Alors que sur l'autre, la RAM prend 100 Mo maxi, les procs moins de 20% et on peut faire autre chose en même temps.

J'ai pas mal cherché et rien, c'est pourquoi j'en appelle à vous. Le swap est configuré de la même manière, la fragmentation des disques est à peu près identique (un peu fragmenté mais sans plus). Je vois vraiment pas où chercher.

Des idées ?

Merci !

[SQLpro]

Comparez les valeurs de

Code :

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

sp_configure

sur les deux serveurs

Vérifiez que l'hyperthreading n'est pas activé.

Comparez les @@VERSION des deux serveurs (notamment le n° de build).

A +

[Shuret]

Merci pour la réponse.

Les résultats de sp_configure et @@version sont strictement identiques sur les 2 serveurs.

Voici le contenu, si ça peut aider :

Version :
Microsoft SQL Server 2000 - 8.00.760 (Intel X86) Dec 17 2002 14:22:05 Copyright (c) 1988-2003 Microsoft Corporation Standard Edition on Windows NT 5.0 (Build 2195: Service Pack 4)

sp_configure :

affinity mask,-2147483648,2147483647,0,0
allow updates,0,1,0,0
awe enabled,0,1,0,0
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,2147483647,2147483647
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,0,0
network packet size (B),512,65536,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,0,0
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

Rectification : il n'y a qu'un processeur dans chaque serveur, mais l'Hyperthreading est activé sur les 2. J'ai essayé de le désactiver sur celui qui fonctionne bien, les temps de réponse sont sembables, mais il semble un peu moins réactif (mais il ne rame pas autant que l'autre).

[SQLpro]

Désactivez l'hyperthreading pour celui qui marche mal. Le bug de l'hyperthreading qui et un bug de fonderie du a Intel est connu et entâche les serveur Citrix et SQL Server.

A +

[Shuret]

Après quelques recherches, j'ai vu en effet que l'Hyperthreading pouvait nuire aux performances sous SQL Server. Je l'ai donc désactivé mais ça n'a rien changé... Cela peut-il venir du matériel ? Même si les serveurs sont basés sur le même modèle, il y a des différences. J'ai comparé les résultats donnés par CPUZ et les voici en gros :

Serveur lent :
CPU Intel Xeon 3,40 GHz Nocona
RAM : 2048 Mo (4x512 Mo DDR PC 3200 dont 2 barettes Samsung et 2 Micron)
Timings : CAS# 3.0, 4.0, 5.0 pour les 2 barettes Samsung, CAS# 3.0, 4.0 pour les Micron.

Serveur rapide :
CPU Intel Xeon 3,20 GHz Nocona
RAM : 1024 Mo (2x512 Mo DDR PC 3200, 2 barettes Nanya)
Timings : CAS# 3.0, 4.0, 5.0 pour les 2 barettes.

Peut-être qu'une barette de RAM est défectueuse ? Ou le proc overclocké et il ne supporte pas la charge ?

[SQLpro]

1Go c'est quand même très peu. Je dirais même trop peu suivant le volume des données que vous avez à traiter.
Quel est le cache hit ratio ?

A +

[Shuret]

Justement, c'est sur le serveur qui n'a que 1 Go que les traitements se font le plus vite...

Je n'ai pas d'outil de monitoring configuré actuellement, je ne peux pas donner le cache hit ratio. Dans tous les cas, je ne pense pas que ça m'aide vu que les requêtes sont les mêmes.

[elsuket]

Bonjour,

Le cache hit ratio peut être suivi en temps réel sous PerfMon:
- démarrer / exécuter : tapez "Perfmon"
- clic-droit sur le graphe : propriétés
- dans l'onglet "Données", cliquez sur supprimer jusqu'à ce qu'il n'y ait plus de compteurs
- cliquez sur le bouton "Ajouter"
- activez le radio : "Choisir les compteurs sur :", puis choisissez votre serveur
- sélectionnez la valeur "Buffer Manager" dans la liste des "objets de performance"
- après activation du radio "sélectionner les compteurs dans la liste", choisissez "taux d'accès au cache des tampons", puis cliquez sur le bouton "ajouter", puis sur le bouton "Fermer"

Le graphe affiche la valeur courante de votre taux d'accès au cache des tampons, en Anglais le fameux Buffer Cache Hit Ratio : c'est le pourcentage de pages trouvées en mémoire tampon par rapport au nombre de pages devant être lues à partir du disque.
Donc, plus il est proche de 100, plus les performances de votre serveur sont bonnes.

Vous pouvez aussi obtenir cette valeur en requêtant sys.sysperfinfo.

Alors, quel est-il ?

[Shuret]

Bonjour,

J'ai essayé hier perfmon sur le serveur mais il n'y a pas de "Buffer manager" dans la liste des objets de performance. Y-a t'il quelque chose à faire pour activer cette option ?

Merci.

[SQLpro]

Apparemment si les compteurs sont absents c'est qu'il y a une mauvaise installation.

A +

[Shuret]

Une mauvaise installation de SQL Server ?

[elsuket]

Bonjour,

Effectivement, si les compteurs de SQL Server ne sont pas disponibles, il s'agit d'une mauvaise installation de SQL Server.
Le nom de l'objet de performance n'est pas exactement Buffer Manager mais SQLServer:Buffer Manager ...

[Shuret]

Alors sur mes 3 serveurs * :

- un des 2 qui fonctionne mal n'a pas les compteurs SQL Server
- celui qui fonctionne bien a un cache hit ratio qui tourne dans les 99,2 % pendant l'exécution d'une requête "lourde"
- l'autre qui fonctionne mal mais qui a les compteurs a un cache hit ratio qui tourne plutôt dans les 93 % avec cette même requête

* j'ai 3 serveurs en fait :
- 2 en prod identiques qui rament
- 1 en test identique aux 2 autres sauf la RAM (1 Go au lieu de 2) et le proc (3,20 GHz au lieu de 3,40). Bien qu'il soit moins "bien", ce dernier fonctionne bien mieux

Faut-il s'alarmer sur ce 93 % ou cela reste t-il raisonnable ? La requête n'est pas terminée (40 min au moins), je donnerai la valeur moyenne quand elle sera finie.

En tout cas merci pour l'aide !

[elsuket]

Bonsoir,

93% c'est très mauvais, 99.2% est bon.

Je commencerais par regarder si les statistiques des colonnes sont à jour : EXEC sp_updatestats.
Vérifie dans les propriétés de la base de données que les statistiques se mettent à jour automatiquement (je crois par clic droit sur la base données ou encore avec la commande EXEC sp_autostats)

Il serait aussi bon de regarder le taux de fragmentation des indexes à l'aide de la commande DBCC SHOWCONTIG (maTable).
Un peu de lecture ici et là

Si ton serveur de développement a exactement la même structure de données que tes serveurs de production, regarde le plan de requête des procédures stockées les plus appelées sur le serveur de développement (je ne me rappelle plus comment on fait pour le visualiser sous SQL Server 2000, mais tu dois pouvoir trouver cela dans le Query Analyzer).
Cela te donnera une seconde indication sur les indexes qui pourraient manquer à ta base de données.

Dans la documentation de SQL Server 2000, en filtrant les articles de l'index sur "Programmeur de bases de données" et en tapant "plan de requête", tu trouveras toutes les icônes du plan de requête graphique, et tu pourras identifier les points faibles de tes requêtes et de l'indexation de ta BD (les principaux sont Bookmark Lookup, Clustered Index Scan, Hash Match et ses copains ...)

Bref, tu as du pain sur la planche

[SQLpro]

Bizzarement j'ai posté une réponse qui a disparue...

Bref pour expliquer :

93% signifie que 93 requêtes sont faites directement en mémoire et que 7 doivent lire le disque. Sachant qu'un accès disque est au minimum 1000 fois plus couteux qu'un accès mémoire, cela veut dire que le temps de réponse moyen est de :
93 * 1 + 7 * 1000 = 7093/100 = 71

99,2% signifie que 99,2 requêtes sont faites directement en mémoire et que 0.3 doivent lire le disque.
99.2 * 1 + 0.8 * 1000 = 899/100 = 9

le ratio est donc de 71/9 = 7,88

Vous nous indiquez des temps de réponse de 2 et 40 minutes, soit un facteur de 20 Ce qui est proche du facteur calculé précédemment. De plus il faut compter avec la concurrence....

A +

[Shuret]

SQLPro > merci pour l'explication claire. C'est vrai que même si 93% peut paraitre un bon cache hit ratio, il peut expliquer la lenteur des réponses.

elsuket > j'ai passé un coup de EXEC sp_updatestats, les stats ont été mises à jour. Elles sont de toute façon mises à jour automatiquement (case cochée dans les propriétés de la base).

Par contre si je fais un EXEC sp_autostats 'EVENEMENTS' j'ai un resultset vide. EVENEMENTS étant la table sur laquelle je fais les requêtes agrégeantes posant problème.

Voici le résultat du DBCC SHOWCONTIG ('EVENEMENTS'), généré en 3'16 :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
DBCC SHOWCONTIG analyse la table 'EVENEMENTS'...
Table : 'EVENEMENTS' (277576027); index ID = 1, base de données ID = 7
Analyse du niveau TABLE effectuée.
- Pages analysées................................: 283557
- extensions analysées...........................: 35584
- extensions commutées..........................: 35584
- Moy des pages par extension...............: 8.0
- Densité d'analyse [meilleure valeur du compte réel].......: 99.61% [35445:35585]
- Fragmentation d'analyse logique..: 0.00%
- Fragmentation d'analyse d'extension..: 0.83%
- Moy octets libres par page.....................: 620.0
- Densité de page moy (pleine)...........: 92.34%
Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur, contactez l'administrateur du système.

Voici celui de l'autre serveur qui rame :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
DBCC SHOWCONTIG analyse la table 'EVENEMENTS'...
Table : 'EVENEMENTS' (277576027); index ID = 1, base de données ID = 7
Analyse du niveau TABLE effectuée.
- Pages analysées................................: 293135
- extensions analysées...........................: 36788
- extensions commutées..........................: 36787
- Moy des pages par extension...............: 8.0
- Densité d'analyse [meilleure valeur du compte réel].......: 99.60% [36642:36788]
- Fragmentation d'analyse logique..: 1.59%
- Fragmentation d'analyse d'extension..: 0.76%
- Moy octets libres par page.....................: 617.5
- Densité de page moy (pleine)...........: 92.37%
Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur, contactez l'administrateur du système.

Aucune procédure stockée n'est utilisée dans la requête que je lance pour tester les performances ou dans toutes celles utilisées dans le reporting qui met 3h. Les indexes sur la table EVENEMENTS sont identiques d'un serveur à l'autre. J'ai en plus défragmenté la table EVENEMENTS la semaine dernière mais aucun amélioration constatée... Les showcontig sont bons ?

[SQLpro]

Oui, ils sont bons. Maintenant sans connaitre ni la structure de la table, ni le traitement il est impossible de te dire ou cela pêche.

premier remède mettre de la RAM

Peut tu poster le DDL de la table ?

Peut tu poster ton traitement ?

A +

[Shuret]

Voici la structure de la table avec les indexes :

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
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
CREATE TABLE [dbo].[EVENEMENTS] (
	[EVENEMENTS_ID] [numeric](9, 0) NOT NULL ,
	[EVENEMENTS_CMN] [char] (3) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
	[EVENEMENTS_NSLCD] [char] (3) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
	[EVENEMENTS_SN] [varchar] (9) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
	[EVENEMENTS_CG] [numeric](3, 0) NULL ,
	[EVENEMENTS_CDA] [varchar] (2) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
	[EVENEMENTS_AU] [varchar] (20) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
	[EVENEMENTS_SI] [varchar] (4) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
	[EVENEMENTS_MDA] [char] (1) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
	[EVENEMENTS_DTE] [datetime] NULL ,
	[EVENEMENTS_HE] [datetime] NULL ,
	[EVENEMENTS_PM] [char] (1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
	[EVENEMENTS_MYP] [char] (2) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
	[EVENEMENTS_TD] [char] (1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
	[EVENEMENTS_TA] [char] (1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
	[EVENEMENTS_JRBQ] [numeric](3, 0) NULL ,
	[EVENEMENTS_DTRBQ] [datetime] NULL ,
	[EVENEMENTS_MTOP] [numeric](16, 0) NULL ,
	[EVENEMENTS_MNOP] [varchar] (4) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
	[EVENEMENTS_MTCVP] [numeric](16, 0) NULL ,
	[EVENEMENTS_MNCVP] [varchar] (4) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
	[EVENEMENTS_SIT] [char] (1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
	[EVENEMENTS_CPC] [varchar] (12) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
	[EVENEMENTS_TTP] [char] (1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
	[EVENEMENTS_CRO] [char] (1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
	[EVENEMENTS_BQ] [char] (5) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
	[EVENEMENTS_GU] [char] (5) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
	[EVENEMENTS_NC] [varchar] (11) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
	[EVENEMENTS_RIB] [varchar] (2) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
	[EVENEMENTS_TCP] [varchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
	[EVENEMENTS_TCR] [numeric](1, 0) NULL ,
	[EVENEMENTS_NCR] [varchar] (23) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
	[EVENEMENTS_DTFV] [varchar] (4) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
	[EVENEMENTS_CC] [varchar] (8) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
	[EVENEMENTS_CR] [varchar] (5) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
	[EVENEMENTS_MV] [varchar] (2) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
	[EVENEMENTS_CMS] [varchar] (2) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
	[EVENEMENTS_CSC] [varchar] (3) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
	[EVENEMENTS_CCO] [char] (3) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
	[EVENEMENTS_CAM] [varchar] (13) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
	[EVENEMENTS_FA] [char] (1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
	[EVENEMENTS_NA] [varchar] (6) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
	[EVENEMENTS_MA] [numeric](16, 0) NULL ,
	[EVENEMENTS_DTLA] [datetime] NULL ,
	[EVENEMENTS_HLA] [datetime] NULL ,
	[EVENEMENTS_CRA] [varchar] (2) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
	[EVENEMENTS_CL] [varchar] (100) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
	[EVENEMENTS_RAQ] [char] (1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
	[EVENEMENTS_NVFRAQ] [numeric](12, 0) NULL ,
	[EVENEMENTS_TRAV] [varchar] (1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
	[EVENEMENTS_NVFRAP] [numeric](12, 0) NULL ,
	[EVENEMENTS_TRCT] [char] (1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
	[EVENEMENTS_NVFCT] [numeric](12, 0) NULL ,
	[EVENEMENTS_TRDI] [char] (1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
	[EVENEMENTS_CRDI] [varchar] (2) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
	[EVENEMENTS_NVFDT] [numeric](12, 0) NULL ,
	[EVENEMENTS_TRHE] [char] (1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
	[EVENEMENTS_NVFRHE] [numeric](12, 0) NULL ,
	[EVENEMENTS_RD] [varchar] (30) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
	[EVENEMENTS_RF] [varchar] (30) COLLATE SQL_Latin1_General_CP1_CI_AS NULL 
) ON [PRIMARY]
GO
 
 CREATE  CLUSTERED  INDEX [EVENEMENTS_Index_DTE] ON [dbo].[EVENEMENTS]([EVENEMENTS_DTE]) WITH  FILLFACTOR = 90,  PAD_INDEX  ON [PRIMARY]
GO
 
 CREATE  INDEX [EVENEMENTS_Index_MTOP] ON [dbo].[EVENEMENTS]([EVENEMENTS_MTOP]) WITH  FILLFACTOR = 90 ON [PRIMARY]
GO
 
 CREATE  INDEX [EVENEMENTS_Index_CPC] ON [dbo].[EVENEMENTS]([EVENEMENTS_CPC]) WITH  FILLFACTOR = 90 ON [PRIMARY]
GO
 
 CREATE  INDEX [EVENEMENTS_Index_RF] ON [dbo].[EVENEMENTS]([EVENEMENTS_RF]) WITH  FILLFACTOR = 90 ON [PRIMARY]
GO
 
 CREATE  INDEX [EVENEMENTS_Index_NCR] ON [dbo].[EVENEMENTS]([EVENEMENTS_NCR]) WITH  FILLFACTOR = 90 ON [PRIMARY]
GO
 
 CREATE  INDEX [EVENEMENTS_Index_RD] ON [dbo].[EVENEMENTS]([EVENEMENTS_RD]) WITH  FILLFACTOR = 90 ON [PRIMARY]
GO

La requête utilisée pour l'exemple :

Code :

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

1
2
3
4
5
6
7
SELECT COUNT(*) AS NB, SUM(EVENEMENTS_MTOP) AS MONTANT, DATEPART(MM, EVENEMENTS_DTE) AS MOIS 
FROM EVENEMENTS
WHERE EVENEMENTS_CMN='TEL' AND EVENEMENTS_SI='S036' AND EVENEMENTS_CL LIKE 'SE%'
AND DATEPART(YYYY, EVENEMENTS_DTE) = 2008
AND DATEPART(MM,EVENEMENTS_DTE) <= 09
GROUP BY DATEPART(MM, EVENEMENTS_DTE)
ORDER BY DATEPART(MM, EVENEMENTS_DTE) ASC

La table EVENEMENTS contient un peu plus de 6 millions d'enregistrements. Ajouter de la RAM ne changera rien : mon problème n'est pas la lenteur d'exécution de cette requête (qui doit pouvoir être optimisée d'ailleurs), mais le fait que sur un serveur identique et légèrement moins puissant (et avec moins de RAM) elle mette 1 min et sur un autre 40. Si j'avais simplement un problème de lenteur, j'aurais essayé d'optimiser la requête et les indexes. Là je veux juste comprendre pourquoi à configuration identique j'ai des temps de réponse pourris. Ou pourquoi j'ai un cache hit ratio de 93%, ce qui semble être également une conséquence du problème.

[SQLpro]

1) créez une table de date et indexez là. Par exemple

Code :

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

1
2
3
4
CREATE TABLE T_DAT (DAT        DATETIME NOT NULL PRIMARY KEY,
                    DAT_AN     SMALLINT NOT NULL),
                    DAT_MOIS   TINYINT NOT NULL;
CREATE INDEX X_DAT_ANMOI ON T_DAT (DAT_AN, DAT_MOIS);

2) peuplez là avec toutes les dates (2000 à 2100 par exemple

Code :

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

1
2
3
4
5
6
7
DECLARE @D DATETIME
SET @D = '20000101'
WHILE @D <= '21001231'
BEGIN
   INSERT INTO T_DAT VALUES (@D, YEAR(@D), MONTH(@D))
   SET @D = @D + 1
END

3) récrivez votre requête ainsi

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
SELECT COUNT(*) AS NB, SUM(EVENEMENTS_MTOP) AS MONTANT, 
       D_DAT_AN, D.DAT_MOIS
FROM   dbo.EVENEMENTS AS E
       INNER JOIN dbo.T_DAT AS D
             ON E.EVENEMENTS_DTE = D.DAT   
WHERE  EVENEMENTS_CMN='TEL' 
   AND EVENEMENTS_SI='S036' 
   AND EVENEMENTS_CL LIKE 'SE%'
   AND D.DAT_AN = 2008
   AND D.DAT_MOIS <= 09
GROUP BY D_DAT_AN, D.DAT_MOIS
ORDER BY D_DAT_AN, D.DAT_MOIS ASC

4) indexez votre table dbo.EVENEMENTS comme suit :

Code :

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

1
2
3
4
 
CREATE INDEX X_EVT  
   ON dbo.EVENEMENTS (EVENEMENTS_SI, EVENEMENTS_CMN, EVENEMENTS_CL) 
   INCLUDE (EVENEMENTS_MTOP);

NOTA : cette syntaxe (INCLUDE) n'étant valable que pour 2005, pour 2000, faites l'index suivant :

Code :

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

1
2
3
 
CREATE INDEX X_EVT  
   ON dbo.EVENEMENTS (EVENEMENTS_SI, EVENEMENTS_CMN, EVENEMENTS_CL, EVENEMENTS_MTOP);

5) exécutez la requête.

vous devriez passer à moins d'une minute.

[Shuret]

Alors là chapeau !

La requête n'a mis que 30 secondes !

Je vais pouvoir faire le tour des requêtes qui posent problème et les réécrire en prenant en compte la nouvelle table de date. Beaucoup des requêtes utilisées dans cette appli font des agrégats sur mois et année, et celles concernant la table EVENEMENTS sont super lentes depuis quelques mois. Je modifierai éventuellement l'index sur la table EVENEMENTS pour coller aux autres requêtes. En tout cas merci pour la précision et l'efficacité de vos renseignements !

Merci aussi à elsuket, j'en ai appris pas mal sur SQL Server cette semaine !

Ca ne me dit pas pourquoi j'ai une différence entre les serveurs, mais je n'aurai plus ce problème.