Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 


The archiving on Integration Engine always consists of two steps. First the message is written to an archive file (ARV_BC_XMB_WRP*) and afterwards the messages will be deleted (ARV_BC_XMB_DEL*).

- ARV_BC_XMB_WRP<date> (archiving, step 1)

- ARV_BC_XMB_DEL<date> (archiving, step 2)

 

In some specific circumstances, for example there are two databases, master database and standby database. During the archiving procedure, everything keeps synchronous between these two DBs. The deletion process of archiving jobs is running so fast that may lead a large pressure to the buffer of the standby DB. Since the buffer size is limited, it is possible to cause the master database hanging. Therefore, you may be wondering how to slow down the deletion process  of archiving jobs on Integration Engine. The main idea is to reduce the number of deletion jobs that run in parallel and there are two options:

 

  • Ues Early Deletion


 

An archiving session is handled as a transactional unit, whenever an error occurs during write phase the entire session is considered invalid. As a consequence all message will be archived again by the very next session. Archiving files resulting from erroneous sessions will not be deleted. The idea here is that the deletion for the first archive data file takes place while the second file is being written.


By allowing early deletion, transactional handling applies to a single archive file rather than the entire session. If an error occurs while writing archive file n, only this very file becomes invalid. All previously written files 1..n-1 remain valid.

To allow early deletion, please run transaction AOBJ, double-click archiving object BC_XMB, de-select option "Do Not Start Before End of Write Phase". In case a popup appears when saving the change asking for a package name, please enter "SXMSPERSIST".

 




  • Use Job Server Group


 

The number of parallel write processes (ARV_BC_XMB_WRP*) is fully controlled by the application, for example, PI system. Parameter ARCHIVE_PARALLEL controls the number of archiving jobs that are simultaneously generated during archiving. This parameter can be found in transaction SXMB_ADMIN -> Integration Engine Configuration -> Configuration -> Category ARCHIVE.



 

However, in contrast the deletion processes are controlled either by ADK (Archive Development Kit) or by the user - depending on the setting in transaction AOBJ -> BC_XMB -> Customizing Settings -> Settings for Delete Program -> Delete Jobs. In case option "Start Automatically" is selected for the Delete jobs, ADK will trigger a deletion job (ARV_BC_XMB_DEL*) for each archiving file. For example, 1 write process creates 50 archiving files there will be 50 deletion jobs fired up by ADK. Here the system will run as many batch jobs in parallel as possible, ie. if n batch processes are available all of them will be used such that one will see n parallel deletion processes.



Here you can specify on which application server or servers the archiving jobs (write, delete, read, etc.) are to run in the background, independently of the archiving object. The system distributed the archiving jobs across the application servers of the server group. If no server group exists yet, it can be created using transaction SM61 as per the following steps:

 

1) Run transaction SM61 (Display control object list)

2) Click on "Job-Servergruppen" button

3) Click on Group (Create a group), and create a name for this group

4) Select the group you have just created and click on Assignment button

5) Here you can select the InstanceName (select the one where you would like to run archiving jobs)

 

Then you can specify this job server group via Archive Administration (transaction SARA -> Customizing -> Cross-Archiving Object Customizing -> Technical Setting -> Server Group for Background Processing). Then it will be used for all kinds of archiving jobs.




The idea here is to take control in the number of background processes that are available fordeletion of archived messages. For example, there are multiple application servers, so it would be an option to pick up one dedicated application server and to configure this server such that it provides 1 background only. This approach guarantees that the deletion is done one-by-one.

 

****Please note that this is a general setting for all archiving jobs and this is also a cross-archiving objects setting, that is, other archiving objects will adhere to this setting as well. Furthermore, there is a slight chance that this particular application server executes some other batch job. Then the archiving jobs including the deletion process will queue up.****

 

Related Notes:

SAP Note 872388 - Troubleshooting archiving and deletion in PI

SAP Note 1987072 - How to Define a Server Group for Archiving

SAP KBA 2269004 - How to reduce the number of parallel archiving jobs on Integration Engine