Partitions transparentes

Les utilisateurs travaillant sur le cube cible n'ont pas besoin de savoir où les données sont stockées, car ils y accèdent comme si elles faisaient partie de leur cube local.

Figure 9-5 Partitions transparentes

Cette image montre comment un utilisateur de la cible de données de partition transparente voit les données provenant de trois sources de données.

Les données étant extraites directement de la source de données, les utilisateurs accèdent à la dernière version. Lorsqu'ils mettent à jour les données, leurs mises à jour sont réécrites dans la source de données. Ce processus signifie que les autres utilisateurs de la source de données et de la cible de données ont un accès immédiat à ces mises à jour.

Avec une partition transparente, les utilisateurs de la source de données et de la cible de données peuvent remarquer des performances plus lentes à mesure que davantage d'utilisateurs accèdent aux données source.

Par exemple, le DBA de TBC peut utiliser une partition transparente pour calculer chaque membre de la dimension Scenario sur un ordinateur distinct. Ce traitement réduit le temps écoulé pour le calcul tout en fournissant aux utilisateurs la même vue des données.

Utilisez une partition transparente pour atteindre les objectifs suivants :

Afficher la dernière version des données pour les utilisateurs
Autoriser les utilisateurs de la cible de données à mettre à jour les données
Réduire l'empreinte de l'espace disque

Lorsque vous créez une partition transparente, la tranche de données du cube cible est désélectionnée sur #MISSING, car les données doivent être stockées sur le cube source. Elle reste effacée même si vous supprimez la partition.

Règles relatives aux partitions transparentes

Les partitions transparentes doivent respecter les règles suivantes :

Les données sont stockées dans le cube source. Le cube cible ne stocke ni ne gère aucune donnée, mais agit comme un point d'accès. Si l'accès en écriture est activé, les utilisateurs qui accèdent au cube cible peuvent mettre à jour les données du cube source.
Lorsque la source et la cible sont des cubes en mode "aggregate storage" (ASO), la fusion de données entre le cube cible et le cube source n'est pas prise en charge.
Les zones transparentes partagées des outlines source de données et cible de données ne doivent pas nécessairement être identiques, mais vous devez pouvoir mettre en correspondance les dimensions qu'elles contiennent. Vous devez indiquer à Essbase comment chaque dimension et membre de la source de données est mis en correspondance avec chaque dimension et membre de la cible de données.
Les outlines de source de données et de cible de données pour les zones non partagées ne doivent pas nécessairement être mappables, mais les associations d'attributs doivent être identiques. Sinon, les utilisateurs peuvent obtenir des résultats incorrects pour certaines extractions. Par exemple, si le produit 100-10-1010 est associé à l'attribut Saveur de raisin de la source, mais que le produit 100-10-1010 n'est pas associé au raisin de la cible, le total des ventes pour toutes les saveurs de raisin de New York est incorrect.
La définition de partition ne doit contenir que des membres stockés. Vous ne pouvez pas utiliser des dimensions d'attribut ou des membres pour définir une partition transparente. Par exemple, la dimension d'attribut Type de marché, associée à la dimension Marché, comporte des membres Urbain, Suburbain et Rural. Vous ne pouvez pas définir de partition sur Urbain, Suburbain ou Rural.
Si une cellule est mise en correspondance à partir de la source de données avec une base en mode "aggregate storage" en tant que cible, tous les éléments dépendants de la cellule doivent également être mis en correspondance avec la même définition de partition.
Vous pouvez créer une partition transparente sur une partition répliquée. En d'autres termes, vous pouvez créer une cible de partition transparente à l'aide d'une source de partition répliquée, comme indiqué dans l'illustration suivante :

Figure 9-6 Partition transparente valide
Comme illustré ci-dessous, vous ne pouvez pas créer de partition transparente sur plusieurs autres partitions. En d'autres termes, vous ne pouvez pas créer de cible de partition transparente à partir de plusieurs sources car chaque cellule d'une base de données doit être extraite à partir d'un seul emplacement (disque local ou disque distant).

Figure 9-7 Partition transparente non valide
Examinez attentivement les formules que vous affectez aux membres de la source de données et de la cible de données.

Avantages des partitions transparentes

Les partitions transparentes peuvent résoudre de nombreux problèmes de base de données, mais elles ne sont pas toujours le type de partition idéal.

Vous avez besoin de moins d'espace disque, car vous stockez les données dans une base de données.

Les données auxquelles vous accédez à partir de la cible de données sont toujours la dernière version.

Lorsque l'utilisateur met à jour les données de la source de données, Essbase effectue ces modifications sur la cible de données.

Les bases de données individuelles sont plus petites et peuvent donc être calculées plus rapidement.

La distribution des données est invisible à l'utilisateur final et aux outils de ce dernier.

Vous pouvez charger les données à partir de la source ou de la cible de données.

Inconvénients des partitions transparentes

