UPD: Update requests in status INIT in SM13

标签：status UPD Update update INIT FREQUENCY watchdog rdisp

2802241 - UPD: Update requests in status INIT in SM13

前记

Symptom

In SM13 update requests in status INIT can be seen forever. They don't get processed, which leads to various follow up symptoms. The most prominent ones are the following two:

• remaining SAP enqueue locks which in turn might block other users
• inconsistencies due to missing data in application tables

Mind that this COULD be a regular status though! For the time, the update request is processed in an UPD work process, the status is still INIT(IAL). There is no RUN or RUNNING status. So make sure, that the update request is indeed not currently processed.

Other Terms

KERNELCOR SM13 INIT INITIAL WATCHDOG rdisp/update_watchdog

Reason and Prerequisites

The usual way how an update is processed in short is:

1. If the save button is pressed in your application, an entry in the VBHDR table is written on the database and from there on the update task can be seen in transaction SM13.
2. At the same time, a trigger request is sent by the kernel and is transmitted via the
1. local dispatcher to the
2. message server, onwards to a
3. remote dispatcher (another instance of the same system providing update service and from there on eventually to an 
4. update work process.
3. In the update work process a session needs to be initialized, that reads the VBHDR entry and triggers the processing of the function modules listed in the update request.

Mind, that the ABAP code executed in an update task is still application code! Any problems here are in the responsibility of the application!

Common issues are

• connectivity issues between client/remote dispatcher and message server. This leads to a loss of the asynchronous trigger request.
• resource issues during the initialization of the user session in the update work process.
• Database issues.

All 3 lead to "untouched" update requests which consequently remain in SM13.

Solution

A new functionality is implemented to alleviate the issue of remaining update tasks in status INIT in transaction SM13.

On each instance a cyclic program checks whether there are

• update tasks in status INIT  
• older than a certain time limit
• with target server on same instance.

If yes, the update task will be triggered again. The algorithm guarantees no double execution of the same update task!

This new feature will be available as of kernel release 753 for technical reasons only.

In kernel release 753 the new feature is INACTIVE per default through parameter setting:

• (753)     ^{rdisp/update_watchdog = FREQUENCY=0h, PROCESSING_DELAY_FOR_START=1h}

Activation of the new feature:

1. Please apply the necessary kernel patch
2. check that parameter parameter rdisp/update_watchdog = FREQUENCY=1h, PROCESSING_DELAY_FOR_START=1h is set

Both steps are obligatory!

In kernel release 773 and 777  the new feature is ACTIVE per default through parameter setting::

• (773 and 777)    ^{rdisp/update_watchdog = FREQUENCY=1h, PROCESSING_DELAY_FOR_START=1h}

In kernel release 781 AND ONWARDS there are

1. separate update watchdogs for V1 and V2 processing
2. additional functions to automatically administer the update processing which are done only during instance startup so far.
3. there is only ONE watchdog running per system (not per instance).

The the parameters relevant for these releases are:

rdisp/vb_watchdog/cleanup	FREQUENCY=24H	additional check for update request older then rdisp/vbdelete
rdisp/vb_watchdog/status_check	FREQUENCY=1H	additional check whether update in total is deactivated
rdisp/vb_watchdog/v1	FREQUENCY=1h, PROCESSING_DELAY_FOR_START=1h	like in 773
rdisp/vb_watchdog/v2	FREQUENCY=0	this NEW parameter checks for hanging updates in status V2

ALL RELEASES:

The default values shouldn't be changed without reason!

The subparameter FREQUENCY determines how often the check is performed (the unit h relates to hour, m to minute).

The subparameter PROCESSING_DELAY_FOR_START determines how "old" an update request in status INIT must be at least, to be triggered again.

The Update Watchdog does not get activated if:

• the subparameter FREQUENCY is lower or equal to 0 (RZ11)
• there are no update processes configured (SM50)
• the instance is in status "passive" (SM51, column STATE)
• the Update Watchdog is already running (last FINISHED run via STAD, <HANDLE UPDATE_WATCHDOG>)

标签：status,UPD,Update,update,INIT,FREQUENCY,watchdog,rdisp
From： https://www.cnblogs.com/weikui/p/16740203.html