Gérer la mise en mémoire cache des interrogations

Oracle Analytics Cloud maintient une mémoire cache locale des jeux de résultats d'interrogation dans la mémoire cache d'interrogation.

Rubriques :

À propos de la mémoire cache d'interrogation

La mémoire cache d'interrogation permet à Oracle Analytics Cloud de répondre à de nombreuses demandes d'interrogation successives sans accéder aux sources de données dorsales et d'améliorer ainsi le rendement. Toutefois, les entrées de la mémoire cache d'interrogation risquent de devenir périmées, car les mises à jour se produisent sur les sources de données dorsales.

Avantages de la mise en mémoire cache

La manière la plus rapide de traiter une interrogation consiste à ignorer la majorité du traitement et d'utiliser une réponse précalculée.

Avec la mise en mémoire cache des interrogations, Oracle Analytics Cloud stocke les résultats précalculés des interrogations dans une mémoire cache locale. Si une autre interrogation peut utiliser ces résultats, le traitement intégral de la base de données est éliminé pour cette interrogation. Le temps de réponse moyen aux interrogations peut ainsi être grandement amélioré.

Outre l'amélioration de la performance, pouvoir répondre à une interrogation à partir d'une mémoire cache locale conserve les ressources du réseau et le temps de traitement sur le serveur de base de données. Les ressources du réseau sont conservées, car les résultats intermédiaires ne sont pas retournés dans Oracle Analytics Cloud. Ne pas exécuter l'interrogation sur la base de données libère le serveur de base de données pour d'autres travaux. Si la base de données utilise un système de rajustement, exécuter moins d'interrogations peut également réduire les coûts du budget.

Les économies de temps de traitement dans Oracle Analytics Cloud, en particulier si les résultats de l'interrogation sont extraits de plusieurs bases de données, représentent un autre avantage de l'utilisation de la mémoire cache pour répondre à une interrogation. Selon l'interrogation, le traitement de jointure et de tri dans le serveur peut être considérable. Si l'interrogation est déjà calculée, ce traitement est évité, ce qui libère les ressources du serveur pour d'autres tâches.

En résumé, la mise en mémoire cache des interrogations peut beaucoup améliorer le rendement des interrogations et réduire le trafic sur le réseau, le traitement de la base de données et les frais généraux liés au traitement.

Coûts de la mise en mémoire cache

La mise en mémoire cache des interrogations présente de nombreux avantages évidents, mais également certains coûts.

  • Potentiel pour les résultats mis en mémoire cache d'être périmés

  • Coûts administratifs de la gestion de la mémoire cache

En ce qui concerne la gestion de la mémoire cache, en général les avantages dépassent largement les coûts.

Tâches d'administration associées à la mise en mémoire cache

Certaines tâches d'administration sont associées à la mise en mémoire cache. Vous devez définir la durée de persistance de la mémoire cache pour chaque table physique de manière appropriée, basée sur la fréquence de la mise à jour des données dans cette table.

Lorsque la fréquence de la mise à jour varie, vous devez effectuer le suivi du moment où les modifications se produisent et épurer la mémoire cache manuellement le cas échéant.

Tenir la mémoire cache à jour

Si les entrées de la mémoire cache ne sont pas éliminées lorsque les données des bases de données sous-jacentes sont modifiées, les interrogations peuvent potentiellement retourner des résultats qui sont périmés.

Vous devez évaluer si c'est acceptable. Il peut être acceptable d'autoriser la mémoire cache à contenir certaines données périmées. Vous devez décider quel niveau de données périmées est acceptable, puis configurer (et suivre) un jeu de règles pour refléter ces niveaux.

Par exemple, supposons qu'une application analyse les données d'entreprise d'un grand conglomérat et que vous effectuez des sommaires annuels sur les diverses divisions de la société. Les nouvelles données n'ont pas d'incidence matérielle sur les interrogations, car elles ont une incidence sur les synthèses de l'année suivante seulement. Dans ce cas, les choix amenant à décider s'il faut épurer la mémoire cache peuvent faire qu'il est plus avantageux de laisser les entrées dans la mémoire cache.

