Introduction
In this blog post we will discuss about the table "DMC_FM_RESTART". We will discuss about what is this table? Why this table is useful during and after the initial load of data to the target Central Finance (CFIN) System.
We will also discuss the problem if this table is not handled properly.
Background
We know that apart from FI Initial loads (which happen directly between target CFIN system and source), load for other tables (Cost Object, Secondary Cost, AVL, etc) happen via SLT .
DMC_FM_RESTART is a transparent table in the SLT system which has assignment IDs to sender objects for restart handling.
This table is used for tracking purposes during the initial load only. This table is not used for tracking records during real-time replication.
Simply speaking, this table keeps metadata of all the records that are loaded in the target CFIN system.
Let's take an example of the cost object table for a particular mass transfer ID. Tcode SE16 will give us the number of records loaded for AUFK in the target CFIN system.
Why is DMC_FM_RESTART useful?
If there is an unplanned outage of source, target or SLT during the initial load then this table helps to resume the load once the systems are up again. Otherwise, we have to restart the loads from scratch which can be a lot of time lost for big tables like secondary cost table, etc.
While the initial load is running, this table keep the metadata of records that are already loaded in the target CFIN system.
Let's say we have a very large table which have 200 million records in the source system and all the 200 million records need to be moved to the target. Out of 200 million , 100 million already moved to the target and suddenly some unplanned outage of SLT happens. When the system is up again then loading will resume from 100 million onwards. We do not need to load the table from scratch as SLT will know (from the metadata present on the table "DMC_FM_RESTART") that 100 million records are already there in the target.
Hours would be lost if the records are not maintained in the DMC_FM_RESTART.
Caution
Due to business requirements, especially in non-production scenarios, we may need to reload a particular table. The following sequence of steps are needed in this case:
- Clear already loaded data for that table from the target CFIN system - CFIN technical Team
- Fix the configuration or master data issues, etc - CFIN technical Team or the master data team
- Clear the data for that specific MT_ID and table from the SLT table "DMC_FM_RESTART" - SLT consultant
- Re-load the table again - SLT consultant
If step 3 is missed by the SLT consultant then the load would take the same time (let's say 20 hours for 200 million records) but nothing would be actually load to the target CFIN system. This is because the metadata present in DMC_FM_RESTART will make SLT system assume that the records are already there in the target CFIN system. The worst part is SLT won't even throw some error (I hope we have a fix for this from SAP in future). So, in the above example there will be a loss of 20 hours. Imagine your client knowing about this :).
Conclusion
DMC_FM_RESTART table is your best friend for resuming loads in case of unplanned outages. But, the same table can be your foe in case of table re-loads if you miss to delete the metadata before doing the initial load again.
Feel free to reach out to me on Abhishek Singh | LinkedIn.
Supporting documentation and information :
SAP Landscape Transformation Replication Server | SAP Help Portal
2942582 - What is the DMC_FM_RESTART table used for? - SLT | SAP Knowledge Base Article
I hope this blog post will help you to understand more about the value of table "DMC_FM_RESTART" . Thank you for spending time reading it. Please do provide your valuable feedbacks and if you have any questions, please contact me.
Please follow me on the forum for more SLT-cFIN related contents
Please follow this space for related contents: SAP Landscape Transformation replication server | SAP | SAP Blogs
- SAP Managed Tags:
