De nombreuses possibilités sont offertes pour améliorer les performances d’une solution BW (Datawarehouse et requêtes). De l’optimisation à l’utilisation des fonctionnalités, le panel de possibilités est assez large.
Intéressons nous aux requêtes BW avant d’acheter des solutions de type BI Accelerator !
Vos requêtes sont longues à exécuter et vous ne savez pas comment et quoi faire pour diminuer les temps d’exécution.
1) Une requête web va plus vite qu’une requête Excel
En effet, une partie du calcul de l’affichage se fait sur Excel alors qu’en mode Web, le serveur prend la totalité des calculs.
2) Plus il y a d’éléments à afficher et plus c’est long !
C’est normal, entre une requête agrégée et une requête de type liste et détails, BW va mettre plus de temps. En cause : la lecture des différentes tables du schéma en étoile et le temps d’affichage des données.
Pour expliquer le fonctionnement, lorsque vous exécutez une requête, BW va créer un fichier texte de l’ordre de quelques kilo octets lisibles l’outil de requêtage.
Le temps sera bien plus long lorsqu’une liste de détails sera demandée.
D’où la sempiternelle réflexion qui est : BW n’est pas optimisé pour faire de l’affichage de liste.
3) Le cache
Avez-vous déjà remarqué qu’une requête va plus vite à s’exécuter lorsque cela a déjà été fait une fois ? BW gère une mémoire cache en conservant les résultats de la dernière exécution lorsque bien sûr les informations n’ont pas été modifiées par un nouveau chargement.
En version 2004s, il y a même la possibilité de gérer des caches delta.
Pour obtenir les options, transaction RSRT, puis propriétés.
Suivant la configuration de la taille de la mémoire cache, il y a plusieurs options :
- pas de cache
Pour versions 3.x, si vous effectuez des chargements fréquents (ex 1 fois par heure), il vaut mieux désactiver le cache.
- cache sans swap
Lorsque le cache est plein, certaines informations sont retirées du cache par un algorithme particulier. Pour accéder aux informations supprimées, BW doit réalimenter le cache.
- cache avec swap
Lorsque le cache est plein, certaines informations sont sauvegardées dans un fichier et peuvent être rappelées ultérieurement.
- cache persistent
Les informations de requêtes sont stockées dans une base de données ou un fichier.
- cross application cache persistent
Les informations sont stockées sur un fichier dans le réseau informatique.
Ces 2 dernières options sont à considérer lorsque vous utilisez notamment plusieurs serveurs d’applications.
Bien sûr, il est possible d’industrialiser le lancement des requêtes pour que les utilisateurs aient accès directement aux données disponibles dans le cache soit via par le pré calcul de requêtes, soit par le broadcast.
4) Les modes de lecture
Dans la même lignée, on peut aussi modifier le volume de lecture des informations.
Toujours dans la même transaction, il est possible de :
- Lire la totalité des informations relatives à une requête
- Recalculer les informations à la navigation
- Recalculer les informations au changement d’un nœud de hiérarchie
5) L’ordre des modes de lecture
Evidemment BW ne va pas utiliser toutes ces options à la fois.
Il existe un ordre prédéfini d’ « essai » d’utilisation des options :
- Lecture du cache
- BI Accelerator
- Recalcul de la requête depuis un agrégat
- Recalcul de la requête
Le constat est que dans un cadre BI 2004S, BI Accelerator n’est pas systématiquement la meilleure solution au niveau de l’optimisation et des coûts !
Une bonne optimisation du cache peut déjà permettre de faire des gains substantiels en temps de calcul des requêtes.
6) Création de requêtes sur un multiprovider
Lorsque vous faites une requête sur un multi-cube, BW va tenter de lire parallèlement les différentes sources.
Evidemment pour que ça aille plus vite, il serait sympathique d’aider BW pour qu’il trouve le chemin plus facilement en :
- rajoutant de manière explicite le nom du cube où est présent l’information
- rajoutant via un user exit la manière de retrouver le cube où est présent l’information
N’oubliez pas que BW lance en parallèle la lecture des différentes informations mais lorsque c’est trop long, il abandonne et lance séquentiellement la lecture. Il est donc, évident qu’il faut désactiver la lecture parallèle lorsque le calcul est trop long. Petit test simple, voir comment se lit une requête à l’exécution via la gestion des processus dans SM50.
Il existe bien des moyens pour optimiser le calcul des requêtes. Malheureusement, cela restera toujours long si la partie datawarehouse est mal paramétrée et d’autres solutions peuvent alors intervenir : redimensionnement des cubes, partitionnement des cubes, découpage des cubes par pays jusqu’à la refonte de vos requêtes.
Evidemment, lorsque vous n’avez plus de solutions du tout et que vous êtes en 2004s, vous avez toujours la possibilité d’acheter un serveur dédié avec la solution BI-Accelerator. Son fonctionnement est quasi identique au mode cache, si ce n’est à la différence qu’il utilise un arbre de recherche de type TREX pour ranger les fichiers issus du calcul. Malheureusement, son coût n’est pas à la portée de toutes les bourses.
Si vous avez des questions ou besoin de conseils, n’hésitez pas à faire appel à Censio pour un audit rapide de vos solutions SAP BI.
Pour plus d'informations,
http://www.censio.fr
Archives
- n'hésitez pas a citer Censio si nos articles vous sont utiles!)