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

Développement SQL Server Discussion :

Requête longue au changement de base de données de "lancement" [2017]


Sujet :

Développement SQL Server

  1. #1
    Futur Membre du Club
    Inscrit en
    septembre 2009
    Messages
    8
    Détails du profil
    Informations forums :
    Inscription : septembre 2009
    Messages : 8
    Points : 6
    Points
    6
    Par défaut Requête longue au changement de base de données de "lancement"
    Bonjour,

    La requete ci dessous s'exécute en moins de 1 seconde lorsque je l'exécute depuis le contexte "BaseClient" (=en sélectionnant la base de données BaseClient en haut à gauche de SSMS), alors qu'elle prend plusieurs minutes depuis master ou d'autres base. Savez-vous d'ou vient ce problème ?

    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    SELECT ARTICLE.ID_ARTICLE IDENT FROM BaseClient.dbo.ARTICLE 
    inner JOIN BaseClient.dbo.COMMUNE ON COMMUNE.ID_COMMUNE=ARTICLE.ID_COMMUNE AND COMMUNE.ID_CLIENT = 3 AND COMMUNE.ANNEE = 2020 
    AND COMMUNE.ID_COMMUNE IN (13857, 13878, 13922, 13928, 13938, 13959, 13985, 14028, 14059, 14067, 14083, 14088, 14092, 14102, 14109, 14116, 14163, 14159) 
    WHERE ( 
    EXISTS ( SELECT 'a'  FROM BaseClient.dbo.DEBITEUR  WHERE DEBITEUR.NOM_CONCAT like '%dupon%' 
    AND DEBITEUR.ID_ARTICLE = ARTICLE.ID_ARTICLE))

    Pour info, voici quelques infos qui vous comprendront peut-être de voir d'où vient le problème :
    - la base BaseClient a été construite en SQL 2008 et est en niveau de compatibilité SQL Server 2008 (100). Lorsque je passe la base depuis laquelle j'exécute la requete en niveau de compatibilité 2008 (100), la réponse est instantanée. (mais d'autres requêtes de l'application deviennent longues)
    - Lorsque je met BaseClient et la base depuis laquelle je lance la requete en niveau de compatibilité SQL Server 2019, les temps sont de nouveau longs.
    - Lorsque je modifie le filtre sur "AND COMMUNE.ID_COMMUNE" et que je met "AND COMMUNE.ID_COMMUNE IN (14092, 14116) ", la réponse est instantanée (le plan d'exécution change)
    - J'ai passé la valeur de READ_COMMITTED_SNAPSHOT à ON sur BaseClient pour pouvoir exécuter la requete depuis un autre contexte

    Avez-vous une idée ?

    Merci par avance pour votre aide

  2. #2
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    7 256
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 7 256
    Points : 23 071
    Points
    23 071
    Billets dans le blog
    2
    Par défaut
    Bonjour,

    Le fait de changer la liste des communes change le facteur de filtrage, il n'est donc pas anormal d'avoir une stratégie différente.
    Possiblement, avec seulement deux communes, vous ramenez un tout petit nombre de cas, il existe alors un ou plusieurs index filtrants, l'un d'eux est utilisé.
    Avec la grande liste, il y a probablement des communes "vedette" qui ramassent l'essentiel des cas, ce faisant, aucun index n'est filtrant, aucun n'est retenu.

    Par ailleurs, l'opérateur LIKE utilisé avec '%chaine%' n'est pas sargable, aucun index ne sera donc utilisé sur ce critère.

    Enfin, les différentes BDD ont elles bien le même contenu ?

  3. #3
    Futur Membre du Club
    Inscrit en
    septembre 2009
    Messages
    8
    Détails du profil
    Informations forums :
    Inscription : septembre 2009
    Messages : 8
    Points : 6
    Points
    6
    Par défaut
    Bonjour,

    Merci pour votre réponse

    Ok je vais peut-être mettre en place un index en texte intégral sur le champs NOM_CONCAT si on ne trouve pas d'autres solutions, et utiliser le critère de cette manière :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    AND CONTAINS(DEBITEUR.NOM_CONCAT, '"dupon"')
    Pour répondre à votre dernière question, les différente BDD ont bien le même contenu

  4. #4
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    20 774
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

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

    Informations forums :
    Inscription : mai 2002
    Messages : 20 774
    Points : 49 208
    Points
    49 208
    Billets dans le blog
    1
    Par défaut
    Le contexte d'une base de données, comme la session peut avoir un paramétrage d'exécution qui diffère... Il faudrait donc voir tout le paramétrage en analysant les plan de requêtes dans ces différents contextes (lire le XML)... en particulier la balise "StatementSetOptions"
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    <StatementSetOptions ANSI_NULLS="true" ANSI_PADDING="true" ANSI_WARNINGS="true" ARITHABORT="true" CONCAT_NULL_YIELDS_NULL="true" NUMERIC_ROUNDABORT="false" QUOTED_IDENTIFIER="true" />
    D'autre part que cette requête soit plus longue en 2019 qu'en version 2008, sur une instance 2019 est un cas fréquent, si vous n'avez pas recalculée toutes les statistiques de l'optimiseur en mode FULLSCAN.
    Chaque version de SQL Server apporte de nombreuses amélioration en terme d'exécution, notamment avec de nouvelles techniques, de nouveaux algorithmes, de nouveaux types d'index, de nouveaux objets et de nouveaux process... Mais, si vos statistiques date de la version 2008, alors le moteur version 2019 ne peut rien en faire.... Un peu comme si vous passiez de la mobylette à la formule 1 en restant, au niveau du carburant, au mélange 2 temps avec essence au plomb !

    Commencez donc par mettre à niveau votre base vers la version 2019, puis recalculez toutes vos stats en mode FULLSCAN avec le code suivant :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    DECLARE @SQL NVARCHAR(max) = N'';
    SELECT @SQL = @SQL + N'UPDATE STATISTICS [' + s.name + ']. [' + o.name + '] WITH FULLSCAN;' 
    FROM   sys.stats AS st
           JOIN sys.objects AS o ON st.object_id = o.object_id
                  JOIN sys.schemas AS s ON o.schema_id = s.schema_id;
    EXEC (@SQL);
    Vous verrez, ça ira mieux !

    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/ * * * * *

  5. #5
    Futur Membre du Club
    Inscrit en
    septembre 2009
    Messages
    8
    Détails du profil
    Informations forums :
    Inscription : septembre 2009
    Messages : 8
    Points : 6
    Points
    6
    Par défaut
    Merci beaucoup pour votre retour !

    J'ai cependant 2 questions. Votre requete fait UPDATE STATISTICS sur chacune des tables de la base sélectionnée, mais :
    - ne faut-il pas ajouter un DISTINCT car la requete renvoie des lignes en double ?
    - ne fait-il pas ajouter un where s.name = 'dbo' pour ne mettre à jour que sur les tables utilisateurs ?

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    SELECT distinct  N'UPDATE STATISTICS [' + s.name + ']. [' + o.name + '] WITH FULLSCAN;' 
    FROM   sys.stats AS st
    JOIN sys.objects AS o ON st.object_id = o.object_id
    JOIN sys.schemas AS s ON o.schema_id = s.schema_id
    where s.name = 'dbo'
    Au niveau du plan d'execution, la balise "StatementSetOptions" est similaire sur les bases

    Merci

  6. #6
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    20 774
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

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

    Informations forums :
    Inscription : mai 2002
    Messages : 20 774
    Points : 49 208
    Points
    49 208
    Billets dans le blog
    1
    Par défaut
    Oui, non

    DISTINCT pas nécessaire si l'on retire la table stats de la requête.

    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/ * * * * *

  7. #7
    Membre expérimenté

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    septembre 2003
    Messages
    731
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2003
    Messages : 731
    Points : 1 621
    Points
    1 621
    Billets dans le blog
    8
    Par défaut
    Citation Envoyé par number5rcp Voir le message
    Merci beaucoup pour votre retour !
    - ne faut-il pas ajouter un DISTINCT car la requete renvoie des lignes en double ?
    Bonjour,

    Chacune des statistiques est liée à une ou plusieurs colonnes de la même table.
    Ce qui explique, de mon point de vue, les doublons au niveau de la table de rattachement (o.name vs (Objects.name) ) à chacune des statistiques considérées.

    Je pense à un petit oubli (st.name), dans le script de notre cher ami SQLPro . A confirmer bien sûr.
    Je dirai plutôt ceci (sans la clause DISTINCT) :
    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    DECLARE @SQL NVARCHAR(max) = N'';
    SELECT @SQL = @SQL + N'UPDATE STATISTICS [' + s.name + ']. [' + o.name + '] [' + st.name  + ']  WITH FULLSCAN;'
    FROM   sys.stats AS st
    INNER JOIN sys.objects as o 
      ON st.object_id = o.object_id
    INNER JOIN sys.schemas as s 
      ON o.schema_id = s.schema_id;
    EXEC (@SQL);
    A+
    "Une idée mal écrite est une idée fausse !"
    http://hamid-mira.blogspot.com

  8. #8
    Membre expérimenté

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    septembre 2003
    Messages
    731
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2003
    Messages : 731
    Points : 1 621
    Points
    1 621
    Billets dans le blog
    8
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    Oui, non

    DISTINCT pas nécessaire si l'on retire la table stats de la requête.

    A +
    Bonjour SQLPro

    C'est exact. Merci pour la précision.

    OK, le DISTINCT n'est pas nécessaire si on retire la table stats de la requête.

    A+
    "Une idée mal écrite est une idée fausse !"
    http://hamid-mira.blogspot.com

  9. #9
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    20 774
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

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

    Informations forums :
    Inscription : mai 2002
    Messages : 20 774
    Points : 49 208
    Points
    49 208
    Billets dans le blog
    1
    Par défaut
    Donc :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    DECLARE @SQL NVARCHAR(max) = N'';
    SELECT @SQL = @SQL + N'UPDATE STATISTICS [' + s.name + ']. [' + o.name + '] WITH FULLSCAN;' 
    FROM   sys.objects AS o ON st.object_id = o.object_id
                  JOIN sys.schemas AS s ON o.schema_id = s.schema_id;
    EXEC (@SQL);
    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/ * * * * *

  10. #10
    Futur Membre du Club
    Inscrit en
    septembre 2009
    Messages
    8
    Détails du profil
    Informations forums :
    Inscription : septembre 2009
    Messages : 8
    Points : 6
    Points
    6
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    Donc :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    DECLARE @SQL NVARCHAR(max) = N'';
    SELECT @SQL = @SQL + N'UPDATE STATISTICS [' + s.name + ']. [' + o.name + '] WITH FULLSCAN;' 
    FROM   sys.objects AS o ON st.object_id = o.object_id
                  JOIN sys.schemas AS s ON o.schema_id = s.schema_id;
    EXEC (@SQL);
    A +
    Bonjour,

    Après mise à jour des statistiques, les requêtes sont effectivement bien plus rapides (au moins dans mon cas problématique).
    Merci beaucoup pour votre aide !

    A+

  11. #11
    Expert confirmé Avatar de nico84
    Homme Profil pro
    Consultant/développeur ERP
    Inscrit en
    mai 2008
    Messages
    2 984
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 58
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Consultant/développeur ERP
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mai 2008
    Messages : 2 984
    Points : 5 000
    Points
    5 000
    Par défaut
    Bonjour,

    Merci pour toutes ces infos, l'optimisation de BD est sans fin...

    Par curiosité, est-ce que l'instruction suivante fait un travail similaire ou ça n'a rien à voir ?
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    ALTER INDEX ALL ON [matable] REBUILD
    Utilisez Planet, gestion d'entreprise gratuite pour TPE / PME

  12. #12
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    20 774
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

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

    Informations forums :
    Inscription : mai 2002
    Messages : 20 774
    Points : 49 208
    Points
    49 208
    Billets dans le blog
    1
    Par défaut
    Un travail différent... REINDEX ALL reconstruit tous les index et en profite pour recalculer les stats.

    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/ * * * * *

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. [AC-2019] Requete longue au changement de base de donnée de "lancement"
    Par number5rcp dans le forum Requêtes et SQL.
    Réponses: 0
    Dernier message: 19/04/2021, 08h25
  2. Requête de mise à jour - Ouverture base de données
    Par ade94 dans le forum Requêtes et SQL.
    Réponses: 1
    Dernier message: 31/05/2007, 16h50
  3. Changement de base de données = vba incompatible
    Par schuitonzo dans le forum Access
    Réponses: 22
    Dernier message: 22/02/2007, 16h46
  4. changement de base de donnée
    Par Pitou5464 dans le forum Access
    Réponses: 3
    Dernier message: 08/08/2006, 14h37
  5. [VBA-E] Requète SQL avec chemin de base de données variable
    Par Svart26 dans le forum Macros et VBA Excel
    Réponses: 2
    Dernier message: 26/05/2006, 13h29

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