Switch Deletion Procedure in SAP XI


In a normal deletion procedure, when a message is eligible for deletion, it is deleted from the table with SQL delete statements. There will be a lot of deletion statements running on the table which also has inserts going on as new messages are processed. In order to make deletion faster, switch deletion was introduced. This procedure means that 2 set of tables are used in XI. At any time one set is used for storing the XI messages. When message pass the retention time, they are marked as logically deleted, but not really deleted from the table yet. As the messages keep accumulating, the fill level of the persistence layer crosses the threshold defined by DROP_MAX_TABLE_LOAD. When this threshold is crossed, the inactive set is activated and all the messages that are within retention time are copied into the active set of tables. The messages marked as logically deleted remain in the old set of tables. These tables are then truncated. This way, the messages are deleted in a single shot.

Now the problematic aspect of this procedure lies with the copying of messages that are still within retention period. Let's take an example scenario to explain this problem.

Let us say that the XI system processed approximately 250,000 messages every day. Let's assume that DROP_MAX_TABLE_LOAD is set to 90% (765,000 messages), the retetion period for messages is 3 days and there are no old messages in the system. Here is how it would look when you run the delete job every day at the end of the day.

Day 1:
250,000 messages processed. 250,000 messages within retention period.
Day 2:
250,000 messages processed. 500,000 messages within retention period.
Day 3:
250,000 messages processed. 750,000 messages within retention period.
Day 4:
250,000 messages processed. 750,000 messages within retention period. 250,000 messages logically deleted.

We now have 1,000,000 messages (750K within retention and 250K eligible for deletion) in XI. As 765,000 messages mark is crossed, the switch to new set of tables happens. 750K messages are copied to the new tables and 250K old messages remain in the old tables. The old tables are truncated, deleting the 250K old messages.

Day 5:
250,000 messages processed. 750,000 messages within retention period. 250,000 messages logically deleted.
Again 750K messages are copied to the new tables and 250K old messages remain in the old tables, which are truncated.

From Day 4 onward, the XI system copies 750K messages, which means a big number of messages are copied every day to delete 250K messages.

To prevent this problem, the retention time should be reduced or give up using switch deletion procedure and stick to simple deletion prcedure. You can increase DROP_MAX_TABLE_LOAD so that the swich happens approximately once in say 7 days, but then you are maintaining a high number of messages in XI, which again has performance implications.

Switch deletion procedure works great when 100K messages are processed for the same retention and DROP_MAX_TABLE_LOAD. Therefore work out message flow and retetion times before you choose to use switch deletion procedure.

Comments

Post a Comment

Popular posts from this blog

OS/DB Migration - CMD. STR, TOC, EXT, R3load, DDLDBS.TPL and more

Image
With increasing need to improve performance or reduce costs or vanishing support for operating systems/databases it becomes inevitable to migrate to a better OS or DB. We feel take a quick look at the primary ingredients of the tools for OS/DB migration handled by R3SETUP. Tools - R3load, R3ldctl and R3szchk R3ldctl creates STRucture files, TemPLate files by reading the technical settings for table/indexes in SAP data dictionary. R3szchk calculates the database size object sizes (EXTent files) for the target system based on the STR files created by R3ldctl. The EXT and STR files can be later split into smaller groups. The most crucial tool R3load is responsible for unloading and loading data from the database. R3load uses the files created by R3ldctl and R3szchk and dumps the data into compressed binary format as .001, .002 .. files. It uses cmd files to achieve the task. If the cmd files are not present, it creates on its own. Files Command files*.cmd  are creat...
Read more

Fixing Inconsistent Table - Table activation fails due to inconsistency between DD and DB

If you find a table to be available on the database, but not active in ABAP dictionary, try calling SE14 as DDIC user, enter the table name and choose Table > Reconstruct, Execute. If this method fails follow these steps: Call transaction code SE37 and execute the function module  DD_TABL_ACTM with single test On the next screen, do not change any other field except the following and set them as shown below: MODE: 12 NTAB_PUTSTATE: N TABNAME: <enter the correct table name> Click on Execute The export parameter ACT_RESULT should show 0. To verify if the inconsistency is fixed, call transaction SE14 > Extras > Database Object > Check and  SE14 > Extras > Runtime object > Check.
Read more

301 Redirect Using SAP Web Dispatcher

301 redirects are typically used to redirect accesses that include www to non-www or vice-versa. Example, when you call http://blogger.com, the call is redirected to www.blogger.com. An end-user may prefer to call a URL in any manner. You must ensure that all these calls are redirected to relevant URLs with content. SAP web dispatcher can be configured to send a redirect (301) to the client. To enable redirection add icm/HTTP/redirect_<xx> to the web dispatcher's profile file. The parameter uses the following syntax: icm/HTTP/redirect_<xx> = PREFIX=<URL prefix>[, FROM=<pattern for URL>, FROMPROT=<incoming protocol>, FOR=<pattern for host name:port>,TO=<new URL prefix>, PROT=<protocol>, HOST=<host>, PORT=<port number/name>] Let's say you want to redirect all the HTTP requests on mysource.com on 80 port to mytarget.com on HTTPS 443 port icm/HTTP/redirect_0 = PREFIX=/, FROM=*, FROMPROT=http, FOR=mysource.com:80,...
Read more