IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Administration SQL Server Discussion :

Statistiques en double - perturbation du plan d'execution


Sujet :

Administration SQL Server

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre Expert
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    Septembre 2016
    Messages
    959
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 58
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de base de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2016
    Messages : 959
    Par défaut Statistiques en double - perturbation du plan d'execution
    Bonjour,

    J'aurais besoin de vos lumières sur le contenu des plan d’exécution par rapport au statistiques.

    Demande 1 : est-ce que les valeurs de la section <OptimizerStatsUsage> ne contiennent que les statistiques effectivement retenues pour le plan en question ou est-ce la liste de toutes les statistiques potentiellement utiles ?
    Demande 2 : pour une étape particulière comment savoir quelle est la statistique utilisée ?
    Demande 3 : s'il y a 2 statistiques portant sur la même colonne, sur quel critère la statistique est choisie pour faire les estimations ?

    [edit]
    Demande 4 : est-ce que les version du CE on changé le critère de sélection de la statistique ?

    Merci d'avance

  2. #2
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    22 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 22 001
    Billets dans le blog
    6
    Par défaut
    En utilisant le TF 8666 vous aurez d'avantages de données dans le plan d'exécution XML. L'information que vous recherchez est dans l'attribut FieldValue relatif à la valeur "wszStatName" de l'attribut FieldName dans chacune des balises ModTrackingInfo.
    En temps ordinaire ces informations ne sont pas conservées car alourdirait considérablement le cache des plans d'exécution, en sus d'être inutiles pour une reprise du plan…

    ATTENTION : ce TF n'est pas documenté et peut générer des plans d'exécution XML qui dépassent la capacité de stockage et donc causer une erreur…

    Exemple :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    USE master;
    DBCC TRACEOFF (8666);
    SELECT * FROM sys.objects;
    Nom : SQL Server Stats used in XML Query Plan.jpg
