How to Deal with Landscape Data Created during System Copy
Introduction
System copy is a function of software provisioning manager and is often used to create Test and QA systems (homogeneous system copy) but also to migrate productive systems to other platforms (heterogeneous system copy – change of OS or DB) – see System Copy and Migration @ the SCN. In any
case, you will get a new technical system with a new SID, while you may keep or delete the original system.
Figure 1: Homogenous and heterogeneous system copy
For both scenarios – homogenous and heterogeneous system copy – basically the same actions in the SLD apply.
These are described in the following.
System Copy Types and Required Actions in Landscape Data Management
Changes in the landscape in most cases require actions in the SLD to keep the Landscape Descriptions up-to-date. Here is a description of various scenarios.
Using the same SLD for the Copy as Used for the Original System:
- The connection to the SLD is copied with the system – after the run of the corresponding Data Supplier, the new technical systems will be available in the SLD
- For the original system you have to decide, whether to keep it or delete it (this is not done automatically – see How-to Manage House-Cleaning in the System Landscape Directory – Duplicate System Entries)
You should check this data – see SAP Note 1842956 – Check Data Supplier Completeness for Technical System
Using a Different SLD
- Re-configure the Data Supplier of the copied system to another SLD system; see SAP Note 1842956
- For the original system, decide, whether you need it still in the (original) SLD or not
- If needed, configure the SLD for reading access in the copied system
Copying a System Running an SLD
- Decide, if the new SLD (being part of SAP NetWeaver AS Java) is needed:
- If not, stop the server SLD
- If you want to use the new SLD, take care of the Data Suppliers of registering systems
Note: If a virtual IP address is
used, you can assign this to the new SLD if the original SLD is no longer used
– see SLD Recommendation – Reasons to Use a Virtual IP Address for SLD Access
Copying an SAP Solution Manager System Running an SLD
Note, that the SLD running on SAP Solution Manager in most cases shall not act as the central SLD in your landscape (also see Planning Guide – System Landscape Directory). Nevertheless, if you are using this SLD, keep in mind, that data supplier settings may require changes (also see SLD Recommendation – Reasons to Use a Virtual IP Address for SLD Access) while the object server name of the SLD will require changes.
For this scenario, see SAP Notes:
- 1797014 – System copy of a Solution Manager with a filled LMDB
- 935245 – Importance of SLD/LMDB “Object Server” parameter
Further Information
- The System Copy Guide is available in SAP Service Marketplace at: http://service.sap.com/sltoolset> Software Logistics Toolset 1.0 > Documentation > System Provisioning > System Copy: Systems based on SAP NetWeaver <release>
- Further information on landscape data handling is available Landscape Descriptions
.
.
Hello Wolf Hengevoss,
First of all thank you for excellent posts.
What would be your recommendation in the following situation?
Solman is copied with change of it’s SID, let’s say to SM1, from original system, let’s say SM0, and this new solman SM1 is now used as the productive system.
SLD data is also copied from the original system SM0. The parameter object server was not changed and has value sm0_objectserver. Is it safe now to change this value to sm1_objectserver as we shall continue to utilize old original data? Or it is better to leave this parameter with original value.
The original system SM0 is still used for some purposes in lanscape but is not connected with SM1.
Thank you in advance for reply
Regards,
Abay
Dear Abay,
thanks a lot for your kind feedback! As for your question – Note1797014 – System copy of a Solution Manager with a filled LMDB (https://launchpad.support.sap.com/#/notes/1797014) should provide the required answers. Please take into account if you copied the SLD also (e.g. because it was the one of the SAP Solution Manager Java stack) or kept the existing one.
I hope that helps!
Best Regards,
Wolf Hengevoss
SAP SE