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

AS/400 Discussion :

Brusque ralentissement requête SQL


Sujet :

AS/400

  1. #1
    Membre éprouvé
    Homme Profil pro
    Responsable de service informatique
    Inscrit en
    Octobre 2006
    Messages
    686
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Jura (Franche Comté)

    Informations professionnelles :
    Activité : Responsable de service informatique
    Secteur : Distribution

    Informations forums :
    Inscription : Octobre 2006
    Messages : 686
    Points : 987
    Points
    987
    Par défaut Brusque ralentissement requête SQL
    Bonjour,
    Dans un de nos vieux programmes, il y a deux requêtes SQL lancées automatiquement le 1er du mois depuis 10 ans, qui prenaient approximativement (en fonction des sociétés traitées) 1 à 5 secondes pour s'exécuter.
    Brusquement, cette nuit, ces requêtes se sont mises à tourner à une vitesse anormale, le programme passant à près de 20mn pour une seule société.
    Le système (V5R4) est à jour de ses PTF, aucune n'a été appliquée depuis le mois dernier. Il n'y a aucun incident hardware. Ni les fichiers, ni les programmes n'ont changé depuis longtemps.
    Alors j'y perds mon latin. Je ne comprends pas ce qui arrive, et surtout pourquoi ces requêtes s'exécutent aussi lentement. J'aurais surement meilleur temps de traiter çà en RPG pur, tellement c'est lent !
    Alors, si quelqu'un a une idée, ou mieux une explication, ce serait le pied. ;-)
    Exemple d'une des deux requêtes :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    Update articl set arcmmo =                              
             (select round(sum(stquan/12), 0) from stagen where strefe = arrefe and                   
                                                ((staafa * 100) + stmmfa) > :LimBasse)
      where arrefe in                                       
             (select strefe from stagen where ((staafa * 100) + stmmfa) > :LimBasse)

  2. #2
    Expert confirmé
    Homme Profil pro
    ANCIEN Consultant/Formateur/Développeur AS/400, iSeries, System i et Cobol
    Inscrit en
    Juin 2007
    Messages
    2 096
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Tunisie

    Informations professionnelles :
    Activité : ANCIEN Consultant/Formateur/Développeur AS/400, iSeries, System i et Cobol
    Secteur : Conseil

    Informations forums :
    Inscription : Juin 2007
    Messages : 2 096
    Points : 4 155
    Points
    4 155
    Par défaut
    Bonjour.

    A première vue et en se basant sur ce que tu dis à propos du hard, surtout quant à l'état des disques, je penserais à un problème de volumétrie des tables concernées ou plus généralement sur les disques, (autres tables, spool, etc...)
    J'essayerais de faire un RGZPFM sur les tables ARTICL et STAGEN avec KEYFILE(*FILE), puis un RCLDBXREF ou carrément un RCLSTG.
    Penser à vérifier l'occupation des disques et au %ASP.

  3. #3
    Membre éprouvé
    Homme Profil pro
    Responsable de service informatique
    Inscrit en
    Octobre 2006
    Messages
    686
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Jura (Franche Comté)

    Informations professionnelles :
    Activité : Responsable de service informatique
    Secteur : Distribution

    Informations forums :
    Inscription : Octobre 2006
    Messages : 686
    Points : 987
    Points
    987
    Par défaut
    Merci pour la réponse.

    L'ASP est loin d'être surchargé, il est à 24% d'occupation.
    Je ne l'ai pas précisé, mais j'ai déjà effectué un RGZPFM sur les fichiers, au cas où. Sans résultat.
    Le RCLDBXREF ne renvoie aucune erreur. J'envisage un RCLSTG.

    Toutefois, j'ai l'impression que le problème est ailleurs. Après des tests, je pense que c'est simplement l'évolution de la base de donnée qui a entrainé ce problème. Je vais remonter les fichiers du mois dernier sur une bibliothèque de test, et lancer la requête sur cette bibliothèque. Si tout se passe bien, j'aurais confirmation que c'est l'apport de nouvelles données (même si peu important), qui a contribué à cette dégradation.
    Car je soupçonne que c'est l'optimiseur de requête qui se prend les pieds dans le tapis. En clair, jusqu'à présent il utilisait les bons chemins d'accès parce que la proportion/nombre d'enregs, étaient dans les bonnes fourchettes. Là, avec les nouveaux enregs ajoutés, il doit arriver à une conclusion différente, et prendre une autre option, qui s'avère catastrophique.
    Je vais donc tenter de modifier la requête, et il faudrait, mais le temps me manque car il y a de nombreux programmes associés, que je modifie le fichier STAGEN pour utiliser des dates au lieu (le fichier est très ancien) de zones (année, mois, jour).


    Edit :
    Les tests sur les sauvegardes du mois dernier montrent une différence monumentale de temps de traitement, malgré un simple ajout de 1000 enregistrements au fichier STAGEN (total 113.000, croisés à 41.000 enregs dans le fichier ARTICL d'origine).
    Après modification de la requête (sélection sur les zones STAAFA et STMMFA de manière individuelle et non dans un calcul), les temps sont redevenus normaux, le programme s'est exécutée en à peine 2 secondes...
    Je m'étonne quand même que l'optimiseur ait pu utiliser une méthode d'accès si gourmande (10 bonnes minutes à 75% de CPU), en lieu et place d'une méthode réellement ultra-rapide. Même en accès RPG pur j'aurais été bien plus vite que cette requête SQL. C'est pourtant hyper efficace sur les traitement de masse d'habitude...
    Bref, si quelqu'un a une bonne explication, et/ou des conseils à me fournir, je suis preneur. Je vais attendre 1 jour ou 2, et je mettrai le sujet en résolu.

  4. #4
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Juin 2002
    Messages
    31
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2002
    Messages : 31
    Points : 37
    Points
    37
    Par défaut
    Bonjour,

    Pour comprendre en détail, il faudrait avoir les plans d’exécution de la requête longue qui a duré 20min ainsi que celle qui a duré 2s pour comparer les mécanismes utilisés par l'optimiseur.

    Par contre, de façon générale, pour aider l'optimiseur à utiliser des index il faut éviter les sélections sur valeurs calculées, c'est à dire préférer cette syntaxe :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    Update articl set arcmmo =                              
             (select round(sum(stquan/12), 0) from stagen where strefe = arrefe and 
                                                (staafa > :LimBasseA or (staafa = :LimBasseA and stmmfa > :LimBasseM))                  
      where arrefe in                                       
             (select strefe from stagen where (staafa > :LimBasseA or (staafa = :LimBasseA and stmmfa > :LimBasseM))
    Ou, si nécessaire, créer un index dérivé avec (staafa * 100) + stmmfa.

    Dans tous les cas, seule le plan d’exécution pourra fournir les informations utiles : index utilisés, index recommandés ...

  5. #5
    Membre régulier
    Homme Profil pro
    Expertise IBM i. Formation, Audit, Conseil, Sécurité
    Inscrit en
    Février 2009
    Messages
    40
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Expertise IBM i. Formation, Audit, Conseil, Sécurité

    Informations forums :
    Inscription : Février 2009
    Messages : 40
    Points : 94
    Points
    94
    Par défaut
    Bonjour,

    Pour avoir un vision de ce que propose l'optimiseur, tu peux utiliser Visual Explain qui te montre la stratégie d'accès utilisée. Tu peux même avoir :
    • Les étapes couteuses, en CPU, en nombre d'enregistrements traités...
    • Le moteur SQL utilisé (SQE ou CQE, à vérifier dans ton cas)
    • Des préconisations sur les index à créer (et les créer automatiquement)
    • Des préconisations sur les données statistiques qu'il faudrait générer

    Tu peux juste demander l'explicitation, sans l'exécution, c'est à dire ne pas retourner les enregistrements mais avoir les données de l'optimiseur.
    En utilisant Visual Explain sur les différentes requêtes que tu évoques, tu devrais avoir une idée de ce qui se passe, tout du moins si le problème vient de SQL (il peut aussi y avoir d'autres causes : verrouillages, par exemple !).
    Pour ceux qui ne connaissent pas Visual Explain
    En deux mots, il s'agit d'une fonction intégrée à System i Navigator (logiciel non facturable, à installer avec toutes ses options à partir d'IBM i Access for Windows). Dans la partie Base de données, il existe un éditeur de script SQL qui permet de taper des requêtes et de les exécuter. Attention au séparateur Bibliothèque/objet (on dirait plutôt Schéma/Table en SQL) qui est le . à la place de notre traditionnel /.
    Un bouton Visual Explain permet de disposer, en graphique, de toutes les données concernant cette requête.
    Ci dessous l'illustration d'une simple requête : SELECT * FROM qsys2.syscolumns.
    Nom : Visual Explain.png
Affichages : 428
Taille : 10,7 Ko
    Nom : Visual Explain 2.png
Affichages : 287
Taille : 13,7 Ko

  6. #6
    Membre éprouvé
    Homme Profil pro
    Responsable de service informatique
    Inscrit en
    Octobre 2006
    Messages
    686
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Jura (Franche Comté)

    Informations professionnelles :
    Activité : Responsable de service informatique
    Secteur : Distribution

    Informations forums :
    Inscription : Octobre 2006
    Messages : 686
    Points : 987
    Points
    987
    Par défaut
    OK, on arrive donc à la même conclusion.
    J'ai décidé de passer du temps à modifier le fichier pour passer sur une zone date unique. Je vais y perdre une bonne journée avec tous les programmes à adapter, mais au moins j'aurais plus de facilités à traiter tout çà dans le futur, et les programmes seront plus clairs.
    Merci.

    Edit : Je n'avais pas pensé à Visual Explain, c'est un tort de ma part. Je vais désormais tester mes requêtes avec cet outil, pour les optimiser.

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

Discussions similaires

  1. [ DB2 ] [ AS400] requête sql
    Par zinaif dans le forum DB2
    Réponses: 6
    Dernier message: 23/08/2008, 20h42
  2. Utilisation de MAX dans une requête SQL
    Par Evil onE dans le forum Langage SQL
    Réponses: 7
    Dernier message: 15/06/2004, 19h38
  3. A propos d'une requête SQL sur plusieurs tables...
    Par ylebihan dans le forum Langage SQL
    Réponses: 2
    Dernier message: 14/09/2003, 17h26
  4. PB requète SQL avec Interbase
    Par missllyss dans le forum InterBase
    Réponses: 2
    Dernier message: 15/07/2003, 12h37
  5. Requête SQL
    Par Leludo dans le forum Langage SQL
    Réponses: 2
    Dernier message: 17/02/2003, 17h44

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