Si les inconvénients suivants sont trop graves, envisagez plutôt d'utiliser des partitions répliquées ou fédérées.

Les partitions transparentes augmentent l'activité du réseau, ce qui ralentit les temps de récupération des utilisateurs.

Etant donné que de plus en plus d'utilisateurs accèdent aux données source, la durée d'extraction peut être plus lente.

Si le cube source échoue, les utilisateurs de la source et de la cible sont affectés. Par conséquent, le réseau et le cube source doivent être disponibles chaque fois que les utilisateurs connectés à la source ou à la cible en ont besoin.

Vous pouvez effectuer certaines opérations d'administration uniquement sur les données locales. Par exemple, si vous archivez le cube cible, Essbase archive uniquement le cube cible et non le cube source. Les opérations d'administration suivantes ne fonctionnent que sur les données locales des bases en mode "block storage" :

Commande de calcul CLEARDATA
Commande de calcul DATACOPY
Commande EXPORT
Commande VALIDATE
Commandes BEGINARCHIVE et ENDARCHIVE

Lorsque vous effectuez un calcul sur une partition transparente, Essbase effectue le calcul en utilisant les valeurs actuelles des données locales et des dépendances transparentes. Essbase ne recalcule pas les dépendances transparentes, car les contours de la source et de la cible peuvent être si différents qu'un tel calcul est inexact. Pour calculer toutes les partitions, exécutez une commande CALC ALL pour chaque partition, puis exécutez une commande CALC ALL au niveau supérieur en utilisant les nouvelles valeurs pour chacune.

Prenons un exemple où :

L'outline du cube cible contient une dimension Market avec des membres East, West, South et Central
L'outline du cube source contient une dimension East avec des membres New York et New Jersey

Si vous tentez de calculer le cube cible, vous supposez que East est un membre de niveau 0. Dans le cube source, cependant, East est dérivé en ajoutant New York et New Jersey. Cependant, tous les calculs à la cible ne sauraient pas cette information et ne pourraient pas refléter les modifications apportées à New York et au New Jersey dans la source. Pour effectuer un calcul précis, calculez East dans la source, puis la cible.

Les formules affectées aux membres du cube source peuvent produire des résultats calculés incohérents avec les formules ou consolidations définies dans le cube cible, et inversement.

Considérations relatives aux performances des partitions transparentes

Pour améliorer les performances des partitions transparentes, tenez compte des consignes suivantes lors de la création de la partition :

Le partitionnement des dimensions denses peut ralentir considérablement les performances, car les dimensions denses sont utilisées pour déterminer la structure et le contenu des blocs de données.

Pour améliorer les performances, envisagez d'inclure une ou plusieurs dimensions dispersées dans la définition de la zone afin que le nombre de blocs requis soit limité aux combinaisons avec les membres dispersés.
L'association de partitions transparentes aux valeurs d'attribut d'une dimension peut augmenter le temps d'extraction, car les attributs sont associés à des dimensions dispersées. Dans ce cas, le partitionnement à un niveau supérieur au niveau associé aux attributs améliore le temps d'extraction. Par exemple, dans la dimension Produit de la base de données Sample.Basic, si les enfants 100-10, 200-10 et 300-10 (niveau 0) sont associés à des attributs, partitionnez leurs parents 100, 200 et 300 (niveau 1) pour obtenir de meilleures performances d'extraction.
Le chargement de données dans le cube source à partir du cube cible peut ralentir considérablement les performances. Si possible, chargez les données dans la source de données localement.
Le temps d'extraction est plus long car les utilisateurs accèdent aux données sur le réseau.
Lorsqu'une partition transparente est la cible, envisagez d'utiliser les paramètres de configuration suivants :
- Pour les demandes envoyées d'un cube source vers un cube cible de partition transparente, vous pouvez consigner les temps de réponse des transactions à l'aide du paramètre de configuration ENABLE_DIAG_TRANSPARENT_PARTITION. La consignation de ces messages est utile lors du dépannage des temps de réponse trop lents.
- Lorsque la cible de partition transparente est un cube en mode "aggregate storage", vous pouvez indiquer la taille maximale de la grille de demandes et de la grille de réponses à l'aide des paramètres de configuration MAX_REQUEST_GRID_SIZE et MAX_RESPONSE_GRID_SIZE.
Le partitionnement des dimensions de base peut ralentir considérablement les performances.

Calcul des partitions transparentes

Lors du calcul de données locales qui dépendent de données distantes, Essbase doit utiliser le calcul ascendant. Assurez-vous que vous utilisez un cache de calculatrice optimisé sur le cube cible. Reportez-vous à Taille du cache de calculateur.

Lorsque vous effectuez un calcul sur une partition transparente, Essbase effectue le calcul en utilisant les valeurs actuelles des données locales et des dépendances transparentes. Lors du calcul de données locales qui dépendent de données distantes, Essbase effectue un calcul ascendant. Le calcul ascendant ne peut être effectué que si le cache de calculateur de la base de données cible est utilisé correctement. Voir Calcul ascendant et descendant.