Supposons, toutefois, que les bases de données sont mises à jour trois fois par jour et que vous effectuez des interrogations sur les activités du jour courant. Dans ce cas, vous devez épurer la mémoire cache bien plus souvent ou peut-être envisager de ne pas l'utiliser du tout.

Un autre scénario consiste à recréer le jeu de données à partir du début à des intervalles réguliers (par exemple, une fois par semaine). Dans cet exemple, vous pouvez épurer toute la mémoire cache dans le cadre du processus de recréation du jeu de données, ce qui garantit que vous n'avez jamais de données périmées dans la mémoire cache.

Quelle que soit votre situation, vous devez évaluer ce qui est acceptable en termes d'informations non courantes retournées aux utilisateurs.

Partage de la mémoire cache par tous les utilisateurs

Si la connexion partagée est activée pour une réserve de connexions particulière, la mémoire cache peut être partagée par tous les utilisateurs et n'a pas besoin d'être prédéfinie pour chaque utilisateur.

Si la connexion partagée n'est pas activée et qu'une connexion à une base de données propre à l'utilisateur est utilisée, chaque utilisateur génère sa propre entrée de mémoire cache.

Activer ou désactiver la mise en mémoire cache des interrogations

Dans Oracle Analytics Cloud, la mise en mémoire cache des interrogations est activée par défaut. Vous pouvez activer ou désactiver la mise en mémoire cache des interrogations dans la page Paramètres de système avancés.

  1. Cliquez sur Console.
  2. Cliquez sur Paramètres de système avancés.
  3. Cliquez sur Performance et compatibilité.
  4. Réglez l'option Activer le cache à Activé ou Désactivé.
    • Activé - La mise en mémoire cache des interrogations de données est activée.
    • Désactivé - La mise en mémoire cache est désactivée.
  5. Cliquez sur Appliquer.
    Patientez pour que les modifications s'actualisent.

Surveiller et gérer la mémoire cache

Pour gérer les modifications des bases de données sous-jacentes et pour surveiller les entrées de la mémoire cache, vous devez développer une stratégie de gestion de la mémoire cache.

Vous avez besoin d'un processus pour invalider les entrées de la mémoire cache lorsque les données des tables sous-jacentes composent les modifications des entrées de la mémoire cache et d'un processus pour surveiller, identifier et supprimer toutes les entrées indésirables.

Cette section traite des sujets suivants :

Choisir une stratégie de gestion de la mémoire cache

Le choix d'une stratégie de gestion de la mémoire cache dépend de la volatilité des données des bases de données sous-jacentes et de la prédictibilité des modifications entraînant la volatilité.

Il dépend également du nombre et du type d'interrogations qui composent la mémoire cache et de leur utilisation. Cette section présente les diverses approches de la gestion de la mémoire cache.

Désactiver la mise en mémoire cache pour le système

Vous pouvez désactiver la mise en mémoire cache pour tout le système afin d'empêcher toutes les nouvelles entrées de la mémoire cache et toutes les nouvelles interrogations d'utiliser la mémoire cache existante. Désactiver la mise en mémoire cache vous permet de l'activer plus tard sans perdre les entrées qui sont stockées dans la mémoire cache.

Désactiver temporairement la mise en mémoire cache est une stratégie utile dans des situations où vous pouvez soupçonner que des entrées sont périmées, mais où vous voulez vérifier si elles le sont réellement avant de les éliminer ou d'épurer toute la mémoire cache. Si vous estimez que les données stockées dans la mémoire cache sont encore pertinentes ou après avoir éliminer en toute sécurité les entrées problématiques, vous pouvez activer la mémoire cache. Si nécessaire, épurez toute la mémoire cache ou la mémoire cache qui est associée à un modèle d'affaires particulier avant de l'activer de nouveau.

Mémoire cache et durée de persistance de la mémoire cache pour des tables physiques spécifiées

Vous pouvez définir un attribut pouvant être mis en mémoire cache pour chaque table physique, ce qui vous permet de spécifier si les interrogations pour cette table sont ajoutées à la mémoire cache afin de répondre aux interrogations futures.

