Discussion :

[lenoblech]

Bonjour

Nous construisons avec amo des cubes via un etl que nous développons

Nous sommes en train de faire des tests pour voir comment réagi le cube pour les besoins d’un de nos clients

J’ai créé un cube ou j’ai mis une dimension et une tables de fait en rolap. Avec les tests et ce que j’ai pu glaner, un reprocessing est nécessaire si nous avons des items qui apparaissent dans la dimension.

Je peux constater que mes modifications sont prises en compte si on configure correctement le proactive cache. Mais nous devons aussi ajouter de la sécurité dynamique à notre cube et le problème se complique.
J’arrive à voir mes modifications en faisant 2 requêtes xmla, un clear du cache sur le cube et un alter sur le rôle.

Ayant dernièrement fait des benchs pour évaluer les perf sur les agrégations nous voulions voir aussi comment se comporte les agrégations avec les partitions en rolap mais je n’en suis pas encore là.

Pour info j’ai trouvé un article intéressant sur le forum qui parle cache

1) Donc je me pose la question si nous avons configuré correctement le cube ou si nous ne devrions pas reprocesser régulièrement le cube comme nous le présente une session des journées sql server
2) Les agrégations sont elles compatible avec le mode rolap. Nous avons pleinement évalué que nous pouvions faire plusieurs partions dont une qui est en mode rolap et qui peut ne pas avoir d’agrégations (chaque partition pouvant avoir des aggrégations designs différents)
3) Y a-t-il un moyen d’optimiser le clear du cache sans envoyer 2 requêtes xmla (surtout le alter sur le rôle). Le problème est présenté sur un forum, sur le forum microsoft on nous dit qu’il faut simplement faire un clear de cache. Ç’est peux être un bug ?

Bonne journée

[Laurent C]

Bon, puisque personne ne s'est lancé, je me dévoue, sachant que je n'ai pas d'expérience ROLAP particulière. Informations non garanties, donc.

J'ai donc créé un cube de test minuscule à la va-vite.

Une dimension, une table de faits.

1) Selon mes derniers tests, de nouveaux membres s'ajoutent bien à la dimension, lorsque de nouveaux enregistrements sont ajoutés à la table sous-jacente. (Pas de XMLA requis, pas de processing au-delà de la publication et des modifcations structurelles du cube.) Même chose pour la table de faits.

Ceci dit, il doit y avoir un tour de main à prendre, car cela n'a pas - semble-t'il - pas marché du premier coup.

Configuration:
StorageMode: Rolap pour cube, dimensions, mesure groups, et partitions
ProactiveCaching: Real-time ROLAP

Traitement des erreurs pour la partition: KeyErrorLimitAction = StopLogging (Pas nécessaire, si l'intégrité référentielle est garantie)

Partition :

2) - Non testé: selon la doc, les aggrégations sont stockées sur l'instance SQL Server en tant que vue indexée (cf BOL) Sinon, il y a également le mode HOLAP.

[lenoblech]

Merci pour la réponse

pour le moment nous avons mis le pb de coté

le mode rolap nécessite un peu d'entrainement , mais je n'arrive pas à le faire fonctionner correctement lorsque je rajoute la sécurité dynamique.

en plus la sécurité dynamique test l'existence d'une combinatoire dans une table de fait que nous appelons fact security qui revient à faire un many to many

on va laisser un peu de temps et les idées seront probablement plus clair dans le futur :-)))

Bonne journée

Christophe