Affichages : 268
Taille : 290,7 Ko

    Citation Envoyé par Michel.Priori Voir le message
    Demande 1 : est-ce que les valeurs de la section <OptimizerStatsUsage> ne contiennent que les statistiques effectivement retenues pour le plan en question ou est-ce la liste de toutes les statistiques potentiellement utiles ?
    OUI

    Demande 2 : pour une étape particulière comment savoir quelle est la statistique utilisée ?
    Voir ci-avant

    Demande 3 : s'il y a 2 statistiques portant sur la même colonne, sur quel critère la statistique est choisie pour faire les estimations ?
    Cela dépend si la limite de nombre d'opération limitant la recherche du meilleur plan a été atteinte (un million). Si non, alors c'est la stats qui donne le meilleur résultat, sauf si le niveau de calcul du plan n'est pas "full".

    Demande 4 : est-ce que les version du CE on changé le critère de sélection de la statistique ?
    OUI

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  3. #3
    Membre Expert
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    Septembre 2016
    Messages
    959
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 58
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de base de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2016
    Messages : 959
    Par défaut
    Merci Frédéric,

    Pour faire au plus rapide j'ai supprimé la stat redondante.
    Pour les tests faudra attendre que je puisse faire un refresh de la base en test ; il y en a pour 3To, faudra être un peu patient car en ce moment on manque de ressource disque et je désire éviter les exploits en prod.


    Citation Envoyé par SQLpro Voir le message
    En utilisant le TF 8666 vous aurez d'avantages de données dans le plan d'exécution XML. L'information que vous recherchez est dans l'attribut FieldValue relatif à la valeur "wszStatName" de l'attribut FieldName dans chacune des balises ModTrackingInfo.
    En temps ordinaire ces informations ne sont pas conservées car alourdirait considérablement le cache des plans d'exécution, en sus d'être inutiles pour une reprise du plan…

    ATTENTION : ce TF n'est pas documenté et peut générer des plans d'exécution XML qui dépassent la capacité de stockage et donc causer une erreur…
    Je testerais ça pour avoir des réponses fiables.
    Merci pour la remarque.

    Citation Envoyé par SQLpro Voir le message
    Demande 3 : s'il y a 2 statistiques portant sur la même colonne, sur quel critère la statistique est choisie pour faire les estimations ?

    Cela dépend si la limite de nombre d'opération limitant la recherche du meilleur plan a été atteinte (un million). Si non, alors c'est la stats qui donne le meilleur résultat, sauf si le niveau de calcul du plan n'est pas "full".
    Ce n'est pas ce que j'ai constaté.

    L'instruction est un MERGE avec une jointure simple dans la source mais provenant de 2 tables de bases distinctes.
    La restriction est une égalité : plus de 132 lignes estimées
    La table jointe estime que chaque valeurs ramènera soit un peu plus de 100 lignes ou un peu plus de 1200 lignes.
    La suite dépend de cette estimation bien sûr.

    La statistique de l'index couvrant est estimé en FULL
    La stat automatique _WA_ est estimé en automatique.
    L'index couvrant est systématiquement choisi. Heureusement !
    Les coûts finaux ne sont pas grandement différents et le temps d’exécution passe de un peu plus de 15ms à un peu plus de 180ms.
    La différence de temps génère des problèmes de retard de traitement globaux de plusieurs heures.

    Visiblement c'est la stat la plus ressente (ou la moins modifiée, ou ...) qui est prise en compte.
    Je n'ai pas eu le temps de valider que la cardinalité estimée est bien présente dans la stat _WA_ et que ce n'est pas le résultat qu'un mixte des 2 stats (là ce serait complètement con, car à prendre entre 2 extrêmes on est sûr à 100% que ce ne sera pas la bonne valeur ; on n'est à l'abri de rien ; j'attends beaucoup du TF 8666)
    Pourquoi diable, pas prendre la stat en FULL de manière systématique ?

    Pour info : Je récupère les plans exécutions réels des évènements étendus.

  4. #4
    Membre Expert
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    Septembre 2016
    Messages
    959
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 58
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de base de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2016
    Messages : 959
    Par défaut
    Re,

    Les tests me permettent de confirmer que la présence d'une stat en double est bien un sujet de confusion pour l'optimizer.

    En suivant l'indicateur de trace indiqué par Frédéric, on a effectivement plus d'informations.
    Malheureusement le lien entre la stat et l'étape n'est pas clairement documenté.

    Tant que je n'aurais pas d'explication claire sur les critères retenus pas SQL pour choisir telle ou telle stat en double j'appliquerais la règle suivante :
    Suppression des stat automatiques si elles sont en doublon avec la 1er colonne d'un index existant.

    Je n'ai pas encore étudié le problème du choix de la stat quand il existe 2 index ayant un commun la 1ere colonne.
    Ce qui me gène est que je ne sais pas quelle règle adopter.


    Pour ceux qui veulent lire un peu de XML voici des passages du plan d’exécution.
    Serveur : Microsoft SQL Server 2017 (RTM-CU15-GDR) (KB4505225) - 14.0.3192.2 (X64) Jun 15 2019 00:45:05 Copyright (C) 2017 Microsoft Corporation Developer Edition (64-bit) on Windows Server 2016 Standard 10.0 <X64> (Build 14393: )
    Instruction : MERGE
    source : 2 tables jointes avec un restriction en égalité sur la table_source2 (plusieurs lignes)
    destination : une table ; sur correspondance update, sur non correspondance insert

    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
    <StmtSimple StatementCompId="8" StatementEstRows="1.99993" StatementId="1" StatementOptmLevel="FULL" CardinalityEstimationModelVersion="140" StatementSubTreeCost="142.208" StatementText="MERGE dbo.Table_cible AS cible [...] ;" StatementType="MERGE" QueryHash="0x5742E0D9810800BB" QueryPlanHash="0x9CE23658528B5589" RetrievedFromCache="true" SecurityPolicyApplied="false">
      <StatementSetOptions ANSI_NULLS="true" ANSI_PADDING="true" ANSI_WARNINGS="true" ARITHABORT="true" CONCAT_NULL_YIELDS_NULL="true" NUMERIC_ROUNDABORT="false" QUOTED_IDENTIFIER="true" />
      <QueryPlan DegreeOfParallelism="48" MemoryGrant="240008" CachedPlanSize="128" CompileTime="37" CompileCPU="37" CompileMemory="2024">
    	<InternalInfo LockClassNoHint="1" LockClassIntLockHint="1" LockClassRCIsoHint="0">
    		[...]
    	  <OptmInfo>
    		  <ModTrackingInfo>
    			<Field FieldName="wszStatName" FieldValue="test">
    			</Field>
    			<Field FieldName="wszColName" FieldValue="COL1">
    			</Field>
    			<Field FieldName="m_cCols" FieldValue="1">
    			</Field>
    			<Field FieldName="m_idIS" FieldValue="2">
    			</Field>
    			<Field FieldName="m_ullSnapShotModCtr" FieldValue="84172550">
    			</Field>
    			<Field FieldName="m_ullRowCount" FieldValue="93129747">
    			</Field>
    			<Field FieldName="ullThreshold" FieldValue="305171">
    			</Field>
    			<Field FieldName="wszReason" FieldValue="sublinear heuristic">
    			</Field>
    		  </ModTrackingInfo>
    			[...]
    		  <ModTrackingInfo>
    			<Field FieldName="wszStatName" FieldValue="IDX_Index_couvrant">
    			</Field>
    			<Field FieldName="wszColName" FieldValue="COL1">
    			</Field>
    			<Field FieldName="m_cCols" FieldValue="1">
    			</Field>
    			<Field FieldName="m_idIS" FieldValue="88">
    			</Field>
    			<Field FieldName="m_ullSnapShotModCtr" FieldValue="84172175">
    			</Field>
    			<Field FieldName="m_ullRowCount" FieldValue="93129365">
    			</Field>
    			<Field FieldName="ullThreshold" FieldValue="305171">
    			</Field>
    			<Field FieldName="wszReason" FieldValue="sublinear heuristic">
    			</Field>
    		  </ModTrackingInfo>
    		   [...]		
    	<OptimizerStatsUsage>
    	  <StatisticsInfo Database="[DB1]" Schema="[dbo]" Table="[Table_source1]" Statistics="[Idx1]" ModificationCount="6034" SamplingPercent="0.398911" LastUpdate="2020-05-18T00:48:04.29" />
    	  <StatisticsInfo Database="[DB1]" Schema="[dbo]" Table="[Table_source1]" Statistics="[Idx2]" ModificationCount="3329" SamplingPercent="0.398911" LastUpdate="2020-05-18T00:48:05.69" />
    	  <StatisticsInfo Database="[DB2]" Schema="[dbo]" Table="[Table_source2]" Statistics="[Idx3]" ModificationCount="1243" SamplingPercent="0.414145" LastUpdate="2020-05-18T00:55:41.73" />
    	  <StatisticsInfo Database="[DB1]" Schema="[dbo]" Table="[Table_source1]" Statistics="[IDX_Index_couvrant]" ModificationCount="375" SamplingPercent="100" LastUpdate="2020-05-18T00:48:02.01" />
    	  <StatisticsInfo Database="[DB2]" Schema="[dbo]" Table="[Table_source2]" Statistics="[Idx4]" ModificationCount="1243" SamplingPercent="0.419605" LastUpdate="2020-05-18T00:55:44.74" />
    	  <StatisticsInfo Database="[DB1]" Schema="[dbo]" Table="[Table_cible]" Statistics="[Idx5]" ModificationCount="4" SamplingPercent="7.84999" LastUpdate="2020-05-18T00:50:29.22" />
    	  <StatisticsInfo Database="[DB1]" Schema="[dbo]" Table="[Table_source1]" Statistics="[test]" ModificationCount="0" SamplingPercent="0.39895" LastUpdate="2020-05-18T14:42:51.7" />
    	  <StatisticsInfo Database="[DB2]" Schema="[dbo]" Table="[Table_source2]" Statistics="[Idx6]" ModificationCount="1243" SamplingPercent="0.419605" LastUpdate="2020-05-18T00:55:43.53" />
    	  <StatisticsInfo Database="[DB1]" Schema="[dbo]" Table="[Table_source1]" Statistics="[Idx7]" ModificationCount="16720" SamplingPercent="0.398911" LastUpdate="2020-05-18T00:48:07.56" />
    	  <StatisticsInfo Database="[DB1]" Schema="[dbo]" Table="[Table_source1]" Statistics="[Idx8]" ModificationCount="375" SamplingPercent="0.415099" LastUpdate="2020-05-18T00:47:04.57" />
    	  <StatisticsInfo Database="[DB1]" Schema="[dbo]" Table="[Table_source1]" Statistics="[Idx9]" ModificationCount="6022" SamplingPercent="0.398911" LastUpdate="2020-05-18T00:48:06.61" />
    	  <StatisticsInfo Database="[DB1]" Schema="[dbo]" Table="[Table_source1]" Statistics="[Idx10]" ModificationCount="375" SamplingPercent="0.394744" LastUpdate="2020-05-18T00:48:07.9" />
    	  <StatisticsInfo Database="[DB2]" Schema="[dbo]" Table="[Table_source2]" Statistics="[Idx11]" ModificationCount="1243" SamplingPercent="0.415764" LastUpdate="2020-05-18T00:55:44.18" />
    	</OptimizerStatsUsage>	
    		[...]
    	 <RelOp AvgRowSize="16" EstimateCPU="0.022878" EstimateIO="0.453125" EstimateRebinds="266.847" EstimateRewinds="0.000888306" EstimatedExecutionMode="Row" GroupExecuted="false" EstimateRows="102.749" EstimatedRowsRead="102.749" LogicalOp="Index Seek" NodeId="17" Parallel="true" Partitioned="true" PhysicalOp="Index Seek" EstimatedTotalSubtreeCost="126.948" TableCardinality="93129700">
    	  <OutputList>
    		<ColumnReference Database="[Table_source1]" Schema="[dbo]" Table="[Table_source1]" Alias="[T1]" Column="COL1">
    		  <InternalInfo PrefetchedColumn="1" PrefetchFlagSet="1" />
    		</ColumnReference>
    	  </OutputList>

  5. #5
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    22 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 22 001
    Billets dans le blog
    6
    Par défaut
    Citation Envoyé par Michel.Priori Voir le message
    Re,

    Les tests me permettent de confirmer que la présence d'une stat en double est bien un sujet de confusion pour l'optimizer.

    En suivant l'indicateur de trace indiqué par Frédéric, on a effectivement plus d'informations.
    Malheureusement le lien entre la stat et l'étape n'est pas clairement documenté.

    Tant que je n'aurais pas d'explication claire sur les critères retenus pas SQL pour choisir telle ou telle stat en double j'appliquerais la règle suivante :
    Suppression des stat automatiques si elles sont en doublon avec la 1er colonne d'un index existant.
    Non, je dirais plutôt :
    S'il existe une state de colonne (et non d'index) qui est équivalente à une stat d'index, alors supprimer la stat de colonne.
    Ce que propose d'ailleurs la requête que je donne ici:
    https://blog.developpez.com/sqlpro/p...es-redondantes
    Qui donne même le code du DROP à faire !

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  6. #6
    Membre Expert
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    Septembre 2016
    Messages
    959
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 58
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de base de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2016
    Messages : 959
    Par défaut
    Re,

    Citation Envoyé par SQLpro Voir le message
    S'il existe une state de colonne (et non d'index) qui est équivalente à une stat d'index, alors supprimer la stat de colonne.
    Merci pour le lien, ça m'aurais évité de faire ma propre requête :p

    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
    with 
     stat as (
    	select 
    		  s.object_id
    		, s.name as stat_name
    		, c.column_id
    		, c.name as column_name
    		, s.auto_created
    	from sys.stats s
    		inner join sys.objects o on o.object_id= s.object_id
    		inner join sys.stats_columns sc on sc.object_id = s.object_id and sc.stats_id=s.stats_id
    		inner join sys.columns c on c.column_id=sc.column_id and c.object_id=sc.object_id
    	where o.is_ms_shipped = 0 
    		and sc.stats_column_id =1 --seule la 1ere colonne de la stat est importante
    		)
    ,stat_index as (
    	select object_id, column_id, column_name,  string_agg (stat_name,', ') as Idx_names, count(1) as Nb_index_With_same_fisrt_column
    	from stat
    	where auto_created = 0
    	group by object_id, column_id, column_name
    	)
    , stat_WA as (
    	select object_id, column_id, stat_name as Auto_stat_names
    	from stat
    	where auto_created = 1
    	)
    select 
    	  OBJECT_NAME(i.object_id) as table_name
    	, i.column_name as first_column_name
    	, i.Nb_index_With_same_fisrt_column
    	, i.Idx_names
    	, s.Auto_stat_names
    	, ' DROP STATISTICS '+ OBJECT_SCHEMA_NAME(i.object_id)+'.' +OBJECT_NAME(i.object_id)+ '.'+  s.Auto_stat_names as SQL_command
    from stat_index i 
    	inner join stat_WA s on s.column_id= i.column_id and s.object_id = i.object_id
    order by table_name, first_column_name
    ;
    Du coup ma nouvelle question :
    Comment détecter, avec le moins d'impact possible sur la prod, les plans d’exécution qui utilisent les stats (le vampire ? :p) redondantes ?

Discussions similaires

  1. Quand change le plan d'execution?
    Par kervoaz dans le forum Administration
    Réponses: 17
    Dernier message: 03/12/2007, 10h45
  2. Bind variables et plan d'execution
    Par Wurlitzer dans le forum Oracle
    Réponses: 6
    Dernier message: 26/02/2007, 14h04
  3. [Oracle 10.2] Plan d'execution fonction PL/SQL
    Par pegase06 dans le forum PL/SQL
    Réponses: 6
    Dernier message: 13/02/2007, 12h02
  4. Plans d'execution differents
    Par jajaCode dans le forum Oracle
    Réponses: 13
    Dernier message: 14/12/2006, 12h29
  5. plan d'execution
    Par osoudee dans le forum MS SQL Server
    Réponses: 1
    Dernier message: 09/03/2006, 10h40

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo