Un audit de votre système BW : Pourquoi faire ?
Les raisons pour lesquelles vous souhaitez faire un audit de votre système BW sont nombreuses mais une des raisons principales est bien souvent la faible performance des rapports.
Vous le constatez tous les jours, le mécontentement des utilisateurs est croissant lorsque l’accès rapide et fiable aux informations n’est pas garanti.
Un projet d’analyse ou d’optimisation des performances de votre système SAP BW pourrait donc non seulement améliorer à terme le temps de réponse de vos rapports mais aussi vous éviter des investissements matériel supplémentaire, en optimisant la modélisation BW et la configuration de votre base de données.
Au cours de l’implémentation de BW, l’optimisation des performances, est un des aspects difficile et compliqué à appréhender. Cela nécessite un mélange de compétences dans des domaines variés comme : la mise en œuvre d’un modèle de données performant, l’optimisation d’une base de données, la configuration du système SAP BW ou l’architecture globale des applications.
Les mesures à prendre sont nombreuses et dépendent essentiellement de votre système et de votre architecture de base.
Quels sont les axes d’analyses et les actions à privilégier pour améliorer les performances de mon système SAP BW ?
Nous pouvons établir plusieurs domaines d’investigations :
- Les Early Watch Alert
- La construction de la requête en elle-même
- L’architecture et le modèle de données
- La gestion de la base de données
Les EARLY WATCH ALERT (EWA)
L’analyse des Early watch Alert (EWA) SAP est un bon début.
Ceci permet de vérifier les composants de votre paysage système et ensuite de déterminer les actions nécessaires pour optimiser les performances.
C’est un bon outil d’évaluation pour obtenir une vue globale de votre système BW sur plusieurs niveaux. Par exemple, Il permet de surveiller de façon régulière les possibles dysfonctionnements sur les programmes ABAP, les dump, goulots d’étranglements, problèmes mémoires, etc…
Le design et l’analyse des requêtes
La création de la requête
Lors de la création des requêtes, l’utilisation de certains éléments peuvent agir directement sur les temps de réponses.
L’usage des inclusions/exclusions, l’emploi de nombreux ratios calculés ou restreints, le passage dans des exits spécifiques, le trop grand nombre de caractéristique libre, l’utilisation de filtres de requête, le plan d’exécution de la requête….
Si possible il faut restreindre la création aux seuls objets nécessaires.
L’analyse des requêtes
Si malgré tout votre requête est lente, quelques transactions pourront vous aider à y voir plus clair.
La transaction RSRT est pratique pour analyser une requête. Elle indique si un agrégat est requis par exemple. Au lancement de la requête un mode ‘debugg’ est aussi disponible pour trouver à quel endroit du processus la requête ralentie.
En choisissant « propriétés de la requête ». Des paramètres peuvent être modifiés pour changer le comportement de la requête indépendamment des règles de l’infoprovider afin d’optimiser son usage (utilisation du cache par exemple).
La transaction RSRV relève les problèmes de construction de la requête, des indexes ou l’application de note SAP, etc…
Dans l’exemple ci-dessous un trop grand nombre de caractéristiques libres est détecté au sein de la requête.
La transaction RSTT fournit des informations sur les performances OLAP et permet de tracer les transferts de données avec l’application ‘front end’. Typiquement vous pouvez tracer l’activité d’un utilisateur et le comportement de la requête lancée avec la base de données BW.
L’architecture et la modélisation des données
Une bonne architecture est un élément de poids pour le bon fonctionnement des chargements et obtenir de meilleurs temps de réponse des requêtes.
L’éditeur SAP prône une architecture en Modèle LSA (Layered Scalable Architecture). (LSA++ simplifié pour HANA). Il faut suivre cette recommandation.
En suivant ce modèle d’architecture à plusieurs niveaux, dont les rôles sont bien déterminés en termes de stockage de données, vous faciliterez la gestion, la maintenance de votre système et les performances globales de votre datawarehouse.
Il y a par exemple des règles à respecter quant aux choix du bon moment ou des bonnes étapes de transformations des données, ce qui influera sur les temps de chargements.
Il y a aussi des règles à respecter quant aux types d’Infoproviders cibles de vos requêtes qui agiront sur les temps de réponse par exemple.
Une fois le concept de LSA bien établi, on peut s’attacher à modéliser le datawarehouse en respectant les bonnes pratiques et les préconisations de SAP aux différents niveaux.
Il faut faire les bons choix des types infoproviders et de leur utilisation dans les différentes couches : data acquisition, Corporate Memory, data distribution et data analysis.
Il faut respecter la bonne distribution des dimensions, des caractéristiques, des ratios dans les infoproviders.
A ce propos, selon votre version de BW, vous pourrez lancer avec la transaction SE38 le programme SAP_INFOCUBE_DESIGNS.
Ce programme collecte des données sur tous les infocubes de votre système BW. Il compte les enregistrements disponibles dans chaque dimension et table de faits. Le programme présente alors le ratio entre le nombre de lignes dans la dimension et le nombre de ligne de la table de fait.
En général, si ce ratio dépasse 10% comme dans l’exemple ci-dessous, les performances peuvent diminuer. Il est alors préférable de redéfinir les dimensions. Cette vérification est à faire régulièrement car le volume des données grossis en fonction de votre activité.
L’utilisation et le monitoring des process chains dans le séquencement des chargements des données : données masterdata puis données transactionnelles par exemple. La parallélisation des process chains permettra alors une mise à disposition plus rapide du reporting.
L’optimisation des infopackages et des DTP et le différent mode d’extraction en FULL ou Delta
L’optimisation du code ABAP dans les différents users exits, BADI’s, routines de transformations, …
La compression des infocubes réduira le nombre d’enregistrement stockés et augmentera sensiblement les performances de votre requête.
La création d’index sur des infoproviders dont les caractéristiques sont par exemple interrogées régulièrement par une requête.
La création d’agrégats, pour une version plus condensée de vos infocubes améliorera les temps de réponse des rapports créés au départ pour l’infocube source.
La gestion de la base de données
Partionnement sémantique (semantic partioning)
En utilisant le principe de partionnement sémantique, vous créez plusieurs infoproviders de même structure contenant moins de données (Un partionnement par région ou par année par exemple). Les chargements sont parallélisés et donc plus rapides => le reporting devient plus performant du fait d’un accès aux données ciblées par partitions.
Archivage des données
L’archivage ou plutôt le manque d’archivage est à prendre en compte dans les performances globales de votre système. Selon vos besoins, Il s’agira par exemple de données vieilles de 2 ans requêtées rarement dans l’année. Les archiver libérera de l’espace. Attention, elles seront cependant toujours accessibles.
De manière générale l’archivage s’inscrit dans un cadre plus large de la politique de rétention des données. Outre l’amélioration des performances, il réduira les coûts de stockage et de maintenance des données et établira un solide socle de gestion des données historiques de votre organisation.
Ménage, ménage, ménage…
Beaucoup de données sont générées pas le système lors de son utilisation. Devenues inutiles, elles doivent être supprimées régulièrement pour améliorer les performances du système en général.
Un peu comme à la maison, on peut planifier un ménage quotidien, hebdomadaire, mensuel, trimestrielle ou annuel. Ici encore, il est bon de définir une stratégie de rétention des données, et, créer des jobs de suppression ou des process chains pour automatiser la procédure afin de ne rien oublier.
On peut agir à plusieurs niveaux avec précaution selon votre version de BW pour nettoyer ces tables régulièrement :
- Sur les données transactionnelles elles-mêmes, en purgeant les PSA, les changes log des DSO et même en utilisant l’option de suppression sélective de données.
- Supprimer dans votre modèle de données certains flux et certains objets devenus obsolètes (infocubes, agrégats…)
- Les entrées de tables d’administration peuvent grossir significativement en volume et affecte les performances de votre système. Vous pouvez choisir d’archiver les données sur les requêtes, les Idocs, supprimer données des jobs et les logs de certaines tables de la base de données
- Surveiller les entrées des tables des statistiques BW : Les statistiques BW calculent et enregistrent dans des tables le temps d’exécution des requêtes Bex, le temps de chargement de données ou de manière plus général les évènements et processus survenant dans BW.
Liste des transactions utiles pour analyser et suivre les performances de votre système BW
Afin de vous aider à mettre en place les préconisations citées ci-dessus, vous pouvez vous appuyer sur les transactions suivantes :
Transaction DB02 pour analyser et suivre les statistiques sur la volumétrie, la taille des tables (PSA, DSO, …), les indexes manquants de la base de données, les espaces alloués aux objets…
Transaction ST03 pour analyser les problèmes de performance sur une période de temps donné, notamment lors d’extraction, de chargement ou de stockage de données.
Transaction SM66 / SM50 permet d’évaluer dans le détail un processus de travail en cours et le bon nombre de processus de travail alloués à une activité.
Transaction SE30, pour les amoureux du code ABAP. Cette transaction permet d’évaluer les performances d’un programme ABAP, d’un module fonction comme son temps d’exécution et ses accès à la base de données.
Transaction SM37 permet de surveiller un job de restructuration ou de chargement de données en cours par exemple et de voir si il est toujours actif ou arrêté ou en erreur.
Transaction ST13 (on HANA) permet d’analyser les problèmes survenant sur les process chains, les infoproviders, les paquets de chargements… Il faut choisir BW-TOOLS dans le paramètre Tool name.
CONCLUSION DE L’EXPERT
Dans le BW « Classique », celui qui n’est pas sur HANA, il faut jouer de toutes les astuces citées précédemment pour optimiser et rendre performant vos chargements et vos requêtes.
On peut constater qu’il n’y a pas une seule façon d’optimiser BW, ceci se fait sur beaucoup de petites choses qui mises, toutes, bout à bout nous permettent un gain et une fiabilité significative.
Attention il faut penser à vérifier et analyser fréquemment votre système.
Mais l’arrivée de HANA, surtout BW/4HANA rebat les cartes de la performance et de l’optimisation dans SAP BW. BW/4HANA bénéficie de nouveaux objets optimisés HANA qui simplifie la modélisation, l’architecture générale, la maintenance et l’administration de votre système BW.
Par exemple, grâce à la nature même de la plateforme SAP BW/4HANA (in-memory database) plus besoin d’agrégats et de roll-up. On parlera aussi d’une architecture LSA++ (au lieu de LSA pour un BW classique) avec moins d’objets de stockages et donc moins de chargements de données entre les différents niveaux.
Voici un exemple de modélisation avant et après le passage vers un BW/4HANA
Une simplification du modèle couplée aux capacités d’une base de données ultra performante comme SAP HANA permet d’accélérer significativement les temps de chargement de données et d’améliorer les performances des requêtes même sur un gros volume de données.
DeciVision peut agir comme un auditeur indépendant pour analyser la cohérence et les performances de votre système SAP BW. Nous pourrons vérifier la qualité de votre architecture et infrastructure SAP BW. Cet audit vous donnera une vue objective sur la qualité et la performance de votre datawarehouse,
L’audit de votre architecture et de ces composantes techniques vous permettra de répondre aux questions suivantes :
- Les temps de réponses et les performances constatées sont-elles normales ?
- Peuvent-elles être améliorées ?
- De manière plus générale, mon datawarhouse est-il assez souple pour s’adapter rapidement à l’évolution des besoins des métiers ?
- Mon système décisionnel est-il suffisamment bien dimensionné pour l’utilisation souhaitée ?
Nous pouvons analyser votre système par rapport aux normes et aux lignes directrices préconisées par l’éditeur SAP mais aussi par rapport aux bonnes pratiques que nous avons su développer.
Nous mettrons en évidence les potentiels problèmes de performance et nous identifierons les points d’améliorations. Nous pourrons ainsi vous proposer un plan d’actions à mettre en place pour atteindre la cible souhaitée.
