Discussion :

[Batou69]

Bonjour à tous,

Nous rencontrons un sérieux problème de fonctionnement sur un site qui utilise SQL Server 2012.

- Nous utilisons SQL 2012 Standard x64 11.0.5058 (SP2) sur une machine équipée de 64Go de ram et 16 coeurs.
- Nous avons environ 50 tables. La plus grosse table de la base fait 140 000 lignes et la moyenne est d'environ 20 000.
- La base est répliquée sur le même serveur. De plus le serveur est dupliqué en temps réel avec Double Take
- Nous avons pour politique interne de n'utiliser que des procédures stockées pour nos requêtes.

Le problème est que les procédures prennent un temps fou à s'éxécuter. Certaines procédures qui mettent quelques millisecondes à s’exécuter en temps normal, prennent certains jours 10 secondes (jusqu'a 25s) à chaque exécution !.
Après de nombreuses investigations, nous avons découvert qu'elles ne restent pas dans le cache.

En fait sur le serveur nous avons environ 200 connexions et 500 PS. Seules 2 d'entre elles restent dans le cache en permanence (pourquoi ces deux là ?), les autre disparaissent toutes d'un coup à intervalles réguliers. Je sais que la recompilation d'une procédure est normal dans le cas de changement de stats par exemple, mais seulement les procédures impactées par ladite stat.
Le buffer cache est utilisé à 10%.
Si on regarde le plan du cache, lorsqu'il y est, le nombre de lignes estimé est souvent délirant pour une des tables. J'ai tenté de mettre à jours les statistiques à la main pour cette table. La performance est meilleure, sans etre au top, et surtout cela reste très provisoire.

Nous avons une grande habitude de SQL Server dans les versions précédentes et nous n'avons jamais rencontré ce problème.

Comment pouvons nous déterminer l'origine du problème ???

Merci pour votre aide !!

[hmira]

Juste pour confirmer vos propos :

Que donne le résultat de la requête ci-dessous :

Code SQL :

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

1
2
3
4
5
6
7
SELECT objtype  AS 'Cached_Object_Type',
count(*) AS 'Nombre_Plans',
sum(cast(size_in_bytes AS BIGINT))/1024/1024 AS 'Plan_Cache_Size_in_MB',
avg(usecounts) AS 'Avg_Use_Count'
FROM sys.dm_exec_cached_plans
GROUP BY objtype
GO

A+

[Batou69]

Le résultat :

Cached_Object_Type	Nombre_Plans	Plan_Cache_Size_in_MB	Avg_Use_Count
UsrTab	1	0	3516
Prepared	16	1	143
View	28	4	3954
AdHoc	35298	1233	12
Check	4	0	188
Trigger	4	0	158
Proc	192	163	755

Donc tout le cache est occupé par des requetes adhoc. Or nous n'utilisons pas ce genre de requetes (sauf pour les diags, tests, devs... ce qui est temporaire).
En fait le cache est rempli d'appel aux procédures avec les arguments différents :

exec MaProcedure 1,3
exec MaProcédure 1,5....

J'ai regardé sur nos autre serveurs en production en 2008R2 et la requete que vous m'avez donné est plutot du genre :

Cached_Object_Type	Nombre_Plans	Plan_Cache_Size_in_MB	Avg_Use_Count
UsrTab	6	0	14421
Prepared	30	3	833
View	114	11	5
AdHoc	3450	156	175
Check	20	0	8
Trigger	5	0	3
Proc	352	107	13164

Je précise que nous utilisons toujours la même DLL d'accès à la base de données et que l'application est de même type avec un certain nombre de programmes identique sans toutefois être une copie conforme.

[SQLpro]

Pourquoi cette réplication et comment est-elle faite ?
(peut être justement pourrie t-elle votre cache...)

Pourquoi Double Take et non pas le mirroring ou AlwaysON ?
Double take ne garantie pas le reprise d'une base de données MS SQL Server... du fait des opérations asynchrones entre fichiers de données et JT !

êtes vous sur de votre version ?
Pouvez vous nous donner le résultat de la requête suivante :

Code :

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

1
2
3
SELECT @@VERSION;
EXEC xp_msver;
SELECT * FROM sys.configurations;

Vos procédures contiennent-elles des commandes DDL (CREATE, ALTER, DROP) ? notamment pour les tables temporaires ???

A +

[hmira]

Oui, effectivement, il y a manifestement une différence de comportement entre votre Serveur de prod (SQL Server 2008 R2 ) et le Seveur SQL 2012 !
Ci-dessous quelques pistes à vérifier
- Vérifiez et comparer (entre les 2 Serveurs) le paramétrage de la base de données ( PARAMETERIZATION) SIMPLE ou FORCED (?). En effet ce paramétrage (PARAMETERIZATION = FORCED) peut limiter la prolifération des requêtes AdHoc. Mais si ce paramétrage n'était actif pour la base de données, sur le Serveur de prod SQL Server 2008 R2, il n'y a aucune raison de l'activer pour la base dans l'environnement SQL Server 2012, tant que vous n'avez déterminé les causes exacts du problème dans un environnement censé être presque identique.

- Vérifier le contenu des ces fameuses requête SQL AdHoc (à partir de leur plan_handle), Vérifier si celles-ci proviennent bien de vos applications ou si leur texte ne vous évoquent rien et au quel elle proviendraient d'autres applications qui vous ne gérez pas et vous ne connaissez pas (?)
-- Exemple :

Code SQL :

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

1
2
3
4
5
6
7
select p.refcounts, p.usecounts, p.plan_handle, s.text
from sys.dm_exec_cached_plans as p
cross apply sys.dm_exec_sql_text (p.plan_handle) as s
where p.cacheobjtype = 'compiled plan'
and p.objtype = 'adhoc'
AND p.usecounts <= 3 
order by p.usecounts asc

- Vérifiez, par exemple avec le profiler, si les connexions de vos applications ne modifient pas les options SET de façons non homogène d'une session à une autre de vos application. En effet, les options SET font partie intégrante du cahe plan, et les modifier fait en sorte qu'un plan déjà existant compilé avec d'autres options SET ne sera pas réutilisé (voir sys.dm_exec_plan_attributes (plan_handle)).

Voilà j'espère que d'autres experts sur ce forum (et il y en a !) vous donneront d'autres conseils et d'autres pistes à explorer ...

A+

PS : A propos d'expert ! j'avais pas vu la réponse de SQLPro ci-dessus !

[Batou69]

Pourquoi cette réplication et comment est-elle faite ?
(peut être justement pourrie t-elle votre cache...)

La réplication est transactionnelle en push dans une base située dans la même instance sur le serveur.
Bon dis comme ça, cela parait débile mais : je ne réplique que les insert et update, pas les delete. Cela constitue donc une base de données d'historique que je peut vider selon un délai différent de la base dite de production.
J'ai pas trouvé mieux pour constituer une base historique sans développer d'usine à gaz. de plus le jour ou j'ai a besoin d'un peu plus de puissance je met en place deux serveurs différents sans changer notre méthode, l'abonné pouvant se trouver n'importe où.
Si vous avez mieux et plus simple je suis preneur....

Pourquoi Double Take et non pas le mirroring ou AlwaysON ?

Plusieurs raisons :

• Always on est nouveau et je ne sait pas m'en servir, je ne sais pas non plus quelles sont exactement ses possibilités (on aime pas changer de techno sans savoir si elle marche !!!)
• Les deux techniques SQL que vous citez ne mirrorent pas le système. Donc sur le serveur répliqué on est obligé de maintenir les applications à jour
• Double take est imposé par le client comme solution de sécurisation des serveurs, mais je doute qu'il sache quelles sont les conséquence sur SQL

Double take ne garantie pas le reprise d'une base de données MS SQL Server... du fait des opérations asynchrones entre fichiers de données et JT !

Ca je ne le savait pas, mais cela ne m'étonne pas du tout.... Je vais en parler au chef du projet qui sera ravi de l'apprendre

