Aller au contenu
  • Nos offres
  • Blog
  • Contact
  • Carrières
Menu
  • Nos offres
  • Blog
  • Contact
  • Carrières
Inscrivez-vous à la newsletter

Inscrivez-vous à la newsletter

Abonnez-vous maintenant et nous vous tiendrons au courant.
Nous respectons votre vie privée. Vous pouvez vous désabonner à tout moment.

Blog

  • Accueil
  • Actualités
  • Cloud
  • Infrastructure
  • Données / Sécurité
  • Intégration
  • Dev / DevOps
  • SAM / FinOps
Menu
  • Accueil
  • Actualités
  • Cloud
  • Infrastructure
  • Données / Sécurité
  • Intégration
  • Dev / DevOps
  • SAM / FinOps
  • le 22/01/2010
  • Romain Spinelli
  • Infrastructures, SOA & Urbanisation

Purger les logs d'Oracle Data Integrator

Partager sur linkedin
Partager sur twitter
Partager sur facebook

Avec ODI, il est important de purger les données du journal (accessibles via le module Operator) pour plusieurs raisons :

  • d’une part généralement lorsque l’on a de gros volumes de données de traces, seul un petit pourcentage de ces données est réellement pertinent, noyé dans la masse des données qui présentent un fonctionnement normal, qui n’atire pas l’attention ;
  • d’autre part, l’accumulation des logs dans le journal peut ralentir considérablement la navigation dans le module Operator d’Oracle Data Integrator. Les filtres peuvent permettre de parer temporairement à ce problème, mais il est impératif à un moment ou à un autre de purger les logs.

PURGE MANUELLE

Il est possible de les purger « manuellement » :

  • soit via l’interface graphique du module Operator :

Un bouton (en forme de corbeille) donne accès à un outil de purge :

Plusieurs paramètres peuvent alors être spécifiés concernant la purge (voir leur description en fin d’article) :

  • soit en exécutant une requête SQL sur les tables systèmes d’Oracle Data Integrator ; les tables concernées sont les suivantes (dans l’ordre des contraintes référentielles) :
SNP_SESSION
SNP_SESS_STEP
SNP_STEP_LOG
SNP_SESS_TASK
SNP_SESS_TASK_LOG
SNP_SESS_TXT_LOG

PURGE AUTOMATIQUE

Une autre solution, qui semble plus intéressante, est d’automatiser cette purge. Pour cela, la méthode conviviale est d’encapsuler le processus de purge dans un package ODI et de planifier l’exécution du scénario qui en découle, ou de lancer son exécution à la fin de chaque traitement souhaité.
Exemple :
On suppose vouloir automatiser la purge des données de production du journal datant de plus de 30 jours et qui se sont déroulées sans erreur.
Pour cela, on peut dans un premier temps mettre dans une variable la durée de conservation des données. On la positionne en mode « Refresh » pour qu’elle se mette à jour à chaque appel et ainsi pour que la période de conservation des logs soit « glissante ». La requête du « Refresh » peut être tout simplement la suivante :

Cette variable, ici nommée « V_FIN_PURGE », permet de garder en mémoire la date de fin de purge (la date courante reculée de 30 jours).
Ensuite il suffit de placer un composant « OdiPurgeLog » au sein du package et de spécifier ses paramètres :

Affectation des paramètres :

  • Date de début : Date de début de purge. Toutes les sessions depuis cette date sont supprimées. Nous laissons ce champ vide.
  • Date de fin : Date de fin de purge. Toutes les sessions jusqu’à cette date sont supprimées. Nous affections à ce champ la valeur de notre variable préalablement mise à jour : #V_FIN_PURGE.
  • Code Contexte : Purge des sessions exécutées dans ce contexte. Nous le laissons vide pour purger les logs de tous les contextes.
  • Nom d’agent : Purge des sessions exécutées par cet agent. Nous le laissons vide pour purger les logs de tous les agents.
  • Etat des sessions : Purge des sessions dans l’état spécifié. Nous spécifions « Done » pour supprimées toutes les traces des exécutions qui se sont déroulées correctement.
  • Nom d’utilisateur : Purge des sessions lancées par cet utilisateur.
  • Filtre sur le nom de session : Permet de préciser un masque de nom de session à purger. Nous précisons « TEST_PROD% » pour purger toutes les sessions de test sur la production.
  • Purge des compte-rendus : Indique si les comptes-rendus de scénarios (qui apparaissent sous le noeud exécution de chaque scénario). sont aussi purgés

Il est à noter que tous ces paramètres sont facultatifs. Si aucun d’entre eux n’est spécifié, toutes les données du journal seront alors supprimées.
Remarque : toutes ces manipulations sont également réalisables si vous utilisez encore Sunopsis, la méthode à appeler étant non pas OdiPurgeLog mais SnpsPurgeLog.
Ce package de purge peut alors être appelé à tout moment par d’autres packages, soit par le planificateur de tâches interne à ODI ou encore un ordonnanceur externe.

Romain Spinelli
Romain Spinelli
Voir tous ses articles

Laisser un commentaire Annuler la réponse

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Articles récents
  • Azure Database pour PostgreSQL [PaaS]
  • Azure Logic Apps : l’outil d’intégration Cloud de Microsoft
  • Purge automatique des archivelogs en PL/SQL
  • ASM et l’importance du usable_file_mb
  • Préparer un Windows Server 2003 pour une migration sur Azure

Mentions légales & Politique de confidentialité

En poursuivant votre navigation, vous acceptez l'utilisation de cookies tiers destinés à réaliser des statistiques de visites et de suivi. Accepter Refuser Personnaliser En savoir plus
Politique de confidentialité et cookies

Politique de confidentialité

Les informations collectées au travers de nos cookies sont exploitées à des fins statistiques (Google Analytics).
Google Analytics
Enregistrer & appliquer

8 JUIN 2022 A PARIS | 8H30 - 18H30

TECH FOR CLIMATE ?

Opportunités et limites de la technologie pour faire face au défi climatique

Programme & Inscriptions

Un évènement imaginé avec 🖤 par Constellation