Product specific Log Level
Table name: /USI/BAL_LV_LOBJ
Maintained via: SM30
The developer may define product-specific default setings for the log writer. These settings define the bare minimum, that needs to be logged no matter what.
The settings will be transported through the landscape, as they are considered a part of the development itself.
CAUTION: The product-specific Log Level can only be increased by other settings. Setting it too high might result in a productive system being flooded with useless log messages. Please be considerate and only log non-reproducible errors by default (e.g. RFC-Errors).
The structure of all customizing tables has been documented in a unified format.
General Information explains how this documentation is to be read.
| Fieldname | Fieldtype | Filter-Priority | Description |
|---|---|---|---|
| LOG_OBJECT | Filter |
1 | Log object |
| SUB_OBJECT | Filter |
2 | Sub object |
| LOG_LEVEL | Data |
Assigned Log-Level | |
| AUTO_SAVE_PACKAGE_SIZE | Data |
Package size for Auto-Save. 0 = Disabled. |
If no suitable customizing can be found, the following default values will be applied.
| Fieldname | Default |
|---|---|
| LOG_LEVEL | 0 (Log completely deactivated) |
| AUTO_SAVE_PACKAGE_SIZE | 0 (Disabled) |
The auto-save (Field AUTO_SAVE_PACKAGE_SIZE) will only be needed for applications, that are creating huge amounts of log messages. An example would be an inbound interface processing huge IDocs, thereby creating ridiculous amounts of log messages.
Messages are added to an internal buffer first. Saving will write that buffer to the database before clearing it.
Saving after e.g. each processed object can have a negative impact on performance due to a needlessly high number of write accesses to the database. Not saving until the end of processing might lead to needlessly high memory consumption. Neither of these options is exactly ideal.
The auto-save can be used to find a compromise between these two extremes. Whenever the internal buffer contains the specified number of messages, the log will be saved automatically. It allows the developer to define a reasonable package-size for incremental saves.
A single log message occupies about 1 KB of RAM. In addition, the data of any additional data containers must be kept in memory. Unfortunately, their size is unpredictable, as they can contain virtually anything. In the vast majority of cases, package sizes between 1000 and 10000 should work fine.