êtes vous sur de votre version ?
Pouvez vous nous donner le résultat de la requête suivante :
SELECT @@VERSION;
EXEC xp_msver;
SELECT * FROM sys.configurations;

Résultat : (désolé je ne sais pas copier les résultats proprement)
SELECT @@VERSION;

Code :

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

1
2
3
4
5
 
Microsoft SQL Server 2012 - 11.0.5058.0 (X64) 
	May 14 2014 18:34:29 
	Copyright (c) Microsoft Corporation
	Standard Edition (64-bit) on Windows NT 6.2 <X64> (Build 9200: )

EXEC xp_msver;

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
 
ProductName;NULL;Microsoft SQL Server
ProductVersion;720896;11.0.5058.0
Language;1036;Français (France)
Platform;NULL;NT x64
Comments;NULL;SQL
CompanyName;NULL;Microsoft Corporation
FileDescription;NULL;SQL Server Windows NT - 64 Bit
FileVersion;NULL;2011.0110.5058.00 ((SQL11_PCU_Main).140514-1820 )
InternalName;NULL;SQLSERVR
LegalCopyright;NULL;Microsoft Corp. All rights reserved.
LegalTrademarks;NULL;Microsoft SQL Server is a registered trademark of Microsoft Corporation.
OriginalFilename;NULL;SQLSERVR.EXE
PrivateBuild;NULL;NULL
SpecialBuild;331481088;NULL
WindowsVersion;331481088;6.2 (9200)
ProcessorCount;16;16
ProcessorActiveMask;NULL;            ffff
ProcessorType;8664;NULL
PhysicalMemory;65491;65491 (68671807488)
Product ID;NULL;NULL

SELECT * FROM sys.configurations;

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
 
101;recovery interval (min);0;0;32767;0;Maximum recovery interval in minutes;1;1
102;allow updates;0;0;1;0;Allow updates to system tables;1;0
103;user connections;0;0;32767;0;Number of user connections allowed;0;1
106;locks;0;5000;2147483647;0;Number of locks for all users;0;1
107;open objects;0;0;2147483647;0;Number of open database objects;0;1
109;fill factor (%);0;0;100;0;Default fill factor percentage;0;1
114;disallow results from triggers;0;0;1;0;Disallow returning results from triggers;1;1
115;nested triggers;1;0;1;1;Allow triggers to be invoked within triggers;1;0
116;server trigger recursion;1;0;1;1;Allow recursion for server level triggers;1;0
117;remote access;1;0;1;1;Allow remote access;0;0
124;default language;2;0;9999;2;default language;1;0
400;cross db ownership chaining;0;0;1;0;Allow cross db ownership chaining;1;0
503;max worker threads;0;128;65535;0;Maximum worker threads;1;1
505;network packet size (B);4096;512;32767;4096;Network packet size;1;1
518;show advanced options;1;0;1;1;show advanced options;1;0
542;remote proc trans;0;0;1;0;Create DTC transaction for remote procedures;1;0
544;c2 audit mode;0;0;1;0;c2 audit mode;0;1
1126;default full-text language;1036;0;2147483647;1036;default full-text language;1;1
1127;two digit year cutoff;2049;1753;9999;2049;two digit year cutoff;1;1
1505;index create memory (KB);0;704;2147483647;0;Memory for index create sorts (kBytes);1;1
1517;priority boost;0;0;1;0;Priority boost;0;1
1519;remote login timeout (s);10;0;2147483647;10;remote login timeout;1;0
1520;remote query timeout (s);600;0;2147483647;600;remote query timeout;1;0
1531;cursor threshold;-1;-1;2147483647;-1;cursor threshold;1;1
1532;set working set size;0;0;1;0;set working set size;0;1
1534;user options;0;0;32767;0;user options;1;0
1535;affinity mask;0;-2147483648;2147483647;0;affinity mask;1;1
1536;max text repl size (B);4194304;-1;2147483647;4194304;Maximum size of a text field in replication.;1;0
1537;media retention;0;0;365;0;Tape retention period in days;1;1
1538;cost threshold for parallelism;5;0;32767;5;cost threshold for parallelism;1;1
1539;max degree of parallelism;0;0;32767;0;maximum degree of parallelism;1;1
1540;min memory per query (KB);1024;512;2147483647;1024;minimum memory per query (kBytes);1;1
1541;query wait (s);-1;-1;2147483647;-1;maximum time to wait for query memory (s);1;1
1543;min server memory (MB);0;0;2147483647;16;Minimum size of server memory (MB);1;1
1544;max server memory (MB);32768;128;2147483647;32768;Maximum size of server memory (MB);1;1
1545;query governor cost limit;0;0;2147483647;0;Maximum estimated cost allowed by query governor;1;1
1546;lightweight pooling;0;0;1;0;User mode scheduler uses lightweight pooling;0;1
1547;scan for startup procs;1;0;1;1;scan for startup stored procedures;0;1
1549;affinity64 mask;0;-2147483648;2147483647;0;affinity64 mask;1;1
1550;affinity I/O mask;0;-2147483648;2147483647;0;affinity I/O mask;0;1
1551;affinity64 I/O mask;0;-2147483648;2147483647;0;affinity64 I/O mask;0;1
1555;transform noise words;0;0;1;0;Transform noise words for full-text query;1;1
1556;precompute rank;0;0;1;0;Use precomputed rank for full-text query;1;1
1557;PH timeout (s);60;1;3600;60;DB connection timeout for full-text protocol handler (s);1;1
1562;clr enabled;0;0;1;0;CLR user code execution enabled in the server;1;0
1563;max full-text crawl range;4;0;256;4;Maximum  crawl ranges allowed in full-text indexing;1;1
1564;ft notify bandwidth (min);0;0;32767;0;Number of reserved full-text notifications buffers;1;1
1565;ft notify bandwidth (max);100;0;32767;100;Max number of full-text notifications buffers;1;1
1566;ft crawl bandwidth (min);0;0;32767;0;Number of reserved full-text crawl buffers;1;1
1567;ft crawl bandwidth (max);100;0;32767;100;Max number of full-text crawl buffers;1;1
1568;default trace enabled;1;0;1;1;Enable or disable the default trace;1;1
1569;blocked process threshold (s);0;0;86400;0;Blocked process reporting threshold;1;1
1570;in-doubt xact resolution;0;0;2;0;Recovery policy for DTC transactions with unknown outcome;1;1
1576;remote admin connections;0;0;1;0;Dedicated Admin Connections are allowed from remote clients;1;0
1579;backup compression default;1;0;1;1;Enable compression of backups by default;1;0
1580;filestream access level;0;0;2;0;Sets the FILESTREAM access level;1;0
1581;optimize for ad hoc workloads;0;0;1;0;When this option is set, plan cache size is further reduced for single-use adhoc OLTP workload.;1;1
1582;access check cache bucket count;0;0;65536;0;Default hash bucket count for the access check result security cache;1;1
1583;access check cache quota;0;0;2147483647;0;Default quota for the access check result security cache;1;1
16384;Agent XPs;1;0;1;1;Enable or disable Agent XPs;1;1
16386;Database Mail XPs;0;0;1;0;Enable or disable Database Mail XPs;1;1
16387;SMO and DMO XPs;1;0;1;1;Enable or disable SMO and DMO XPs;1;1
16388;Ole Automation Procedures;0;0;1;0;Enable or disable Ole Automation Procedures;1;1
16390;xp_cmdshell;0;0;1;0;Enable or disable command shell;1;1
16391;Ad Hoc Distributed Queries;0;0;1;0;Enable or disable Ad Hoc Distributed Queries;1;1
16392;Replication XPs;0;0;1;0;Enable or disable Replication XPs;1;1
16393;contained database authentication;0;0;1;0;Enables contained databases and contained authentication;1;0

Vos procédures contiennent-elles des commandes DDL (CREATE, ALTER, DROP) ? notamment pour les tables temporaires ???

Nous n'utilsons ni curseurs, ni tables temporaires directement. Les procédures sont uniquement constituées d'une commande select, insert, update ou delete. En revanche, nous utilisons très intensivement les CTE, parfois plus de 20 à 30 dans certaines requetes extrêmes...

