SAP DMO (Database Migration Option) of SUM

Introduction

SAP systems with their intricate architectures, play a crucial role in today’s businesses. To keep up with the evolving needs, regular upgrades and migrations are essential. However, these processes can be time-consuming, costly, and risky if not executed properly.

That’s precisely where SAP DMO of SUM (Database Migration Option of Software Update Manager) comes into play. This robust tool offers a streamlined, efficient, and cost-effective solution for SAP system upgrades and migrations. It empowers businesses to transition their SAP systems with minimal downtime, reduced risk of data loss, and simplified migration process.

In this article, we will explore the features, benefits, and step-by-step process flow of SAP DMO of SUM. We will also explore best practices to ensure your SAP system upgrades and migrations are not only successful but also efficient and hassle-free.

Concept

To migrate from any other database (referred to as “anyDB”) to SAP HANA, two primary approaches are recommended:

1) Classical Migration

Classical migration, also known as heterogenous system copy, involves the use of two primary tools: Software Provisioning Manager (SWPM) and the Software Update Manager (SUM). This approach is used when migrating from anyDB to SAP HANA, especially when the source and target databases are identical.

Software Provisioning Manager (SWPM)

• SWPM is a tool used to prepare the target SAP HANA system and ensure its compatibility with the migration process.
• It handles the tasks such as installing SAP HANA, configuring the system, and setting up the necessary environment.
• SWPM is responsible for ensuring the SAP HANA system is ready to receive the migrated data and applications.

Software Update Manager (SUM)

• SUM plays a crucial role in the classical migration process.
• It handles the actual migration of data, applications, and configurations from the source system (anyDB) to the target SAP HANA system.
• SUM ensures that data integrity is maintained during the migration and that all dependencies are resolved.
• It also manages the upgrade of SAP software components to the required version for SAP HANA compatibility.

In classical migration, these two tools, SWPM and SUM, work in tandem to ensure a successful and controlled migration process. Although this approach offers greater flexibility and customization options, it can be complex, involving manual decisions on table splitting. Typically, the expertise of certified consultants is required, particularly for productive migrations.

2) Database Migration Option (DMO) of SUM

• DMO is not a stand-alone tool; instead it is integrated into the Software Update Manager (SUM). This integration allows SUM to combine unicode conversion, upgrade, and migration into a single step, often referred to as the one-step migration procedure.

• DMO is the SAP recommended procedure for migrating to SAP HANA. It’s user-friendly process that does not require a certified consultant.

• This approach is particularly suitable when the source and target databases are not identical, making it ideal for heterogenous migrations.

• Additionally, all processes within DMO are automated, including the intelligently splitting of large tables.

Choosing between Classical Migration and DMO

As DMO is a use case of SUM, the obvious question arises: when to use SUM and when to use DMO of SUM?

• If the source system is already on an SAP HANA database: simply use SUM. (Homogenous Migration)
• If the source system is not on an SAP HANA database: opt for DMO of SUM  (Heterogenous Migration)

Features

1) DMO is an in-place migration, meaning that it upgrades and migrates the existing system instead of new installation.

2) Reduces overall business downtime by optimizing the migration process by carrying out certain steps concurrently.

3) Provides heterogenous database migration support, making it a versatile tool, that can be used in various scenarios.

4) Automatically detect and correct certain error that occur during the migration process, reducing the need for manual intervention.

5) Perform post-migration activities automatically, such as updating the SLD and configuring the system for optimal performance.

6) Supports migration from anyDB to not only SAP HANA but also SQL Server, SAP ASE, DB6, SAP MaxDB.

Benefits

1) Avoids landscape changes (SID, hostnames), and allows combination of all relevant steps for in-place migration to target database (Unicode Conversion, Update and Migration) in one tool.

2) Downtime optimized (scenario based).

3) DMO offers an added advantage of a quick and effortless reset function, as long as the source database maintains consistency throughout the entire process.

