Scenario: You want to migrate your existing ABAP-based SAP system to SAP HANA DB or SAP ASE DB or MS SQL Server DB. You choose the in-place migration avoiding landscape changes (SID, host name, and so on), so you need an update of your SAP system. Classical migration is complex and requires several steps to be considered.
Solution: Use the database migration option (DMO) of the Software Update Manager.
Benefits:
Migration steps are simplified.
System update, Unicode conversion, and database migration are combined in one tool.
Business downtime is reduced.
Software Update Manager is used. Migrating your existing SAP system to the target database means switching the SAP system to a new database that is running on a new host.
Classical migration is the sequence of an SAP software update (using Software Update Manager) and heterogeneous system copy (using Software Provisioning Manager).
DMO simplifies the migration and is often referred to as the one-step procedure to the target database. Running an SAP system, for example, on an SAP HANA database requires a specific SAP software level. This means that the SAP system has to be updated before the migration takes place.
If the SAP system is updated, this may result in requirements for the database host software, especially the database software release. So, for some scenarios, the source database software has to be updated before the SAP system is updated.
As with the SAP HANA database, non-Unicode systems are no longer supported. So, the migration procedure may have to cover the Unicode conversion as well.
The following restrictions concerning Unicode exist:
- An SAP ECC system can be non-Unicode up to SAP_BASIS 740.
- Starting from SAP_BASIS 750, only Unicode is possible.
- When upgrading or converting an SAP system to SAP_BASIS 750 and above, the source SAP system must be Unicode already.
- It isn't possible to convert to Unicode as part of an upgrade or a conversion to SAP_BASIS 750 and above.
- Starting from SAP_BASIS 740, an SAP ECC system can run with an SAP HANA DB.
- An SAP system running with SAP HANA DB requires Unicode, even with SAP_BASIS 740.
With the DMO of the Software Update Manager, the procedure is simplified. SAP system update and database migration are combined in one tool, in one procedure. If necessary, the Unicode conversion may be included as well. For some source database types, it isn't required to update the source database software for the migration.
The preceding figures illustrate a process where the SAP application server is separate from the database host, which is referred to as a distributed installation. The DMO procedure works independently of the installation type. It can be used for a central installation, in which the database runs on the same host as the SAP application server.
DMO provides the following benefits:
A combined procedure only needs one maintenance phase (not two).
Reduced business downtime (TCO).
Fewer regression tests are necessary.
Stable application server and SAP system-ID due to in-place migration.
Low impact on the system landscape, as only the database server is new.
The source database is kept and can be reactivated as a fallback, reduces risk, no restore required.
More time for testing before cut over.
The following figures only show the Primary Application Server (PAS) – formerly known as Central Instance. The Software Update Manager has to be located on the PAS or an AAS host. The system is running, the existing kernel executables that are comprised in an instance (such as work processes) are running on the application server, based on the source release. The database consists of the application data and the repository (such as programs). The repository is abbreviated as PRD REP to emphasize that it's the productive repository, used by the system.
The DMO procedure is started from within a browser, sending an HTTP request to the SAP Host Agent, as shown after this.
The SAP Host Agent requests authorization from the browser, this user is used to start the Software Update Manager. As the DMO procedure only works on AS ABAP-based systems (for which the SAPup is the relevant Software Update Manager part), the SAPup is started.
After some basic configuration settings, such as checking the stack.XML, the SAPup will start to create the shadow system. The shadow system consists of a shadow repository and a shadow instance.
Since Software Update Manager 2.0 SP 08, the shadow repository is created on the target database: Shadow on Target (SOT). It contains the basic tables and some customizing tables, which will already be updated to the target release during uptime. The shadow repository doesn't influence the PRD repository. The system is still running, and users may work in the system and use functionality (like a transaction) that may change application data on the database.
Changes on the PRD repository are no longer allowed, as they wouldn't be considered on the shadow repository. This is why, in this phase, the system is running and available for users (uptime processing), but the development environment is locked.
The shadow instance is running on the PAS host, and is based on the shadow kernel. The shadow kernel is the kernel for the source database, but for the target release.
Now, the application tables must be migrated, so to prevent changes on the application tables, the system must be shut down. The downtime migration is executed, in which the target kernel is also used: it's the kernel for the new database (for example, SAP HANA DB) and for the target release.
For the migration of the application data, two R3load processes run in parallel. The first R3load of the shadow kernel exports the data from the source database. The second R3load process imports the data into the target database, for example, SAP HANA DB. Both R3load processes are running on the Software Update Manager host. The DMO configuration includes configuring the number of R3load pair processes to run in parallel.
After the migration of the application data, the shadow instance is removed. The target kernel is now used for the system, and the system is started. The system is still in downtime because it can't be used by users.
Now, the application tables are updated to the target release.
Finally, the DMO procedure is finished.
The system is now migrated to the target database, and updated to the target release.
R3load Modes
The DMO procedures use R3load for the migration, like the classical migration based on the Software Provisioning Manager (formerly known as SAPinst) does. For the typical classical migration, the R3load file mode is used.
The file mode means that the export files are created and imported later. Meanwhile, it's also possible to use a parallel export and import for the classical migration.
Another possibility for the classical migration is to use the R3load socket mode, which transfers the files using a socket connection.
With the DMO procedure, both R3load processes are executed on the same host, the PAS host. This allows the use of the R3load pipe mode that transfers the data using the main memory of the host. No files are created, and so no directory has to be prepared to host all export files.
In case the R3load stops, the SAPup will restart the process without the need of manual intervention of a user.
In this case, only temporary files are created. When a file has been processed by the R3load import process, the file is deleted.
Facts about Benchmarking
- Benchmarking is an option of Software Update Manager.
- It allows a quick migration test, skipping the update part of DMO.
- You execute it prior to the DMO run to test the migration rate, and adjust the number of R3loads.
- Options allow only exporting data, or migrating part of the database.
Benchmarking is an option of SAPup. It allows a quick migration test, skipping the update part of DMO. You execute it before the DMO run to test the migration rate, and adjust the number of R3loads. Options allow only exporting data or migrating part of the database. Benchmarking can't run parallel to DMO, so no SAPup must run when starting benchmarking.
Reset specifics for Benchmarking: the last step of benchmarking is to drop the tables from the target database. The Reset button allows you to quickly start with the next benchmarking run, reusing the previous parameters (they're set as default). The Cleanup button will instead delete the files (like logs) from the Software Update Manager folder, allowing a fresh start without previous settings.
Adjust the number of R3load processes. During the migration, monitor the performance of the Software Update Manager host on which SAPup is running. To make the best use of the host's performance, adjust the number of R3load processes.
Using table migration durations for the next run. SAPup stores the table migration durations in dedicated files. To speed up the migration, you can use these files for the next DMO run (on the same system) because SAPup first starts the migration for the tables with the longest runtime. It's more effective to sort the tables based on their migration duration than on their size.