SAP system copy Job logic instead of customizing

Direkt zum Seiteninhalt
Job logic instead of customizing
Hybrid: for example, the source systems on-premises and the target systems on cloud
If the data stocks become obsolete, they can be updated by another system copy. From a technical point of view, such a refresh corresponds to the initial setup, including the associated costs as well as the load on the productive systems and manual rework. In addition, a refresh also interrupts all processes on the target system. If it is a development system, all newer development objects must be saved and transported back in after the copy. The version history is lost in the process.

Unicode conversion: A Unicode target system is built from a non-Unicode source system. Unicode conversion can only be performed using procedures based on R3load.
SAP system startup and shutdown, including virtual hosts
SAP recommends that you always update enterprise software in your production system using the SAP transport system and never make changes directly in the production system. In addition, SAP suggests that you validate change transports through a QA system that is approximately identical to the production system and has up-to-date transaction data. Outdated data can affect the validity of change transport tests, which can lead to errors and failures in the production system. However, end-user transaction data is received only from the production system. Such data must therefore be passed regularly throughout the SAP transport chain to ensure that your non-production systems have up-to-date and valid transaction data. This can usually be accomplished by passing a system copy of the production system, created for updates, to the QA system. To reduce the number of test cycles, it is also advisable to update your development system occasionally.

So much information... how can you keep it so that you can find it again when you need it? Scribble Papers is a "note box" that makes this very easy.

While homogeneous SAP system copy expects identical combinations of operating/database systems on the source and target systems, there is also a requirement for different combinations of operating/database systems on the source and target systems in the project environment (eg, during migrations). This is referred to as a "heterogeneous SAP system copy". Technically, it is quite possible to build up a degree of automation here as well, but officially certified consultants ("migration consultants") are required to perform the heterogeneous system copy.

With "Shortcut for SAP Systems" any tables can be saved and restored. This is especially useful in the context of an SAP system copy - quite a few tables are system-specific and must exist unchanged in the system after a system copy.Shortcut for SAP Systems uses R3trans - a utility from SAP that is essentially used in the Transport Management System (TMS) environment. With "Shortcut for SAP Systems" it is now also available outside the TMS and enables completely new and diverse application possibilities. Among others in the environment of a system copy. R3trans works database independent. I.e. even in the case of a system refresh from an SAP system with an Oracle DB to a system with HANA, the backup and restore process works!

Procedure: - Identify the largest or longest running tables in the system that determine the total system copy time - Perform an initial copy of these tables at source system production time - Record the changes to these tables - Copy the delta using RFC, at source system production time - Use the standard procedure to copy all non-IMIG tables (downtime).

To eliminate downtime in the production system and minimize the impact on application performance-regardless of the size of the production data reconciliation-you can use, for example, HP StorageWorks System Copy for SAP (HP System Copy), which has a disk array-based replication capability.
SAP Corner
Zurück zum Seiteninhalt