New SAP system build - System copy method

[prav_mishra]

Hi All,

We are planning to install the SAP system with the export image as a source system .

First we export the data to create the export image from source via SWPM and using the SWPM again on target system to install SAP with the export image as source.

We are looking for pre-requeste to perform this task and to clarify whether the separate SAP installation is required for this method. We are using same version and same SID on source and target system.

Please help me on this.

Thanks and Regards,

Sathish Kumar.S

Mob: +91 9677273457

[BJarkowski]

Have you tried to find the answer on your own? There is so much content available.

I don't think anyone will give you exact prerequisite, as it may differ depending on the system export method and the release of your system. But please start the investigation here:

https://wiki.scn.sap.com/wiki/display/SL/System+Copy+Guides

You can also have a look at one of the available blogs:

https://blogs.sap.com/2017/11/02/sap-hana-system-copy-homogeneous-on-multi-tenant-database/

https://blogs.sap.com/2013/04/16/system-copy-backuprestore-method/

[former_member612175]

Hi Sathish,

Finish off with the base build of the target system to reduce the downtime window. you can simply install a vanilla SAP NW system with the desired SAP Kernel and DB versions. Anyways with the migration, the vanilla SAP NW system will be overwritten by the data you bring in with the migration.

Below are the rough steps that you can follow and tune to speed up the entire migration activity.

1. Pre-requisites

• you can capture the current active objects in the source and record it in a list (REPLIST) so that when you finish off the migration and run SGEN on the target, it finishes early.
• Run the stats job manually at the source with a maximum number of parallel processes (max 32).
• Identify the transparent & Cluster tables for table splitting
• Update the R3* components on the source before starting the SAPINST
• Start export preparation on source database (DBSIZE.XML)

2. Downtime

• Deletion of QCM* tables on source
• Start Table Splitting of transparent tables on the source database
• User locking & putting released jobs to schedule
• SMIGR_CREATE_DDL report execution on the source
• Start DB Instance Export on the source database
• DB Import Preperations on target

# you can use sorted / unsorted export and migmon to speed up the migration activity. Do bump-up the CPU on your source and target during the migration phase to speed up the whole scenario

3. Post-processing

• cross-check the kernel and db patches on the target.
• Reinitialization of the DDLOG sequence on target.
• Permanent License with the new hardware key
• SGEN -- using the REPLIST so prepared in step 1 of the pre-requisite
• create statistics on the DB
• finish off the other regular post-processing activities
• take golden backups

It sounds elaborate but if you get a kick off the flow OSDB migrations are simple and fun.

Regards

Prateek