Purpose
The purpose of this page is to present some parameters to help tuning and improving the performance and efficiency when dealing with Archiving and Deletion procedures.
Overview
For several performance issues, we may face some cases where the Archiving and/or Deletion procedures are not running properly, e.g. consuming too much time or not running in a better configured way.
In such cases, the archiving or deletion of XML messages do not work as intended and so the messages keep accumulating faster and storing more size in DB level each time.
To discuss about that and also set tuning parameters to improve those procedures this page is created.
Common Parameters
Going to transaction SXMB_ADM, then clicking on “Integration Engine Configuration” and “Configuration” button, you can set a list of determined parameters.
Starting with the Archiving procedure, we have 2 parameters that may be considered:
- ROWS_PER_LOOP: will consider the number that was set in order to handle the messages to be archived. For small messages, a higher value can be set; for big messages, it’s recommended to decrease this value for the purpose of handling those messages in small batches to avoid the archiving jog to get stuck, for example, due to “EXPORT_TOO_MUCH_DATA” dumps.
- ARCHIVE_PARALLEL: you can create sections for parallel on Archiving procedure, for example, handle with 100 messages in each of those sessions. You can configure up to 100 sections (00 to 99). For your information, going to transaction SE38 -> RSXMB_ARCHIVE_MESSAGES report, you have the option of changing the range for random messages to be archived. But pleae notice that the report RSXMB_ARCHIVE_MESSAGES should be done by SAP only; it's recommended in very rare cases as in general we should use SXMB_ADMIN > Administration -> Schedule Archiving Job.
Besides that, the retention period is also something that counts a lot concerning the performance of the system. If you have set a high value, depending on how big is your landscape and how many messages you have flowing through PI, it’s recommended to set here a low value in order to archive and delete the messages more often.
The retention period can be for ASYNC and SYNC messages, and its unit can be measured in seconds, minutes, hours and days with the following parameters:
-
- PERSIST_DURATION (ASYNC as subparameter)
- PERSIST_DURATION (SYNC as subparameter)
- PERSIST_DURATION_UNIT (ASYNC as subparameter)
The same applies for both ARCHIVE and DELETION categories.
Besides that, we have also the HISTORY subparameter, which uses the same above parameters for retention period. Even though it’s not being a critical table to handle (SXMSPHIST), as its data is small in size, it’s important to maintain a reasonable value as the data can be too much depending on how many messages you have processed in total.
As it was mentioned that SYNC messages can also be maintained with the retention period parameters, it’s important to check if the LOGGING_SYNC is set to “1” beforehand. To disable the storage of the SYNC messages, set it to “0”. This parameter is highly considered when dealing with performance issues as maintain SYNC messages in the system is not set by default and also highly affects the performance on the system, since it can store an extra mass number of messages. Hence, check if it’s really necessary before setting it up.
Tuning parameters
Concerning tuning parameters, we may consider the following ones:
-
- EO_INBOUND_PARALLEL: For inbound queues
- EO_OUTBOUND_PARALLEL: For outbound queues
Both parameters above will process up to the set value in parallel in order to speed up the message processing. You have the option of setting additional parameters like those using subparameter setting a specific pipeline or interface you’d like to specify for an exceptional usage.
Continuing with the tuning, we also have the parameter EO_MSG_SIZE_LIMIT. It’s used since inbound and outbound queues are processed for large messages in parallel, two messages may be loaded simultaneously into the memory of the Integration Server. The prefix of the outbound queues is XBTM.
Another relevant tuning parameter is the EO_MSG_SIZE_LIMIT_PARALLEL. This parameter refers to the EO_MSG_SIZE_LIMIT explained above. With this one, you can further improve the way the memory loaded, by processing large messages (that exceeds the value set in EO_MSG_SIZE_LIMIT) in parallel. The value you set determines the level of parallelization.
Common Reports
- RSXMB_DEL_CLUST_TABLE: This is a check report developed to identify / correct inconsistencies in XI 2.0. Later it was adapted to XI3.0 (and above), however, the inconsistency did not re-occur. Please bear in mind it is not a deletion report, even though the name suggests.
- RSXMB_DEL_ERR_VERSIONS: It identifies and eliminates error versions from a message which is not required anymore. As the total number of versions decreases, the archiving session requires less memory. Unnecessary error versions mainly occur in XI3.0. As of PI7.0 version handling was improved, hence this report will most-likely be unable to identify such error versions.
- RSXMB_DEL_TO_ARCH: This report enables the option to change the interface action from “deletion” to “archiving” belatedly.
- RSXMB_SWITCH_ARCHIVE_VERSIONS: Which this report you can decide whether the first version of message or all of its versions shall be archived. Very tricky to handle issues concerning big files that cannot be archived or errors during archiving phase.
Updating statistics for DB tables
Sometimes we can find a situation where messages got stuck or are even throwing some errors just like TIME_OUT dumps, for example.
In order to address some of these cases, it’s interesting to handle with the updating of the statistics for the DB tables, taking into account the related DB vendor (Oracle, IBM, …).
For MS SQL and MaxDB, we don’t need to worry about it as the database does it for you. However that’s not the case when we speak about Oracle and IBM vendors.
For those, we have some notes to deal with this situation. They are:
- Note 1020260 - Delivery of Oracle statistics: For Oracle DB. By applying SAP Note 1020260 hard-coded statistics are set for a few critical tables.
For these tables the automatic update is skipped. It's possible to check, for all other tables, whether the optimizer statistics are maintained by going to transaction DB14 and clicking on BRCONNECT. The “Update optimizer statistics” database operation should be running and updated, but it does not give us information if the note itself has been applied. For that purpose, we can go to transaction DB20, enter the name of the database table of PI persistence layer (for example, SXMSPMAST) and display the statistics (refresh button).
As we can see the current statistic is up-to-date green light and the active flag is not set to “I”, meaning this table is not ignored by the regular statistic run.
Once SAP Note 1020260 has been applied the status line changes to “Statistics ignored” (or something similar) and the active flag is set to “I” such that this table is no longer handled by
the regular statistic update run.
- Note 1483627 - PI7.0x/7.1x: Table statistics during switch procedure: This is related to the DB2 and DB6 as well for IBM. These statistics are more related when you have configured the Switch Procedure. In case of performance issues with these, note 1425488 is recommended as it’ll deal with Volatile tables. You can check if that’s the case by going to transaction DB02 -> Space -> Single Table Analysis -> write down the table name under "Name" field. There you can check if the Volatile option is set on.
Prioritization of queues
Going to SXMB_ADM -> “Configure Sender/Receiver ID”, we have the option of configuring Message Sender/Receiver ID for queue prioritization. With that option we can set, for example, queues that handle messages with big size as top priority and queues that handle messages with small size with low priority. It can enhance the performance of the system by taking into account which queue is being processed with priority depending on how the queue is overloaded.
After you have set the Sender and Receiver that you’ll use for queue prioritization, you can go to “Configure Filter for Queue Prioritization”, in the same SXMB_ADM transaction.
There you’ll select which queue has priority by setting the queue prefix, e.g., XBTL, the operator, e.g., “>” or “<”, the desired value to be considered and the description for which purpose the condition has been created.
Generally it takes into account the queues XBT1... XBTI... XBT9... as Low… Normal… High priorities. In the qRFC monitor, the defaults are 30 - 60 - 120 seconds for each priority.
Related Content
Related Docs
Prioritized Message Processing
Related Notes
SAP note 817820: Queue for large messages in the Integration Server outbox
SAP note 872388: Troubleshooting Archiving and Deletion in PI
SAP note 894509: PI Performance Check
SAP note 1020260: Delivery of Oracle statistics
SAP note 1425488: DB6: Performance problems with volatile tables
SAP note 1483627: PI7.0x/7.1x: Table statistics during switch procedure