After the program has been set running, note this should be in background, it can be immediately monitored. In another session, you are able to go to the transaction /N/BTR/MINICUBE check the date and user are correct for the run you are searching for.

After starting the run with parallel interval generation (as recommended) two programs will be seen /BTR/MDR_PP_FBDLS_IVLGEN which deals with the interval generation and /BTR/MDR_PP_FBDLS_MULTI which deals with the update phase.
To get more options available through the Minicube screen press the Diffuser Mode button , for further information on running, monitoring and administering Diffuser programs, please refer to the Diffuser Administrators Guide. With the Diffuser Enabled the number of jobs working on the run can be viewed and it is possible to increase (or decrease) the number of parallel jobs being run by selecting the “left” and “right” arrows appropriately, or even pause and restart the run if required. By selecting the instance and then choosing “Intervals” which intervals have currently been processed can be viewed, which are currently in progress and those that are yet to be started. Select the “Refresh” button to refresh where the intervals are currently.

The image below shows both the programs /BTR/MDR_PP_FBDLS_IVLGEN which deals with the interval generation and /BTR/MDR_PP_FBDLS_MULTI which deals with the update phase. We can see the /BTR/MDR_PP_FBDLS_IVLGEN is working thought he list of all tables and the update program /BTR/MDR_PP_FBDLS_MULTI has a status of ‘Generating intervals’ it is waiting on the program /BTR/MDR_PP_FBDLS_IVLGEN to complete. Expanding the intervals for the /BTR/MDR_PP_FBDLS_IVLGEN shows each table that has to be processed and the status, note that larger tables can take much longer than ver small tables. Therefore the estimate of time remaining for the /BTR/MDR_PP_FBDLS_IVLGEN is less accurate.

In the image below the interval generation is complete and now the update program /BTR/MDR_PP_FBDLS_MULTI is in process you can see the intervals being processed. Note that tables with the prefix S like Interval 7 SBDSER representing table BDSER means the table only has one interval as the size of the table fell below the commit size, whereas tables with a prefix N like Interval 10 NVBAP representing table VBAP means the table has more than one interval as the table is above the commit size.

It is recommended that during the run, sometime is spent monitoring through transaction SM66, to find the optimum number of processors, this needs to be done after the interval generation has completed an the update run (with program /BTR/MDR_PP_FBDLS_MULTI ) is processing. If the commit times there are under 100 seconds then increasing 5 processors and then monitoring again is a good option. If the runtimes rise over 100 seconds it is advisable to reduce the number of processors. Checking the database load may also give another indication on the optimum number of processors, using more processors can be counter productive. When using high numbers of background processors there are occasions when the database can start to raise deadlocks, in this case check the memory and CPU of the database server if this can be raised this can help deal with the bottleneck.


Was this helpful?

Yes No
You indicated this topic was not helpful to you ...
Could you please leave a comment telling us why? Thank you!
Thanks for your feedback.

Post your comment on this topic.

Post Comment