Si vous activez la mise en mémoire cache d'une table, toutes les interrogations impliquant la table sont ajoutées à la mémoire cache. Toutes les tables peuvent être mises en mémoire cache par défaut. Toutefois, certaines tables peuvent ne pas être de bons candidats à inclure dans la mémoire cache sauf si vous configurez les paramètres de persistance de la mémoire cache appropriés. Par exemple, supposons qu'une table stocke des données de bannière boursière mises à jour toutes les minutes. Vous pouvez préciser que vous voulez éliminer les entrées de cette table toutes les 59 secondes.

Vous pouvez également utiliser les paramètres de persistance de la mémoire cache pour spécifier la durée pendant laquelle les entrées de cette table sont stockées dans la mémoire cache d'interrogation. Cette fonction est utile pour les sources de données qui sont mises fréquemment mises à jour.

  1. Dans l'outil d'administration de modèle, dans la couche physique, cliquez deux fois sur la table physique.

    Si vous utilisez le modélisateur sémantique, voir Quelles sont les propriétés générales d'une table physique?.

  2. Dans la boîte de dialogue des propriétés Table physique , dans l'onglet Général, effectuez une des sélections suivantes :

    • Pour activer la mise en mémoire cache, sélectionnez Pouvant être mis en mémoire cache.

    • Pour empêcher une table d'être mise en mémoire cache, désélectionnez Pouvant être mis en mémoire cache.

  3. Pour définir l'expiration d'une mémoire cache, spécifiez une durée de persistance de la mémoire cache et une unité de mesure (jours, heures, minutes ou secondes). Si vous ne voulez pas que les entrées de la mémoire cache expirent automatiquement, sélectionnez Validité permanente du cache.

  4. Cliquez sur OK.

Incidence des modifications des modèles sémantiques sur la mémoire cache d'interrogation

Lorsque vous modifiez des modèles sémantiques à l'aide du modélisateur sémantique ou de l'outil d'administration de modèle, les modifications peuvent avoir des implications pour les entrées stockées dans la mémoire cache. Par exemple, si vous modifiez la définition d'un objet physique ou d'une variable dynamique de modèle sémantique, les entrées de la mémoire cache qui référencent cet objet ou cette variable peuvent ne plus être valides. Ces modifications peuvent entraîner le besoin d'épurer la mémoire cache. Vous pouvez utiliser deux scénarios lorsque vous modifiez un modèle sémantique existant et lorsque vous créez (ou chargez) un nouveau modèle.

Modifications du modèle sémantique

Lorsque vous modifiez un modèle sémantique ou chargez un autre fichier .rpd, toutes les modifications apportées ayant une incidence sur les entrées de la mémoire cache entraînent automatiquement l'élimination de toutes les entrées de la mémoire cache qui référencent les objets modifiés. L'élimination se produit lorsque vous chargez les modifications. Par exemple, si vous supprimez une table physique d'un modèle sémantique, toutes les entrées de la mémoire cache qui référencent cette table sont éliminées au moment de l'archivage. Toutes les modifications apportées à un modèle sémantique dans la couche logique éliminent toutes les entrées de mémoire cache pour ce modèle.

Modifications des variables globales de modèle sémantique

Les valeurs des variables globales de modèle sémantique sont actualisées par les données retournées par les interrogations. Lorsque vous définissez une variable globale de modèle sémantique, vous créez un bloc d'initialisation ou vous en utilisez un qui existe déjà et qui contient une interrogation SQL. Vous configurez également une programmation pour exécuter l'interrogation et actualiser régulièrement la valeur de la variable.

Si la valeur d'une variable globale de modèle sémantique change, les entrées de la mémoire cache qui utilisent cette variable dans une colonne deviennent périmées et de nouvelles entrées sont générées lorsque les données de ces entrées sont de nouveau nécessaires. Les anciennes entrées de la mémoire cache ne sont pas supprimées immédiatement, mais sont nettoyées au moyen du mécanisme de mise en mémoire cache habituel.

Stratégies d'utilisation de la mémoire cache

Un des principaux avantages de la mise en mémoire cache des interrogations consiste à améliorer leur rendement.

La mise en mémoire cache des interrogations peut être utile pour prédéfinir la mémoire cache pendant les périodes creuse en exécutant les interrogations et en mettant en mémoire cache leurs résultats. Une bonne stratégie de prédéfinition exige que vous sachiez quand les présences dans la mémoire cache se produisent.

Afin de prédéfinir la mémoire cache pour tous les utilisateurs, utilisez l'interrogation suivante :

