Skip to end of metadata
Go to start of metadata

Purpose

This document provides different scenarios that may cause Update Requests remaining on transaction SM13 in status ‘Initial‘.

Overview

Status ‘Initial‘ means: “The update request has been created but has not been fully processed. (This status applies from the moment the dialog work process passes the update request to the update work process up to the COMMIT in the update work process)“ 

Further details of the update request are shown with a double clik (or via menu  Goto > Update module). There, we can see that involved FMs (they can be type V1 or type V2) are also in status ‘Initial‘. This means that none of them have yet been processed.

Header information of the request (Goto > update Header) shows: 

  • Update Server: application server were the update record should be processed (involving UPD & UP2 work processes).
  • UD Client: application server where the DIA request was executed.


A new functionality has been implemented to alleviate the issue of remaining update tasks in status INIT in transaction SM13.
See Note 2802241 - UPD: Update requests in status INIT in SM13

Where to check information?

This image shows flow of information. Communication is stablished between involved application servers (UPD Client & UPD Server) through Dispatcher -> Message Server -> Dispatcher.

Relevant information can be found on:

  • SystemLog entries (transaction SM21) at update request timestamp.
  • Message Server trace file (dev_ms) at around relevant timestamp.
  • Dispatchers trace files (dev_disp) on both involved application servers at around relevant timestamp.
  • Status of UPD work processes (transaction SM50) on Update Server.
  • UPD work processes trace file (dev_wX) on Update Server.
  • Load on both application servers.

Possible reasons  

Overflow of the UPD or UPD2 Dispatcher Queue on Update Server (7.2x)

 System Log will show error: 

Error adding a request to the dispatcher queue ( UPD)       
Request (type UPD) cannot be processed  

Dispatcher trace file shows following:  

*** ERROR => DpRqIPutIntoQ: OverFlow (type 6, max: 2001, prio LOW) [dpxxqueu.c   622]
***LOG Q0H=> DpRqPutIntoQueue, DpRqIPutIntoQ ( UPD) [dpxxtool2.c  3981]
***LOG Q0G=> DpRqBadHandle, bad_req ( UPD) [dpxxdisp.c  5263]
***ERROR=>BAD REQUEST – Reason:DpRqPutIntoQueue failed

This can be confirmed on transaction SM51 -if server has not been restarted- by  selecting application server: Goto  > Server Name > Information > Queue Information  

Dispatcher queue reached value ‘rdisp/elem_per_queue‘, which defines the number of requests of each WP type Dispatcher can handle, not only for UPD or UPD2 processes.

 >> UPD and UPD2 load needs to be correctly distributed among different application servers to avoid this overload problems. The situation could be an isolated event or an incident due to the execution a job/program that needs many UPD or UPD2 work processes.  

Disconnection to Message Server on one of the Dispatchers

Dispatcher trace from UPD server or UPD client application server will show disconnection to Message Server:

*** ERROR => MsINiRead: NiBufReceive failed (NIECONN_BROKEN) [msxxi.c      2848]
****************************************************************************
*  LOCATION    SAP-Dispatcher <server>_<SID>_<nr> on host <hostname>
*  ERROR       Reading data from the message server (<mshost>/ <msport>) failed.
*                     Please check the trace file of the message server.
*
*  TIME               xxxxxx
*  RELEASE         xxx
*  COMPONENT   MS (message handling interface, multithreaded)
*  MODULE      /bas/7xx_REL/src/krn/ms/msxxi.c
*****************************************************************************
*** ERROR => MsIReadFromHdl: MsINiRead (rc=NIECONN_BROKEN) [msxxi.c      2236]
MBUF state OFF
DpMBufTypeMod: MBUF component DOWN (event=MBUF_DPEVT_DOWN)
DpMsServerDown: wakeup waiting sessions
*** ERROR => DpMsgProcess: MsReceive () -> MSENILAYER, partner:                      [dpMessageSer 255]
*** ERROR => DpMsgProcess: disconnect from msg_server [dpMessageSer 338]

>> Ensure network stability between different application servers.  

Extended Memory exhausted  on one of involved application servers (7.4x)

If Extended Memory on UPD Client or UPD Server is exhausted, updates may stay in ‘Init’ status. Work process trace file (dev_wx) will show:

Y  *** ERROR => dyInitSpa: EmAlloc failed [dyimode.c    2554]  
Y  {root-id=901B0E0B00C41EE781B0B5C240D9A454}_{conn-  id=00000000000000000000000000000000}_0   
EM Dump

Extended Memory consumption on each application server can be checked on transaction ST02; if MaxUse reaches In Mem value, Extended Memory was exhausted:   You may also find many LOAD_NO_ROLL dumps on ST22 transaction, pointing to same shortage on Extended Memory resources.

>> Adjust Extended Memory size, based on application server needs.

Extended Global (EG) exhausted on UPD server (7.4x)

Extended Global area is a memory pool located in the Extended Memory. This area is reserved for globla data, that is user-independent. The amount of data involved in this area is smaller, a percentage from the whole Extended Memory pool.
UPD w ork process trace file (dev_wx) will show:

X  *** ERROR => EgAlloc: MmxMalloc failed (9) to allocate 1048576 bytes. [egxx.c       627]
X  {root-id=525400DB31461ED8809A946A5FC739D2}_{conn-id=00000000000000000000000000000000}_0
X  *** ERROR => EgAlloc: out of memory, check em/global_area_MB and eg_oom_mm.dump file for memory allocations. [egxx.c       628]

With SAP NetWeaver 7.4x the extended global area (EG) configuration has changed, as the table buffer has been moved into EG (which is a part of EM).  

>> Adjust Extended Global memory.    

Shortage on Page file (Windows environment)

    UPD work process trace file (dev_wx) from update server will show: 

X *** ERROR => <EsNT> error: [esnti.c 2926]MapViewOfFileEx(27c,34,0,1275068416,4194304,000007DE99A00000) returned 0000000000000000
(lastError = 1455) [esnti.c 3541]
X {root-id=FA163E4942951ED8819C4454E325842F}_{conn-id=00000000000000000000000000000000}_0
X *** ERROR => <EsNT> MapViewOfFileEx size=4194304 ptr=000007DE99A00000 HighPart=0 LowPart=1275068416 MapHandle=000000000000027C error=1455 [esnti.c 2939]
Y *** ERROR => dyInitSpa: EmAlloc failed [dyimode.c 2703]
M ***LOG R1U=> Error in EmAlloc& [dyimode.c 2709]

This only occurs on Windows operating system platform.
Mapping the block via MapViewOfFile is failed due to no more page file available.

>> Adjust page file based on memory requirements.

 

 

  • No labels