Archivage et purge des fichiers journaux du système de fichiers et de la base de données

Pour maintenir le fonctionnement efficace de WebSphere Business Integration Connect, vous pouvez utiliser les procédures suivantes afin d'archiver ou de purger les fichiers journaux du système de fichiers et de la base de données.

Purge des fichiers journaux d'applications

Les fichiers journaux sont situés dans trois répertoires : $REPERTOIRE_INSTALLATION/<réceptionnaire, console et routeur>/was/logs/server1.

  1. Arrêtez l'application appropriée en exécutant le script d'arrêt situé dans $REPERTOIRE_INSTALLATION/<réceptionnaire, console et routeur>/was/bin/stopServer.sh server1.
  2. Supprimez les fichiers journaux le cas échéant.

Purge des répertoires d'irréfutabilité

Les fichiers et les répertoires d'irréfutabilité sont situés dans : $REPERTOIRE_COMMUN/non_rep/. Archivez d'abord les fichiers les plus anciens situés dans les répertoires, en commençant par 0 et en augmentant le chiffre pour les nouveaux fichiers.

  1. Arrêtez le service du routeur à l'aide du script suivant : $REPERTOIRE_INSTALLATION/router/was/bin/stopServer.sh server1.
  2. Compressez les fichiers à l'aide de la commande tar UNIX ou de WinZip.
  3. Déplacez les fichiers vers une source de support externe pour le stockage hors site le cas échéant.

Purge des tables de bases de données

Certaines tables de base de données peuvent être purgées si nécessaire, mais aucune des autres tables ne doit être modifiée, afin de maintenir le fonctionnement correct du système. Les tables don le nom commence par BP_ et LG_ peuvent être purgées, à l'exception de deux tables : les tables BP_ se terminant par les suffixes _QUE et _HIST sont maintenues en permanence par le moteur de RosettaNet et ne doivent en aucun cas être modifiées. Les tables BP_ dont le nom se termine par _QUE sont des tables de file d'attente. Les tables BP_ dont le nom se termine par _HIST sont des tables d'historiques utilisées pour l'archivage. La table BP_RNSTATEHDR_QUE est par exemple archivée dans la table BP_RNSTATEHDR_HIST.

Les tables dont le nom commence par CG_ et PR_ contiennent des données de configuration ou de profil et ne doivent pas non plus être modifiées, afin de conserver des fonctionnalités système appropriées.

Fonctionnalités d'archivage et de purge pour les moteurs d'état RosettaNet et AS1/AS2

Le critère pour purger les données d'une table repose sur le nombre de jours pendant lesquels les données doivent être conservées en ligne. Les données contenues dans les tables dont les nom se termine par _HIST sont archivées et purgées quotidiennement. De même, les informations de fichier journal sont tronquées de façon quotidienne.

Le critère de purge contient un seul paramètre d'entrée, p_days, qui correspond au nombre de jours pendant lesquels les données doivent être conservées en ligne. Une fois que l'administrateur de base de données a défini le paramètre d'entrée, la procédure s'exécute comme suit :
Table Table historique Action

RosettaNet



BP_rnStateHdr

BP_rnStateHdr_Hist

Purger

BP_rnStateDtl

BP_rnStateDtl_Hist

Purger

BP_Sponsor_State

BP_Sponsor_State_Hist

Purger

BP_rnStateHdrAuditLog

Néant

Tronquer

AS1/AS2



BP_State_Hdr

BP_State_Hdr_Hist

Purger

BP_AS_State_Hdr

BP_AS_State_Hdr_Hist

Purger

BP_AS_State_Dtl

BP_AS_State_Dtl_Hist

Purger

Durée de conservation des données

