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.
Les fichiers journaux sont situés dans trois répertoires : $REPERTOIRE_INSTALLATION/<réceptionnaire, console et routeur>/was/logs/server1.
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.
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.
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
|
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é.
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.
Vous pouvez purger les tables de journalisation suivantes en fonction de leur date de création.
Vous ne devez pas modifier les tables récapitulatives suivantes afin de conserver des fonctionnalités système appropriées.