Utilisation du ProActive Caching
Le proActive caching répond à un besoin d’avoir du temps réel sur le rafraichissement des données d’un cube.
Fonctionnement du ProActive Caching
La figure ci-dessous décrit l’enchainement des étapes du proActive Caching
1. La première étape est une interrogation d’une application cliente du serveur Analysis Services sous forme de requête MDX
2. Le serveur Analysis Services interroge son cache pour obtenir les informations
3. Une modification est effectuée sur la source de données relationnelle et notifie Analysis Services.
4. En retour Analysis Services envoie deux messages au serveur relationnelle dans un intervalle de temps définit pour évaluer si la base est toujours en cours de modification. L’idée est d’éviter de minimiser la construction de cache, surtout sur des traitements en lot.
5. Analysis Services commence à construire un nouveau cache pour remplacer le cache « périmé ».
6. Pendant la reconstruction, les requêtes des clients sont traitées avec le mode ROLAP
7. Une fois que le nouveau cache est construit, ce dernier est activé et l’ancien est supprimé.
Si pendant la phase de reconstruction, l’accès aux données en mode ROLAP s’avère trop long, il est possible d’utiliser le paramètre spécial -1 de telle sorte à continuer à utiliser l’ancien cache jusqu’à que le nouveau soit prêt.
Mise en place du ProActive caching
Le proactive caching peut être configuré pour les dimensions et les partitions.
1. La première étape est de se positionner au niveau de la partition, puis de cliquer sur storage Setting
2. Par la suite cocher l’option Enable Proactive caching
Présentation des options du proactive caching
propriétés |
description |
Silence interval |
Temps minimum pour évaluer que la base relationnelle n’est plus en activité |
Silence override interval |
Temps maximum à partir duquel le cache est tout de même reconstruit suite à une notification de changement |
latency |
Temps à partir duquel le cache périmé est supprimé |
Update the cache periodically |
Quelques soit la fréquence des modifications des données, le cache est reconstruit à une fréquence définit par ce paramètre |
Online immediatly |
Le serveur répond aux requêtes avec le mode ROLAP pendant que le cache est reocnstruit |
Rolap Aggregation |
Le serveur essaye de creér des vues matérialisées en mode ROLAP |
Ce tableau montre qu’il y a un compromis à évaluer entre les temps de réponse des utilisateurs versus la dernière version des données.
Si les performances sont primordiales, il faut forcer Analysis Services à ne pas basculer en mode ROLAP ; pour cela, utiliser les options identiques à la copie d’écran ci-dessus.
Notification de modification de la source relationnelle
Trois options s’offrent à nous afin qu’Analysis Services soit notifié des modifications.
Ces options sont décrites à travers la copie d’écran ci-dessous
La première option s’appuie sur le mécanisme de trace de SQL Server et ne peut être utilisé uniquement si la source de données est SQL Server. Avec cette option la partition de donnée est traitée en mode complet. Le mode « ajout » n’est pas supporté.
La deuxième option est d’envoyer au serveur Analysis Services une commande XMLA
<Command> <NotifyTableChange> <Object>...</Object> <TableNotifications>...</TableNotifications> </NotifyTableChange> </Command> |
L’inconvénient typique de cette méthode est lorsque le serveur Analysis Services est éteint. L’application cliente doit donc pouvoir conserver sous forme de liste d’attente les messages de modification.
La troisième option est d’interroger la base de données à un intervalle de temps régulier.
Cette méthode est valable à condition que la table suivie possède une colonne qui identifie les modifications comme une date par exemple
select MAX(ModifiedDate) from Sales.SalesOrderDetail |
Par default, Analysis Services interroge la base de données toutes les 10 secondes
Recommandations générales
Tous les objets qui ont les mêmes paramètres de proActive caching sont regroupés dans un même lot de traitement. Dans un lot, les dimensions sont toujours traitées en premier et les partitions dans un second temps.
Il est donc une bonne pratique de
1. spécifier des paramètres identiques aux objets dépendants,
2. Activer l’option « enable incremental update » afin d’enrichir le cache avec juste les nouvelles données,
3. Minimiser le nombre d’objets sur lesquelles le proActiveCaching est activé sachant que cette fonctionnalité est consommateur de ressource
4. Partitionner les données et activer cette fonctionnalité uniquement sur la partition de données active