Archivado y depuración de los registros de la base de datos y el sistema de archivos

Para mantener la eficacia operativa de WebSphere Business Integration Connect, se pueden utilizar los siguientes procedimientos para archivar o depurar los archivos de registro del sistema de archivos o la base de datos.

Depuración de los archivos de registro de la aplicación

Los archivos de registro de la aplicación se encuentran en tres áreas: $DIRECTORIO_INSTALACIÓN/<receptor, consola y direccionador>/was/logs/server1.

  1. Detenga primero la aplicación correspondiente ejecutando el script stop que se encuentra en $DIRECTORIO_INSTALACIÓN/<receptor, consola y direccionador>/was/bin/stopServer.sh server1.
  2. Elimine los archivos de registro según sea necesario.

Depuración de directorios de no repudiación

Los directorios y los archivos de no repudiación se encuentran en: $DIRECTORIO_COMÚN/non_rep/. Empiece archivando los archivos más antiguos que se encuentren en los directorios que empiecen por 0, y aumente el número para los archivos más recientes.

  1. Detenga el servicio de direccionador con el script: $DIRECTORIO_INSTALACIÓN/router/was/bin/stopServer.sh server1.
  2. Comprima los archivos utilizando el mandato tar de UNIX o WinZip.
  3. Mueva los archivos a un origen de soporte externo para extraer el almacenamiento según sea necesario.

Depuración de tablas de base de datos

Determinadas tablas de base de datos pueden depurarse cuando sea necesario, pero para mantener la funcionalidad correcta del sistema no deben modificarse las demás tablas. Las tablas que empiezan por BP_ y LG_ pueden depurarse con dos excepciones: las tablas BP_ que terminan en _QUE y _HIST las mantiene constantemente el motor RosettaNet y no deben cambiarse. Las tablas BP_ que terminan en _QUE son tablas de colas y las tablas BP_ que terminan en _HIST son tablas de historial y se utilizan para el archivado. Por ejemplo, la tabla BP_RNSTATEHDR_QUE se archiva en la tabla BP_RNSTATEHDR_HIST.

Las tablas que empiezan por CG_ y PR_ contienen datos de configuración o de perfil, y también deben permanecer sin modificar para mantener la funcionalidad correcta del sistema.

Funcionalidad de archivado y depuración para los motores de estado de RosettaNet y AS1/AS2

El criterio para depurar los datos de la tabla se basa en el número de días que se deben mantener los datos en línea. Los datos de las tablas que finalizan en _HIST se archivan y depuran cada día. Asimismo, toda la información de registro se trunca cada día.

El criterio de depuración contiene sólo un parámetro de entrada, p_days, que es el número de días que se deben mantener los datos en línea. Una vez que DBA establece el parámetro de entrada, el procedimiento funciona de la siguiente manera:
Tabla Tabla de historial Acción

RosettaNet



BP_rnStateHdr

BP_rnStateHdr_Hist

Depurar

BP_rnStateDtl

BP_rnStateDtl_Hist

Depurar

BP_Sponsor_State

BP_Sponsor_State_Hist

Depurar

BP_rnStateHdrAuditLog

Ninguna

Truncar

AS1/AS2



BP_State_Hdr

BP_State_Hdr_Hist

Depurar

BP_AS_State_Hdr

BP_AS_State_Hdr_Hist

Depurar

BP_AS_State_Dtl

BP_AS_State_Dtl_Hist

Depurar

Tiempo de retención de datos

El procedimiento depura los datos según la combinación de la fecha de creación del registro en la cabecera y el parámetro de entrada p_days. El TPA de Tiempo de realización almacenado en la cabecera no se considera. Es responsabilidad de DBA asegurarse de que p_days es mayor que el número máximo de (Tiempo de realización/1440). El tiempo de realización se almacena en minutos.

Se recomienda mantener en línea los datos de las tablas durante BP_ p_days o ((Tiempoderealización/1440) +1 día), cualquiera que sea el mayor. Los datos de las tablas BP_DupCheck y BP_RnMsgDigest se deben mantener siete días. Los datos de BP_Process_Log se deben mantener dos días.