4) Only one downtime phase: Reduces business downtime (TCO), fewer regression tests  necessary.

5) Manual efforts & error-proneness reduced.

6) Source or original database is preserved and can be reactivated as a fallback, which reduces TCO and risk and also eliminates the need for a restore. This provides more time for testing before the final migration.

7) DMO is cost-effective solution for businesses looking to migrate their SAP systems to SAP HANA database, simplifying the migration process and minimize disruptions to the system landscape.

8) Lower prerequisites are required for both SAP and DB start releases, reducing effort (TCO) and potentially avoiding the need to update the source database.

Understanding DMO of SUM

Classical Migration Vs DMO

DMO Support Matrix

• ABAP stack only (Dual-stack split has to be done beforehand).

• For BW Systems
  • Start release: SAP BW 7.00 (or higher)
    • at least SP17 required for software component SAP_BASIS 700
    • at least SP02 required for software component SAP_BASIS 701
    • at least SP19 required for software component SAP_BW 700
    • at least SP02 required for software component SAP_BW 701
  • Target release: SAP BW 7.40 (or higher SP stacks)

• For SAP Business Suite Systems
  • Start release:
    • SAP R/3 rel 4.6c and 4.7
      • SAP R/3 release 4.6C requires SAP_BASIS support package level 62 or higher.
      • SAP R/3 release 4.7 is not supported.
    • SAP ECC 5.0
      • SAP ECC 5.0 systems need at least SP14 for SAP_BW 350, and additionally, in case that a unicode conversion is required, SP26 for software component SAP_BASIS 640.
    • SAP ERP 6.0 or higher (for example EHP1, EHP2, EHP3).
      • Systems based on SAP NetWeaver 7.0 (for example SAP ERP 6.0) need at least SP17 for software component SAP_BASIS and SP19 for software component SAP_BW.
    • Systems as part of SAP Business Suite 7 or higher (SAP ERP 6.0 EHP4, SAP CRM 7.0, SAP SRM 7.0, SAP SCM 7.0)
    • SAP BW 7.00 (or higher)
      • Systems based on SAP NetWeaver 7.0 at least SP17 for software component SAP_BASIS and SP19 for software component SAP_BW
  • Target release: System based on SAP NetWeaver 7.4

• Operating System and Platforms
  • The application server(s) must support the operating system for the target SAP release according to PAM.
  • Incorporate SAP Note 1951491 into the planning of your target database if you are targeting SAP NetWeaver 7.4 SP08 or higher.
  • If your source database is running on a Windows operating system and your target product version is based on SAP_BASIS 750, you must have MS Windows Server 2012 or a higher version.

• Target Database
  • DMO supports not only SAP HANA as target databases but also SAP ASE, SAP MaxDB, Microsoft SQL Server and DB6.
  • To successfully migrate anyDB source database to SAP HANA, you must have minimum of SAP HANA version 90 or higher.
  • If you want to run SAP Netweaver 7.5 ABAP on SAP HANA, then you need to have at least SAP HANA SPS09, revision 97. (Refer SAP Note 2158828).

DMO: How it Works?

Pre-Requisites

Here are some essential pre-requisite steps to follow before executing DMO for updating and migrating your SAP system to SAP HANA DB.

• Verify SAP Source Product Compatibility: SAP source product release should meets all target database requirements.
• Choose the Right Target Database: DMO supports migration to various target databases including SAP HANA, SQL Server, SAP ASE, IBM DB6. Make sure your chosen target database aligns with your migration goals.
• Setup a Download Directory: Create a dedicated download directory with sufficient diskspace. This directory will be used to store latest kernel patches required for the target database.
• Stack.xml: If you are planning to use DMO in conjunction with a system update, generate stack.xml from the maintenance planner. This step is crucial for proper planning and execution.
• Ensure Source Database Configuration: Verify your source database contains both application and productive repositories in the source release. This is essential for a successful migration.
• PAS Kernel: Ensure that the PAS (Primary application server, formerly known as Central Instance) has kernel version aligned with the source release.
• Separate Host for Target Database: Install the target database on a separate host. This separation helps in maintaining the integrity of your migration process.
• PAS Host: The Software Update Manager (SUM) should be installed on PAS host for efficient handling of migration.
• SAP Host Agent: Keep the SAP host agent on the PAS up-to-date. This update is necessary to facilitate seamless communication during the DMO process.
• Front-end Browser: Lastly, utilize a front-end browser as your user interface. This browser-based approach simplifies interaction and enhances user experience throughout the migration process.

