Discussion :

[coco2083]

Bonjour à tous,

J'utilise en Production une base de données sur SQL Server 2022.
Malheureusement de façon aléatoire (2 fois par mois environ), certaines requêtes (surtout une) sont très longues.
J'ai pu identifier grâce au "Query Store" que le "plan" avait changé.
SQL Server a subitement choisi d'utiliser un autre index.
Le plan de maintenance fonctionne correctement (j'utilise Ola Hallengren), mes index ne sont pas fragmentés, mes statistics sont en FULL SCAN.
Pour résoudre le problème de façon rapide, j'ai forcé le bon plan, mais j'aimerai bien trouver la raison de ce changement.

Le hasard fait que j'ai aussi le même problème quand j'utilise "Top Resource Consuming Queries" dans le "Query Store".
Du coup j'ai aussi forcé le plan pour ce cas...

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
SELECT TOP (@results_row_count)
    p.query_id query_id,
    q.object_id object_id,
    ISNULL(OBJECT_NAME(q.object_id),'') object_name,
    qt.query_sql_text query_sql_text,
    ROUND(CONVERT(float, SUM(rs.avg_duration*rs.count_executions))*0.001,2) total_duration,
    SUM(rs.count_executions) count_executions,
    COUNT(distinct p.plan_id) num_plans
FROM sys.query_store_runtime_stats rs
    JOIN sys.query_store_plan p ON p.plan_id = rs.plan_id
    JOIN sys.query_store_query q ON q.query_id = p.query_id
    JOIN sys.query_store_query_text qt ON q.query_text_id = qt.query_text_id
WHERE NOT (rs.first_execution_time > @interval_end_time OR rs.last_execution_time < @interval_start_time)
GROUP BY p.query_id, qt.query_sql_text, q.object_id
HAVING COUNT(distinct p.plan_id) >= 1
ORDER BY total_duration DESC

Quelqu'un a une idée de ce que je peux vérifier ?
Merci
A+

[SQLpro]

Sans le contexte impossible de savoir. Cela peut être un défaut de statistiques. Par exemple si vous insérez des données dans une table avec la date du jour (qui n'existait pas jusqu'alors) et que vous faites un traitement sur ces lignes à ce moment là, alors l'optimiseur va en conclure qu'il n'existe pas de ligne à cette date et faire un plan optimisé pour une seule ligne, alors qu'il est possible que le nombre de lignes nouvelle soit de plusieurs milliers...

Nous ne savons pas si votre base est en rétrocompatibilité, si les stats sont activées en mode auto-update, si vous êtes en édition Enterprise...

A +

[coco2083]

Bonjour SQLpro,

Je suis en Standard edition.
La base est en version 160 (2022).
L'auto-update des statistics est activé.

L'application fait une requête sur une seule table mais en boucle.
Quand il prend l'index1 en quelques secondes le traitement est terminé, par contre avec l'index2, le traitement peut durer 40min...
Comment je peux déterminer pourquoi aujourd'hui il va utiliser l'index1 et un jour l'index2 ?
Je suis preneur de piste de recherche...

Merci
A+

[licardentaistor]

quelle est la requête en question, comment est construit index1, index2 ?

[SQLpro]

Cela peut être lié avec "L'auto-update des statistics est activé."

En effet, ce dernier ne peut agir en mode, FULLSCAN.

vérifiez les date/heure des requêtes fautives et des recalculs de stats...

Si tel est le cas, le forçage via querystore est une bonne chose...

A +

[coco2083]

Voici la requête en question :

Code :

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

1
2
3
4
5
6
 
Select CPT.ROWID, CPT.*
From CPTDETAIL CPT
Where CPT.ACCOUNT = @P1 And CPT.TIERS = @P2 And CPT.SOCIETE = @P3 And CPT.CHECK = @P4
Order by CPT.TYP,CPT.ACCOUNT,CPT.TIERS,CPT.SOCIETE,CPT.DATE,CPT.ID
Option (FAST 1)

Et voici les 2 index :

Code :

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

1
2
3
4
5
6
CREATE NONCLUSTERED INDEX [CPT_INDEX1] ON [CPTDETAIL] (
	[CHECK] ASC,	[ACCOUNT] ASC,	[TIERS] ASC,	[SOCIETE] ASC,	[DATE] ASC,	[ID] ASC )
 
 
CREATE UNIQUE NONCLUSTERED INDEX [CPT_INDEX2] ON [CPTDETAIL] (
	[TYP] ASC,	[ACCOUNT] ASC,	[TIERS] ASC,	[SOCIETE] ASC,	[DATE] ASC,	[ID] ASC )

Quant l'optimiseur utilise que l'index1 c'est très rapide.


Quand l'optimiseur utilise que l'index2 c'est très lent.


Il s'agit d'une grosse table.
Il n'y a pas ou peu de ligne inséré entre l'exécution du plan de maintenance (en FULL SCAN pour les stats) et l'exécution de la requête.
Je vais voir pour tracker les mises à jour de ces stats.