Discussion :

[olivtone]

Bonjour a Tous

J'ai un serveur sur SQL2012 SP1 en PROD, qui part en sucette, sur les update statistics qui prend enormement de temps, alors qu'en PREPROD les update statistics sont 10 fois moins longs (même 100 moins longues)

Apres un redemarrage du serveur SQL, les Problemes sont regles(je ne comprends pas pourquoi), les performances redeviennent normales, les statistiques reviennent a un temps normal, mais au bout d'une semaine, je m'apercois que les stats

repartent en sucette complete au niveau du temps.

Ce sont des tables microsoft dynamic CRM, et je voulais savoir si quelqu'un a deja eu ce probleme de son cote sur un SQL Server 2012 SP1 ?

La BDD est en mode de compatibilité 2008 (préconisation CRM)

J'ai mis un en place un UPDATE WITH FULLSCAN sur ces tables toutes les nuits.

N'y a t il pas un Traceflag a rajouter sur SQL Server 2012 SP1 (je le rappele ce sont des tables CRM )

Merci a vous

[mikedavem]

J'ai un serveur sur SQL2012 SP1 en PROD, qui part en sucette, sur les update statistics qui prend enormement de temps, alors qu'en PREPROD les update statistics sont 10 fois moins longs (même 100 moins longues)

Apres un redemarrage du serveur SQL, les Problemes sont regles(je ne comprends pas pourquoi), les performances redeviennent normales, les statistiques reviennent a un temps normal, mais au bout d'une semaine, je m'apercois que les stats

Je n'ai pas souvenir d'avoir vu ce genre de phénonèmes sur 2012 SP1 mais bon je suis peut être passé à côté. Ceci dit le problème que tu décris a plus l'air de concerner un problème environnemental qu'un problème interne SQL Server (ressources disponibles / contention au moment de ton test par rapport la préprod etc ...)

++

[olivtone]

ok merci a toi de ton retour

Question concernant les Stats

On refait un reogarnize toutes les nuits pour les index qui ont plus de 30 % dans notre plan de nuit, cela fait il un update stats sur la table ou juste sur les index ?

Car apres on refait un UPDATE stats sur les tables qui ont plus de trois jours ou les 500 lignes qui ont été modifiés

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
 
DECLARE @SQL NVARCHAR(max);
SET @SQL = N'';
SELECT @SQL = @SQL + 'UPDATE STATISTICS ' + s.name +'.' + o.name + '(' + st.name +');'
FROM   sys.stats AS st
       LEFT OUTER JOIN sys.indexes AS i
	        ON st.object_id = i.object_id
			   AND st.name = i.name
       JOIN sys.objects AS o
	        ON st.object_id = o.object_id
       JOIN sys.schemas AS s
	        ON o.schema_id = s.schema_id	
       CROSS APPLY sys.dm_db_stats_properties (st.object_id, st.stats_id) AS sp
WHERE  modification_counter > 0
  AND  (last_updated < DATEADD(day, -3, GETDATE())
        OR  rows / NULLIF(modification_counter, 0) > 0.2)
  AND  rows > 500;
EXEC (@SQL);

Cela peut il fausser les estimations au niveau des stats ?

Et vous que faites vous au niveau de vos plans de maintenance ?

Merci

[SQLpro]

Ce n'est pas une bonne façon de faire la maintenance.
Il faut : reconstruire les index fragmentés à plus de 30% (ceci recalcule les stats en mode FULLSCAN) ALTER INDEX ... REBUILD
défragmenter les index fragmentés à plus de 10% et moins de 30
recalculer les stats en mode FULLSCAN des stats trop vieille ayant plus de n% de modif...

A +

[olivtone]

recalculer les stats en mode FULLSCAN des stats trop vieille ayant plus de n% de modif...

A +

Hello SQLpro

merci de ton retour

N% de modif c'est a dire ?

Mais vu que la BDD a deja l'auto update statistics déja activé par defaut sur les proprietes de la BDD, y a t il un interet de le faire ?

Et a quelle frequence faut il les lancer ?

Merci a toi

[SQLpro]

AUTO UPDATE STATISTIC n'intervient que si une requête arrive et s'aperçoit que les stats ne sont pas à jour. Cela pénalise dont la requête. En sus c'est fait par échantillon. Moins précis que FULLSCAN.

Il faut donc faire régulièrement une mise à jour des stats par FULLSCAN en ne prenant que les stats réellement obsolète. Voir avec sys.dm_db_stats_properties (OF).

