Discussion :

[cristophe0071983]

bonjour a tous

j'ai une requéte qui viens du logiciel sage et qui prennent beaucoup du temps pendant la phase d'exécution

En affichant le plan d’exécution de cette dernière requêtes je viens de découvrir la présence d'une opération de type key lookup

ci joint le syntaxe du requêtes en question

Code :

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

SELECT TOP 1 * FROM F_LOTSERIE ORDER BY DL_NoOut DESC,  cbMarq DESC

ce je que j'arrive pas comprendre a quoi sert cette opération key lookup si les deux colonnes DL_NoOut,cbMarq qui sont mis dans le clause order by ,

ils sont intégrer dans l'index non cluster ILS_NOOUT (voir l'imprime écran),normalement je doit avoir que l'opération Scan Index

merci pour vos aides

[SQLpro]

Votre index ne contient que les 2 colonnes. La clause SELECT contient l'étoile donc, doit renvoyer TOUTES les colonnes de la table. Comme il faut bien retrouver ces autres colonnes, une première lecture est faite dans l'index pour le tri et revient lires les colonnes manquantes dans la table.

L'imbécilité est d'avoir un SELECT * !

A +

[cristophe0071983]

malgré que j'ai procéder a ajouter tout les colonnes du table au index non cluster

l'optimiseur n'a pas éliminer l'option key lookup mis dans son plan d’exécution il a juste éliminer cette index et il a changer par un autre

en conservant toujours l'option key lookup

[SQLpro]

ça c'est une idée pire....

Il faut éliminer le SELECT *

A +

[iberserk]

Frédéric, il s'agit de 'ERP' LIGNE 100 de SAGE (je reconnais les tables).

Tu n'as malheureusement pas la main sur les requêtes...

J'ai eu une "altercation" avec les "architectes" SAGE concernant leurs version 7.5 et 7.70 avec des régression des performances ahurissante par rapport à la V16 sur certaines requêtes (utilisation abusive et non maîtrisée des ROW_NUMBER())

Mon client (très connu, leader dans les coffrets cadeaux) a annulé la migration devant le peu de réaction de SAGE.

[iberserk]

Avez vous essayé d'ajouter un index avec les deux colonne en DESC?
Pouvez vous également nous montrer le coût de la requête?

[cristophe0071983]

bonjour

la majorité des requêtes lancer par ERP sage se fait de la même Facon select 1 * et comme dit iberserk j'ai pas la main de le changer

Code :

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

SELECT TOP 1 * FROM F_DOCLIGNE WHERE DO_Domaine > @DO_Domaine ORDER BY DO_Domaine,DL_TypePL,cbDL_PieceBL,cbMarq;

Code :

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

SELECT TOP 1 * FROM F_DOCENTETE WHERE (DO_Type = @P1 AND (([dbo].CB_FntStr(DO_Ref) = [dbo].CB_FntStr(@P2) AND cbMarq < @P3) OR ([dbo].CB_FntStr(DO_Ref) < [dbo].CB_FntStr(@P4)))) ORDER BY (convert(varbinary(18),ISNULL(DO_Ref,''))) DESC, cbMarq DESC

Code :

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

SELECT TOP 1 * FROM F_LOTSERIE ORDER BY DL_NoOut DESC,  cbMarq DESC

[SQLpro]

Frédéric, il s'agit de 'ERP' LIGNE 100 de SAGE (je reconnais les tables).

Tu n'as malheureusement pas la main sur les requêtes...

J'ai eu une "altercation" avec les "architectes" SAGE concernant leurs version 7.5 et 7.70 avec des régression des performances ahurissante par rapport à la V16 sur certaines requêtes (utilisation abusive et non maîtrisée des ROW_NUMBER())

Mon client (très connu, leader dans les coffrets cadeaux) a annulé la migration devant le peu de réaction de SAGE.

Je suis hélas tout à fait d'accord. La ligne 100 est hélas pourrie, au contraire de la ligne 1000 dont le modèle est particulièrement bien fait... S'agit-il d'une volonté de SAGE de dire ligne 100 kaput, passez donc à la ligne 1000 ?

Je ne saurait l'affirmer, mais je pose la question !

A +

[Zabriskir]

au contraire de la ligne 1000 dont le modèle est particulièrement bien fait

Vous n'êtes pas trop difficile.
J'ai passé votre requête et voici ce que j'obtiens sur la ligne 1000.

@+

[SQLpro]

Vous n'êtes pas trop difficile.
J'ai passé votre requête et voici ce que j'obtiens sur la ligne 1000.

@+

Oui, mais sur combien de tables en tout ?
Si c'est 5 % c'est acceptable !

A +

[Zabriskir]

156 tables sur 722 sortent avec votre requête. Ça fait 20% quand même.
Et toutes les PK en char(32) avec un UNID mais ça c'est la cerise.
Pour reprendre votre propos, je dirais que c'est un modèle "relativement" bien fait par rapport à la ligne 100

@+