Showing results for 
Search instead for 
Did you mean: 

Master Data daemon and BW 7.3 / BWA 7.2

Active Participant
0 Kudos

Hi All,

Can anyone direct me to a document or explain how the new master data daemon works in the BW7.3/BWA7.2 environment?

As far as I can understand, the daemon job runs every three minutes (changeable global parameter) and reads the new SID entries from RSDDTREXNEWSID and updates the BWA SID indexes.

What happens to the job when the BWA system is not reachable/unavailable?

What happens to the job when all the BWA indexes are deleted?

Since this job handles all SIDs (both MD SIDs and associated NAV SIDs and the regular SIDs), how does it work in tandem with ACR?

How is the job scheduled for the first time? When BWA is installed or when the first indexing activity begin? Also does it need to run under a specific userid? Currently I see it is under my userid.

(I am still not used to the new forum interface and struggling to find a search box to search before posting these questions. Sorry)



Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi Jay,

Here is the OSS note 1640103 about the MD Daemon. I recommend you to change all scheduled jobs to be ran under a batch/system user id therefore when anybody is terminated, jobs will still run as scheduled.



Release 730/731 introduces the BWA master data daemon. This report is automatically scheduled when an InfoProvider is indexed for the first time. It is the task of the master data daemon to index new characteristic values for the BWA. This process runs asynchronously to roll up processes. Therefore, for the successful completion of a roll up, you must check whether there are new characteristic values for characteristics of the relevant InfoProvider that have not yet been indexed by the master data daemon. However, if the values are not in the BWA, the new movement data cannot be accessed because this may lead to data inconsistencies. For this reason, the roll up is not yet complete.
Depending on the system settings, the roll up process waits a specific length of time in which the system checks regularly whether the master data daemon has indexed the characteristic values.
The application log of the roll up process contains the following messages:

  • (RSDDB 371) "Data not indexed yet for characteristic <IO>".
  • (RSDDB 359) "Master data delta daemon job (ID <daemon_ID>) is running. Please wait..."

If the daemon is not finished in the specified time, the roll up process terminates with an error message:

  • (RSDDB 362) "New characteristic values have not been indexed yet"
  • (RSDDB 364) "Check the status of the master data delta daemon (ID: <job_ID>)"

You can now check why the master data daemon was not able to index the new characteristic values. On the one hand, you can check the corresponding job in transaction SM37. For this, you search for the job with a job count = <job_ID>.
Or you view the application log in transaction SLG1 with the object RSDDTREX, the subobject TAGGRFILL, and the external ID NEWMD_INDEX:<daemon_ID>).
In principle, there are two situations in which the daemon does not manage to index the characteristic values that are not considered errors:

  • The number of characteristic values is very large or there are different performance problems meaning that indexing takes longer than the roll up process wants to wait. In this case, you can modify the system settings. In transaction RSDDBIAMON, choose "BW Accelerator" -> "Index Settings" -> "Change Global Parameters" or execute the report "RSDDTREX_ADMIN_MAINTAIN". The "Index Process" tab page contains the parameters "WRITEINDEX" and "WAITTIME". You can raise the relevant values. However, this has the disadvantage that roll up processes may have to wait a very long time and use up system resources in doing so. To schedule the master data daemon regularly at short intervals, the number of characteristic values to be indexed should remain low. You can recognize this problem from the runtime of a daemon process being greater than WAITTIME*WRITEINDEX [seconds], which you can see from the application log based on the time stamp. In addition, there may be problems if the table RSDDTREXNEWSID has too many entries (that is, a large six-digit number). In this case, the causes for the table growth should be clarified.
  • The InfoObject <IO> is locked by a terminated change run, for example. The application log of the daemon process contains message RSENQ 063 "Attributes of characteristic <IO> are locked by terminated change run <CID>". If the InfoObject is locked, the daemon cannot index the new characteristic values. As a result, all dependent roll up processes cannot be successfully completed either. In this case, you must ensure that the change run <CID> runs successfully.

If you have solved the problem, you can restart the roll up process or the process chain. Of course, reindexing is not necessary.

Answers (1)

Answers (1)

0 Kudos

Take a look at this document.

What’s New with SAP NetWeaver BW 7.30 and BW Accelerator 7.20?

See section 7.6. Master data delta Daemon.