-
Title
What is the event log ageing feature of SharePlex in version 9 and up -
Description
Starting with SharePlex version 9 and up, there is a new feature introduced that aids in housekeeping and management of event_log and trace_log. The feature is termed event log ageing. It may appear to be a misnomer since the feature applies to both event_log and trace_log. The article delves on this feature.
-
Cause
General information. -
Resolution
The SharePlex event log is no longer truncated when the file reaches its maximum size. Now, when file reaches its maximum size, it is renamed to event_log_n, where n is a sequence number, and then a new file is created as the active log. For example, when the first event log reaches its maximum size, it is renamed to event_log_0000000001 and then a new file is opened as the active event log. When that file reaches its maximum size, it is renamed to event_log_0000000002, and so forth. It is noteworthy that the renaming of the logs occur seamlessly in that it is done while SharePlex keeps running. In the process the older logs are retained and this allows the users to purge the older logs as and when convenient. The feature of ageing is not confined to event_log but also applies to the trace_log, albeit differently. For trace_log, the ageing involves truncating them when they reach the maximum size threshold as defined by the parameter SP_SLG_LOG_MAXSIZE explained below.
The feature does not apply to the logs created by processes, namely the *ocap* log (for Capture), *ord* log (for Read) and *opo* log (for Post). These logs are typically written in cyclical manner and do not pose any issue like disk full since by default there are three such logs for each of these processes and each log is 50M maximum by default. The problem of runaway growth of logs only occur in event_log and trace_log which keep expanding indefinitely. Hence this feature is created to address it.
The feature makes use of the parameter SP_SLG_LOG_MAXSIZE. The parameter is set to a size which you want to be the tipping point following which you want the current event_log to be renamed and a new log to take its place and henceforth become the current event_log. For trace_log, the parameter will truncate the current trace_log once it reaches the tipping point thereby the previous content of the trace_log will be purged. It should be noted that the same parameter applies to both event_log and trace_log so it is not possible to define the maximum size differently for these two.
Here is the excerpt taken from Reference Guide:
SP_SLG_LOG_MAXSIZE
This parameter controls the size of the SharePlex Event and Trace logs. When the file reaches its maximum size, the following happens, depending on the log:
* The Event Log is renamed to event_log_n, where n is the next number in the sequence of files, and then a new file is created as the active event log. For example, when the first event log reaches its maximum size, it is renamed to event_log_0000000001 and then a new file is opened as the active log. When that file reaches its maximum size, it is renamed to event_log_0000000002, and so forth.
* The Trace Log is truncated. Before writing to this log, SharePlex checks its size. If the size is larger than the value of this parameter, SharePlex truncates the file before writing to it.
Before increasing this parameter, make certain that you have enough disk space to accommodate the new file size.
Default: 500 MB
Range of valid values: 1 to 2048 MB in increments of 1 MB
Takes effect: when SharePlex is restarted
-
Additional Information
Since the event log is aged but the trace log is purged when the threshold as defined by SP_SLG_LOG_MAXSIZE is reached, these two actions will most likely occur at different times since it is highly unlikely that these two logs reach the threshold size at the same time. If wishing to preserve the trace log before it is purged, it will be advisable to set the parameter SP_SLG_LOG_MAXSIZE to a sufficiently high value. It should be kept in mind that when debug is set on processes that generate trace_log, it can grow at astronomical speed. It would be frustrating to see the trace_log getting purged when the debugging is still in progress. To avoid such scenario, it is better to set conservatively to a very high value even if it generates a very large event log due to the ageing.