By diligently addressing these pre-requisites, you will be well-prepared to embark on your DMO journey, ensuring a successful update and migration of your SAP system to SAP HANA DB.

Technical Approach

Step 1: Initiating the Process: Open a relevant SAP URL in web browser. This sends HTTP request to the SAP host agent. Once the required credentials is provided, the request is then forwarded to SAPup, which is executed on PAS host. (SAPup is a command line tool executed on PAS for performing upgrade process such as starting & stopping of SAP instances, modifying database tables, applying patches & updates).

Step 2: Phases of DMO: DMO process is segregated into “Uptime processing” and “Downtime processing”.

Step 3: Shadow System Setup: The processing sequence is centered on the functionality of SUM’s “shadow” system. A shadow system basically comprises of a shadow instance and shadow repository. A shadow instance is an additional replicated ABAP instance, that is created on the application server by SUM on the host where SUM was started. It is utilized to prepare steps that are executed during the downtime period.

Step 4: Shadow Repository: The shadow repository is available on target product version level. This implies that the shadow instance must utilize the target kernel to build the shadow repository, which could contain new object types.

Step 5: Copying to Target Repository: The shadow repository is then copied on to target database, using a tool R3load, which is part of kernel.

Step 6: Uptime Processing: Uptime processing means the SAP system is still running and end users can work productively with the system. During uptime processing, shadow repository (on new SAP release) is being set up (repository tables such as tenant, schema etc) and copied on target SAP HANA database.

Step 7: Downtime Migration: During downtime migration, application tables are migrated from the source database host to the target SAP HANA database host via R3load process. A pair of R3load enables parallel execution on the same host. The first R3load of shadow kernel exports the data, the second R3load of target kernel imports the data into SAP HANA database. As data is transferred via main memory of the host, no export files (dump files) are created. This option is referred as “memory pipes”,

Step 8: Kernel Switch: After migration of application data (including data conversion), SUM performs a kernel switch, from the SAP source system kernel to the SAP kernel for the target system. The update is completed, and the SAP system is operational and running on the target SAP HANA database.

Throughout the entire procedure, the source database remains unchanged. If for any reason you need to return to the source database, SUM provides a simple reset operation that restores the system’s status prior to shutdown (without the need for a manual database restoration). The SUM deletes the data from SAP HANA DB, restores the previous kernel, and removes the shadow repository.

R3load Methods: File Vs Socket Vs Pipe

Using SWPM: R3load with File Mode

The file mode R3load data transfer option is utilized using SWPM tool. In this, data is exported into a file and compressed before being transferred over the network.

Using SWPM: R3load with Socket Mode

The socket mode R3load option is utilized using SWPM tool. In this, data is exported and transferred over the network. So its important for customers to have a strong network bandwidth such as 10 Gbps. Memory requirements for socket mode is same as file mode.

Using DMO: R3load with Pipe Mode

 DMO allows both R3load processes to run on a single host (PAS) and communicate through the host’s main memory using the default “pipe” mode. However for Windows OS, DMO uses “file” mode as default mode.

Since both R3load processes are running on the same host, socket mode is not an option in DMO and not necessary. To use “file” mode instead of “pipe” mode for DMO, you must utilize the “clone/method” parameter.

FAQs on DMO of SUM