SELECT User, SRs

Après avoir prédéfini la mémoire cache à l'aide de SELECT User, SRs, les interrogations suivantes représentent des présences dans la mémoire cache :

SELECT User, SRs WHERE user = valueof(nq_SESSION.USER) (and the user was USER1)
SELECT User, SRs WHERE user = valueof(nq_SESSION.USER) (and the user was USER2)
SELECT User, SRs WHERE user = valueof(nq_SESSION.USER) (and the user was USER3)

Cette section traite des sujets suivants :

À propos des présences dans la mémoire cache

Lorsque la mise en mémoire cache est activée, chaque interrogation est évaluée pour déterminer si elle remplit les conditions d'une présence dans la mémoire cache.

Une présence dans la mémoire cache signifie qu'Oracle Analytics Cloud a pu utiliser la mémoire cache pour répondre à l'interrogation sans avoir eu besoin d'aller dans la base de données. Oracle Analytics Cloud peut utiliser la mémoire cache d'interrogation pour répondre à des interrogations au même niveau d'agrégation ou à un niveau supérieur.

De nombreux facteurs déterminent les présences dans la mémoire cache. Ces facteurs sont décrits dans le tableau ci-dessous.

Facteur ou règle Description

Un sous-ensemble de colonnes de la liste SELECT doit correspondre

Toutes les colonnes de la liste SELECT d'une nouvelle interrogation doivent exister dans l'interrogation mise en mémoire cache afin de remplir les conditions d'une présence dans la mémoire cache ou elles doivent pouvoir être calculées à partir des colonnes de l'interrogation.

Cette règle décrit les conditions minimales d'une présence dans la mémoire cache, mais satisfaire à cette règle ne garantit pas une présence. Les autres règles listées dans ce tableau doivent également s'appliquer.

Les colonnes de la liste SELECT peuvent comprendre des expressions pour les colonnes des interrogations mises en mémoire cache

Oracle Analytics Cloud peut calculer des expressions pour les résultats mis en mémoire cache afin de répondre à la nouvelle interrogation, mais toutes les colonnes doivent se trouver dans le résultat mis en mémoire cache. Par exemple, l'interrogation :

SELECT product, month, averageprice FROM sales WHERE year = 2000

entraîne des présences dans la mémoire cache pour l'interrogation :

SELECT product, month, dollars, unitsales FROM sales WHERE year = 2000

, car averageprice peut être calculé à partir de dollars et unitsales (averageprice = dollars/unitsales).

La clause WHERE doit être sémantiquement identique ou être un sous-ensemble logique

Pour que l'interrogation remplisse les conditions d'une présence dans la mémoire cache, les contraintes de la clause WHERE doivent être équivalentes aux résultats mis en mémoire cache ou en être un sous-ensemble.

Une clause WHERE qui est un sous-ensemble logique d'une interrogation mise en mémoire cache remplit les conditions d'une présence dans la mémoire cache si le sous-ensemble satisfait à l'un des critères suivants :

  • Un sous-ensemble des valeurs de la liste IN. Les interrogations demandant moins d'éléments d'une interrogation mise en mémoire cache de la liste IN remplissent les conditions d'une présence dans la mémoire cache. Par exemple, l'interrogation suivante :

    SELECT employeename, region
FROM employee, geography
WHERE region in ('EAST', 'WEST')

    remplit les conditions d'une présence pour l'interrogation mise en mémoire cache ci-dessous :

    SELECT employeename, region
FROM employee, geography
WHERE region in ('NORTH', 'SOUTH', 'EAST', 'WEST')

  • Elle contient moins de contraintes OR (mais identiques) que le résultat mis en mémoire cache.

  • Elle contient un sous-ensemble logique d'une comparaison littérale. Par exemple, le prédicat suivant :

    WHERE revenue < 1000

    remplit les conditions d'une présence dans la mémoire cache pour une interrogation comparable avec le prédicat :

    WHERE revenue < 5000

  • Il n'y a pas de clause WHERE. Si une interrogation sans clause WHERE est mise en mémoire cache, les interrogations qui satisfont à toutes les autres règles de présence dans la mémoire cache remplissent les conditions d'une présence dans la mémoire cache indépendamment de leur clause WHERE.

En outre, les colonnes qui sont utilisées pour la clause WHERE doivent se trouver dans la liste de projection. Par exemple, l'interrogation suivante :

SELECT employeename
FROM employee, geography
WHERE region in ('EAST', 'WEST')

n'entraîne pas une présence dans la mémoire cache pour l'interrogation de prédéfinition de la liste précédente, car REGION ne figure pas dans la liste de projection.

Les interrogations de dimension seulement doivent constituer une correspondance exacte.

S'il s'agit d'une interrogation de dimension seulement, c'est-à-dire qu'aucun fait ou mesure n'est inclus dans l'interrogation, seule une correspondance exacte des colonnes de projection de l'interrogations mise en mémoire cache représente des présences dans la mémoire cache. Ce comportement empêche les faux positifs lorsqu'il existe plusieurs sources logiques pour une table de dimension.

Les interrogations avec des fonctions spéciales doivent constituer une correspondance exacte.

Les autres interrogations qui contiennent des fonctions spéciales comme les fonctions de série chronologique (AGO, TODATE et PERIODROLLING), les fonctions de limite et de décalage (OFFSET et FETCH), les fonctions de relation (ISANCESTOR, ISLEAF, ISROOT et ISSIBLING), les fonctions d'agrégation externe et, en général, les mesures de filtre doivent également constituer une correspondance exacte avec les colonnes de projection de l'interrogation mise en mémoire cache. Dans ces cas-là, le filtre doit également constituer une correspondance exacte. Pour les mesures de filtre, si la mesure peut être réécrite sous forme de clause WHERE, vous pouvez tirer parti de la mémoire cache du sous-ensemble.

Le jeu de tables logiques doit correspondre

Pour remplir les conditions d'une présence dans la mémoire cache, toutes les interrogations entrantes doivent avoir le même jeu de tables logiques que l'entrée de la mémoire cache. Cette règle empêche les fausses présences dans la mémoire cache. Par exemple, SELECT * FROM product ne correspond pas à SELECT * FROM product, sales.

Les valeurs des variable de session doivent correspondre, notamment les variables de session de sécurité

Si l'énoncé SQL logique ou physique réfère à des variables de session, les valeurs de ces variables doivent correspondre. Sinon, il ne s'agit pas d'une présence dans la mémoire cache.

De plus, les valeurs des variables de session qui sont sensibles à la sécurité doivent correspondre aux valeurs des variables de session de sécurité définies dans le modèle sémantique, même si l'énoncé SQL logique lui-même ne référence pas les variables de session. Voir Garantir des résultats de la mémoire cache corrects lors de l'utilisation d'une sécurité de base de données au niveau de la rangée.

Conditions de liaison équivalentes

La table logique jointe obtenue d'une nouvelle demande d'interrogation doit être identique aux résultats mis en mémoire cache (ou un sous-ensemble) pour remplir les conditions d'une présence dans la mémoire cache.

L'attribut DISTINCT doit être le même

Si une interrogation mise en mémoire cache élimine les enregistrements en double avec le traitement DISTINCT (par exemple, SELECT DISTINCT...), les demandes pour les colonnes mises en mémoire cache doivent également inclure le traitement DISTINCT; une demande pour la même colonne sans le traitement DISTINCT représente une absence dans la mémoire cache.

Les interrogations doivent contenir des niveaux d'agrégation compatibles

Les interrogations qui demandent un niveau agrégé d'informations peuvent utiliser des résultats mis en mémoire cache à un niveau inférieur d'agrégation. Par exemple, l'interrogation suivante demande la quantité vendue au niveau du fournisseur, de la région et de la ville :

SELECT supplier, region, city, qtysold
FROM suppliercity

L'interrogation suivante demande la quantité vendue au niveau de la ville :

SELECT city, qtysold
FROM suppliercity

La deuxième interrogation entraîne une présence dans la mémoire cache pour la première interrogation.

Agrégation supplémentaire limitée

Par exemple, si une interrogation avec la colonne qtysold est mise en mémoire cache, une demande pour RANK(qtysold) entraîne une absence dans la mémoire cache. En outre, une interrogation qui demande qtysold au niveau du pays peut obtenir une présence dans la mémoire cache à partir d'une interrogation qui demande qtysold au niveau du pays et de la région.

