Nous avons précédemment vu l’activation du WriteBack sur un groupe de mesures ainsi qu’une utilisation simple de la commande MDX UPDATE .
Intéressons nous maintenant à la façon dont tout cela est géré au niveau moteur du cube.
Stockage des données de WriteBack
Le fait de valider notre modification (COMMIT) va la propager dans la partition de WriteBack et va également créer une nouvelle ligne dans la table de WriteBack :

On remarque déjà que la structure de cette table de WriteBack est très proche de la structure de la table source de notre groupe de mesure :

Cette table va assurer la pérennité des données qu’elle contient, en effet elle ne sera jamais supprimée automatiquement, même si nous désactivions le WriteBack.
Elle est en quelque sorte la source de notre partition de WriteBack et permettra de la réalimenter par exemple si le cube était dé-processé (UNPROCESS).
Elle peut aussi permettre d’annuler une publication de valeur.
(Si l’on maitrise le périmètre des modifications et qu’il n’y a pas de risque de chevauchement entre plusieurs modifications consécutives de différents utilisateurs sur une même cellule)
En effet si on repère la publication incriminée à l’aide des deux champs d’audit (DateTime et User) on peut supprimer les lignes correspondante de la table et lancer un process la partition de WriteBack pour revenir en arrière !
La dernière remarque concernera la façon dont les données sont stockées à savoir de manière différentielle.
Dans notre exemple :
Ancienne valeur (9858,2 dans la partition principale)
+ Incrément (141,8 dans la partition et la table de WriteBack)
= Nouvelle valeur (10000 récupéré par un Select qui agrège les deux partitions)
On se rend tout de suite compte qu’un tel comportement peut entraîner une dégradation des performances de part la multiplicité des sources et surtout par le fait que la partition de WriteBack est en lecture / écriture et n’a pas de design d’agrégation.
Non régression des performances
Pour remédier à ce problème et récupérer les performances de requêtage, on peut convertir (manuellement dans SSMS ou via un job planifié) la partition de WriteBack vers une partition définitive « classique » en lecture seule, ayant le même design d’agrégation que la partition d’origine.

A suivre : Les différents modes d’allocation d’un UPDATE