En gestion d'objet, chaque utilisateur peut poser, par l'intermédiaire du menu Sélection / Sélection, des filtres destinés à sélectionner dans la liste gauche une partie seulement de la table. Une telle sélection peut ensuite être mémorisée, et réutilisée régulièrement.

Cette fonctionnalité intéressante est néanmoins source de problèmes potentiels de performance lorsque les tables ainsi filtrées sont très volumineuses (plusieurs centaines de milliers de lignes, par exemple). Elle l'est d'autant plus que ces mémos peuvent être standard (ie. chargés dès que l'utilisateur entre dans la fonction), et globaux (ie. partagés par un ensemble d'utilisateurs).

La fonction d'analyse permet, a posteriori, de détecter des problèmes potentiels de performance compte tenu des mémos posés par les utilisateurs dans un dossier. Attention, elle ne donne que des indications, et peut dans certains cas révéler des problèmes qui n'en sont pas. Par exemple, un mémo pour lequel aucun index discriminant n'est trouvé par cet utilitaire peut très bien compléter un filtre défini par ailleurs dans la logique du traitement standard.

Il est néanmoins prudent de vérifier, pour chaque ligne de trace ainsi trouvée, la pertinence du message d'erreur, en prenant des mesures correctives. Ces mesures peuvent être de deux types :

  • suppression du mémo correspondant ou avertissement à l'utilisateur
  • ajout d'un index d'optimisation si celui-ci paraît adapté

Afin d'obtenir ce résultat, le traitement lit tous les fichiers mémos présents sur le dossier, rapproche les critères utilisés des différents index existant sur la table (y compris les index d'optimisation), et pose un diagnostic en tenant compte du nombre de lignes présents dans la table.

Il est à noter que deux paramètres, mentionnés ci-dessous, permettent de contrôler a priori les mémos créés par les utilisateurs. Mais ces mémos ne sont contrôlés qu'à leur création. Or des mémos jugés performants à l'origine peuvent très bien ne plus l'être quelques mois après, si la volumétrie de la base les rend lourds à l'exécution. C'est pourquoi il est intéressant de lancer cet utilitaire même si les deux paramètres ci-dessous sont correctement renseignés.

Pré-requis

SEEREFERTTO Reportez-vous à la documentation de Mise en oeuvre

Gestion de l'écran

Ecran de saisie

On définit simplement trois valeurs (en nombre de lignes) caractérisant les tables sur lesquelles on teste les mémos.

Lorsque l'exécution de la fonction est terminée, on obtient un fichier trace en deux parties. La première partie est une liste des problèmes trouvés, triés dans l'ordre alphabétiques des fichiers de mémo et numéroté . La trace donne les informations sous la forme suivante :

  • une première ligne d'en-tête détaillant le nom du mémo (NOM), le fait qu'il soit local ou global, l'utilisateur concerné (UUUUU), et la table sur laquelle est posée le mémo (XXXXXX). Les mémos problématiques sont numérotés (champ NNN), ce qui donne la ligne suivante (local pouvant être remplacé par global) :

NNN Mémo local UUUUU.NOM sur table XXXXXX (intitulé table)

  • une ou plusieurs lignes explicitant les problèmes de performance rencontrés sur ce mémo. Les tableaux ci-dessous donne les messages susceptibles d'être rencontrés :

MESSAGE

DEFINITION

*** WARN (MMMM) *** DESCRIPTION

Problème de performance : la table fait MMMM lignes.

*** PERF (MMMM) *** DESCRIPTION

Problème de performance sérieux : la table fait MMMM lignes.

*** CRIT (MMMM) *** DESCRIPTION

Problème de performance critique : la table fait MMMM lignes.

 

CHAMP DESCRIPTION

Explication

Pas d'index adapté au filtre sur le(s) champ(s) CHAMP1 CHAMP2 ... : Problème de performance

Compte tenu des filtres indiqués, aucun index approprié n'existe. Si le mémo est utile et fréquemment utilisé, il faudra envisager un index d'optimisation.

La clé de tri de la liste gauche (CLE1) est différente de la clé de filtrage (CLE2)

La base de donnée se sert d'un premier index (CLE2) pour filtrer les données, puis les trie selon l'index CLE1 afin de présenter la liste gauche. Ceci peut être un problème de performance si l'index servant au filtrage est peu sélectif (un grand nombre de lignes devant alors être triées).

Opérateur 'Différent' sur champ CHAMP1

Opérateur 'Comme' sur champ CHAMP1

Ces deux opérateurs ne permettent pas à la base de données d'utiliser de façon simple les index sur des bornes de valeur ; les performances peuvent donc être mauvaises.

Opérateur 'ou' entre deux conditions

La sélection implique une ou plusieurs conditions séparées par des ou. Ce type de requête est en général assez lourd.

Sélection sur expression : expression

Ce type de sélection n'est pas analysé et doit donc être vérifié pour savoir si un problème potentiel de performance existe.

Plusieurs tables dans le mémo, vérifier la requête

On fait des sélections sur des jointures. Ce type de requête ne peut pas être vérifié  automatiquement par l'utilitaire : une vérification manuelle s'impose pour savoir si un problème de performance peut exister.

La deuxième partie de la trace donne une liste hiérarchisée des problèmes précédents (une ligne par problème). On y retrouve tout d'abord le numéro de problème précédent, le nom du mémo sous la forme UUUUUU.NOM/TABLE, le nombre de lignes de la table, et un résumé succinct des critères de filtre. L'ordre de tri est le suivant :

  • les mémos standards sont classés d'abord, puis les mémos non standards.
  • les mémos globaux sont classés d'abord, puis les mémos locaux
  • à égalité sur ces deux premiers critères, on trie selon le nombre décroissant de lignes dans la table.

Ceci permet de se focaliser d'abord sur les mémos susceptibles de provoquer le plus de problèmes de performance.

Tâche batch

Cette fonction peut être lancée en batch, mais il n'existe pas de tâche standard dédiée à son lancement.

Messages d'erreur

Il n'y a pas de message d'erreur autre que les messages d'erreur génériques.

Tables mises en oeuvre

SEEREFERTTO Reportez-vous à la documentation de Mise en oeuvre