Discussion :

[Pol63]

ca va faire du code à relire tout ca ...

j'ai pas vu de compilation ou de recompilation de cachemiss cacheremove ou autre lors de mes traces
mais selon la requete que je ne comprends pas trop fournies par microsoft j'aurais plusieurs statements par requete
donc surement des soucis

Code :

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

1
2
3
4
5
6
7
8
9
10
 
select top 50  
    sum(qs.total_worker_time) as total_cpu_time,  
    sum(qs.execution_count) as total_execution_count, 
    count(*) as  number_of_statements,  
    qs.plan_handle  
from  
    sys.dm_exec_query_stats qs 
group by qs.plan_handle 
order by sum(qs.total_worker_time) desc

merci pour toutes ces précisions
on va mettre des dbo dans les requetes et dans les procédures stockées rapidement je pense


ca me fait penser que y a un autre truc que j'ai pas compris, sur tes articles tu parles de fenetres des données, j'en avais déduis que sql server pouvait mettre en ram jusqu'à la base entière + des plans ou autre
mai on a déjà vu notre serveur prendre plus de 3Go de RAM alors que la base fait moins d'1Go, ca me semble étrange
enfin si j'ai bien compris aussi, sql server n'est pas prévu pour redonner la ram qu'il a pris meme s'il s'en sert plus, peut si l'os lui demande seulement ...

[SQLpro]

j'ai pas vu de compilation ou de recompilation de cachemiss cacheremove ou autre lors de mes traces
mais selon la requete que je ne comprends pas trop fournies par microsoft j'aurais plusieurs statements par requete
donc surement des soucis

Par nature (et c'est comme cela dans tous les SGBDR du fait des mécanismes des OS internes) la mise en cache des plans de requêtes est sensible à la casse. Tant est si bien que des requêtes strictement identique d'un point de vue syntaxique mais avec des casses différentes vont conduire à autant de plan de requête en cache et chacun des plans va vieillir plus vite donc dégager du cache plus rapidement.
C'est pourquoi dans mon cours d'optimisation que j'ai monté à, Orsys, ou je montre ce phénomène, j'insiste bien sur ce point, que l'on peut régler notamment par l'utilisation d'une collation forte à l'installation du serveur.

ca me fait penser que y a un autre truc que j'ai pas compris, sur tes articles tu parles de fenetres des données, j'en avais déduis que sql server pouvait mettre en ram jusqu'à la base entière + des plans ou autre
mai on a déjà vu notre serveur prendre plus de 3Go de RAM alors que la base fait moins d'1Go, ca me semble étrange

Le cache des procédures y est aussi pour quelque chose
puis la base tempdb, c'est une base aussi et elle peut être très sollicité si :

• usage de tables temporaires ou variable table
• trigger
• niveau d'isolation snapshot
• opération d'indexation

etc...

enfin si j'ai bien compris aussi, sql server n'est pas prévu pour redonner la ram qu'il a pris même s'il s'en sert plus, peut si l'os lui demande seulement ...

L'OS système est autorisé à demander de la RAM uniquement en cas de stress système. S'ensuit une négociation et par nature, SQL reprendra cette RAM dès qu'il en aura besoin, tant est si bien que l'on obtient un phénomène de vases communicants.

A +

[Pol63]

Par nature (et c'est comme cela dans tous les SGBDR du fait des mécanismes des OS internes) la mise en cache des plans de requêtes est sensible à la casse. Tant est si bien que des requêtes strictement identique d'un point de vue syntaxique mais avec des casses différentes vont conduire à autant de plan de requête en cache et chacun des plans va vieillir plus vite donc dégager du cache plus rapidement.

nos requetes sont codés dans vb, donc c'est toujours la même casse
on a rarement écrit 2x la même à 2 endroits différents ...


la base ou j'avais fait

ALTER DATABASE mabase
SET PARAMETERIZATION FORCED

le % processeur étant descendu de 9 à 2 ce matin
là c'était revenu à 9
j'ai réexécuté la même requête et c'est retombé à 2

donc je comprends vraiment pas quoi faire pour que ca reste à 2% dans le temps ...

et l'agent sql est arreté depuis plusieurs jours aussi ...

[Pol63]

ALTER DATABASE mabase
SET PARAMETERIZATION FORCED

vide le cache des plans d'execution apparemment, donc je pense que c'est un soucis de détermination de plan d'exécution ...

je verrais si après rajout des dbo. ca change

[Pol63]

pour les dbo. dans le from ca suffit ou il en faut partout ? (parmis les 2 possibilités suivantes)


select champ FROM dbo.table1 inner join dbo.table2 on table1.id = table.id


select champ FROM dbo.table1 inner join dbo.table2 on dbo.table1.id = dbo.table.id


et champ, faut il le préfixer de la table ? de dbo.table ?

[SQLpro]

1) dans le from suffit
2) vérifiez aussi pour le code SQL des vues, procédures triggers et fonctions
3) utilisez des alias pour surnommer les tables dans la jointure et utilisez ces alias si ambiguïté pour les colonnes homonymes (en principe FK seulement).

A +

[Pol63]

on poursuit sur d'autres pistes aussi

et je viens de faire une appli avec 4 threads qui lancent la meme requete
2 avec le user sa, 2 avec le user qu'on utilise dans l'appli
2 avec les from sans dbo. et 2 avec les from avec dbo.


la première chose plutot visible, c'est que les requetes sur le user sa sont plus rapide 10ms en moyenne contre 12ms

un truc à voir sur les users ?



sinon la requete trouvée sur technet

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
 
select top 50  
    sum(qs.total_worker_time) as total_cpu_time,  
    sum(qs.execution_count) as total_execution_count, 
    count(*) as  number_of_statements,  
    qs.plan_handle  , te.text
from  
    sys.dm_exec_query_stats qs 
cross apply  sys.dm_exec_sql_text(qs.plan_handle) te
group by qs.plan_handle , te.text
order by sum(qs.total_worker_time) desc

me donne 14 statements pour les 4 requête, je pense qu'un statement est un nombre de plan d'execution pour une requete, en tout il devrait etre à 1 idéalement, je ne vois pas pourquoi ca en ferait 14 ...

[SQLpro]

La démultiplication des utilisateurs non SQL par les tables sans schéma en est généralement la cause.

A +