Pour ce qui est du serveur :
La base tempdb est sur le disque système (oui je sais c'est pas bien) mais on a que 2 disques et on a préféré la séparer des disques de données normales. elle comporte 8 fichiers comme suggéré par pas mal de posts sur le sujet....
Le plan de maintenance est effectué toutes les nuit hors production, il réorganise ou reconstruit les index selon le taux de fragmentation (entre 10 et 30% reorg, > 30% rebuild)
On effectue aussi un update systématique des statistiques qui on plus d'un jour. MAIS : il y a boulette dans le script car on utilise les options par défaut et donc il me semble qu'il fait un sample de la table, pas un fullscan.

A+

[SQLpro]

La réplication est transactionnelle en push dans une base située dans la même instance sur le serveur.
Bon dis comme ça, cela parait débile mais : je ne réplique que les insert et update, pas les delete. Cela constitue donc une base de données d'historique que je peut vider selon un délai différent de la base dite de production.
J'ai pas trouvé mieux pour constituer une base historique sans développer d'usine à gaz. de plus le jour ou j'ai a besoin d'un peu plus de puissance je met en place deux serveurs différents sans changer notre méthode, l'abonné pouvant se trouver n'importe où.
Si vous avez mieux et plus simple je suis preneur....

Vous feriez mieux d'utiliser change tracking ou change data capture et faire le différentiel aux heures creuses

Plusieurs raisons :

• Always on est nouveau et je ne sait pas m'en servir, je ne sais pas non plus quelles sont exactement ses possibilités (on aime pas changer de techno sans savoir si elle marche !!!)
• Les deux techniques SQL que vous citez ne mirrorent pas le système. Donc sur le serveur répliqué on est obligé de maintenir les applications à jour
• Double take est imposé par le client comme solution de sécurisation des serveurs, mais je doute qu'il sache quelles sont les conséquence sur SQL

AlwaysOn est extrêmement fiable. Nous l'utilisons par exemple pour Geodis sur une base de 7 To.

Vous avez donc des applications sur le serveur. C'est probablement cela qui fait que votre système est bancal. SQL Server doit être installé sur un serveur dédié et aucune autre application ni service ne doit tourner sur ce serveur, pas même un antivirus !

SELECT * FROM sys.configurations;

vous devriez régler correctement le parallélisme :
1) cost threshold for parallelism à 12 ou 24
2) max degree of parallelism à 2 ou 4

Pourquoi un max server memory à 32768 ? avez-vous d'autres instances sur le même serveur ? d'autres applications ? d'autres services ??? Lesquels ??????
Si non, alors mettez 60 Go

Placez le OPTIMIZE FOR ad hoc workloads à 1

Pour ce qui est du serveur :
La base tempdb est sur le disque système (oui je sais c'est pas bien) mais on a que 2 disques et on a préféré la séparer des disques de données normales. elle comporte 8 fichiers comme suggéré par pas mal de posts sur le sujet....

sur le disque local, c'est bien. Mais en revanche 8 fichiers c'est beaucoup. Passez à 4 et régler le parallélisme à 4 maximum. Faites de même pour votre base de production => 4 fichiers d'égale longueur pour les données

Le plan de maintenance est effectué toutes les nuit hors production, il réorganise ou reconstruit les index selon le taux de fragmentation (entre 10 et 30% reorg, > 30% rebuild)

vous voulez dire "aux heures creuses" ?

On effectue aussi un update systématique des statistiques qui on plus d'un jour. MAIS : il y a boulette dans le script car on utilise les options par défaut et donc il me semble qu'il fait un sample de la table, pas un fullscan.

Ce serait mieux !

A +

[Batou69]

Vous avez donc des applications sur le serveur. C'est probablement cela qui fait que votre système est bancal. SQL Server doit être installé sur un serveur dédié et aucune autre application ni service ne doit tourner sur ce serveur, pas même un antivirus !

J'entends ce discours très souvent, et dans nos formations SQL on nous le répète souvent. Sur le papier je suis d'accord.

Mais nous sommes dans une environnement logistique et industriel, les coûts sont la préoccupation permanente de nos décideurs. Séparer le serveur SQL des autres applications revient à acheter 2+2=4 serveurs (à cause de la sécurisation). Ce coût est trop important pour nos clients et nos installations pour le moment.


D'autre part nous travaillons aussi pour des clients comme Geodis. Et il n'est pas question de se passer d'antivirus.
Cela est la plupart du temps imposé par le client. Nous avons eu des sites de production à l'arrêt à cause d'une infection.

Il est déjà difficile de négocier un accès à distance sur le serveur de prod, alors si on dit en plus qu'il n'y a pas d'anti virus, c'est le refus direct.
Malheureusement la plupart du temps nous avons à faire à des décideurs qui ne connaissent pas grand chose aux réseaux....

vous devriez régler correctement le parallélisme :
1) cost threshold for parallelism à 12 ou 24
2) max degree of parallelism à 2 ou 4

Je connais ces paramètres mais ne voyais pas la relation avec mes problèmes de cache vide.
J'ai fait la modif et cela se passe nettement mieux !!

Pourquoi un max server memory à 32768 ? avez-vous d'autres instances sur le même serveur ? d'autres applications ? d'autres services ??? Lesquels ??????
Si non, alors mettez 60 Go

C'est corrigé. Et non pas d'autres instances sur le serveur.

Placez le OPTIMIZE FOR ad hoc workloads à 1

Ok c'est fait aussi. Bien que je ne comprenne pas bien pourquoi je sois obligé de faire cela alors que nous n'utilisons que des PS. J'ai noté que la majorité des plans en cache (30000 sur 35000) étaient des 'FECTH API_CURSOR....'
J'ai l'impression que c'est ce paramètre qui a arrangé le plus les choses.....

sur le disque local, c'est bien. Mais en revanche 8 fichiers c'est beaucoup. Passez à 4 et régler le parallélisme à 4 maximum. Faites de même pour votre base de production => 4 fichiers d'égale longueur pour les données

Avez vous un tuto, un post ou une documentation qui expliquerai cela ? Je croyais que la parallélisation était faite au groupe de fichier pas au fichier...

vous voulez dire "aux heures creuses" ?
Ce serait mieux !

Oui lorsque le serveur n'est plus sollicité


En tous les cas, je vous remercie pour votre aide précieuse !!!

A+

[hmira]

C'est corrigé. Et non pas d'autres instances sur le serveur.

