Skip to Content
-1

New SAP system build - System copy method

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

Add a comment
10|10000 characters needed characters exceeded

Related questions

2 Answers

  • Posted on Aug 22, 2019 at 03:17 PM

    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/

    Add a comment
    10|10000 characters needed characters exceeded

  • Posted on Oct 15, 2019 at 10:10 AM

    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

    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.