La procédure purge les données en fonction d'une combinaison de la date de création de l'enregistrement dans l'en-tête et du paramètre d'entrée p_days. La durée d'exécution des TPA stockés dans l'en-tête n'est pas prise en compte. L'administrateur de base de données doit vérifier que la valeur du paramètre p_days dépasse la valeur maximale (Durée d'exécution/1440). La durée d'exécution est stockée en minutes.

Nous vous recommandons de conserver en ligne les données contenues dans les tables BP_ pendant p_days ou ((Durée d'exécution/1440) + 1 jour), selon la valeur la plus élevée. Les données contenues dans les tables BP_DupCheck et BP_RnMsgDigest doivent être conservées pendant sept jours. Les données contenues dans la table BP_Process_Log doivent être conservées pendant deux jours.

Les tables dont le nom commence par DB sont des tables de métadonnées, à l'exception de DB_ProcAuditLog. Si la table DB_ProcAuditLog est activée, vous devez la purger ou la tronquer quotidiennement ou en fonction des besoins de l'utilisateur. Ce journal est normalement désactivé pour la production car il est principalement utilisé dans les environnements du développement et de l'assurance qualité.

Tables de journalisation et de récapitulatif

Les tables dont le nom commence par LG_ sont des tables de journalisation et de récapitulatif, à l'exception des tables suivantes : LG_EventCd, LG_Media et LG_media_Cfg. Il s'agit de tables de métadonnées que vous ne devez pas modifier afin de conserver des fonctionnalités système appropriées. Les tables dont le nom commence par LG_Access_ ne sont pas utilisées dans les versions 4.2.1 et 4.2.2.

Vous pouvez archiver et purger les tables de journalisation suivantes en fonction de l'ID activité, et la table de pilotage doit être LG_Activity. La date de création ou la colonne RcvDocTS permet de déterminer le nombre de jours pendant lesquels les données doivent être conservées en ligne. L'utilisation de RcvDocTS est préférable car il s'agit d'une colonne indexée. Les données peuvent rester en ligne pendant sept jours ou ((Durée d'exécution/1440) + 1 jour), selon la valeur la plus élevée.

Table
Remarques

LG_ACTIVITY

LG_ACTIVITY_DTL

LG_ACTIVITY_ENDSTATE

LG_ACTIVITY_RNDTL

LG_ACTIVITY_RNHDR

LG_AS_DTL

LG_AS_HDR

LG_ACTIVITY_EVENT
Lie LG_Activity et LG_event

LG_EVENT

LG_EVENT_EVENTSUMMARY
Lie LG_Event à LG_EventSummary et LG_EventSummary. DRILLDOWNFLG permet d'indiquer que le zoom avant n'est pas disponible (non mis en oeuvre dans les procédures des versions 4.2.1 et 4.2.2).

LG_ACTIVITY_SUMMARY
Lie LG_Activity à LG_Summary et LG_Summary. DRILLDOWNFLG permet d'indiquer que le zoom avant n'est pas disponible (non mis en oeuvre dans les procédures des versions 4.2.1 et 4.2.2).

Vous pouvez purger les tables de journalisation suivantes en fonction de leur date de création.

Table
Remarques

LG_Delivery_Log
Tout enregistrement datant de plus d'un jour après la date de création peut être purgé.

LG_DM_Doc_Lock
Tout enregistrement datant de plus d'un jour après la date de création peut être purgé.

LG_Msg_Archive
Tout enregistrement datant de plus de sept jours après la date de création peut être purgé.

LG_STACKTRACE
Tout enregistrement datant de plus de sept jours après la date de création peut être purgé.

LG_SYNCH_REQ_RESP
Tout enregistrement datant de plus de sept jours après la date de création ou ((Durée d'exécution/1440) + 1 jour), selon la valeur la plus élevée, peut être purgé.

LG_VALIDATION
Tout enregistrement datant de plus de sept jours après la date de création peut être purgé.

LG_VTP_STATUS
Tout enregistrement datant de plus de sept jours après la date de création peut être purgé.

Vous ne devez pas modifier les tables récapitulatives suivantes afin de conserver des fonctionnalités système appropriées.

Table
Remarques

Tables de récapitulatif des événements

LG_EVENTSUMMARY

LG_EVENTSUMMARY_XREF

Tables de récapitulatif des processus

LG_PROCESSSUMMARY_AS

LG_PROCESSSUMMARY_AS_MI

LG_PROCESSSUMMARY_AS_XREF

LG_PROCESSSUMMARY_RN

LG_PROCESSSUMMARY_RN_MI

LG_PROCESSSUMMARY_XREF

Tables de récapitulatif des documents

LG_DOCPROCESSING_SUMLG_MSGLENGTH_SUMMARY

LG_SUMMARY

LG_SUMMARY_MI

LG_SUMMARY_PROCESSSUMMARY
Lie LG_Sum_Xref_Lnk à LG_ProcessSummary_Xref

LG_SUMMARY_RN

LG_SUMMARY_RN_MI

LG_SUM_XREF_LNK
Lie LG_SUM_XREF_PART et LG_SUM_XREF_PRCS à LG_Summary

LG_SUM_XREF_PART

LG_SUM_XREF_PRCS

Récapitulatif de la longueur des messages

LG_MSGLENGTH_SUMMARY

Copyright IBM Corp. 1997, 2004