Partitions répliquées

Par exemple, dans les exemples d'applications Samppart et Sampeast, l'administrateur de base de données de The Beverage Company (TBC) a créé une partition répliquée entre la base de données East et la base de données Company contenant Actual, Budget, Variance et Variance%. Les utilisateurs de la région Est stockent désormais leurs données budgétaires localement. Comme ils n'ont pas besoin de récupérer ces données en direct à partir du siège social de l'entreprise, les temps de réponse sont plus rapides et ils ont plus de contrôle sur les temps d'arrêt et l'administration des données locales.

Les modifications apportées aux données dans un flux de partition répliquée passent du cube source au cube cible. Les modifications apportées aux données répliquées dans la cible de données ne retournent pas à la source de données. Si les utilisateurs modifient les données sur la cible de données, Essbase écrase leurs modifications lorsque l'administrateur de base de données met à jour la partition répliquée.

Lorsqu'une partition répliquée est définie, le DBA peut sélectionner un paramètre pour empêcher la mise à jour des données de la partie répliquée du cube cible. Le paramètre de mise à jour (qui autorise ou interdit les mises à jour) est prioritaire sur l'accès fourni par les filtres de sécurité et est également pris en compte par les opérations par lots, telles que le chargement et le calcul des données.

Utilisez une partition répliquée pour atteindre l'un des objectifs suivants :

Diminuer l'activité du réseau
Réduire les temps de réponse aux requêtes
Diminuer les temps de calcul
Récupérer plus facilement en cas de défaillance du système

Règles pour les partitions répliquées

Vous devez être en mesure de mapper les zones répliquées partagées des outlines source et cible, bien que les zones partagées ne soient pas nécessairement identiques. Vous devez indiquer à Essbase comment chaque dimension et membre de la source est mis en correspondance avec chaque dimension et membre de la cible.

Les outlines source et cible des zones non partagées ne doivent pas nécessairement être mappables.

Etant donné qu'aucune des zones que vous utilisez en tant que cible de partition répliquée ne peut provenir d'une source de partition transparente, vous ne pouvez pas créer de partition répliquée au-dessus d'une partition transparente, comme indiqué dans l'illustration :

Figure 9-4 Partition répliquée non valide

Cette image montre comment une cible de partition répliquée ne peut pas contenir de données provenant d'une source de partition transparente.

Les cellules de la cible d'une partition répliquée ne peuvent pas provenir de deux sources ; les cellules d'une partition doivent provenir d'un cube. Pour répliquer des cellules à partir de plusieurs cubes, créez une partition différente pour chaque source de données.

Les cellules d'un cube cible peuvent être la source d'une autre partition répliquée. Par exemple, si la base de données Samppart.Company contient une partition répliquée de la base de données Sampeast.East, vous pouvez répliquer les cellules de Sampeast.East dans une troisième base de données, telle que Sampwest.West.

Vous ne pouvez pas utiliser des membres d'attribut pour définir une partition répliquée. Par exemple, associés à la dimension Market, les membres de la dimension d'attribut Market Type sont Urban, Suburban et Rural. Vous ne pouvez pas définir une partition sur Urban, Suburban ou Rural, car une partition répliquée contient des données dynamiques et non des données stockées. Par conséquent, une tentative de mise en correspondance d'attributs dans des partitions répliquées génère un message d'erreur. Toutefois, vous pouvez utiliser la commande WITHATTR pour répliquer des données d'attribut.

Avantages des partitions répliquées

Comme les données sont stockées plus près des utilisateurs finals, dans le cube cible, les partitions répliquées peuvent réduire l'activité du réseau, ce qui améliore les temps d'extraction.

Les données sont plus facilement accessibles à tous les utilisateurs. Certains utilisateurs accèdent aux données du cube source, d'autres au cube cible.

Les échecs ne sont pas aussi catastrophiques. Etant donné que les données se trouvent à plusieurs emplacements, si une base de données échoue, seuls les utilisateurs connectés à cette base de données ne peuvent pas accéder aux informations. Les données sont toujours disponibles et peuvent être extraites des autres sites.

Les administrateurs locaux contrôlent le temps d'arrêt. Par exemple, étant donné que les utilisateurs de la région Est accèdent à leurs propres données répliquées au lieu de la base de données Société, un administrateur peut arrêter la base de données Société sans affecter les utilisateurs de la région Est.