Las tablas con nombres que empiecen por DB son tablas de metadatos, excepto DB_ProcAuditLog. Si el registro DB_ProcAuditLog está activado, se debe depurar o truncar diariamente, o se debe ralizar, según las necesidades del usuario. Este registro está desactivado normalmente en la producción, ya que se utiliza principalmente en el desarrollo y en entornos de QA.

Tablas de registro y de resumen

Las tablas con nombres que empiezan por LG_ son tablas de registro y de resumen con la excepción de: LG_EventCd, LG_Media y LG_media_Cfg. Estas son tablas de metadatos y deben permanecer sin modificar para poder mantener la funcionalidad correcta del sistema. La tablas que empiezan por LG_Access_ no se utilizan en las versiones 4.2.1 y 4.2.2.

Las siguientes tablas de registro se pueden archivar y depurar a partir del ID de actividad, y la tabla de control será LG_Activity. Se puede utilizar createdate o RcvDocTS para determinar el número de días que se deben mantener en línea los datos. RcvDocTS puede ser la mejor opción porque es una columna indexada. Los datos pueden permanecer en línea siete días o ((Tiempoderealización/1440) +1 día), cualquiera que sea el mayor.

Tabla
Notas

LG_ACTIVITY

LG_ACTIVITY_DTL

LG_ACTIVITY_ENDSTATE

LG_ACTIVITY_RNDTL

LG_ACTIVITY_RNHDR

LG_AS_DTL

LG_AS_HDR

LG_ACTIVITY_EVENT
Enlaza LG_Activity con LG_event

LG_EVENT

LG_EVENT_EVENTSUMMARY
Enlaza LG_Event con LG_EventSummary y LG_EventSummary. DRILLDOWNFLG se puede utilizar para indicar que la información no está disponible (no se ha implementado en los procedimientos de 4.2.1 y 4.2.2).

LG_ACTIVITY_SUMMARY
Enlaza LG_Activity con LG_Summary y LG_Summary. DRILLDOWNFLG se puede utilizar para indicar que la información no está disponible (no se ha implementado en los procedimientos de 4.2.1 y 4.2.2).

Las siguientes tablas de registro se pueden depurar según la fecha de creación.

Tabla
Notas

LG_Delivery_Log
Se puede depurar un registro que tenga más de 1 día a partir de la fecha de creación.

LG_DM_Doc_Lock
Se puede depurar un registro que tenga más de 1 día a partir de la fecha de creación.

LG_Msg_Archive
Se puede depurar un registro que tenga más de 7 días a partir de la fecha de creación.

LG_STACKTRACE
Se puede depurar un registro que tenga más de 7 días a partir de la fecha de creación.

LG_SYNCH_REQ_RESP
Se puede depurar un registro que tenga más de 7 días a partir de la fecha de creación o (Tiempoderealización/1440) +1 día), cualquiera que sea el mayor.

LG_VALIDATION
Se puede depurar un registro que tenga más de 7 días a partir de la fecha de creación.

LG_VTP_STATUS
Se puede depurar un registro que tenga más de 7 días a partir de la fecha de creación.

Las siguientes tablas de resumen deben permanecer sin modificar para poder mantener la funcionalidad correcta del sistema.

Tabla
Notas

Tablas de resumen de eventos

LG_EVENTSUMMARY

LG_EVENTSUMMARY_XREF

Tablas de resumen de procesos

LG_PROCESSSUMMARY_AS

LG_PROCESSSUMMARY_AS_MI

LG_PROCESSSUMMARY_AS_XREF

LG_PROCESSSUMMARY_RN

LG_PROCESSSUMMARY_RN_MI

LG_PROCESSSUMMARY_XREF

Tablas de resumen de documentos

LG_DOCPROCESSING_SUMLG_MSGLENGTH_SUMMARY

LG_SUMMARY

LG_SUMMARY_MI

LG_SUMMARY_PROCESSSUMMARY
Enlaza LG_Sum_Xref_Lnk con LG_ProcessSummary_Xref

LG_SUMMARY_RN

LG_SUMMARY_RN_MI

LG_SUM_XREF_LNK
Enlaza LG_SUM_XREF_PART y LG_SUM_XREF_PRCS con LG_Summary

LG_SUM_XREF_PART

LG_SUM_XREF_PRCS

Resumen de longitud de mensaje

LG_MSGLENGTH_SUMMARY

Copyright IBM Corp. 1997, 2004