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 :

DELETE très lent : Optimisation ?


Sujet :

Développement SQL Server

  1. #1
    Futur Membre du Club
    Profil pro
    Inscrit en
    Février 2004
    Messages
    8
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2004
    Messages : 8
    Points : 6
    Points
    6
    Par défaut DELETE très lent : Optimisation ?
    Bonjour à tous,

    Sur le logiciel que je développe, je suis confronté à un problème de performance que je n'arrive pas à résoudre : lors de la suppression d'une entité, un script SQL est censé supprimer une centaine de lignes sur une table centrale de l'application (beaucoup de tables ont une clé étrangère pointant sur elle...). Or ce script met plus d'une minute à s'exécuter (que ce soit sur l'environnement de production ou sur un environnement local ou je reproduis le même scénario).

    En gros la requête simplissime est du style :

    DELETE FROM PROP.MA_TABLE WHERE id_ma_table in (100, 123, .....)

    Quels sont les pistes d'optimisation que je pourrais explorer ? (indexes sur toutes les clés étrangères "id_ma_table" ? problèmes avec les statistiques ? ...)

    Merci !
    Cornelius - Montpellier

  2. #2
    Modérateur

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Janvier 2005
    Messages
    5 826
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Janvier 2005
    Messages : 5 826
    Points : 12 371
    Points
    12 371
    Par défaut
    Bonjour,

    Cela est difficile à dire sans avoir le script DDL de création de la table, et sans connaître le nombre de lignes que contient votre table.
    Le mieux serait encore le plan de requête (CTRL+S sous SSMS) histoire de voir le nombre de lignes manipulé estimé ... et s'il est réellement équivalent à ce que vous avez dans la table ...

    @++

  3. #3
    Futur Membre du Club
    Profil pro
    Inscrit en
    Février 2004
    Messages
    8
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2004
    Messages : 8
    Points : 6
    Points
    6
    Par défaut
    La table comporte 67 000 lignes et le plan d'exécution de ma requête DELETE ressemble à ça :

    http://img513.imageshack.us/img513/9613/planexec.jpg

    (le schéma de l'image se répète X fois, avec toutes les tables [une vingtaine] qui ont une clé étrangère pointant sur la table concernée par la suppression)
    Cornelius - Montpellier

  4. #4
    Modérateur

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Janvier 2005
    Messages
    5 826
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Janvier 2005
    Messages : 5 826
    Points : 12 371
    Points
    12 371
    Par défaut
    Combien, approximativement, comporte de lignes la table #DST ?
    Est-ce qu'une table qui référence votre table contient un nombre important de lignes ?
    Est-ce que la colonne qui sert de clé étrangère dans ces tables est indexée ?
    Et si tel est le cas, ces indexes ne seraient-ils pas fortement fragmentés ?
    N'y-a-t-il pas un pourcentage dans votre plan de requête qui indique où se trouve le goulot d'étranglement ?
    N'y-a-t-il pas des indexes manquants sur les tables impliquées dans cette suppression ?
    Quelle est la clause WHERE de votre instruction DELETE ?
    Est-ce que les colonnes qui sont spécifiées dans le WHERE sont indexées ?
    Est-ce que le prédicat que spécifie votre clause WHERE est SARGable ?

    Désolé de vous pourrir de questions, mais je manque d'éléments pour vous aider

    @++

  5. #5
    Futur Membre du Club
    Profil pro
    Inscrit en
    Février 2004
    Messages
    8
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2004
    Messages : 8
    Points : 6
    Points
    6
    Par défaut
    Combien, approximativement, comporte de lignes la table #DST ?
    Cette table est une table temporaire "simulant" le " IN (100, 123, ....)". Elle comporte 111 lignes, les 111 que je dois supprimer.

    Est-ce qu'une table qui référence votre table contient un nombre important de lignes ?
    Oui. La table la plus fournie comporte 720 000 lignes.

    Est-ce que la colonne qui sert de clé étrangère dans ces tables est indexée ?
    Non. Mais lors de mes différents tests j'ai rajouté ces indexes, et cela n'a pas impacté les performances. Peut être ma création d'indexes n'était pas optimale...

    Et si tel est le cas, ces indexes ne seraient-ils pas fortement fragmentés ?
    Comment puis-je savoir cela ?

    N'y-a-t-il pas un pourcentage dans votre plan de requête qui indique où se trouve le goulot d'étranglement ?
    il y a 2 ou 3 "11 %" (on en voit un sur l'image)

    N'y-a-t-il pas des indexes manquants sur les tables impliquées dans cette suppression ?
    Sans doute sur les clés étrangères donc...

    Quelle est la clause WHERE de votre instruction DELETE ?
    Concrètement, la requête est la suivante :
    delete L from vin.lot L INNER JOIN #DST D ON d.id_lot_dst = L.id_lot
    équivalente en fait à :
    DELETE FROM vin.tl_resa_lot WHERE id_lot in (82186,82187,82188,82189,82190,82191,82192,82193,82194,82195,
    82196,82197,82198,82199,82200,82201,82202,82203,82204,82205,82206,
    82207,82208,82209,82210,82211,82212,82213,82214,82215,82216,82217,
    82218,82219,82220,82221,82222,82223,82224,82225,82226,82227,82228,
    82229,82230,82231,82232,82233,82234,82235,82236,82237,82238,82239,
    82240,82241,82242,82243,82244,82245,82246,82247,82248,82249,82250,
    82251,82252,82253,82254,82255,82256,82257,82258,82259,82260,82261,
    82262,82263,82264,82265,82266,82267,82268,82269,82270,82271,82272,
    82273,82274,82275,82276,82277,82278,82279,82280,82281,82282,82283,
    82284,82285,82286,82287,82288,82289,82290,82291,82292,82293,82294,
    82295,82296)


    Est-ce que les colonnes qui sont spécifiées dans le WHERE sont indexées ?
    Oui, c'est la clé primaire

    Est-ce que le prédicat que spécifie votre clause WHERE est SARGable ?
    Je crois bien que oui (d'après ce que je comprends du terme SARGable )

    Désolé de vous pourrir de questions, mais je manque d'éléments pour vous aider
    Avec plaisir, merci beaucoup !
    Cornelius - Montpellier

  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
    21 782
    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 : 21 782
    Points : 52 783
    Points
    52 783
    Billets dans le blog
    5
    Par défaut
    Pour votre plan de requête sauvegarder l'image au format XML et postez là.

    (clic droit dans l'image... enregsitrer...)

    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
    Futur Membre du Club
    Profil pro
    Inscrit en
    Février 2004
    Messages
    8
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2004
    Messages : 8
    Points : 6
    Points
    6
    Par défaut
    Hélas j'ai l'impression que SQL Server Management Express ne connaît pas la traduction XML des plans d'exécution...
    Cornelius - Montpellier

  8. #8
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 782
    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 : 21 782
    Points : 52 783
    Points
    52 783
    Billets dans le blog
    5
    Par défaut
    Dans ce cas, offrez vous l'édition développeur de SQL Server, car elle a SSMS complet et coute peut cher (40 € je crois)... Parce qu'il est difficile d'optimiser sans les bons outils !

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

Discussions similaires

  1. optimisation connection très lente
    Par LeGnome12 dans le forum Internet
    Réponses: 0
    Dernier message: 22/06/2011, 23h15
  2. [ASE]optimisation d'une proc stock trés lente
    Par 461219 dans le forum Adaptive Server Enterprise
    Réponses: 8
    Dernier message: 04/01/2008, 13h23
  3. Très lent comment optimiser svp ?
    Par dev7 dans le forum PostgreSQL
    Réponses: 1
    Dernier message: 02/06/2006, 12h16
  4. [Oracle 8.1.5] Base devenant très lente après DELETE
    Par J.TROSSET dans le forum Oracle
    Réponses: 8
    Dernier message: 11/10/2005, 14h16

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