L'augmentation de la mémoire affectée au cache du calculateur améliore considérablement les performances de calcul avec des partitions transparentes. Lorsqu'un calcul est démarré, un message dans le fichier journal de l'application indique si le cache de calculateur est activé ou désactivé sur la base de données cible. L'utilisation du cache de calcul sur la base de données cible réduit le nombre de blocs demandés à la source de données lors du calcul. La réduction des blocs demandés, à son tour, réduit le trafic réseau généré par le transfert de blocs sur le réseau.

Performances du calcul transparent des partitions

Le calcul des données sur la cible d'une partition transparente peut ralentir les performances lorsqu'Essbase doit extraire les blocs dépendants du réseau à partir de la source avant le calcul. Pour optimiser les calculs transparents, utilisez Calcul dynamique, gérez le cache du calculateur, évitez les formules descendantes et évitez les formules complexes sur les membres de définition de zone.

Les performances avec des calculs transparents peuvent également ralentir si Essbase doit effectuer un calcul descendant sur n'importe quelle partie de la cible de données contenant des formules de membre descendantes. Lorsque la cible de données ne contient pas de formules de membre descendantes, Essbase peut effectuer un calcul ascendant sur la cible de données, ce qui est beaucoup plus rapide.

Lorsque Essbase effectue le calcul sur le cube source, il peut toujours effectuer un calcul ascendant.

Envisagez d'utiliser les options de calcul suivantes :

Si vous êtes absolument certain qu'un script de calcul de partition cible n'implique pas l'accès aux données distantes, vous pouvez utiliser la commande de calcul SET REMOTECALC OFF dans le script de calcul pour arrêter les efforts d'extraction de la partition source.
Implémentez des membres de calcul dynamique en tant que parents des données transparentes afin que les données soient calculées à la volée lors de leur extraction. Ce traitement réduit le temps de traitement par lots. Essbase effectue le calcul uniquement lorsque les utilisateurs le demandent.
Implémentez une couche répliquée entre les données transparentes de bas niveau et les données locales de haut niveau.

Tenez compte des stratégies de performances suivantes :

Conservez la partition entièrement dans la zone de cache de la calculatrice, ce qui signifie que tous les membres dispersés de la définition de partition doivent être contenus dans le cache de la calculatrice. Par exemple, dans le cube Sample Basic, si une définition de partition inclut @IDESC(East), tous les descendants de East doivent se trouver dans le cache du calculateur.
Activez le cache du calculateur et affectez-lui une quantité suffisante de mémoire.
N'utilisez pas de formules complexes sur les membres qui définissent la partition. Par exemple, dans Exemple de base, l'affectation d'une formule complexe à New York ou New Jersey (les deux enfants de East) force Essbase à utiliser la méthode de calcul descendante.

Partitions transparentes et formules de membre

Si les outlines de la cible de données et de la source de données sont identiques, à l'exception des formules de membre différentes, assurez-vous que la définition de partition génère les résultats de calcul souhaités.

Par exemple, supposons que les outlines de source de données et de cible de données contiennent toutes deux une dimension Market avec les membres North et South, et les enfants North et South. Sur la cible de données, Market est calculé à partir des données des membres Nord et Sud (et de leurs enfants) de la source de données. Si l'un de ces membres de la source de données contient des formules de membre, ces formules sont calculées, ce qui affecte la valeur calculée de Market sur la cible de données. Ces résultats peuvent différer de la façon dont le membre du marché est calculé à partir des membres Nord et Sud sur la cible de données, où ces formules peuvent ne pas exister.

Assurez-vous que toutes les formules que vous affectez aux membres de la source de données et de la cible de données produisent les résultats souhaités.

Partitions transparentes et utilisation des ports

Un port est utilisé pour chaque combinaison utilisateur/machine unique. Si un utilisateur définit plusieurs partitions transparentes sur un serveur, en utilisant le même nom d'utilisateur, un seul port est occupé.

Dans une partition transparente, lorsqu'un utilisateur (user1) accède à une zone de la cible qui accède aux données source, user1 utilise le nom d'utilisateur déclaré dans la définition de partition (utilisateur de partition) pour accéder aux données à partir de la base de données source. Cet accès entraîne l'utilisation d'un port supplémentaire car différents utilisateurs (utilisateur1 et utilisateur de partition) se connectent à l'application.

Si un deuxième utilisateur (user2) se connecte à la base de données cible et effectue une exploration vers le bas pour accéder aux données source, user2 utilise également le nom d'utilisateur déclaré dans la définition de partition (utilisateur de partition). Etant donné que l'utilisateur de partition est déjà connecté à la base de données source, aucun port supplémentaire n'est nécessaire pour l'utilisateur de partition, tant que user2 accède à la même base de données source.