Etant donné que seules les données pertinentes sont conservées sur chaque site, les bases de données peuvent être plus petites. Par exemple, les utilisateurs de la région Est ne peuvent répliquer que les informations budgétaires de l'est, au lieu d'accéder à une base de données plus grande contenant des informations budgétaires pour toutes les régions.

Inconvénients des partitions répliquées

Vous avez besoin de plus d'espace disque car les données sont stockées à plusieurs emplacements.

Etant donné que l'administrateur de partition doit actualiser manuellement les données régulièrement, les utilisateurs risquent de ne pas voir la dernière version des données.

Remarques concernant les performances des partitions répliquées

Pour améliorer les performances des partitions répliquées, suivez les instructions suivantes :

Ne répliquez pas les membres calculés dynamiquement dans le cube source, car Essbase doit tester l'outline pour rechercher les membres calculés dynamiquement et leurs enfants afin de déterminer comment effectuer le calcul.

Ne répliquez pas les données dérivées du cube source. Au lieu de cela, répliquez le niveau pratique le plus bas de chaque dimension et effectuez les calculs sur le cube cible une fois la réplication terminée.

Par exemple, pour répliquer la base de données dans la dimension Market :

Définissez la zone partagée en tant que membres de niveau inférieur de la dimension Market qui vous intéresse, par exemple, les membres East, West, South et Central et les membres de niveau 0 des autres dimensions.
Une fois la réplication terminée, calculez les valeurs de Market et les valeurs de niveau supérieur dans les autres dimensions de la cible.

Parfois, vous ne pouvez pas calculer de données dérivées au niveau du cube cible. Dans ce cas, répliquez-le à partir du cube source. Vous ne pouvez pas calculer les données dérivées à la source si elles répondent à l'un des critères suivants :
- Nécessite que les données en dehors de la zone répliquée soient calculées.
- Requiert des scripts de calcul à partir desquels vous ne pouvez pas extraire uniquement la partie à calculer sur la cible.
- Est répliqué sur un ordinateur avec peu de puissance de traitement, comme un ordinateur portable.

Pour optimiser la réplication d'un cube en mode "aggregate storage" (ASO) qui est la cible répliquée alors qu'une base de données en mode "block storage" est le cube source et que les deux outlines sont identiques, utilisez la méthode "replication supposant une outline identique", de l'une des manières suivantes.

Activez le paramètre de configuration REPLICATIONASSUMEIDENTICALOUTLINE. La syntaxe est la suivante :
```
REPLICATIONASSUMEIDENTICALOUTLINE [appname [dbname]] TRUE | FALSE
```
Exécutez l'instruction alter database MaxL avec la grammaire replication_assume_ididentique_outline. L'instruction peut uniquement être émise vers un cube ASO et ne s'applique pas à la réplication en mode "block storage". La syntaxe est la suivante :
```
alter database appname.dbname enable | disable replication_assume_identical_outline;
```

Le partitionnement le long d'une dimension dense prend plus de temps que le partitionnement le long d'une dimension dispersée. Lorsque Essbase réplique des données partitionnées le long d'une dimension dense, il doit accéder à chaque bloc de la source de données, puis créer chaque bloc dans la cible de données au cours de l'opération de réplication.

Vous ne pouvez pas répliquer des données dans un membre calculé dynamiquement au niveau du cube cible. Essbase ne charge ni ne réplique les données dans les membres de calcul dynamique, car ces membres ne contiennent pas de données tant qu'un utilisateur ne les demande pas lors de l'exécution. Essbase évite d'envoyer des données répliquées pour les membres dynamiques denses et dispersés sur la cible de réplication, car ces données ne sont pas stockées sur la cible.

Pour répliquer uniquement les valeurs de données qui ont été modifiées au lieu de la partition entière, reportez-vous à la section Populate or Update Replicated Partitions.

Partitions répliquées et utilisation des ports

Avec les partitions répliquées, les utilisateurs se connectent au cube cible uniquement. Lorsque les données sont mises à jour sur la cible, le processus de réplication des données du cube source vers le cube cible utilise un port, et cette connexion est basée sur le nom utilisateur déclaré dans la définition de partition (utilisateur de partition).

Remarques :

En raison de la nature à court terme de la réplication, les partitions et les ports répliqués sont rarement un problème.