A +

[olivtone]

Ok je ne le savais pas pour le AUTO UPDATE STATISTIC merci

En fait je me suis trompé c'est un bien un REORGANIZE entre 10 et 30 % et un REBUILD au dela de 30 %

Question (j'en profite )

- quand on fait un UPDATE STATS sans le FULLSCAN, il fait juste La MAJ des statistiques au niveaux des index de la table et non de la table entiere ?

- Le reorganize au niveau Index ne fait pas un UPDATE Stats par defaut ?


J'ai peut etre une piste concernant les Stats qui partent en sucette

car j'ai un rebuild INDEX de la table complet (la fragmentation est a 36%) à 6h du matin , mais il enchaine apres avec un UPDATE STATS a 7h30 sans FULLSCAN

Du coup la requete est recompilée, et cela genere un nouveau plan, c'est microsoft qui le dit

Code :

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

1
2
3
 
 
Toutefois, la mise à jour des statistiques entraîne une recompilation des requêtes. À ce titre, il est déconseillé de mettre à jour les statistiques de façon trop régulière eu égard aux performances.

Du coup je vois dans les temps que la requete qui tape sur cette fameuse table passe de 5 secondes à 4 minutes...

Dans ma requete elle tape deja sur la table sys.dm_db_stats_properties

Je prends en compte les Statistiques qui ont plus de 3 jours ou si les modifications de lignes ont depassé les 500

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
 
DECLARE @SQL NVARCHAR(max);
SET @SQL = N'';
SELECT @SQL = @SQL + 'UPDATE STATISTICS ' + s.name +'.' + o.name + '(' + st.name +');'
FROM   sys.stats AS st
       LEFT OUTER JOIN sys.indexes AS i
	        ON st.object_id = i.object_id
			   AND st.name = i.name
       JOIN sys.objects AS o
	        ON st.object_id = o.object_id
       JOIN sys.schemas AS s
	        ON o.schema_id = s.schema_id	
       CROSS APPLY sys.dm_db_stats_properties (st.object_id, st.stats_id) AS sp
WHERE  modification_counter > 0
  AND  (last_updated < DATEADD(day, -3, GETDATE())
        OR  rows / NULLIF(modification_counter, 0) > 0.2)
  AND  rows > 500;
EXEC (@SQL);

[mikedavem]

Question (j'en profite )

- quand on fait un UPDATE STATS sans le FULLSCAN, il fait juste La MAJ des statistiques au niveaux des index de la table et non de la table entiere ?

- Le reorganize au niveau Index ne fait pas un UPDATE Stats par defaut ?

Quand tu fais une mise à jour de statistiques sans fullscan, SQL Server utilise une valeur d'échantillonnage suivant un algorithme non linéaire en fonction du nombre de lignes que tu as dans ta table. En gros l'algorithme est là pour minimiser l'impact que pourrait avoir l'opération de mise à jour tout en essayant de maintenir un taux d'échantillonnage correct pour réfléterla distribution de tes données. Le taux d'échantillonnage diminue lors que ton nombre de lignes augmente et ce comportement ne peut être changé et est directement sous le contrôle de l'optimiseur SQL.

FULLSCAN ne veut pas dire que tu mets à jour toutes les statistiques présents sur ta table (que ce soit une statistique liée à des colonnes d'index ou non). Il y a un argument que tu peux utiliser pour cela (ALL | COLUMNS | INDEX) avec la commande UPDATE STATISTICS.

La réorganisation d'index ne fait pas de mise à jour d'index en effet. Seule la reconstruction d'index met à jour les statistiques de colonnes concernées par celui-ci.

car j'ai un rebuild INDEX de la table complet (la fragmentation est a 36%) à 6h du matin , mais il enchaine apres avec un UPDATE STATS a 7h30 sans FULLSCAN

Si tu fais un rebuild d'un index de ta table, autant exclure la statistique correspondante à cet index avec ton opération suivante (UPDATE STATS).
Après si 07h30 est une plage horaire où tu as déjà de l'activité n'aurais-tu pas intérêt à déplacer cette opération plus tôt le matin ou plus tard la nuit?

++

[olivtone]

ok merci beaucoup mikedavem (et SQLpro) bien sur pour ces retours, c'est vraiment cool

je ne savais pas qu'un UPDATE STATS (on va dire un peu mal controlé) pouvait changer a ce point le performances sur SQL

Merci a tous en tout cas