Publicité
+ Répondre à la discussion
Page 2 sur 3 PremièrePremière 123 DernièreDernière
Affichage des résultats 21 à 40 sur 41
  1. #21
    Expert Confirmé
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    juillet 2006
    Messages
    2 896
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : juillet 2006
    Messages : 2 896
    Points : 2 579
    Points
    2 579

    Par défaut

    Et à la demande de mikedavem (qui efface mes messages le bougre :p), voici le plan et les messages (voir pièce jointe).
    Fichiers attachés Fichiers attachés
    Kropernic (anciennement Griftou).

  2. #22
    Expert Confirmé Sénior
    Avatar de mikedavem
    Homme Profil pro David BARBARIN
    Architecte de base de données
    Inscrit en
    août 2005
    Messages
    4 582
    Détails du profil
    Informations personnelles :
    Nom : Homme David BARBARIN
    Localisation : France, Ain (Rhône Alpes)

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

    Informations forums :
    Inscription : août 2005
    Messages : 4 582
    Points : 9 147
    Points
    9 147

    Par défaut

    Oui oui dsl fausse manipulation

    Tu pourrais éventuellement essayer de créer un index cluster sur la table temporaire #T2 pour voir. Comme cela à vue de nez tu devrais encore voir certaines opérations de l'optimiseur disparaitre.

    ++

  3. #23
    Expert Confirmé
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    juillet 2006
    Messages
    2 896
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : juillet 2006
    Messages : 2 896
    Points : 2 579
    Points
    2 579

    Par défaut

    Citation Envoyé par mikedavem Voir le message
    Oui oui dsl fausse manipulation
    Pas de souci ^^

    Citation Envoyé par mikedavem Voir le message
    Tu pourrais éventuellement essayer de créer un index cluster sur la table temporaire #T2 pour voir. Comme cela à vue de nez tu devrais encore voir certaines opérations de l'optimiseur disparaitre.

    ++
    Pour l'index cluster, il me faudrait une colonne unique qui n'est pas présente en l'état.
    Ajouter une colonne avec la fonction ROW_NUMBER() ?

    Mais pour le moment, ça a l'air de bien tourner avec l'index proposer par dbaffaleuf. Le jour où ça se gâte, je me souviendrai de tenter l'index cluster.
    Kropernic (anciennement Griftou).

  4. #24
    Expert Confirmé Sénior
    Avatar de mikedavem
    Homme Profil pro David BARBARIN
    Architecte de base de données
    Inscrit en
    août 2005
    Messages
    4 582
    Détails du profil
    Informations personnelles :
    Nom : Homme David BARBARIN
    Localisation : France, Ain (Rhône Alpes)

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

    Informations forums :
    Inscription : août 2005
    Messages : 4 582
    Points : 9 147
    Points
    9 147

    Par défaut

    Tu n'as pas besoin d'avoir de colonne unique pour un index cluster. Je n'ai pas dit clé primaire mais index cluster :-)

    ++

  5. #25
    Expert Confirmé
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    juillet 2006
    Messages
    2 896
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : juillet 2006
    Messages : 2 896
    Points : 2 579
    Points
    2 579

    Par défaut

    Citation Envoyé par mikedavem Voir le message
    Tu n'as pas besoin d'avoir de colonne unique pour un index cluster. Je n'ai pas dit clé primaire mais index cluster :-)

    ++
    Ah ? Je croyais qu'un index cluster était toujours unique.

    Où aurais-je été pêché ça ?
    Kropernic (anciennement Griftou).

  6. #26
    Expert Confirmé Sénior
    Avatar de mikedavem
    Homme Profil pro David BARBARIN
    Architecte de base de données
    Inscrit en
    août 2005
    Messages
    4 582
    Détails du profil
    Informations personnelles :
    Nom : Homme David BARBARIN
    Localisation : France, Ain (Rhône Alpes)

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

    Informations forums :
    Inscription : août 2005
    Messages : 4 582
    Points : 9 147
    Points
    9 147

    Par défaut

    Citation Envoyé par Kropernic Voir le message
    Ah ? Je croyais qu'un index cluster était toujours unique.

    Où aurais-je été pêché ça ?
    Peut-être du fait que lorsqu'on implémente une clé primaire par défaut SQL Server créée un index unique cluster ... :-)

    ++

  7. #27
    Expert Confirmé
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    juillet 2006
    Messages
    2 896
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : juillet 2006
    Messages : 2 896
    Points : 2 579
    Points
    2 579

    Par défaut

    Probable oui.

    Je testerai à l'occasion.
    Kropernic (anciennement Griftou).

  8. #28
    Membre émérite
    Profil pro David BAFFALEUF
    Inscrit en
    février 2008
    Messages
    736
    Détails du profil
    Informations personnelles :
    Nom : David BAFFALEUF
    Localisation : France

    Informations forums :
    Inscription : février 2008
    Messages : 736
    Points : 922
    Points
    922

    Par défaut

    Citation Envoyé par Kropernic Voir le message
    Je serais, à l'heure actuelle, bien incapable de reproduire la démarche que vous avez eue pour arriver à cette solution.
    Les dernières stats io envoyées:

    Code :
    1
    2
     
    TABLE '#T2__ ... ___000000000014'. Scan count 1, logical reads 1564563, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
    1564563 logical reads sur #T2, lecture complète de la table dans le plan (table scan). CRD_SERIAL est colonne principale de l'index pour résoudre le prédicat #T2.CRD_SERIAL < #T3.SER_ID, et les colonnes additionnelles (TCA_ID, CRD_RECHARGEABLE) pour couvrir le select et la jointure. Mais il faudrait voir le dernier plan pour confirmer.
    David B.

  9. #29
    Expert Confirmé
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    juillet 2006
    Messages
    2 896
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : juillet 2006
    Messages : 2 896
    Points : 2 579
    Points
    2 579

    Par défaut

    Citation Envoyé par dbaffaleuf Voir le message
    Mais il faudrait voir le dernier plan pour confirmer.

    Le dernier plan se trouve en pièce jointe du premier message de cette page-ci.
    Kropernic (anciennement Griftou).

  10. #30
    Expert Confirmé
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    juillet 2006
    Messages
    2 896
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : juillet 2006
    Messages : 2 896
    Points : 2 579
    Points
    2 579

    Par défaut

    Une dernière question :

    Puis-je tirer comme conclusion qu'il vaut mieux toujours utiliser des tables temporaires plutôt que des CTE ?
    Kropernic (anciennement Griftou).

  11. #31
    Membre émérite
    Profil pro David BAFFALEUF
    Inscrit en
    février 2008
    Messages
    736
    Détails du profil
    Informations personnelles :
    Nom : David BAFFALEUF
    Localisation : France

    Informations forums :
    Inscription : février 2008
    Messages : 736
    Points : 922
    Points
    922

    Par défaut

    Citation Envoyé par Kropernic Voir le message
    Une dernière question :

    Puis-je tirer comme conclusion qu'il vaut mieux toujours utiliser des tables temporaires plutôt que des CTE ?
    Il n'y a pas de toujours ou de jamais (sauf auto_shrink), il n'y a que des 'ça dépend'

    En l'occurence dans ton cas, ça dépend du manque de précision dans les estimations de cardinalités (le comptage des lignes en sortie de chaque opérateur) qui induit le mauvais choix de jointure (nested loops join). Je me demande si à l'origine tes indexes ne sont pas fragmentés, et donc quelle est la dernière date de calcul des stats sur ces indexes.
    David B.

  12. #32
    Expert Confirmé
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    juillet 2006
    Messages
    2 896
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : juillet 2006
    Messages : 2 896
    Points : 2 579
    Points
    2 579

    Par défaut

    Citation Envoyé par dbaffaleuf Voir le message
    Il n'y a pas de toujours ou de jamais (sauf auto_shrink), il n'y a que des 'ça dépend'

    En l'occurence dans ton cas, ça dépend du manque de précision dans les estimations de cardinalités (le comptage des lignes en sortie de chaque opérateur) qui induit le mauvais choix de jointure (nested loops join). Je me demande si à l'origine tes indexes ne sont pas fragmentés, et donc quelle est la dernière date de calcul des stats sur ces indexes.
    Même réponse que précédemment :

    Je ne connais encore rien de toute ce qui touche aux statistiques. Je sais que ça existe, quelque part, mais ça s'arrête là.

    J'attends que sqlpro pondent un article sur le sujet
    Kropernic (anciennement Griftou).

  13. #33
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro Frédéric BROUARD
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 362
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BROUARD
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 362
    Points : 27 472
    Points
    27 472

    Par défaut

    Citation Envoyé par Kropernic Voir le message
    Une dernière question :

    Puis-je tirer comme conclusion qu'il vaut mieux toujours utiliser des tables temporaires plutôt que des CTE ?
    Oh que non !!!!

    Lisez mon livre sur SQL et dans la partie administration des serveurs, dont le chapitre est en ligne, je traite des problèmes de performances....
    Or les tables temporaires pose des problèmes de performances difficiles à cerner.
    En effet, comme il faut bien stocker en RAM les données de ces tables temporaires, cela met de la pression mémoire, qui fait dégager d'autres données. Ce n'est donc pas la table temporaire qui sera moins efficace... C'est TOUT LE RESTE !
    En sus, une table temporaire est journalisée comme toute table de toute base, ce qui suppose des opérations d'écritures de fichiers...
    Enfin toute requête, CTE ou non, peut conduire à créer des tables temporaire pour réaliser le traitement (woktable).
    On ne peut donc pas opposer ces deux choses !

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  14. #34
    Expert Confirmé
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    juillet 2006
    Messages
    2 896
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : juillet 2006
    Messages : 2 896
    Points : 2 579
    Points
    2 579

    Par défaut

    Citation Envoyé par SQLpro Voir le message
    En effet, comme il faut bien stocker en RAM les données de ces tables temporaires, cela met de la pression mémoire, qui fait dégager d'autres données. Ce n'est donc pas la table temporaire qui sera moins efficace... C'est TOUT LE RESTE !

    La partie en gras me fait un peu peur... Ok ma requête a été boostée et réponds au quart de tour mais si c'est pour que le reste du serveur rame à cause de ça quand ce sera en production (je dramatise sûrement mais bon), je ne suis pas sûr que cela en vaille vraiment la peine.

    Du coup, ne serait-il pas préférable que je cherche un autre moyen d'exécuter cette requête qui soit tout autant performant ?

    Je me souviens d'un papier que vous avez écrit où vous parlez de l'efficacité des vues indexées dans le cas de calculs importants.

    Je ne fais pas vraiment de calcul mais pas mal de fonction d'agrégation MIN et MAX. Est-ce que une ou plusieurs vues indexées ne serait pas une meilleure solution ?
    Kropernic (anciennement Griftou).

  15. #35
    Expert Confirmé Avatar de StringBuilder
    Homme Profil pro Sylvain Devidal
    Chef de projets
    Inscrit en
    février 2010
    Messages
    1 769
    Détails du profil
    Informations personnelles :
    Nom : Homme Sylvain Devidal
    Âge : 35
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2010
    Messages : 1 769
    Points : 2 590
    Points
    2 590

    Par défaut

    S'il y a des min/max, peut-être aussi des colonnes calculées en mode persistantes ?

  16. #36
    Expert Confirmé
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    juillet 2006
    Messages
    2 896
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : juillet 2006
    Messages : 2 896
    Points : 2 579
    Points
    2 579

    Par défaut

    Nope, pas de colonnes calculées persistantes. Du moins, pas dans mes "vraies" tables.

    Après, est-ce que les colonnes produites par les fonction min et max dans les #tables sont considérées comme telle, je ne suis pas assez calé pour le savoir.
    Kropernic (anciennement Griftou).

  17. #37
    Expert Confirmé Sénior
    Avatar de mikedavem
    Homme Profil pro David BARBARIN
    Architecte de base de données
    Inscrit en
    août 2005
    Messages
    4 582
    Détails du profil
    Informations personnelles :
    Nom : Homme David BARBARIN
    Localisation : France, Ain (Rhône Alpes)

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

    Informations forums :
    Inscription : août 2005
    Messages : 4 582
    Points : 9 147
    Points
    9 147

    Par défaut

    La partie en gras me fait un peu peur... Ok ma requête a été boostée et réponds au quart de tour mais si c'est pour que le reste du serveur rame à cause de ça quand ce sera en production (je dramatise sûrement mais bon), je ne suis pas sûr que cela en vaille vraiment la peine.
    Il faut prendre avec parcimonie (dans le sens où il faut appliquer à votre contexte) ce qui est dit et tester ta nouvelle implémentation de requête et voir l'impact de celle-ci par rapport à ta première version (CTE) sur ton serveur avec les données réelles.

    ++

  18. #38
    Expert Confirmé
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    juillet 2006
    Messages
    2 896
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : juillet 2006
    Messages : 2 896
    Points : 2 579
    Points
    2 579

    Par défaut

    Ah mais c'est pas pour tout de suite ça...

    La DB n'est même pas encore sur le serveur de production (logique, c'est un projet en développement).

    En plus, on attend de nouveaux serveurs d'ici la fin de l'année ^^

    EDIT :

    J'ai tenté l'expérience avec les vues mais je n'arrive même pas à un résultat qui tourne... Je ne savais pas que les vues étaient si contraignantes dès qu'on commence à utiliser des vues dans la définition d'une nouvelle vue.
    Kropernic (anciennement Griftou).

  19. #39
    Expert Confirmé
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    juillet 2006
    Messages
    2 896
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : juillet 2006
    Messages : 2 896
    Points : 2 579
    Points
    2 579

    Par défaut

    Je reviens sur le sujet...

    D'après le message de sqlpro, l'emploi de tables temporaires (et dans certains cas, celui de CTE's qui conduit à la création de tables temporaires) peut poser des problèmes de performances aux autres traitements du SGDBR.

    Du coup, que faudrait-il alors mettre en œuvre comme solution ?

    J'imagine que la "simple" requête reste la piste à privilégier plutôt que de multiples CTE's ou tables temporaires non ?

    Cette "simple" requête existe mais elle prend énormément de temps (j'ai déjà patienté 30 min avant de l'annuler). Le problème vient probablement d'un problème d'indexation de mes tables.

    Voici la requête en question :
    Code :
    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
         SELECT
                 CRD.TCA_ID,
                 CRD.CRD_RECHARGEABLE,
                 MIN(CRD.CRD_SERIAL) AS 'MIN',
                 MAX(CRD.CRD_SERIAL) AS 'MAX'
         FROM
                 DBO.T_GIFT_COMMANDE_GFC GFC
                     INNER JOIN dbo.T_CARD_CRD CRD
                         ON    GFC.GFT_ID = CRD.GFT_ID
                      OUTER APPLY    (
                                 SELECT
                                          MIN(SER_ID) AS 'CRD_SERIAL'
                                 FROM
                                         DBO.T_SERIAL_SER SER
                                 WHERE
                                         SER_ID > CRD.CRD_SERIAL
                                      AND SER_ID NOT IN    (
                                                         SELECT
                                                                 CRD_SERIAL
                                                         FROM
                                                                 DBO.T_GIFT_COMMANDE_GFC GFC2
                                                                     INNER JOIN dbo.T_CARD_CRD CRD3
                                                                         ON    GFC2.GFT_ID = CRD3.GFT_ID
                                                          WHERE
                                                                 CRD3.TCA_ID = CRD.TCA_ID
                                                              AND GFC2.CMD_ID = @CMD_ID
                                                         )
                                 ) T
         WHERE
                 GFC.CMD_ID = @CMD_ID
          GROUP BY
                 CRD.TCA_ID,
                 CRD.CRD_RECHARGEABLE,
                 T.CRD_SERIAL
         ORDER BY
                 CRD.TCA_ID,
                 CRD.CRD_RECHARGEABLE,
                 [MIN]
    Cette requête est une adaptation d'une requête que iberserk avait proposé pour un problème similaire. J'avais choisi de la réécrire (car je ne maitrise pas les FULL/OUTER APPLY) avec des CTE's que j'utilise régulièrement.

    Selon vous connaissances expertes, que faut-il préférer ? La requête unique où la décomposition en plusieurs requêtes ?

    EDIT :

    Ajout du plan de requête estimé en pièce jointe.
    Fichiers attachés Fichiers attachés
    Kropernic (anciennement Griftou).

  20. #40
    Expert Confirmé
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    juillet 2006
    Messages
    2 896
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : juillet 2006
    Messages : 2 896
    Points : 2 579
    Points
    2 579

    Par défaut

    Une piste aussi qui n'est pas à exclure, serait de renvoyer les données brutes à l'applicatif client et d'y faire le traitement.

    Niveau traitement, cela devrait aller très vite. Par contre, le transfert des données via le réseau, ça risque de merdé...

    Donc de base, je serais plutôt pour faire le taff côté DB même si c'est un traitement grandement cosmétique...
    Kropernic (anciennement Griftou).

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •