Automatic determination of delta states after SAP system copy/recovery
Key solution steps
To meet ever-changing business requirements, a production system must be continuously developed and adapted after the initial installation. To do this, you need development, consolidation, and quality assurance (QA) systems that can provide the appropriate updates to the production system as SAP transports.
Normally, therefore, the target system is created using a copy of the production system. The advantages here are: After the initial setup, data is already available, and users receive a completely identical test environment. However, the disadvantages of this procedure are the high memory requirements, the lack of anonymization of the data and the long runtime of the copy process.
Critical factor: Availability
Table splitting requires 2 tools: R3ta, which determines the WHERE conditions used to access subsets of a table. TableSplitter, which splits the WHERE-conditions determined by R3ta into packages with one or more subsets.
When executing a system copy, all tables, processes, databases, etc. are taken into account when copying. Logical system names must also be converted (using the BDLS trasaction code). The process of a system copy usually does not change. If no structural changes have been made to the SAP systems involved, the process is even 100% identical. Due to the very high repeatability of the nevertheless complex process, it is advisable to automate it to a large extent.
For some time now, SAP customers have been supported in system copying by very powerful automation tools that can be used as needed, such as "Shortcut for SAP Systems". Nothing has to be installed in your SAP systems for this - no transport requests, no AddOns!
Advantages: - Downtime is reduced to an acceptable value - Since only 5-10% of the data is copied at downtime, much less optimization and testing effort is required to achieve the given downtime window.
Regardless of the storage size, this process takes only a few seconds.