La clause ORDER BY doit comprendre des colonnes de la liste sélectionnée

Les interrogations pour trier par des colonnes qui ne sont pas contenues dans la liste de sélection entraînent des absences dans la mémoire cache.

Diagnostic du comportement des présences dans la mémoire cache

Pour mieux évaluer le comportement des présences dans la mémoire cache, réglez la variable de session ENABLE_CACHE_DIAGNOSTICS à 4, comme illustré dans l'exemple suivant :

ENABLE_CACHE_DIAGNOSTICS=4

Garantir des résultats de la mémoire cache corrects lors de l'utilisation d'une sécurité de base de données au niveau de la rangée

Lorsque vous utilisez une stratégie de sécurité de base de données au niveau de la rangée, par exemple une base de données privée virtuelle, les résultats de données retournés dépendent des données d'identification d'autorisation de l'utilisateur.

En conséquence, Oracle Analytics Cloud doit savoir si une source de données utilise une sécurité de base de données au niveau de la rangée et les variables qui sont pertinentes pour la sécurité.

Pour garantir que les présences dans la mémoire cache se produisent sur les entrées de la mémoire cache qui comprennent toutes les variables sensibles à la sécurité et y correspondent, vous devez configurer correctement l'objet de base de données et les objets de variable de session dans l'outil d'administration de modèle, comme suit :

  • Objet de base de données. Dans la couche physique, dans l'onglet Général de la boîte de dialogue Base de données, sélectionnez Base de données privée virtuelle pour spécifier que la source de données utilise la sécurité de base de données au niveau de la rangée.

    Si vous utilisez la sécurité de base de données au niveau de la rangée avec la mise en mémoire cache partagée, vous devez sélectionner cette option pour empêcher le partage des entrées de la mémoire cache dont les variables sensibles à la sécurité ne correspondent pas.

  • Objet de variable de session. Pour les variables associées à la sécurité, dans la boîte de dialogue Variable de session, sélectionnez Prendre en compte la sécurité pour les identifier comme sensibles à la sécurité lors de l'utilisation d'une stratégie de sécurité de base de données au niveau de la rangée. Cette option garantit que les entrées de la mémoire cache sont marquées avec des variables sensibles à la sécurité, ce qui permet leur mise en correspondance pour toutes les interrogations entrantes.

Exécuter une série d'interrogations pour alimenter la mémoire cache

Pour optimiser les présences potentielles dans la mémoire cache, une stratégie consiste à exécuter une série d'interrogations pour alimenter la mémoire cache.

Ci-dessous se trouvent quelques recommandations ayant trait aux types d'interrogation à utiliser lors de la création d'une série d'interrogations avec laquelle prédéfinir la mémoire cache.

  • Interrogations prédéfinies communes. Les interrogations qui sont exécutées couramment, notamment celles dont le traitement est cher, représentent d'excellentes interrogations pour prédéfinir la mémoire cache. Les interrogations dont les résultats sont intégrés dans des tableaux de bord sont de bons exemples d'interrogations communes.

  • Listes SELECT sans expression. L'élimination des expressions des colonnes de la liste SELECT développe la possibilité de présences dans la mémoire cache. Une colonne mise en mémoire cache avec une expression peut seulement répondre à une nouvelle interrogation avec la même expression; une colonne mise en mémoire cache sans expression peut répondre à une demande pour cette colonne avec n'importe quelle expression. Par exemple, une demande mise en mémoire cache telle que :

    SELECT QUANTITY, REVENUE...

    peut répondre à une nouvelle interrogation telle que :

    SELECT QUANTITY/REVENUE...

    mais non l'inverse.

  • Aucune clause WHERE. Si un résultat mis en mémoire cache ne comporte pas de clause WHERE, il peut être utilisé pour répondre à des interrogations qui satisfont aux règles de présence dans la mémoire cache pour la liste de sélection avec toute clause WHERE incluant des colonnes dans la liste de projection.

