Fermer

octobre 25, 2018

Configurer la purge de cache OBIEE avec la table d'interrogation d'événements


Introduction

Une table d'interrogation d'événements (S_NQ_EPT) est un moyen d'identifier pour le serveur Oracle BI qu'une ou plusieurs tables physiques ont été mises à jour. Chaque ligne ajoutée à une table d'événements met en évidence une seule mise à jour sur une seule table. Le système de cache lit à partir de cette table, extrait les informations de ces lignes et vide les entrées en fonction de ces informations.

Une fois ce processus en place et la table d'événements configurée dans le référentiel Oracle BI, le vidage de la mémoire cache se produit tout seul. . Les anciennes entrées de cache sont purgées automatiquement aux intervalles d'interrogation spécifiés, étant donné qu'ETL écrit correctement les enregistrements dans cette table d'interrogation. Dans cet article, nous verrons le processus de configuration de la purge de cache OBIEE (11g). Cela n'inclut PAS les étapes ETL nécessaires pour charger la table d'interrogation. Cela doit être fait par l'équipe de développement ETL.

Structure des tables d'interrogation

Nous pouvons configurer une table d'interrogation d'événements dans chaque base de données physique (Développement, UAT, PROD, etc.) pour surveiller les modifications apportées à la base de données. La table d'événements doit être mise à jour chaque fois qu'une table de la base de données est modifiée. Elle doit être prise en charge par le processus ETL. Cela dépend également du fait que les tables sont supposées être maintenues en mémoire cache (ou qu'une purge doit être effectuée). Il n'est pas nécessaire que les autres tables qui entrent dans cette catégorie soient présentes dans les lignes de cette table d'interrogation d'événements. La table d'événements doit avoir la structure indiquée ci-dessous. Les noms de colonne pour la table d'événements sont uniquement suggérés; on peut utiliser n'importe quelle autre convention d'appellation logique. Cependant, l'ordre des colonnes doit être identique dans la couche physique du référentiel (puis par ordre alphabétique ascendant).

Nom de la colonne
(par ordre alphabétique ascendant)
Type de données Null -able Description Commentaires
Catalog_Name VARCHAR Oui Nom du catalogue où réside la table physique mise à jour. Remplissez la colonne Catalog_Name uniquement si l'événement table ne réside pas dans la même base de données que les tables physiques qui ont été mises à jour. Sinon, définissez-le sur NULL.
DB_Name VARCHAR Oui Nom de la base de données où réside la table physique mise à jour. Remplissez la colonne DB_Name uniquement si la table d'événements contient ne réside pas dans la même base de données que les tables physiques mises à jour. Sinon, définissez-la sur NULL.
Other VARCHAR Oui Réservé aux modifications futures Cette colonne doit être définie sur une valeur NULL.
Schema_Name VARCHAR. 19659014] Yes Nom du schéma dans lequel réside la table physique mise à jour. Remplissez la colonne Schema_Name uniquement si la table des événements ne réside pas dans la même base de données que les tables physiques mises à jour. Sinon, définissez-le sur NULL.
Table_Name VARCHAR Non Nom de la table physique mise à jour. Le nom doit correspondre à celui défini pour la table dans la zone physique. couche de l'outil d'administration.
Update_Time DATE ou TIMESTAMP Non Heure à laquelle la mise à jour de la table d'événements a eu lieu. Il s'agit d'une clé à valeur unique qui change pour chaque ligne ajoutée à la table. horodatage actuel comme valeur par défaut.
Update_Type INT Non Spécifiez une valeur de 1 dans le script de mise à jour. pour indiquer une mise à jour standard. D'autres valeurs sont réservées pour une utilisation future.

Configuration de la table de sondage d'événements

Création d'un utilisateur dans la base de données :

CREATE utilisateur OBIEE_USER IDENTIFIED BY OBIEE_USER; GRANT connect, ressource TO OBIEE_USER;

Création de la table d'interrogation d'événement:

  • Accédez au chemin " instances instance1 bifoundation OracleBIServerComponent coreapplication_obis1 schema ".
  • Open. SAEPT.Oracle et copiez le DDL. Créez la table sous le schéma BIPlatform en exécutant le DDL dans la base de données.

Purge du cache à l'aide de la table d'interrogation des événements

Pour vous assurer que le serveur Oracle BI dispose d'un accès en écriture à la table d'interrogation des événements, mais pas Pour toutes les autres tables d'une base de données, procédez comme suit:

  • Créez une base de données physique distincte dans la couche physique de la RPD avec un pool de connexions privilégiées.
  • Affectez un utilisateur à ce pool de connexions particulier doté de privilèges de suppression. ] Remplissez la base de données privilégiée avec la table d'événements.

Importation de la table physique:

  • Importez la table S_NQ_EPT dans le référentiel à partir de la base de données dans laquelle nous avons créé la table.
  • Ouvrez la RPD en mode hors connexion, allez à. Fichier -> importer les métadonnées et importer le tableau (S_NQ_EPT) dans la couche physique.

  • Accédez à Outils -> Utilitaires et sélectionnez l'option Oracle BI Event Tables dans la liste des options comme indiqué ci-dessous. Cliquez sur Exécuter .

  • Sélectionnez la table S_NQ_EPT comme table de scrutation des événements et sélectionnez le bouton >> . Réglez la fréquence d’interrogation sur une valeur supérieure à 10 minutes. Idéalement, il devrait durer 12 à 24 heures, car les tables sont généralement chargées une ou deux fois par jour au plus. Cliquez sur OK.

  • Après avoir enregistré cette table en tant que table d'événements Oracle BI Server, vous ne pouvez pas mettre cette table en cache, ce qui est explicite.

Validate Cache de vidage

manières d'implémenter le chargement de la table d'interrogation d'événements (update ou insert ou les deux) une fois le travail quotidien d'ETL terminé.

1. Modification de chaque flux de travail Informatica pour chaque table cible d'entrepôt afin d'inclure des instructions d'insertion SQL post-ETL.
2. Configuration de nouvelles tâches pour gérer les insertions une fois la charge ETL principale terminée.
3. Déclencheurs dans la base de données Oracle pour les insertions.

L'option 3 est la plus facile à configurer et doit être sélectionnée pour une maintenance aisée. L'option 1 est très fastidieuse car elle aura des conséquences sur des centaines de flux de travail. L'option 2 nécessite beaucoup plus de configuration que l'option 3.

Pour l'option 3, procédez comme suit:

1. Une nouvelle table est créée pour contenir les noms des tables cible de l'entrepôt devant être vidées par ce mécanisme de scrutation d'événements:

CREATE TABLE S_NQ_EPT_TAB (TAB_NAME VARCHAR2 (200 octets) NON NULL ENABLE);

2. Ajoutez ensuite un déclencheur à la table de métadonnées W_ETL_REFRESH_DT dans le CAD. La date d'actualisation de cette table est modifiée une fois l'ETL terminée. Le déclencheur se déclenchera chaque fois que la table sera modifiée et si la date d'actualisation n'est pas nulle, il insérera une nouvelle ligne dans la table d'interrogation:

CREATE OR REPLACE TRIGGER SCHEMA.S_NQ_EPT_NEWROW
APRÈS LA MISE À JOUR DU DACINFA.W_ETL_DEF_HT.
POUR CHAQUE RANG
BEGIN
SI: NEW.LAST_REFRESH_DT N'EST PAS NULL ALORS
FUSIONNER DANS SCHEMA.S_NQ_EPT P
UTILISER (SELECT TAB_NAME FROM SCHEMA.S_NQ_EPT_TAB WHITAH)
ON (P.TABLE_NAME = T.TAB_NAME)
LORSQU'IL NE CORRESPOND PAS, INSERT
(P.UPDATE_TYPE, P.UPDATE_TS, P.DB_NAME, P.CATALOG_NAME,
P.SCHEMA_NAME, P. TABLE_NAME, P.OTHER_RESERVED)
VALEURS (1, SYSTIMESTAMP, 'Oracle Data Warehouse', 'Catalogue', 'dbo', T.TAB_NAME, NULL);
END IF;
END;




Source link