Quelle valeur avez-vous définie pour "Max Server Memory" ?
La valeur de 60 Go proposée, à juste titre par SQLPro, était sous l'hypothèse qu'il n'y avait rien d'autre sur le serveur (pas d'antivirus, etc..), or, semble-t-il, ce n'est pas votre cas.
Pouvez-vous nous donner le résultat de la requête ci-dessous :

Code SQL :

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

1
2
SELECT max_workers_count
from sys.dm_os_sys_info

A+

[Batou69]

Quelle valeur avez-vous définie pour "Max Server Memory" ?
La valeur de 60 Go proposée, à juste titre par SQLPro, était sous l'hypothèse qu'il n'y avait rien d'autre sur le serveur (pas d'antivirus, etc..), or, semble-t-il, ce n'est pas votre cas.

Oui en effet, nous avons d'autres programmes qui tournent.Alors, j'ai opté pour une valeur raisonnable par rapport à l'utilisation actuelle du serveur : le mini à 16Go et le max à 43Go car le buffer cache est à 30% plein avec cette valeur. Le PLE est à 7 Jours.
Le mini est là pour prévenir qu'un autre programme nous bouffe toute la ram (un petit bug d'un collègue )

Cela va faire bondir certains mais on a 200 sessions TS sur ce serveur aussi, il faut bien leur laisser un peu de place....

Mais je vous rassure, elles servent uniquement pour un écran d'affichage sans clavier ni souris. Quelques Mo de ram tout au plus et quasiment pas de CPU.


Je crois tout de même que pour une base qui fait 150Mo au total et qui ne devrait pas grossir, avoir 40Go de ram, ca suffit non ???

Pouvez-vous nous donner le résultat de la requête ci-dessous :

Code SQL :

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

1
2
SELECT max_workers_count
from sys.dm_os_sys_info

Heuuuuu : 704

A+

[hmira]

Votre Serveur est actuellement surdimensionné par rapport à la charge réelle, avec un PLE à 7 jour ! etc..

Il faudra évidement mesurer plus précisément les besoins réelles en mémoire des autres applications (autres que SQL Server) etc..

Si la valeur 43 Go pour le paramètre "Max Server Memory" vous donne entière satisfaction alors gardez la jusqu'à nouvel ordre (Pression mémoire externe ou interne sur SQL Server).

Souvenez-vous juste que, compte tenu de votre environnement actuel, vous ne devez pas aller au delà de 58 Go pour Max Server Memory.

A+

[Batou69]

Votre Serveur est actuellement surdimensionné par rapport à la charge réelle, avec un PLE à 7 jour ! etc..

Oui on aime pas avoir des problèmes de performance avec la base chez nos clients. Et puis nos bases sont de taille très modestes comparées à la ram disponible maintenant.

Souvenez-vous juste que, compte tenu de votre environnement actuel, vous ne devez pas aller au delà de 58 Go pour Max Server Memory.

Je connaissait la "regle" du 80/20 et celle de Glenn Berry, mais je ne vois pas ce qui permet de trouver 58Go ?

A+

[hmira]

Je connaissait la "regle" du 80/20 et celle de Glenn Berry, mais je ne vois pas ce qui permet de trouver 58 Go ?

Ci-dessous l'explication détaillée.

En fait, il faut :

1 - Réserver au moins 2 Go pour Windows +
2 - Réserver 2 Mo par worker Thread (dans votre cas soit 704 * 2 Mo soit environ 1,4 Go) +
3 - 512 Mo (soit 0,5 Go) pour les Serveurs liés, les procédures étendues (DLLs) et les objets créés par automation (sp_OA Calls) +
4 - 1 à 3 Go pour les autres applications. Sur ce dernier point j'ai opté pour une "cote mal taillée" de 2 Go.
Remarque : Sur ce dernier point, comme je l'ai indiqué ci-haut, il faudra évidemment effectuer des mesures plus précises (Cf MSSQL$<instance>:Memory Manager\Total Server Memory (KB) counter etc.) .

Donc, ce qui nous fait un total de 5,9 Go, que j'ai arrondi à 6 Go.

Donc, soit 64 Go - 6 Go = 58 Go CQFD !

A+

[Babyneedle]

J'entends ce discours très souvent, et dans nos formations SQL on nous le répète souvent. Sur le papier je suis d'accord.

Mais nous sommes dans une environnement logistique et industriel, les coûts sont la préoccupation permanente de nos décideurs. Séparer le serveur SQL des autres applications revient à acheter 2+2=4 serveurs (à cause de la sécurisation). Ce coût est trop important pour nos clients et nos installations pour le moment.

Les entreprises ne peuvent pas avoir le beurre et l'argent du beurre. Si elles ne peuvent pas se permettre une infra décente avec SQL Server, qu'elles passent à ProsgreSQL ou MySQL.

C'est une excuse que j'entends souvent de la part de personnes avec peu d'expérience (ou une expérience médiocre). Surtout dans un contexte industriel, ce qui coute cher, c'est la lenteur des systèmes et le downtime.

Il n'y a pas de magie. Un serveur partagé = performances médiocres. Fin de l'histoire.

[mikedavem]

Je suis de l'avis de Babyneedle mais peut être pas aussi radicale

Bien souvent et je le vois chez mes clients, lorsqu'il s'agit d'avoir vraiment de la performance il faut bien souvent les moyens qui vont avec. Il n'y pas forcément besoin d'avoir des serveurs ultra puissants mais une bonne architecture applicative et de bases de données associée fait bien souvent l'affaire. On le voit encore ici où finalement le problème de performance est plus lié à une configuration "bancale" qu'à un réel problème de matériel qui peut s'avérer coûteux ici (vu de loin ... il faudrait avoir le détail technique du matériel acheté ici).

La question de l'antivirus revient souvent effectivement et là je suis plus modéré. Effectivement l'absence d'antivirus n'est souvent pas compliante avec les standards de sécurité des entreprises et on peut comprendre leurs craintes ... il faut bien entendu mesurer les facteurs de risque comme la valeur des informations sur le serveur, le niveau se sécurité requis, le coût en cas de perte ou de vol etc ... Maintenant on peut tout à fait bien configurer un antivirus avec les exclusions qui vont bien. Dans le cas de Batou69 vu de loin je dirais que l'antivirus n'est pas vraiment un problème ici à moins de prouver le contraire. Dans les environnements "haute performances" effectivement un choix doit être fait car tout comme autre application externe à SQL Server celui va venir consommer des ressources qui peuvent être nécessaires à SQL Server.

++

[Batou69]

Les entreprises ne peuvent pas avoir le beurre et l'argent du beurre. Si elles ne peuvent pas se permettre une infra décente avec SQL Server, qu'elles passent à ProsgreSQL ou MySQL.

C'est une excuse que j'entends souvent de la part de personnes avec peu d'expérience (ou une expérience médiocre). Surtout dans un contexte industriel, ce qui coute cher, c'est la lenteur des systèmes et le downtime.

Il n'y a pas de magie. Un serveur partagé = performances médiocres. Fin de l'histoire.

Je pense que ce n'est pas si simple que cela. Il y a tout un tas de facteurs à prendre en compte et parmi ceux là, il y a la technique, la volumétrie, le prix, le temps de réponse souhaité etc....
Je ne crois pas que l'on puisse généraliser même si votre affirmation reste vraie dans bien des domaines.

Pour notre part, on a des besoins modestes alors on fait avec des moyens qui vont avec. Le problème dans le cas précis, c'est que le passage à 2012 fait que ce que nous faisons habituellement ne réagit pas de la même façon. Alors oui on est pas dans les règles de l'art.... mais on ne fait pas non plus des trucs de dingue : des base de quelque centaines de Mo tout au plus et des processus nécessitant des temps de réponse max de 500 millisecondes.... rien d'extraordinaire.
Il faut aussi, parfois, savoir ne pas utiliser un canon pour tuer une mouche.

A+


Edit : erreur de base de données sur le forum Developpez : priceless...

[Batou69]

Pour info, et pour rebondir sur le sujet actuel de mélanger SQL avec application, nous avons toujours des requêtes qui "partent en vrille".

En examinant le cache d’exécution (qui ne se vide plus maintenant) on s'appercoit que pour certaines tables, le nombre de lignes estimées reste toujours à 1 mais le nombre de lignes réel est de plusieurs centaines de millier.

La réalité c'est que la table en question contient 350 lignes.....

Un remise à jour manuelle des statistiques, et tout rentre dans l'ordre.

Je ne pense pas que ce phénomène soit dû à une quelconque interaction entre les applications présente sur le serveur et SQL.

[mikedavem]

En examinant le cache d’exécution (qui ne se vide plus maintenant) on s'appercoit que pour certaines tables, le nombre de lignes estimées reste toujours à 1 mais le nombre de lignes réel est de plusieurs centaines de millier.

Là il faudrait avoir le détail d'une de tes requêtes et son plan d'exécution associé pour que l'on puisse t'aider ... mais effectivement ici ton problème n'a rien à voir avec un partage d'application sur ton serveur SQL ... ne mélangeons pas les problèmes

++

[SQLpro]

Je biens de terminer une mission pour Geodis à Paris (mise en haute dispo via AlwaysOn de la production Cargo Wise... base de 7 To).
J'ai découvert pas mal d'énormités sur les installations SQL Server et le paramétrage des bases et nous les avons fait remontées...
Il ne faut pas sacrifier le discours. Si l'on veut des performances et que l'on ne s'en donne pas les moyens, alors l'histoire est finie !

J'entends ce discours très souvent, et dans nos formations SQL on nous le répète souvent. Sur le papier je suis d'accord.

Mais nous sommes dans une environnement logistique et industriel, les coûts sont la préoccupation permanente de nos décideurs. Séparer le serveur SQL des autres applications revient à acheter 2+2=4 serveurs (à cause de la sécurisation). Ce coût est trop important pour nos clients et nos installations pour le moment.

Certains serveurs peuvent être en VM, mieux vaut pas pour SQL Server car souvent on tombe sur des problèmes d'IO à cause des disques virtuels ou des SAN mutrualisés. 2 à 3 Serveurs suffisent, car nous pouvons nous payer le luxe de croiser les applis :
avec 2 serveur : l'un à la base active et l'application inactive. L'autre à la base inactive et l’application active. Ainsi en fonctionnement normal vous avez toute la puissance à disposition et une bonne séparation des rôles. En cas de panne, vous récupérez la charge sur le seul serveur survivant... temporairement !

D'autre part nous travaillons aussi pour des clients comme Geodis. Et il n'est pas question de se passer d'antivirus.

Si vous n'avez que du SQL Server alors DMZ, donc, pas d'AV. Sinon, au minimum excluez tous les fichiers de toutes les bases (système compris)

Cela est la plupart du temps imposé par le client. Nous avons eu des sites de production à l'arrêt à cause d'une infection.

Il est déjà difficile de négocier un accès à distance sur le serveur de prod, alors si on dit en plus qu'il n'y a pas d'anti virus, c'est le refus direct.
Malheureusement la plupart du temps nous avons à faire à des décideurs qui ne connaissent pas grand chose aux réseaux....


Je connais ces paramètres mais ne voyais pas la relation avec mes problèmes de cache vide.
J'ai fait la modif et cela se passe nettement mieux !!

SQL Server parallélise les requêtes qui dépassent un certains seuil et cela sur tous les CPU. Mais pour être efficace, le parallélisme doit être architecturalement complet :
- au niveau RAM via les noeuds NUMA (ne pas dépasser le nombre de nœuds NUMA)
- au niveau disque via les fichiers de chaque base (autant que de nœuds NUMA)
- être relativement restreint afin de permettre de servir plusieurs "clients" à la fois.
Exemple : 4 CPU à 8 coeurs, donc en principe 4 noeuds NUMA => base de prod et tempdb avec 4 fichiers de data d'égale longueur situé sur des axes physiques difféfrents
=> maxdop = 4

C'est corrigé. Et non pas d'autres instances sur le serveur.


Ok c'est fait aussi. Bien que je ne comprenne pas bien pourquoi je sois obligé de faire cela alors que nous n'utilisons que des PS. J'ai noté que la majorité des plans en cache (30000 sur 35000) étaient des 'FECTH API_CURSOR....'
J'ai l'impression que c'est ce paramètre qui a arrangé le plus les choses.....


Avez vous un tuto, un post ou une documentation qui expliquerai cela ? Je croyais que la parallélisation était faite au groupe de fichier pas au fichier...

Créez un nouveau groupe de fichier appelé DATA avec 4 fichiers
Déplacer vos objets par ALTER INNDEX REBUILD TO FileGroup...
Videz les anciens fichiers (DBCC SHRINKFILE (...empty..)
Supprimez les anciens fichier

Oui lorsque le serveur n'est plus sollicité


En tous les cas, je vous remercie pour votre aide précieuse !!!

A+

A +

[Batou69]

Là il faudrait avoir le détail d'une de tes requêtes et son plan d'exécution associé pour que l'on puisse t'aider ... mais effectivement ici ton problème n'a rien à voir avec un partage d'application sur ton serveur SQL ... ne mélangeons pas les problèmes

++

Bon alors c'est un peu difficile de donner toute la structure des tables impliquées dans cette requete mais j'ai le plan d'execution. Et il montre que le moteur se gourre complétement dans le nombre de lignes estimées. Dans le cas présent c'est pas énorme, mais parfois c'est beaucoup plus grave et cela ralentit tout le moteur.
La "solution" trouvée est de faire un 'update stats' toutes les heures

La requete :

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
 
WITH
       CTE_UOW AS
       (
             SELECT 
                    UOW.NO_UOW
             FROM
                    DBO.UOW
             INNER JOIN
                    TRACETRI.PLAN_TRI_EN_COURS PTR
             ON
                    UOW.NO_PORTEFEUILLE = PTR.NO_PORTEFEUILLE
             where
                    UOW.ETAT_UOW = 2
             GROUP BY
                    UOW.NO_UOW
 
       )
       SELECT
                    CTE_UOW.NO_UOW
		FROM
			CTE_UOW
		JOIN
			UOW_SUPPORT UOS
		ON
			CTE_UOW.NO_UOW = UOS.NO_UOW
		JOIN   
			SUPPORT SUP
		ON
			SUP.NO_SUPPORT = UOS.NO_SUPPORT
			AND SUP.NO_CONTENEUR IS NULL

A noter que le nombre d'io est asser comique aussi :

Code :

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

1
2
3
4
5
6
7
 
(153*ligne(s) affectée(s))
Table 'SUPPORT'. Nombre d'analyses 0, lectures logiques 1074, 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 'UOW_SUPPORT'. Nombre d'analyses 10, lectures logiques 23, 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 'EVENEMENT_PLAN_TRI'. Nombre d'analyses 11, lectures logiques 41, 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 'PLAN_TRI'. Nombre d'analyses 10, lectures logiques 20, 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 'UOW'. Nombre d'analyses 1, lectures logiques 2, 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.

Le nombre de lectures logiques de la table SUPPORT est sans relation avec le nombre de lignes dans la table (actuellement 351) et ce chiffre n'est pas dans le plan d'execution...
Je n'y comprend plus rien...

Code :

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

1
2
 
<ShowPlanXML xmlns="http://schemas.microsoft.com/sqlserver/2004/07/showplan" Version="1.2" Build="11.0.5058.0"><BatchSequence><Batch><Statements><StmtSimple StatementText="WITH&#xd;&#xa;       CTE_UOW AS&#xd;&#xa;       (&#xd;&#xa;             SELECT &#xd;&#xa;                    UOW.NO_UOW&#xd;&#xa;             FROM&#xd;&#xa;                    DBO.UOW&#xd;&#xa;             INNER JOIN&#xd;&#xa;                    TRACETRI.PLAN_TRI_EN_COURS PTR&#xd;&#xa;             ON&#xd;&#xa;                    UOW.NO_PORTEFEUILLE = PTR.NO_PORTEFEUILLE&#xd;&#xa;             where&#xd;&#xa;                    UOW.ETAT_UOW = 2&#xd;&#xa;             GROUP BY&#xd;&#xa;                    UOW.NO_UOW&#xd;&#xa; &#xd;&#xa;       )&#xd;&#xa;&#xd;&#xa;&#xd;&#xa;       SELECT&#xd;&#xa;                    CTE_UOW.NO_UOW&#xd;&#xa;&#x9;&#x9;FROM&#xd;&#xa;&#x9;&#x9;&#x9;CTE_UOW&#xd;&#xa;&#x9;&#x9;JOIN&#xd;&#xa;&#x9;&#x9;&#x9;UOW_SUPPORT UOS&#xd;&#xa;&#x9;&#x9;ON&#xd;&#xa;&#x9;&#x9;&#x9;CTE_UOW.NO_UOW = UOS.NO_UOW&#xd;&#xa;&#x9;&#x9;JOIN   &#xd;&#xa;&#x9;&#x9;&#x9;SUPPORT SUP&#xd;&#xa;&#x9;&#x9;ON&#xd;&#xa;&#x9;&#x9;&#x9;SUP.NO_SUPPORT = UOS.NO_SUPPORT&#xd;&#xa;&#x9;&#x9;&#x9;AND SUP.NO_CONTENEUR IS NULL&#xd;&#xa;" StatementId="1" StatementCompId="1" StatementType="SELECT" RetrievedFromCache="true" StatementSubTreeCost="0.0298486" StatementEstRows="22.8915" StatementOptmLevel="FULL" QueryHash="0xEA7AE501E762BCAB" QueryPlanHash="0xCB509BEB7B103E17" StatementOptmEarlyAbortReason="GoodEnoughPlanFound"><StatementSetOptions QUOTED_IDENTIFIER="true" ARITHABORT="true" CONCAT_NULL_YIELDS_NULL="true" ANSI_NULLS="true" ANSI_PADDING="true" ANSI_WARNINGS="true" NUMERIC_ROUNDABORT="false"/><QueryPlan DegreeOfParallelism="1" CachedPlanSize="56" CompileTime="8" CompileCPU="8" CompileMemory="992"><MemoryGrantInfo SerialRequiredMemory="0" SerialDesiredMemory="0"/><OptimizerHardwareDependentProperties EstimatedAvailableMemoryGrant="256000" EstimatedPagesCached="256000" EstimatedAvailableDegreeOfParallelism="4"/><RelOp NodeId="0" PhysicalOp="Nested Loops" LogicalOp="Inner Join" EstimateRows="22.8915" EstimateIO="0" EstimateCPU="0.000255909" AvgRowSize="15" EstimatedTotalSubtreeCost="0.0298486" Parallel="0" EstimateRebinds="0" EstimateRewinds="0" EstimatedExecutionMode="Row"><OutputList><ColumnReference Database="[TRACE_TRI_ITM]" Schema="[dbo]" Table="[UOW]" Column="NO_UOW"/></OutputList><RunTimeInformation><RunTimeCountersPerThread Thread="0" ActualRows="174" ActualEndOfScans="1" ActualExecutions="1"/></RunTimeInformation><NestedLoops Optimized="0"><OuterReferences><ColumnReference Database="[TRACE_TRI_ITM]" Schema="[dbo]" Table="[UOW_SUPPORT]" Alias="[UOS]" Column="NO_SUPPORT"/></OuterReferences><RelOp NodeId="1" PhysicalOp="Nested Loops" LogicalOp="Inner Join" EstimateRows="61.2222" EstimateIO="0" EstimateCPU="0.000255909" AvgRowSize="23" EstimatedTotalSubtreeCost="0.0167884" Parallel="0" EstimateRebinds="0" EstimateRewinds="0" EstimatedExecutionMode="Row"><OutputList><ColumnReference Database="[TRACE_TRI_ITM]" Schema="[dbo]" Table="[UOW]" Column="NO_UOW"/><ColumnReference Database="[TRACE_TRI_ITM]" Schema="[dbo]" Table="[UOW_SUPPORT]" Alias="[UOS]" Column="NO_SUPPORT"/></OutputList><RunTimeInformation><RunTimeCountersPerThread Thread="0" ActualRows="605" ActualEndOfScans="1" ActualExecutions="1"/></RunTimeInformation><NestedLoops Optimized="0"><OuterReferences><ColumnReference Database="[TRACE_TRI_ITM]" Schema="[dbo]" Table="[UOW]" Column="NO_UOW"/></OuterReferences><RelOp NodeId="2" PhysicalOp="Stream Aggregate" LogicalOp="Aggregate" EstimateRows="1" EstimateIO="0" EstimateCPU="1e-006" AvgRowSize="15" EstimatedTotalSubtreeCost="0.0131832" Parallel="0" EstimateRebinds="0" EstimateRewinds="0" EstimatedExecutionMode="Row"><OutputList><ColumnReference Database="[TRACE_TRI_ITM]" Schema="[dbo]" Table="[UOW]" Column="NO_UOW"/></OutputList><RunTimeInformation><RunTimeCountersPerThread Thread="0" ActualRows="14" ActualEndOfScans="1" ActualExecutions="1"/></RunTimeInformation><StreamAggregate><DefinedValues/><GroupBy><ColumnReference Database="[TRACE_TRI_ITM]" Schema="[dbo]" Table="[UOW]" Column="NO_UOW"/></GroupBy><RelOp NodeId="3" PhysicalOp="Nested Loops" LogicalOp="Inner Join" EstimateRows="1" EstimateIO="0" EstimateCPU="4.18e-006" AvgRowSize="15" EstimatedTotalSubtreeCost="0.0131822" Parallel="0" EstimateRebinds="0" EstimateRewinds="0" EstimatedExecutionMode="Row"><OutputList><ColumnReference Database="[TRACE_TRI_ITM]" Schema="[dbo]" Table="[UOW]" Column="NO_UOW"/></OutputList><RunTimeInformation><RunTimeCountersPerThread Thread="0" ActualRows="14" ActualEndOfScans="1" ActualExecutions="1"/></RunTimeInformation><NestedLoops Optimized="0"><OuterReferences><ColumnReference Database="[TRACE_TRI_ITM]" Schema="[TraceTri]" Table="[EVENEMENT_PLAN_TRI]" Alias="[EPT]" Column="NO_PLAN_TRI"/><ColumnReference Column="Expr1009"/></OuterReferences><RelOp NodeId="4" PhysicalOp="Nested Loops" LogicalOp="Inner Join" EstimateRows="1" EstimateIO="0" EstimateCPU="4.18e-006" AvgRowSize="27" EstimatedTotalSubtreeCost="0.00989442" Parallel="0" EstimateRebinds="0" EstimateRewinds="0" EstimatedExecutionMode="Row"><OutputList><ColumnReference Database="[TRACE_TRI_ITM]" Schema="[dbo]" Table="[UOW]" Column="NO_UOW"/><ColumnReference Database="[TRACE_TRI_ITM]" Schema="[TraceTri]" Table="[EVENEMENT_PLAN_TRI]" Alias="[EPT]" Column="NO_PLAN_TRI"/><ColumnReference Column="Expr1009"/></OutputList><RunTimeInformation><RunTimeCountersPerThread Thread="0" ActualRows="14" ActualEndOfScans="1" ActualExecutions="1"/></RunTimeInformation><NestedLoops Optimized="0"><Predicate><ScalarOperator ScalarString="[TRACE_TRI_ITM].[TraceTri].[EVENEMENT_PLAN_TRI].[NO_PLAN_TRI] as [EPT].[NO_PLAN_TRI]=[TRACE_TRI_ITM].[TraceTri].[PLAN_TRI].[NO_PLAN_TRI] as [PTR].[NO_PLAN_TRI]"><Compare CompareOp="EQ"><ScalarOperator><Identifier><ColumnReference Database="[TRACE_TRI_ITM]" Schema="[TraceTri]" Table="[EVENEMENT_PLAN_TRI]" Alias="[EPT]" Column="NO_PLAN_TRI"/></Identifier></ScalarOperator><ScalarOperator><Identifier><ColumnReference Database="[TRACE_TRI_ITM]" Schema="[TraceTri]" Table="[PLAN_TRI]" Alias="[PTR]" Column="NO_PLAN_TRI"/></Identifier></ScalarOperator></Compare></ScalarOperator></Predicate><RelOp NodeId="5" PhysicalOp="Nested Loops" LogicalOp="Inner Join" EstimateRows="1" EstimateIO="0" EstimateCPU="4.18e-006" AvgRowSize="19" EstimatedTotalSubtreeCost="0.00660404" Parallel="0" EstimateRebinds="0" EstimateRewinds="0" EstimatedExecutionMode="Row"><OutputList><ColumnReference Database="[TRACE_TRI_ITM]" Schema="[dbo]" Table="[UOW]" Column="NO_UOW"/><ColumnReference Database="[TRACE_TRI_ITM]" Schema="[TraceTri]" Table="[PLAN_TRI]" Alias="[PTR]" Column="NO_PLAN_TRI"/></OutputList><RunTimeInformation><RunTimeCountersPerThread Thread="0" ActualRows="14" ActualEndOfScans="1" ActualExecutions="1"/></RunTimeInformation><NestedLoops Optimized="0"><OuterReferences><ColumnReference Database="[TRACE_TRI_ITM]" Schema="[dbo]" Table="[UOW]" Column="NO_PORTEFEUILLE"/></OuterReferences><RelOp NodeId="6" PhysicalOp="Clustered Index Scan" LogicalOp="Clustered Index Scan" EstimateRows="1" EstimateIO="0.003125" EstimateCPU="0.0001812" AvgRowSize="21" EstimatedTotalSubtreeCost="0.0033062" TableCardinality="22" Parallel="0" EstimateRebinds="0" EstimateRewinds="0" EstimatedExecutionMode="Row"><OutputList><ColumnReference Database="[TRACE_TRI_ITM]" Schema="[dbo]" Table="[UOW]" Column="NO_UOW"/><ColumnReference Database="[TRACE_TRI_ITM]" Schema="[dbo]" Table="[UOW]" Column="NO_PORTEFEUILLE"/></OutputList><RunTimeInformation><RunTimeCountersPerThread Thread="0" ActualRows="14" ActualEndOfScans="1" ActualExecutions="1"/></RunTimeInformation><IndexScan Ordered="1" ScanDirection="FORWARD" ForcedIndex="0" ForceSeek="0" ForceScan="0" NoExpandHint="0" Storage="RowStore"><DefinedValues><DefinedValue><ColumnReference Database="[TRACE_TRI_ITM]" Schema="[dbo]" Table="[UOW]" Column="NO_UOW"/></DefinedValue><DefinedValue><ColumnReference Database="[TRACE_TRI_ITM]" Schema="[dbo]" Table="[UOW]" Column="NO_PORTEFEUILLE"/></DefinedValue></DefinedValues><Object Database="[TRACE_TRI_ITM]" Schema="[dbo]" Table="[UOW]" Index="[PK_UOW]" IndexKind="Clustered"/><Predicate><ScalarOperator ScalarString="[TRACE_TRI_ITM].[dbo].[UOW].[ETAT_UOW]=(2)"><Compare CompareOp="EQ"><ScalarOperator><Identifier><ColumnReference Database="[TRACE_TRI_ITM]" Schema="[dbo]" Table="[UOW]" Column="ETAT_UOW"/></Identifier></ScalarOperator><ScalarOperator><Const ConstValue="(2)"/></ScalarOperator></Compare></ScalarOperator></Predicate></IndexScan></RelOp><RelOp NodeId="7" PhysicalOp="Index Seek" LogicalOp="Index Seek" EstimateRows="1" EstimateIO="0.003125" EstimateCPU="0.0001581" AvgRowSize="11" EstimatedTotalSubtreeCost="0.0032831" TableCardinality="1" Parallel="0" EstimateRebinds="0" EstimateRewinds="0" EstimatedExecutionMode="Row"><OutputList><ColumnReference Database="[TRACE_TRI_ITM]" Schema="[TraceTri]" Table="[PLAN_TRI]" Alias="[PTR]" Column="NO_PLAN_TRI"/></OutputList><RunTimeInformation><RunTimeCountersPerThread Thread="0" ActualRows="14" ActualEndOfScans="14" ActualExecutions="14"/></RunTimeInformation><IndexScan Ordered="1" ScanDirection="FORWARD" ForcedIndex="0" ForceSeek="0" ForceScan="0" NoExpandHint="0" Storage="RowStore"><DefinedValues><DefinedValue><ColumnReference Database="[TRACE_TRI_ITM]" Schema="[TraceTri]" Table="[PLAN_TRI]" Alias="[PTR]" Column="NO_PLAN_TRI"/></DefinedValue></DefinedValues><Object Database="[TRACE_TRI_ITM]" Schema="[TraceTri]" Table="[PLAN_TRI]" Index="[IX_PTR_NO_PORTEFEUILLE]" Alias="[PTR]" TableReferenceId="1" IndexKind="NonClustered"/><SeekPredicates><SeekPredicateNew><SeekKeys><Prefix ScanType="EQ"><RangeColumns><ColumnReference Database="[TRACE_TRI_ITM]" Schema="[TraceTri]" Table="[PLAN_TRI]" Alias="[PTR]" Column="NO_PORTEFEUILLE"/></RangeColumns><RangeExpressions><ScalarOperator ScalarString="[TRACE_TRI_ITM].[dbo].[UOW].[NO_PORTEFEUILLE]"><Identifier><ColumnReference Database="[TRACE_TRI_ITM]" Schema="[dbo]" Table="[UOW]" Column="NO_PORTEFEUILLE"/></Identifier></ScalarOperator></RangeExpressions></Prefix></SeekKeys></SeekPredicateNew></SeekPredicates></IndexScan></RelOp></NestedLoops></RelOp><RelOp NodeId="8" PhysicalOp="Stream Aggregate" LogicalOp="Aggregate" EstimateRows="1" EstimateIO="0" EstimateCPU="1.7e-006" AvgRowSize="19" EstimatedTotalSubtreeCost="0.0032859" Parallel="0" EstimateRebinds="0" EstimateRewinds="0" EstimatedExecutionMode="Row"><OutputList><ColumnReference Database="[TRACE_TRI_ITM]" Schema="[TraceTri]" Table="[EVENEMENT_PLAN_TRI]" Alias="[EPT]" Column="NO_PLAN_TRI"/><ColumnReference Column="Expr1009"/></OutputList><RunTimeInformation><RunTimeCountersPerThread Thread="0" ActualRows="14" ActualEndOfScans="14" ActualExecutions="14"/></RunTimeInformation><StreamAggregate><DefinedValues><DefinedValue><ColumnReference Column="Expr1009"/><ScalarOperator ScalarString="MAX([TRACE_TRI_ITM].[TraceTri].[EVENEMENT_PLAN_TRI].[DATE_EVENEMENT] as [EPT].[DATE_EVENEMENT])"><Aggregate Distinct="0" AggType="MAX"><ScalarOperator><Identifier><ColumnReference Database="[TRACE_TRI_ITM]" Schema="[TraceTri]" Table="[EVENEMENT_PLAN_TRI]" Alias="[EPT]" Column="DATE_EVENEMENT"/></Identifier></ScalarOperator></Aggregate></ScalarOperator></DefinedValue></DefinedValues><GroupBy><ColumnReference Database="[TRACE_TRI_ITM]" Schema="[TraceTri]" Table="[EVENEMENT_PLAN_TRI]" Alias="[EPT]" Column="NO_PLAN_TRI"/></GroupBy><RelOp NodeId="9" PhysicalOp="Index Scan" LogicalOp="Index Scan" EstimateRows="2" EstimateIO="0.003125" EstimateCPU="0.0001592" AvgRowSize="19" EstimatedTotalSubtreeCost="0.0032842" TableCardinality="2" Parallel="0" EstimateRebinds="0" EstimateRewinds="0" EstimatedExecutionMode="Row"><OutputList><ColumnReference Database="[TRACE_TRI_ITM]" Schema="[TraceTri]" Table="[EVENEMENT_PLAN_TRI]" Alias="[EPT]" Column="NO_PLAN_TRI"/><ColumnReference Database="[TRACE_TRI_ITM]" Schema="[TraceTri]" Table="[EVENEMENT_PLAN_TRI]" Alias="[EPT]" Column="DATE_EVENEMENT"/></OutputList><RunTimeInformation><RunTimeCountersPerThread Thread="0" ActualRows="28" ActualEndOfScans="14" ActualExecutions="14"/></RunTimeInformation><IndexScan Ordered="1" ScanDirection="FORWARD" ForcedIndex="0" ForceSeek="0" ForceScan="0" NoExpandHint="0" Storage="RowStore"><DefinedValues><DefinedValue><ColumnReference Database="[TRACE_TRI_ITM]" Schema="[TraceTri]" Table="[EVENEMENT_PLAN_TRI]" Alias="[EPT]" Column="NO_PLAN_TRI"/></DefinedValue><DefinedValue><ColumnReference Database="[TRACE_TRI_ITM]" Schema="[TraceTri]" Table="[EVENEMENT_PLAN_TRI]" Alias="[EPT]" Column="DATE_EVENEMENT"/></DefinedValue></DefinedValues><Object Database="[TRACE_TRI_ITM]" Schema="[TraceTri]" Table="[EVENEMENT_PLAN_TRI]" Index="[IX_DATE_EVT_NO_PLAN_TRI]" Alias="[EPT]" TableReferenceId="1" IndexKind="NonClustered"/></IndexScan></RelOp></StreamAggregate></RelOp></NestedLoops></RelOp><RelOp NodeId="14" PhysicalOp="Index Seek" LogicalOp="Index Seek" EstimateRows="1" EstimateIO="0.003125" EstimateCPU="0.0001581" AvgRowSize="12" EstimatedTotalSubtreeCost="0.0032831" TableCardinality="2" Parallel="0" EstimateRebinds="0" EstimateRewinds="0" EstimatedExecutionMode="Row"><OutputList/><RunTimeInformation><RunTimeCountersPerThread Thread="0" ActualRows="14" ActualEndOfScans="14" ActualExecutions="14"/></RunTimeInformation><IndexScan Ordered="1" ScanDirection="FORWARD" ForcedIndex="0" ForceSeek="0" ForceScan="0" NoExpandHint="0" Storage="RowStore"><DefinedValues/><Object Database="[TRACE_TRI_ITM]" Schema="[TraceTri]" Table="[EVENEMENT_PLAN_TRI]" Index="[IX_DATE_EVT_NO_PLAN_TRI]" Alias="[EPT]" TableReferenceId="2" IndexKind="NonClustered"/><SeekPredicates><SeekPredicateNew><SeekKeys><Prefix ScanType="EQ"><RangeColumns><ColumnReference Database="[TRACE_TRI_ITM]" Schema="[TraceTri]" Table="[EVENEMENT_PLAN_TRI]" Alias="[EPT]" Column="NO_PLAN_TRI"/><ColumnReference Database="[TRACE_TRI_ITM]" Schema="[TraceTri]" Table="[EVENEMENT_PLAN_TRI]" Alias="[EPT]" Column="DATE_EVENEMENT"/></RangeColumns><RangeExpressions><ScalarOperator ScalarString="[TRACE_TRI_ITM].[TraceTri].[EVENEMENT_PLAN_TRI].[NO_PLAN_TRI] as [EPT].[NO_PLAN_TRI]"><Identifier><ColumnReference Database="[TRACE_TRI_ITM]" Schema="[TraceTri]" Table="[EVENEMENT_PLAN_TRI]" Alias="[EPT]" Column="NO_PLAN_TRI"/></Identifier></ScalarOperator><ScalarOperator ScalarString="[Expr1009]"><Identifier><ColumnReference Column="Expr1009"/></Identifier></ScalarOperator></RangeExpressions></Prefix></SeekKeys></SeekPredicateNew></SeekPredicates><Predicate><ScalarOperator ScalarString="[TRACE_TRI_ITM].[TraceTri].[EVENEMENT_PLAN_TRI].[ETAT_PLAN_TRI] as [EPT].[ETAT_PLAN_TRI]=(2)"><Compare CompareOp="EQ"><ScalarOperator><Identifier><ColumnReference Database="[TRACE_TRI_ITM]" Schema="[TraceTri]" Table="[EVENEMENT_PLAN_TRI]" Alias="[EPT]" Column="ETAT_PLAN_TRI"/></Identifier></ScalarOperator><ScalarOperator><Const ConstValue="(2)"/></ScalarOperator></Compare></ScalarOperator></Predicate></IndexScan></RelOp></NestedLoops></RelOp></StreamAggregate></RelOp><RelOp NodeId="16" PhysicalOp="Index Seek" LogicalOp="Index Seek" EstimateRows="61.2222" EstimateIO="0.003125" EstimateCPU="0.000224344" AvgRowSize="15" EstimatedTotalSubtreeCost="0.00334934" TableCardinality="836" Parallel="0" EstimateRebinds="0" EstimateRewinds="0" EstimatedExecutionMode="Row"><OutputList><ColumnReference Database="[TRACE_TRI_ITM]" Schema="[dbo]" Table="[UOW_SUPPORT]" Alias="[UOS]" Column="NO_SUPPORT"/></OutputList><RunTimeInformation><RunTimeCountersPerThread Thread="0" ActualRows="605" ActualEndOfScans="14" ActualExecutions="14"/></RunTimeInformation><IndexScan Ordered="1" ScanDirection="FORWARD" ForcedIndex="0" ForceSeek="0" ForceScan="0" NoExpandHint="0" Storage="RowStore"><DefinedValues><DefinedValue><ColumnReference Database="[TRACE_TRI_ITM]" Schema="[dbo]" Table="[UOW_SUPPORT]" Alias="[UOS]" Column="NO_SUPPORT"/></DefinedValue></DefinedValues><Object Database="[TRACE_TRI_ITM]" Schema="[dbo]" Table="[UOW_SUPPORT]" Index="[IX_UOWS_NO_UOW]" Alias="[UOS]" IndexKind="NonClustered"/><SeekPredicates><SeekPredicateNew><SeekKeys><Prefix ScanType="EQ"><RangeColumns><ColumnReference Database="[TRACE_TRI_ITM]" Schema="[dbo]" Table="[UOW_SUPPORT]" Alias="[UOS]" Column="NO_UOW"/></RangeColumns><RangeExpressions><ScalarOperator ScalarString="[TRACE_TRI_ITM].[dbo].[UOW].[NO_UOW]"><Identifier><ColumnReference Database="[TRACE_TRI_ITM]" Schema="[dbo]" Table="[UOW]" Column="NO_UOW"/></Identifier></ScalarOperator></RangeExpressions></Prefix></SeekKeys></SeekPredicateNew></SeekPredicates></IndexScan></RelOp></NestedLoops></RelOp><RelOp NodeId="17" PhysicalOp="Index Seek" LogicalOp="Index Seek" EstimateRows="1" EstimateIO="0.003125" EstimateCPU="0.0001581" AvgRowSize="9" EstimatedTotalSubtreeCost="0.0128042" TableCardinality="345" Parallel="0" EstimateRebinds="60.1493" EstimateRewinds="0.0728765" EstimatedExecutionMode="Row"><OutputList/><RunTimeInformation><RunTimeCountersPerThread Thread="0" ActualRows="174" ActualEndOfScans="431" ActualExecutions="605"/></RunTimeInformation><IndexScan Ordered="1" ScanDirection="FORWARD" ForcedIndex="0" ForceSeek="0" ForceScan="0" NoExpandHint="0" Storage="RowStore"><DefinedValues/><Object Database="[TRACE_TRI_ITM]" Schema="[dbo]" Table="[SUPPORT]" Index="[IX_SUP_NO_CONTENEUR]" Alias="[SUP]" IndexKind="NonClustered"/><SeekPredicates><SeekPredicateNew><SeekKeys><Prefix ScanType="EQ"><RangeColumns><ColumnReference Database="[TRACE_TRI_ITM]" Schema="[dbo]" Table="[SUPPORT]" Alias="[SUP]" Column="NO_CONTENEUR"/><ColumnReference Database="[TRACE_TRI_ITM]" Schema="[dbo]" Table="[SUPPORT]" Alias="[SUP]" Column="NO_SUPPORT"/></RangeColumns><RangeExpressions><ScalarOperator ScalarString="NULL"><Const ConstValue="NULL"/></ScalarOperator><ScalarOperator ScalarString="[TRACE_TRI_ITM].[dbo].[UOW_SUPPORT].[NO_SUPPORT] as [UOS].[NO_SUPPORT]"><Identifier><ColumnReference Database="[TRACE_TRI_ITM]" Schema="[dbo]" Table="[UOW_SUPPORT]" Alias="[UOS]" Column="NO_SUPPORT"/></Identifier></ScalarOperator></RangeExpressions></Prefix></SeekKeys></SeekPredicateNew></SeekPredicates></IndexScan></RelOp></NestedLoops></RelOp></QueryPlan></StmtSimple></Statements></Batch></BatchSequence></ShowPlanXML>

Enfin, il faut noter que la vue xml de management studio ne donne pas les bonnes informations !!!

Deux petites images pour le prouver sur le plan ci dessus.

A+



Le nombre de lignes estimées est différent entre les deux outils ???