En général, les meilleures interrogations avec lesquelles prédéfinir la mémoire cache sont des interrogations qui consomment un grand nombre de ressources de traitement de la base de données et qui seront probablement réémises. Faites attention de ne pas prédéfinir la mémoire cache avec de simples interrogations qui retournent de nombreuses rangées. Ces interrogations (par exemple, SELECT * FROM PRODUCTS, où PRODUCTS est mappé directement à une seule table de la base de données) nécessitent très peu de traitement pour la base de données. Le réseau et les frais généraux en représentent les principaux frais et la mise en mémoire cache ne permet pas d'améliorer ces facteurs.

Quand Oracle Analytics Cloud actualise les variables du modèle sémantique, il examine les modèles d'affaires pour déterminer s'ils référencent ces variables. Si c'est le cas, Oracle Analytics Cloud épure toute la mémoire cache de ces modèles d'affaires. Voir Incidence des modifications des modèles sémantiques sur la mémoire cache d'interrogation.

Utiliser des agents pour prédéfinir la mémoire cache d'interrogation

Vous pouvez configurer des agents pour prédéfinir la mémoire cache d'interrogation Oracle Analytics Cloud.

Prédéfinir la mémoire cache peut améliorer le temps de réponse pour les utilisateurs lorsqu'ils exécutent des analyses intégrées dans leurs tableaux de bord. Vous pouvez ainsi programmer des agents pour exécuter des demandes qui actualisent ces données.

  1. Dans Oracle Analytics Cloud, ouvrez la page d'accueil classique et sélectionnez Agent (section Créer).
  2. Dans l'onglet Général, sélectionnez Destinataire pour l'option Exécuter en tant que. La prédéfinition personnalisée de la mémoire cache se sert de la visibilité des données pour personnaliser le contenu de diffusion de l'agent pour chaque destinataire.
  3. Dans l'onglet Programmation, indiquez comment vous voulez prédéfinir la mémoire cache.
  4. Facultatif : Sélectionnez Condition et créez ou sélectionnez une demande conditionnelle. Par exemple, vous pouvez avoir un modèle d'affaires qui détermine lorsque le processus ETC est terminé. Vous pouvez utiliser un rapport basé sur ce modèle d'affaires comme déclencheur conditionnel du début de la prédéfinition de la mémoire cache.
  5. Dans l'onglet Contenu de diffusion, sélectionnez une demande individuelle ou une page entière de tableau de bord pour laquelle vous voulez prédéfinir la mémoire cache. Sélectionner une page de tableau de bord peut vous faire gagner du temps.
  6. Dans l'onglet Destinataires, sélectionnez des utilisateurs individuels ou des groupes comme destinataires.
  7. Dans l'onglet Destinations, effacez toutes les destinations de l'utilisateur et sélectionnez Mémoire cache du serveur Oracle Analytics.
  8. Enregistrez l'agent en sélectionnant le bouton Enregistrer dans le coin supérieur droit.

La seule différence entre les agents de prédéfinition de la mémoire cache et les autres agents est qu'ils effacent automatiquement la mémoire cache précédente et n'apparaissent pas dans le tableau de bord comme alertes.

Note :

Les agents de prédéfinition de la mémoire cache éliminent seulement les interrogations avec correspondance exacte, des données périmées peuvent donc toujours exister. Assurez-vous que la stratégie de mise en mémoire cache comprend toujours l'épuration de la mémoire cache, car les interrogations d'agent ne traitent pas les interrogations ad hoc ni les forages.

Utilisez l'outil d'administration de modèle pour épurer automatiquement la mémoire cache de tables spécifiques

L'épuration de la mémoire cache supprime les entrées de la mémoire cache d'interrogation et permet au contenu de rester actualisé. Vous pouvez éliminer automatiquement les entrées de la mémoire cache de tables spécifiques en définissant le champ Durée de persistance de la mémoire cache pour chaque table dans l'outil d'administration de modèle.

Note :

Si vous utilisez le modélisateur sémantique, voir Quelles sont les propriétés générales d'une table physique?

Cette fonction est utile pour les sources de données qui sont fréquemment mises à jour. Par exemple, si une table stocke des données de bannière boursière qui sont mises à jour toutes les minutes, vous pouvez utiliser le paramètre Durée de persistance de la mémoire cache pour éliminer les entrées de cette table toutes les 59 secondes. Voir Mémoire cache et durée de persistance de la mémoire cache pour des tables physiques spécifiées.